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

From: Fernando Gont <[email-masked]>
Date: Mon, 23 Aug 2010 00:19:56 -0300

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.

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.

c) Attack #3: ISATAP Router to ISATAP Router

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

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

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

**** 4) Section 1 (nit):
"SP network"

s/SP/Service Provider (SP)/

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

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

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

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

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

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

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

Thanks!

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

---

From: Gabi Nakibly <[email-masked]>
Date: Tue, 24 Aug 2010 13:13:13 -0700 (PDT)

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

Fred & Gabi

----- Original Message ----
> From: Fernando Gont <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Sent: Mon, August 23, 2010 6:19:56 AM
> Subject: Comments on draft-nakibly-v6ops-tunnel-loops
> 
> Hi Gabi & Fred,
> 

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.

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

Same as above.

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

> vs. native IPv6 routing state.

The text will be revised to make this clearer.
 
> s/zeroed out/is decremented to zero/  (sounds better to me)

Yes, this change will be made.

> s/SP/Service Provider (SP)/

We will change this.

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

> It might make snse to insert a comma between "public" and "or".

Yes, this change will be made.

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

> over which packets are tunneled, etc.)

OK. The next version will provide a network diagram.
 
> attack vectors above. They seem to be simpler than the ones you're

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.

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

> "List of recent Teredo peers"?

As mentioned above, Teredo is not addressed by the draft.
 
> Thanks!

Thank you.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 27 Aug 2010 04:58:03 -0300

Hi, Gabi,

Thanks so much for your response. Please find my comments inline....

> receive it on its *internal* interface. The rule you propose can not mitigate

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)

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

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. :-)

> 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)

> For example, a
> 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.

> However, we do agree that a
> 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.

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

>   destination IPv6 address of the packet."

Great.

> We will add these countermeasures in the draft with this reservation.

Ok.

> As mentioned above, Teredo is not addressed by the draft.

What about ISATAP?

Thanks!

Kind regards,

---

From: Gabi Nakibly <[email-masked]>
Date: Tue, 31 Aug 2010 12:47:29 -0700 (PDT)

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

Fred & Gabi

----- Original Message ----
> To: Gabi Nakibly <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; [email-masked]
> Sent: Fri, August 27, 2010 10:58:03 AM
> Subject: Re: Comments on draft-nakibly-v6ops-tunnel-loops
> 
> Hi, Gabi,
> 

We shall note this in the draft.

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

> 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.
 
> border router of that island should be doing 6to4, or a configured

Unless the IPv6 island is behind a NAT.
 
> 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.
 
> > As mentioned above, Teredo is not addressed by the draft.

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.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 01 Sep 2010 01:36:49 -0300

Hi, Gabi,

Please find my comments inline...

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

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

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.

> Unless the IPv6 island is behind a NAT.

See above. Nevertheless, Teredo provides connectivity for hosts, not for
networks.

> it does not mention the Teredo attacks.

You're right -- my fault.

> cache. 

In this case the NC would contain the corresponding IPv4 addresses, and
 reachable state, or what?

Thanks!

Kind regards,