Subject: [BEHAVE] [NAT64] Hairpinning loop

From: Simon Perreault <[email-masked]>
Date: Fri, 06 Nov 2009 05:27:37 +0800

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

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 Nov 2009 16:27:38 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: Thursday, November 05, 2009 1:28 PM
> To: Behave WG
> Subject: [BEHAVE] [NAT64] Hairpinning loop
> 
> Hello,
> 

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

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Nov 2009 10:28:37 +1300

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

---

From: Simon Perreault <[email-masked]>
Date: Sat, 07 Nov 2009 21:56:09 +0900

> with a native IPv6 address.

RFC 4787 section 6, RFC 5382 section 7.2, and RFC 5508 section 5 address
this for the IPv4-IPv4 case.

Does this still apply for IPv6-IPv4?

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 8 Nov 2009 07:08:16 +0900

> Sent: Saturday, November 07, 2009 9:56 PM
> To: Brian E Carpenter
> Cc: [email-masked]; 'Behave 
> WG'; Dan Wing
> Subject: Re: [BEHAVE] [NAT64] Hairpinning loop
> 
> Brian E Carpenter wrote:

Yeah, I might only know my peer's IPv4 address, because my application
only refers IPv4 addresses.  An application might do that to maintain
compatibility with IPv4-only hosts (which can only understand IPv4
addresses).  I discuss this situation in
draft-wing-behave-nat64-referrals-01.txt
for a couple of protocols.

