Re: Comments on draft-nakibly-v6ops-tunnel-loops

[Gabi Nakibly <gnakibly@yahoo.com>]

Hi Fernando,
We shall include your proposed mitigation in the draft. 
See our response inline.

Fred & Gabi



----- Original Message ----
> From: Fernando Gont <fernando@gont.com.ar>
> To: Gabi Nakibly <gnakibly@yahoo.com>
> Cc: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>; fltemplin@acm.org
> Sent: Fri, August 27, 2010 10:58:03 AM
> Subject: Re: Comments on draft-nakibly-v6ops-tunnel-loops
> 
> Hi, Gabi,
> 
> Thanks so much for your response. Please find my comments inline....
> 
> >> a) "Attack #1: 6to4 Relay to ISATAP Router" discussed in [USENIX09]
> >> implies that an ISATAP router will receive an encapsulated IPv6 packet
> >> on its *external* interface, destined to an IPv6 address that does not
> >> belong to that site, but nevertheless forward it on the native IPv6 
network.
> >>
> >> The rule here should be simple: tunneled packets should only be received
> >> on the internal interface. Furthermore, ingress filtering should prevent
> >> processing a packet with an *internal* src addr that was received on an
> >> *external* interface.
> >>
> > 
> > We agree with your observation. However, please note that the ISATAP router 
>will
> > not always receive the attack packet (packet #0) on its external interface.
> > The packet may enter the inside network through a border router which is not 
>the
> > ISATAP router.  Let's take for example a network with two border routers. 
The
> > first border router is an ISATAP router that borders with a native IPv6 
>network
> > and a second border router that borders with an IPv4 network. The attack 
>packet
> > may enter the network through the second router and the ISATAP router may
> > receive it on its *internal* interface. The rule you propose can not 
mitigate
> > the attack in this case.
> 
> In this scenario, the second router should be doing ingress filtering.
> I'd argue that having such a scenario and not doing ingress filtering is
> opening the door to lots of trouble -- not just this only issue.
> 
> Nevertheless, it should be clarified in the I-D this possible scenario.
> Because for other scenarios, the check I've mentioned would solve this
> issue.
> 
> (Note, nevertheless, that ingress filtering on the second router, plus
> the check I've mentioned fix this potential problem, with no magic)
> 

We shall note this in the draft.

> 
> 
> > 
> >> b) "Attack #2: ISATAP Router to 6to4 Relay"
> >>
> >> This one implies that the ISATAP router will send a tunneled packet on
> >> its *external* interface. Being ISATAP an *Intra-site* tunneling
> >> protocol, this clearly shouldn't happen (but Fred Templin is certainly
> >> in a much better position than me to correct me if I'm wrong).
> >>
> >> Both in this case and in Attack #1 above, there should never be a case
> >> in which a packet is received on the external physical interface, and
> >> forwarded back on that external physical interface.
> > 
> > Similarly to the case we described above, the packet will indeed be forwarded 
>by
> > the ISATAP router over its internal interface, but the packet will find its 
>way
> > out through the second border router and loop will continue.
> 
> This scenario should be clearly explained, then. -- Even then, being a
> border router the ISATAP router probably knows the IP address block
> that's used within the site. Therefore, it should probably filter those
> packets that would need to be tunneled off-site.

An ISATAP router doesn't do that by default. We 
suggest similar measure to this  in the Neighbor Cache Check.

> 
> But, again: it should be made clear that you're thinking about a
> two-border-router scenario.
> 
> 
> 
> >> c) Attack #3: ISATAP Router to ISATAP Router
> >>
> >> Same as above.
> >>
> > 
> > Same as above.
> 
> Same as above. :-)
> 
> 
> 
> >> d) "Attack #4: Teredo Client to NAT"
> >>
> >> This not only implies that a Teredo client will accept packets on its
> >> Teredo interface, but also that it will forward them. Both behaviors
> >> seem to be ill-advised (despite the fact that Windows allegedly
> >> implements them).
> >>
> >> The countermeasure here is straightforward: drop packets received on the
> >> Teredo interface that are not received to your nodes. Never forward
> >> packets on the Teredo interface that have not originated in your own node.
> >>
> >> e) "E. Attack #5: Teredo Server"
> >>
> >> This one is probably trickier. Although one should probably argue that
> >> packets received on a physical interface for a unicast address, with a
> >> src addr that belongs to the host should be dropped. (such packets would
> >> typically be forwarded internally).
> >
> > 
> > Regarding the last two Teredo attacks, please note that the draft does NOT
> > address them. The nature of these two attacks are different from the 
previous
> > ones, hence to make the draft more coherent and simple it only addresses
> > protocol-41 tunnel-based loops.
> > As to the countermeasure you proposed for attack #4, I think that it may not 
>be
> > suitable for Teredo clients that do need to forward packets.
> 
> Are there any of these available? For instance, does RFC 4380 support
> this? - I don't think that's the case (of the top of my head, though)
>

