Subject: Re: [Hipsec] Re: Comments on draft-ietf-hip-nat-traversal-01.txt

From: Miika Komu <[email-masked]>
Date: Wed, 4 Apr 2007 11:58:09 +0300 (EEST)

On Fri, 30 Mar 2007, Philip Matthews wrote:

Hi Philip,

I agree with the rest of the comments and I still think that integration 
with ICE is useful, but can you clarify some things?

If understood correctly, the main benefits of integrating ICE with the 
current approach are related to end-host multihoming and to the address 
selection procedures? The current draft already defines the behaviour with 
hairpinning and TURN relays, but what is exactly missing or could be 
improved? (I still need more work with ICE and STUN documentation.)

> > I think it would be best to do the following:
> >
> >   * use the relay immediately for IPsec traffic
> >   * start ICE-like probing of address candidates
> >   * switch to the workable pairs of address candidates (UPDATE 
> > handover)
> >     if any were found, otherwise stick to the relay
> >
> > This way, the initial connection delay observed by the application is
> > smaller as it can already start sending data through the relay.
>
> ICE used to work in a similar manner, up until the -10 version.  This
> has the problem though that there will ALWAYS be a burst of packets 
> through the
> TURN relay, and then you will switch away from the relay to a direct 
> path. This puts a lot of load on your TURN server if 100's or 1000's of 
> nodes to this, and it will also lead to packet reordering problems 
> unless there is a
> higher-level protocol (like TCP) to take care of this problem.
>
> My suggestion is to just accept the delay the occurs until a direct path 
> is found.

Agree, the burst of packets may not be a nice thing for the TURN relays. 
However, I would like to avoid the initial delay in most cases. The 01 
version of the draft does not introduce the delay because the UDP hole 
punching occurs using the HIP base exchange and some additional NOTIFYs.

This makes me wonder if we could have a some kind of hybrid approach where 
we minimize initial connection set-up, try direct data channel and 
fallback to the relay only after ICE-style probing fails. If the probing 
fails, it can result in TCP timeouts because ESP packets are dropped. 
However, I think this would be a reasonable tradeoff because the relay is 
needed in the most cases.

> Some general comments:
>
> First of all, I would recommend working out most of the details without 
> worrying about media relays. Media relays will be easy to add once the other 
> details are known. Also note that BOTH ends must be behind a 
> non-endpoint-dependent NAT before a TURN relay is needed, and statistically 
> less than 10% of all NATs fall into the category (according to research done 
> at Cornell), which means less than 1% of connection attempts will need a TURN 
> relay.

This was actually surprise to me. I thought that only a single 
endpoint-dependent NAT on the path would necessitate a TURN relay. Does 
this mean that the current NAT traversal draft also would work without the 
TURN-like relay with a probability of 99 procent?

May I ask where did this 10 % come from? I am getting a little mismatching 
information. I wonder if it the same paper from Guha et al. The paper 
below estimates that 70.1% of the deployed NATs support endpoint 
independent filtering in the wild (table 6):

http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf

I counted from the online survey that 141 of 218 of the currently tested 
NAT devices support endpoint independent mappings:

https://www.guha.cc/saikat/stunt-results.php?

And of course, there is the recommendation from IETF to consider for 
future NAT manufacturers:

ftp://ftp.rfc-editor.org/in-notes/rfc4787.txt

Also, do you think that we should use STUN as it is for detecting 
initially whether the host is behind a NAT or not? Or would it be better 
to use HIP based STUN mechanism (with e.g. RVS).

-- 
Miika Komu                                       http://www.iki.fi/miika/

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Philip Matthews <[email-masked]>
Date: Wed, 4 Apr 2007 08:21:33 -0400

[Private reply.]

I think it is best for us to talk about this in a phone call. I find  
e-mail to be a poor way to communicate complex ideas like this. I am  
busy this week, but next week should be good for me. I think that  
either Tuesday or Wednesday next week would work for me. We could do  
the phone call at 9h00 Ottawa time, which is 16h00 Helsinki time. Let  
me know what works for you.

I will try to reply on-list to a few of your points below.

- Philip

On 4-Apr-07, at 04:58 , Miika Komu wrote:

