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

[Gabi Nakibly <gnakibly@yahoo.com>]

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 <brian.e.carpenter@gmail.com>
> To: Fred Baker <fred@cisco.com>
> Cc: IPv6 Operations <v6ops@ops.ietf.org>
> Sent: Wed, July 21, 2010 5:57:48 AM
> Subject: Re: draft-nakibly-v6ops-tunnel-loops review
> 
> 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
> 
> On 2010-07-21 03:05, Fred Baker wrote:
> > 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?
> > 
> > On Jul 19, 2010, at 8:25 PM, Brian E Carpenter wrote:
> > 
> >> 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
> > 
> > http://www.ipinc.net/IPv4.GIF
> > 
> > 
> 
>