RFC 4380's definition of a Teredo Client:

   "A node that has some access to the IPv4 Internet and wants to gain
   access to the IPv6 Internet."

A node is a host or a router. From this we deduce that the RFC does not 
exclude forwarding on a Teredo client.
 
> 
> > For example, a
> > router that serves as a gateway to an internal IPv6 network while the 
>router's
> > external IPv6 connectivity is achieved via Teredo. 
> 
> This setup would be really broken. If there's an IPv6 island, then the
> border router of that island should be doing 6to4, or a configured
> tunnel or the like.
>

Unless the IPv6 island is behind a NAT.
 
> 
> 
> > However, we do agree that a
> > simple countermeasure similar to the one you proposed can be devised.
> > But, again, this is not related to the draft. If the list feels that these 
> > attacks should be addressed, suitable updates to Teredo can be proposed. If 
>yes, 
>
> > I welcome any comments.
> 
> IMHO, if you mention the attack, you should probably point a possible
> way to fix this. -- although I understand that in this particular case
> this would be more in the scope of 6man than v6ops.
>

Please note that although the draft references [USENIX09] 
it does not mention the Teredo attacks.
 
> 
> 
> >> **** 5) Section 2, first para:
> >> "  In this section we shall denote an IPv6 address of a node reached via
> >>  a given tunnel by the prefix of the tunnel and the IPv4 address of
> >>  the node, i.e., Addr(Prefix, IPv4)."
> >>
> >> This seems misleading. the IPv4 address (IPv4) corresponds to the tunnel
> >> end-point, and not to the node that is reachable by the given tunnel.
> > 
> > Good point, but to be more precise the IPv4 address corresponds to an 
> > (IPv4) interface associated with the tunnel endpoint. The tunnel endpoint 
> > may associate multiple such interfaces with the tunnel endpoint, however, 
> > so the proposed resolution is to change "the IPv4 address" to "an IPv4 
>address".
> > We will change this to make it clearer.
> 
> Looking at the text again, I realize that I looked confusion to me in
> this aspect: "node reached via a given tunnel" sounded to me more like
> e.g. a  node in a network that was accessed through a tunnel (this
> "node" was different from the node/router that was the tunnel endpoint)
> -- hence the confusion.
> 
> Again, a network diagram would be helpful here.
> 
> 
> > 
> >> **** 7) Section 2 (nit):
> >> "  The source address of the packet is a T1
> >>  address with Prf1 as the prefix and IP2 as the embedded IPv4 address,
> >>  i.e., Addr(Prf1, IP2)."
> >>
> >> While I do understand what you're talking about, this is the first time
> >> you mention that of "embedded address". Therefore, that of "embedded
> >> addresses" should be clarified/explained.
> >>
> > 
> > OK. By way of clarification, the third sentence of Section 1 will be changed 
>to 
>
> > the following:
> > 
> >  "Automatic tunnels form a category of tunnels in which a
> >  packet's egress node's IPv4 address is embedded within the
> >  destination IPv6 address of the packet."
> 
> Great.
> 
> 
> 
> >> **** 9) Section 3.1 (meta-comment):
> >>
> >> See the "counter-measures" I suggested when discussing each of the
> >> attack vectors above. They seem to be simpler than the ones you're
> >> proposing here....
> > 
> > Yes, but only if it can be operationally assured that the case we described 
> > above is avoided. 
> > 
> > We will add these countermeasures in the draft with this reservation.
> 
> Ok.
> 
> 
> 
> >> **** 11) Section 3.2.1
> >>
> >> This section talks about the "Neighbor Cache Check". Does such a thing
> >> necessarily exist for, e.g., ISATAP?
> >>
> >> I guess that in the case of Teredo, you're really talking about the
> >> "List of recent Teredo peers"?
> > 
> > As mentioned above, Teredo is not addressed by the draft.
> 
> What about ISATAP?

Sorry, due to an oversight the response for the ISATAP case was not 
included in our last email. Here it is:
RFC4861 discusses the neighbor cache wrt all
IPv6 interfaces, but by implication a router may omit the neighbor
cache in order to reduce state. Section 8.4 of RFC5214 says:

 "After address resolution, ISATAP hosts SHOULD perform an initial
  reachability confirmation by sending Neighbor Solicitation messages
  and receiving a Neighbor Advertisement message.  ISATAP routers MAY
  perform this initial reachability confirmation, but this might not
  scale in all environments."

This calls for the ISATAP router to maintain at least a minimal
neighbor cache if it elects to perform initial reachability
confirmations, so there is at least one published case in which
an ISATAP router is implicitly required to maintain a neighbor
cache. Section 3.2.1 simply describes a second case in which an
ISATAP router is implicitly required to maintain a neighbor cache;
hence, there does not seem to be a need to mention this explicitly
in this document.

> 
> Thanks!
> 
> Kind regards,
> -- 
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
> 
> 
>