[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-nakibly-v6ops-tunnel-loops
We shall include your proposed mitigation in the draft.
See our response inline.
Fred & Gabi
----- Original Message ----
> From: Fernando Gont <email@example.com>
> To: Gabi Nakibly <firstname.lastname@example.org>
> Cc: "email@example.com" <firstname.lastname@example.org>; email@example.com
> 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
> >> 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
> > 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
> > ISATAP router. Let's take for example a network with two border routers.
> > first border router is an ISATAP router that borders with a native IPv6
> > and a second border router that borders with an IPv4 network. The attack
> > 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
> > 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
> (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
> > the ISATAP router over its internal interface, but the packet will find its
> > 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
> > 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
> > 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
> > 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
> > 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
> > 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
> > 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."
> >> **** 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.
> >> **** 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.
> Kind regards,
> Fernando Gont
> e-mail: firstname.lastname@example.org || email@example.com
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1