Re: [BEHAVE] [NAT64] Hairpinning loop
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BEHAVE] [NAT64] Hairpinning loop



 

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


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.