We might imagine that applications would refer IPv6 (when available)
and also IPv4.  That works, but it's possible to get referred through
an IPv4-only node, which would remove the IPv6 address (a case where
referring from A to B to C, where "B" is IPv4-only and the others
are trying to do the right thing and refer both IPv6 and IPv4.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Nov 2009 12:09:55 +1300

> Does this still apply for IPv6-IPv4?

I abstained from IPv4-IPv4 NAT discussions years ago, so I'm not
familiar with those scenarios. However, since the normal mode for
IPv6 is multiple addresses per host, I would suggest that any
communication that occurs between IPv6 hosts behind the same NAT64
SHOULD occur using some other form of address, so it is perfectly
OK to specify that hairpin packets SHOULD be dropped. It is not
the same as IPv4.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Nov 2009 12:20:35 +1300

Commenting on my own comment...

> OK to specify that hairpin packets SHOULD be dropped. It is not

I should have read Dan's message first. OK, if a via-IPv4 referral
has taken place, the host generating the hairpin packet might
have no choice (but see the GROBJ BOF). But since we have a looping
issue, I would modify what I just wrote to "hairpin packets MAY
be dropped" so that an implementor has the freedom to choose.

   Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 20 Nov 2009 10:50:46 +0100

I have added:

in section Filtering and Updating Binding and Session Information

        <t>Irrespectively of the transport protocol used, the NAT64 must 
silently discard
            all incoming IPv6 packets containing a source address that 
contains the Pref64::/n.
            This is required in order to prevent hairpinning loops as 
described in the Security
            Considerations section. </t>

I have also used part of your text to describe the problem in the 
security section, i hope you are ok with this.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 20 Nov 2009 10:53:37 +0100

> be dropped" so that an implementor has the freedom to choose.
mmm, afaiu, if we filter incoming packet containing Pref64::/n in the 
source address, then we don't have a loop problem.
And in the nat64 context, there is no reason to receive a packet with 
the Pref64 in the soruce address afaict... am i missing something?

Regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 20 Nov 2009 08:59:53 -0800

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Friday, November 20, 2009 1:54 AM
> To: Brian E Carpenter
> Cc: Simon Perreault; Dan Wing; 'Behave WG'; 
> [email-masked]

I guess you're thinking 'loop problem' is avoidable by dropping
packets?  My worry is that if we drop packets like that, we could
break an application that has no other means to contact its intended
peer.  For example, an application that only knows one IP address for
its peer, and that IP address is on the 'far' side of the same
translator that both of them are using.

> the Pref64 in the soruce address afaict... am i missing something?

If by 'nat64' you mean 'stateful nat64', sure, you won't receive
packets with source addresses matching the stateful nat64's prefix.

-d

---

From: Simon Perreault <[email-masked]>
Date: Fri, 20 Nov 2009 12:06:01 -0500

> translator that both of them are using.

I don't understand what you're saying. We drop packets using Pref64::/n as
source. The IP address on the far side will be an IPv4 address, which one can
express using an IPv6 address in Pref64::/n, but that will be the destination,
not the source.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 20 Nov 2009 09:19:41 -0800

> From: Simon Perreault [mailto:[email-masked]] 
> Sent: Friday, November 20, 2009 9:06 AM
> To: Dan Wing
> Cc: 'marcelo bagnulo braun'; 'Brian E Carpenter'; 'Behave 
> WG'; [email-masked]
> I don't understand what you're saying. We drop packets using 
> Pref64::/n as source.

For stateful, yes, that makes sense.

For stateless, I had understood the prefix of the translator
and the prefix of the hosts is the same, per the last sentence I
am quoting from
http://tools.ietf.org/html/draft-ietf-behave-address-format-01#section-3.3

   Organizations deploying stateless translation SHOULD assign a Network
   Specific Prefix to their translation service.  Both "IPv4
   translatable" and "IPv4 Embedded" MUST be constructed as specified in
   section 2.  "IPv4 translatable" addresses MUST use the selected
   Network Specific Prefix.  Both types of addresses SHOULD use the same
   prefix. 

-d

> The IP address on the far side will be an IPv4 
> address, which one can

---

From: Xing Li <[email-masked]>
Date: Sat, 21 Nov 2009 14:44:47 +0800

Dan Wing 写道:
>>>> mmm, afaiu, if we filter incoming packet containing 
>>>>         
>> Pref64::/n in the 
>>     
>>> peer.  For example, an application that only knows one IP 
>>>       
>> address for
>>     

Yes. If both types of addresses (IPv4-translatable and IPv4-converted) 
use the same prefix, then the hairpin function is NOT required.

xing

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 21 Nov 2009 14:49:29 -0800

> [mailto:[email-masked]] On Behalf Of Xing Li
> Sent: Friday, November 20, 2009 10:45 PM
> To: Dan Wing
> Cc: [email-masked]; 'Behave WG'

I disagree.

The peer's IPv6 address could have been originally communicated
in SIP, XMPP, or whatever, but could have been discarded by an
IPv4-only SIP proxy, IPv4-only SBC, IPv4-only SIP endpoint, 
IPv4-only XMPP endpoint, or whatever.  And when the IPv6-only
endpoint finally receives the referral, it contains only an
IPv4 address.

Thus, the IPv6 host will only know its peer's IPv4 address -- 
and does not know its IPv4 address.  Because it doesn't know
of the IPv6 host's address, the packet has to be sent to the
translator, and the translator needs to hairpin the packet.

If we constrain the problem by declaring something like "IPv4
applications should not be discard IPv6 addresses", then I 
agree we don't need hairpinning in the translator.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 21 Nov 2009 17:49:37 -0800

> [mailto:[email-masked]] On Behalf Of Dan Wing
> Sent: Saturday, November 21, 2009 2:49 PM
> To: 'Xing Li'

Or is it, maybe, that when the peer's IPv6 prefix and the translator's IPv6
prefix are the same, the peer's IPv4 representation is the same as the
translator's.  I think that must be the situation.  This should be better
described in the address-format document; instead of just a SHOULD, describe
that it causes normal IPv6 packet routing to allow two IPv6 hosts to
communicate directly without going through the translator, because each IPv6
host (behind the translator) are effectively doing the same function as the
translator (namely, putting the translator's IPv6 prefix [which is also the
IPv4 peer's IPv6 prefix] in front of the IPv4 address [using
wing-behave-learn-prefix and a translator-aware application, or using DNS64]).

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 22 Nov 2009 09:11:39 +0100

