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

[Gabi Nakibly <[e-mail]>]

Hi Fernando,
Thanks for your valuable input. Please see our response inline.

Fred & Gabi



----- Original Message ----
> From: Fernando Gont <[e-mail]>
> To: "[e-mail]" <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Sent: Mon, August 23, 2010 6:19:56 AM
> Subject: Comments on draft-nakibly-v6ops-tunnel-loops
> 
> Hi Gabi & Fred,
> 
> Some comments/questions on/about the aforementioned I-D:
> 
> **** 1) Page 3. The I-D states:
> 
> " Ref. [USENIX09] pointed out the existence of a
>   vulnerability in the design of IPv6 automatic tunnels."
> 
> I've read the aforementioned reference ([USENIX09]), and while it is an
> interesting read, it seems misleading in some aspects. First of all, I'd
> argue that the vulnerabilities that it discusses may be real, they do
> not really have to do with "vulnerabilities in the design of IPv6
> automatic tunnels". I'd argue that they have to do either with poor
> operations practices, or with dumb implementation practices (although
> possibly still IETF-spec-compliant).
> 
> Please let me exemplify (these a)-e) comments are really about the
> Nakibly & Arov paper, but clearly related to this I-D) :
> 
> 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.

> 
> 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.
 
> 
> c) Attack #3: ISATAP Router to ISATAP Router
> 
> 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. 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. 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.

> **** 2) Section 1:
>   "This assumption poses a
>   security vulnerability since it may result in an inconsistency
>   between a tunnel's overlay IPv6 routing state and the native IPv6
>   routing state there by allowing a routing loop to be formed."
> 
> I'm not sure this terminology is clear. i.e., overlay IPv6 routing state
> vs. native IPv6 routing state.
>

The text will be revised to make this clearer.
 
> 
> **** 3) Section 1 (nit):
>   "The loop terminates only when
>   the Hop Limit field in the IPv6 header of the packet is zeroed out."
> 
> s/zeroed out/is decremented to zero/  (sounds better to me)
> 

Yes, this change will be made.

> 
> **** 4) Section 1 (nit):
> "SP network"
> 
> s/SP/Service Provider (SP)/
> 

We will change this.

> 
> **** 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.

> 
> **** 6) Section 2, page 4 (nit):
> 
> "....  they are either both public or both private and belong to the
> same internal network."
> 
> It might make snse to insert a comma between "public" and "or".
> 

Yes, this change will be made.

> 
> **** 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."

> 
> **** 8) Section 2, Figure 1:
> 
> It would be of much help to have a network diagram. I read this document
> before reading [USENIX09], and needed to draw a network diagram myself
> to better understand the issues you're discussing. Providing such a
> diagram in the I-D would be a plus. (native IPv6 network, IPv4 network
> over which packets are tunneled, etc.)
>

OK. The next version will provide a network diagram.
 
> 
> **** 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.

> 
> **** 10) Sections 3.1/3.1.1
> 
> It's not clear to me if the advice in Section 3.1 is supposed to be
> different from that in Section 3.1.1. Is Section 3.1.1. simply being
> more detailed than Section 3.1?
> 

The final two paragraphs of Section 3.1
describe a sub-case that must be addressed in more detail and
provide a lead-in to Section 3.1.1 which provides the details.
Hence, we would prefer to retain the existing text and section
organization.

> 
> **** 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.
 
> 
> Thanks!

Thank you.

> 
> Kind regards,
> -- 
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
>