Subject: Re: draft-nakibly-v6ops-tunnel-loops review

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Jul 2010 15:25:17 +1200

On 2010-07-16 02:48, Fred Baker wrote:
> Could I interest you in doing a thorough review of draft-nakibly-v6ops-tunnel-loops and commenting to v6ops?\

Summary
-------

This draft proposes mitigation techniques for malicious loops formed
using a mixture of automatic IPv6-in-IPv4 tunnel mechanisms.

The draft doesn't recommend a choice of technique. I think that for the
work to go forward, the WG would need to agree on a recommendation.
Otherwise, the world will shrug its shoulders.

Details
-------

Several IPv6 transition aids rely on automatic tunneling of IPv6 in
IPv4. If an attacker succeeds in making two such methods link up
with each other head-to-tail, a loop will form, and will consume all
available resources. With manually configured tunnels, such a loop
will be excluded by construction, but with automatic tunnels, an attacker
can (under certain conditions) create a packet that a tunnel egress
will feed back into regular IPv6 routing such that it ends up back
in the tunnel again, until its hop limit expires.

Section 2 describes the attack scenario. I find the terminology
rather confusing:

1. For each tunnel, there is an object called "the tunnel router".
I assume this is supposed to be the encapsulating ingress router.
But it isn't stated clearly.

2. Tunnels have egress decapsulators. Their role is not described
very clearly, but is assumed to be understood.

3. There's a reference to destination hosts being "in" the tunnel.
("The attack is ... initiated by sending an
   IPv6 packet (packet 0 in Figure 1) destined to an end point in T2...")

But hosts aren't in tunnels. They are outside the tunnel, beyond the
egress router. [OK, some hosts do their own decapsulation, but then one
can separate their decapsulator from their IPv6 stack, and anyway such
hosts are not routers and will not forward packets back into the network.]

So does this mean  "destined to a fictitious end point that appears
to be reached via T2"?

There's a similar problem in the very first sentence of section 2:

" In this section we shall denote an IPv6 address of a tunnel's node by
   the prefix of the tunnel and the IPv4 address of the node, i.e.,
   Addr(Prefix, IPv4). "

Does that mean

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

4. The description in section 2 then states that a packet to IPv6 address
(Prf2, IP1) is encapsulated in tunnel T2 and delivered to router R1 as the
tunnel egress, but that R1 erroneously treats it as if it came from tunnel T1.
It isn't made very clear that this happens *because* the whole of the IPv4
Internet acts as a shared link layer as far as these automatic tunneling
techniques are concerned. Therefore, R1 can only rely on the (dubious)
addresses in the packet headers to figure out what to do next, and what it
does is send the packet back to R2, because that's what the IPv6 prefix tells
it to do.

As far as I can see, the return packet from R1 to R2 could be sent by
native IPv6 if such connectivity exists, but is more likely to be sent
via tunnel T1, which is what R1 probably uses to provide global v6 access.
The draft should make this point clear, anyway.

Section 3 of the draft describes three possible mitigation strategies.

1. Checking the embedded IPv4 addresses explicitly in the tunnel end points.
This is fairly straightforward and would fix the problem in most cases, but
creates some overhead. Configuration would be needed to deal with 6rd
and with RFC1918-based tunnels.

2. Checking that the end point exists, by various techniques. I am more
pessimistic about these options than the author seems to be.

3. Use different protocol numbers for different tunnel types. This would
be hard to deploy - in fact I think it's hopeless, since backwards
compatibility with proto 41 would have to be kept.

By the way, is it sufficient if either R1 or R2 makes the checks?

   Brian Carpenter

---

From: Fred Baker <[email-masked]>
Date: Tue, 20 Jul 2010 08:05:36 -0700

Thanks much for the review. Looks like it at least needs an update before being finalized.

Question for you. Would you consider an updated version of the document ready for WGLC, or do we need further discussion on it? Apart from the beauty of the prose, are the notions proposed sound?

> By the way, is it sufficient if either R1 or R2 makes the checks?

http://www.ipinc.net/IPv4.GIF

---

From: Fred Baker <[email-masked]>
Date: Tue, 20 Jul 2010 10:41:52 -0700

On Jul 19, 2010, at 8:25 PM, Brian E Carpenter wrote:
> The draft doesn't recommend a choice of technique. I think that for the work to go forward, the WG would need to agree on a recommendation. Otherwise, the world will shrug its shoulders.

Following up on Brian's excellent review. Let's discuss this. In view of draft-arkko-ipv6-transition-guidelines and draft-ietf-v6ops-tunnel-security-concerns, do we need this draft? Should we prefer it to one of the others? Is there something specific we would like this document to recommend?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Jul 2010 15:25:17 +1200

Summary
-------

Details
-------

Does that mean

   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Jul 2010 15:52:44 +1200

> Following up on Brian's excellent review. Let's discuss this. In view of draft-arkko-ipv6-transition-guidelines and draft-ietf-v6ops-tunnel-security-concerns, do we need this draft? Should we prefe…

The word 'loop' does not occur in draft-ietf-v6ops-tunnel-security-concerns, from
which I deduce that draft-nakibly covers a disjoint problem space. I suppose
in theory the two documents could be merged, but from a practical viewpoint
it seems better to keep them separate.

Also, I think draft-nakibly is too specific to consider it as really
intersecting with draft-arkko. Whatever models we recommend in draft-arkko,
some people will be running automatic tunnels for years, so the exposure
to loops will exist. Actually it seems that the Security Considerations
in draft-arkko should perhaps refer to draft-ietf-v6ops-tunnel-security-concerns
and to draft-nakibly.

My $0.02

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Jul 2010 15:57:48 +1200

Fred,

IMHO this is indeed sound work. As I said, even if it's to be informational,
I think there should be some sort of choice made among the solutions, or
at least a summary of the pros and cons. So I think we need progress on
that before a WGLC.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Jul 2010 15:25:17 +1200

Summary
-------

Details
-------

Does that mean

   Brian Carpenter

---

From: Gabi Nakibly <[email-masked]>
Date: Wed, 21 Jul 2010 08:37:48 -0700 (PDT)

Brian,
Thanks for the thorough review. I agree that a summary of the pros and cons of 
the solutions is in order.  Nonetheless, I believe that making a clear choice 
among the solutions may be hard to do since in different situations different 
solutions may preferable. 

Gabi

----- Original Message ----
> From: Brian E Carpenter <[email-masked]>
> To: Fred Baker <[email-masked]>
> Cc: IPv6 Operations <[email-masked]>
> Sent: Wed, July 21, 2010 5:57:48 AM
> Subject: Re: draft-nakibly-v6ops-tunnel-loops review
> 
> Fred,
> 
> > Question for you. Would you consider an updated version of the document ready 
>for WGLC, or do we need further discussion on it? Apart from the beauty of the 
>prose, are the notions proposed sound?
> > 
> >>> Could I interest you in doing a thorough review of 
>draft-nakibly-v6ops-tunnel-loops and commenting to v6ops?\
> >> Summary
> >> -------
> >>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 Jul 2010 13:21:36 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Gabi Nakibly
> Sent: Wednesday, July 21, 2010 8:38 AM
> To: Brian E Carpenter; Fred Baker
> Cc: IPv6 Operations

I believe the situation for ISATAP router can be handled
best by the Section 3.2.3 Neighbor Reachability Check. I
believe it should be the recommended solution for ISATAP,
and we should just come right out and say this.

Fred
[email-masked]