> I agree with the rest of the comments and I still think that  
> integration with ICE is useful, but can you clarify some things?
>
> If understood correctly, the main benefits of integrating ICE with  
> the current approach are related to end-host multihoming and to the  
> address selection procedures? The current draft already defines the  
> behaviour with hairpinning and TURN relays, but what is exactly  
> missing or could be improved? (I still need more work with ICE and  
> STUN documentation.)
>
>> >   * switch to the workable pairs of address candidates (UPDATE >  
>> handover)
>> has the problem though that there will ALWAYS be a burst of  
>> packets through the
>> TURN relay, and then you will switch away from the relay to a  
>> direct path. This puts a lot of load on your TURN server if 100's  
>> or 1000's of nodes to this, and it will also lead to packet  
>> reordering problems unless there is a
>> My suggestion is to just accept the delay the occurs until a  
>> direct path is found.
>
> Agree, the burst of packets may not be a nice thing for the TURN  
> relays. However, I would like to avoid the initial delay in most  
> cases. The 01 version of the draft does not introduce the delay  
> because the UDP hole punching occurs using the HIP base exchange  
> and some additional NOTIFYs.
>
> This makes me wonder if we could have a some kind of hybrid  
> approach where we minimize initial connection set-up, try direct  
> data channel and fallback to the relay only after ICE-style probing  
> fails. If the probing fails, it can result in TCP timeouts because  
> ESP packets are dropped. However, I think this would be a  
> reasonable tradeoff because the relay is needed in the most cases.
>
>> Some general comments:
>>
>> First of all, I would recommend working out most of the details  
>> without worrying about media relays. Media relays will be easy to  
>> add once the other details are known. Also note that BOTH ends  
>> must be behind a non-endpoint-dependent NAT before a TURN relay is  
>> needed, and statistically less than 10% of all NATs fall into the  
>> category (according to research done at Cornell), which means less  
>> than 1% of connection attempts will need a TURN relay.
>
> endpoint-dependent NAT on the path would necessitate a TURN relay.  
> Does this mean that the current NAT traversal draft also would work  
> without the TURN-like relay with a probability of 99 procent?
>
> May I ask where did this 10 % come from? I am getting a little  
> mismatching information. I wonder if it the same paper from Guha et  
> al. The paper below estimates that 70.1% of the deployed NATs  
> support endpoint independent filtering in the wild (table 6):
>
> I counted from the online survey that 141 of 218 of the currently  
> tested NAT devices support endpoint independent mappings:
>
> And of course, there is the recommendation from IETF to consider  
> for future NAT manufacturers:
>
> initially whether the host is behind a NAT or not? Or would it be  
> better to use HIP based STUN mechanism (with e.g. RVS).
>
> --

---

From: Philip Matthews <[email-masked]>
Date: Wed, 4 Apr 2007 08:57:13 -0400

> On Fri, 30 Mar 2007, Philip Matthews wrote:

[Snip]
> reasonable tradeoff because the relay is needed in the most cases.

Yes, there is a delay issue with ICE. The latest draft versions  
reduce this somewhat, by increasing the rate that address pairs are  
tried. There are also tricks, like pre-gathering candidates, that can  
be used to speed things up.

However, there  is already a delay with HIP as defined today, because  
of the key exchange and the puzzle computation.

[snip]

> endpoint-dependent NAT on the path would necessitate a TURN relay.

ICE will find a direct path if one end is behind an address-and-port- 
dependent mapping/filtering NAT if the NAT has only a single public  
address (the common case), and the other end is behind an endpoint- 
independent-mapping/address-dependent-filtering NAT.

> without the TURN-like relay with a probability of 99 procent?

I don't know exactly how frequently the approach in draft-ietf-hip- 
nat-traversal-01 will fail. However, I know that the general approach  
of using STUN alone was not reliable enough -- hence the development  
of ICE. (The start of the ICE work pre-dates my involvement in this  
area, so I have not seen precise figures, but I can draw you a number  
of network diagrams where STUN alone does not work)

[snip]

> better to use HIP based STUN mechanism (with e.g. RVS).

Not sure what you mean by this, but I will comment that no one has  
yet found a NAT property detection algorithm that is 100% reliable.  
Even the test "am I behind a NAT" is not 100% reliable.  However, it  
is possible that the error cases will drop as the IETF  
recommendations on NATs become more widely implemented.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Wed, 4 Apr 2007 09:21:08 -0400

Whoops.   My apologies for bothering the list with the message below,  
which I had meant to send only to Miika.
- Philip
On 4-Apr-07, at 08:21 , Philip Matthews wrote:

> [Private reply.]
>
> I think it is best for us to talk about this in a phone call. I  
> find e-mail to be a poor way to communicate complex ideas like  
> this. I am busy this week, but next week should be good for me. I  
> think that either Tuesday or Wednesday next week would work for me.  
> We could do the phone call at 9h00 Ottawa time, which is 16h00  
> Helsinki time. Let me know what works for you.
>
>> the current approach are related to end-host multihoming and to  
>> the address selection procedures? The current draft already  
>> defines the behaviour with hairpinning and TURN relays, but what  
>> is exactly missing or could be improved? (I still need more work  
>> with ICE and STUN documentation.)
>>
>> data channel and fallback to the relay only after ICE-style  
>> probing fails. If the probing fails, it can result in TCP timeouts  
>> because ESP packets are dropped. However, I think this would be a  
>>> must be behind a non-endpoint-dependent NAT before a TURN relay  
>>> is needed, and statistically less than 10% of all NATs fall into  
>>> the category (according to research done at Cornell), which means  
>>> less than 1% of connection attempts will need a TURN relay.
>>
>> Does this mean that the current NAT traversal draft also would  
>> work without the TURN-like relay with a probability of 99 procent?
>>
>> mismatching information. I wonder if it the same paper from Guha  
>> et al. The paper below estimates that 70.1% of the deployed NATs