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.