[BEHAVE] [NAT64] Hairpinning loop
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[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.)
Does this make sense?
Simon
--
DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
vCard 4.0 --> http://www.vcarddav.org
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.