Re: [BEHAVE] [NAT64] Hairpinning loop

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

On 2009-11-06 13:27, Dan Wing wrote:
>  
> 
>> -----Original Message-----
>> From: behave-bounces at ietf.org 
>> [mailto:behave-bounces at ietf.org] On Behalf Of Simon Perreault
>> Sent: Thursday, November 05, 2009 1:28 PM
>> To: Behave WG
>> Subject: [BEHAVE] [NAT64] Hairpinning loop
>>
>> Hello,
>>
>> In draft-ietf-behave-v6v4-xlate-stateful-02, Section 6 contains the
>> following text:
>>
>>    TBD: Is there such a thing as a hairpin loop (likely not naturally,
>>    but perhaps through a special-crafted attack packet with a spoofed
>>    source address)?  If so, need to drop packets that hairpin 
>> more than
>>    once.
>>
>> I believe that the answer is yes.

On reading section 6 a few times, I couldn't figure out a case where
sending a hairpin packet would actually have any value to a user.
There will always be another way of reaching the intended destination
with a native IPv6 address.

So unless this is wrong, why not just say that all hairpin packets
MUST be discarded?

  Brian
>>
>> If the IPv6-only client can guess the IPv4 binding address 
>> that will be
>> created, it can use the IPv6 representation of it as source 
>> address for
>> creating this binding. Then any packet sent to the binding's IPv4
>> address will loop in the NAT64.
>>
>>
>> Example:
>>
>> IPv4 pool => 192.0.2.0/24
>>
>> IPv6-only client sends this to NAT64:
>>
>> Source: [Pref64::192.0.2.1]:500
>> Destination: whatever
>>
>> The NAT64 allocates 192.0.2.1:500 as IPv4 binding address.
>>
>> Now anything sent to 192.0.2.1:500, be it a hairpinned IPv6 
>> packet or an
>> IPv4 packet, will loop.
>>
>>
>> How hard is it to guess? Easy. First you create a binding and use e.g.
>> STUN to know your external IPv4. New bindings will always have this
>> address. Then you use a source port in the range 1-1023. This will
>> increase your chances to 1/512 (since range and parity must be
>> preserved). Many NAT44 implementations today will go further and
>> allocate the same source port if it is available.
>>
>>
>> Easy fix: Drop IPv6 packets whose source address is in Pref64::/n. (Is
>> this mentioned somewhere already? I couldn't find anything having this
>> effect.)
> 
> Yes, that mitigation is described in
> http://tools.ietf.org/html/draft-ietf-behave-address-format-01#section-4.1
> 
> However, the security considerations section does not mention the
> attack you are describing; it probably should.  I CC'd the authors.
> 
>> Does this make sense?
> 
> Yes.
> 
> -d
> 
>> Simon
>> -- 
>> DNS64 open-source   --> http://ecdysis.viagenie.ca
>> STUN/TURN server    --> http://numb.viagenie.ca
>> vCard 4.0           --> http://www.vcarddav.org
>> _______________________________________________
>> Behave mailing list
>> Behave at ietf.org
>> https://www.ietf.org/mailman/listinfo/behave
> 
> _______________________________________________
> Behave mailing list
> Behave at ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>