Dan Wing escribió:
>>>>>> packets?  My worry is that if we drop packets like 
>>>>>>             
>> that, we could
>>     
>>>>>> break an application that has no other means to contact 
>>>>>>             
>>> its intended
>>>       
>>>>    Organizations deploying stateless translation SHOULD 
>>>>         
>>> assign a Network
>>>       
>>>>    translatable" and "IPv4 Embedded" MUST be constructed as 
>>>>         
>>> specified in
>>>       
>>>>    Network Specific Prefix.  Both types of addresses SHOULD 
>>>>         
>>> use the same
>>>       
>>>>    prefix. 
>>>>
>>>>   
>>>>         
> translator

but wouldn't this require some mechanism in the IPv6 host to do this?

Regards, marcelo

>  (namely, putting the translator's IPv6 prefix [which is also the

---

From: Xing Li <[email-masked]>
Date: Sun, 22 Nov 2009 12:49:12 +0800

Dan Wing 写道:
> translator's.  I think that must be the situation.  

Yes, exactly. The translator's prefix represents the "IPv4 default
route" and the host's prefix
represents individual subnet(s). The more specific win principle will
guides the packets to the
host rather than the translator.
> This should be better

Thanks, we will add the text in the address-format document.

regards,

xing

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 22 Nov 2009 12:36:42 -0800

> [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
> Sent: Sunday, November 22, 2009 12:12 AM
> To: Dan Wing
> Cc: 'Behave WG'; 
> [email-masked]; 'Xing Li'

If using DNS, and having a DNS-based referral, the DNS64 will give 
it such an address -- thus, no change in the application.  

If not using DNS64 (as described in draft-wing-v6ops-v6app-v4server),
the application (or the underlying OS) needs to build its own IPv6
destination address.  For that to work, the application (or the 
underlying OS) needs to know the 6/4 translator's prefix in order
to build its own IPv6 destination address.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 22 Nov 2009 12:37:23 -0800

> host rather than the translator.

Ok.  Thanks.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 22 Nov 2009 23:03:24 +0100

Dan Wing escribió:
>>>>>>    section 2.  "IPv4 translatable" addresses MUST use 
>>>>>>             
>> the selected
>>     
>>> Or is it, maybe, that when the peer's IPv6 prefix and the 
>>>       
>> translator's IPv6
>>     
>>> prefix are the same, the peer's IPv4 representation is the 
>>>       
>> same as the
>>     
>>> translator's.  I think that must be the situation.  This 
>>>       
>> should be better
>>     
>>> described in the address-format document; instead of just a 
>>>       
>> SHOULD, describe
>>     
>>> communicate directly without going through the translator, 
>>>       
>> because each IPv6
>>     
>>> host (behind the translator) are effectively doing the same 
>>>       
>> function as the
>>     
>>> translator
>>>       
but if they are using dns64, the host will not have to create the
address itself, so i am not sure how this relates to the hairpinning
case we were mentioning before. I mean, afiau, the hairpinning case
happens when the host is epxosed to the address directly.
Whent he host receives the fqdn, this is just another normal
communication where no need of hairpinning... am i missing something?

> to build its own IPv6 destination address.

right, this is what i had in mind.

Regards, marcelo

>>> wing-behave-learn-prefix and a translator-aware 
>>>       
>> application, or using DNS64]).
>>     
>>> -d
>>>
>>>
>>>   
>>>       
>>>> -d
>>>>
>>>>
>>>>     
>>>>         
>>>>> xing
>>>>>
>>>>>
>>>>>       
>>>>>           
>>>>>> -d
>>>>>>
>>>>>>   
>>>>>>         
>>>>>>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 Nov 2009 09:04:11 -0800

> Sent: Sunday, November 22, 2009 2:03 PM
> To: Dan Wing
> Cc: 'Xing Li'; 
> [email-masked]; 'Behave WG'

I see what you're saying now.  Yes, if the host has an AAAA record we would
not expect the administrator to point that AAAA record at the translator's
IPv6 address, but rather the administrator should point the AAAA at the host's
actual address.  With an AAAA record, the DNS64 function would return the AAAA
record (without synthesizing the response) so the communication -- when DNS64
was involved -- would be direct and not go through the translator.

> right, this is what i had in mind.

Ok.

-d