[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on draft-nakibly-v6ops-tunnel-loops
Hi Fernando,
Gabi and I talked about this; please see our responses below:
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fernando Gont
> Sent: Tuesday, August 31, 2010 9:37 PM
> To: Gabi Nakibly
> Cc: v6ops@ops.ietf.org; fltemplin@acm.org
> Subject: Re: Comments on draft-nakibly-v6ops-tunnel-loops
>
> Hi, Gabi,
>
> Please find my comments inline...
>
> >>>> 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.
>
> One would expect the ISATAP router to omplement some kind of access
> control that determines who can make use of the ISATAP service. In the
> abscense of "strong" authentication, one would expect that ISATAP router
> to implement IP_address-based "authentication". -- One might argue that
> it's an implementation detail that is simply not addresses in the ISATAP
> spec (in the same way that the spec does not specify how ISATAP hosts
> discover the ISATAP router in the first place...)
OK.
> >>>> 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.
>
> Forwarding IPv6 packets would mean that the check of the source IPv4
> address of the outer packet wrt the embedded IPv4 addresses in the
> source IPv6 address would fail.
You are right. In light of this, it seems that forwarding
packets by a Teredo client is operationally unnecessary.
Point taken.
> Also, Teredo is supposed to be "last resort". so it seems unlikely that
> a router is connected to a network that provides IPv6 connectivity to
> the hosts connected to that network, but not to the router.
>
> Finally, forwarding packets over the Teredo tunnel would not work if RPF
> is deployed.
>
>
>
> >>> 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.
>
> See above. Nevertheless, Teredo provides connectivity for hosts, not for
> networks.
>
>
> >>> 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.
>
> You're right -- my fault.
>
>
>
>
> >>>> **** 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.
>
> In this case the NC would contain the corresponding IPv4 addresses, and
> reachable state, or what?
This is implementer's choice - see Section 5 of RFC4861:
"This section describes a conceptual model of one possible data
structure organization that hosts (and, to some extent, routers) will
maintain in interacting with neighboring nodes. The described
organization is provided to facilitate the explanation of how the
Neighbor Discovery protocol should behave. This document does not
mandate that implementations adhere to this model as long as their
external behavior is consistent with that described in this document."
Thanks - Fred
fred.l.templin@boeing.com
> 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
>
>
>
>