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

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

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