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

From: Miika Komu <[email-masked]>
Date: Fri, 30 Mar 2007 19:27:53 +0300 (EEST)

On Fri, 30 Mar 2007, Joakim Koskela wrote:

> The base exchange would look something like this:
>
>
>     50500         11111    50500   50500       44444          50500
>   +---+        +----+         +-------+            +----+        +---+
>   |   +--(1)-->|    +---(2)-->+ RVS-R |            |    |        |   |
>   |   |        |    |         |       |            |    |        |   |
>   |   |        |    |<--(3a)--+ [*E1] +---(3b)---->|    |        |   |
>   |   |        |    |         |       |            |    |        |   |
>   |   |<-(4a)--+ N  |         |       |            | N  +--(4b)->|   |

I think steps 3a and 4a are unnecessary. They are needed only the 
01 draft version both-hosts-behind-nat protocol design.

> [*E1] The RVS might need to create a state for the I-R exchange to be
>       able to forward subsequent packages (R1, I2 & R2). (what say
>       you?)

We have to remember that the responder has registered already to the RVS, 
so there is already state for that. The question is that do we need state 
for the initiator as well in the RVS.

I think the answer is "not necessarily". The state information is not 
necessary for forwarding base exchange packets because it is possible to 
piggypack all the necessary addresses to the packets. I'd say the state 
information is mostly needed for the case when the RVS acts as a TURN-like 
relay or suggests another TURN-like relay. The RVS or relay needs know 
where to forward the UDP encapsulated ESP traffic.

> [*E2] I MAY configure an external TURN server to relay the data
>       traffic between I and R. If so, it is done here.  The
>       I-configured TURN server is further referenced to as IP-TURN-I,
>      22222

Yes, there are three alternatives:

   1. initiator suggests a TURN-like relay
   2. responder suggests a TURN-like relay
   3. RVS suggests a TURN-like relay (either itself or another relay)

If both (1) and (2) are done, we can have asymmetrically routed traffic 
going one way through the relay of initiator and trough the relay of 
the responder the other way. At least the mobility and multihoming draft 
does not prefer this kind of operation because of IPsec window issues.

> After the base exchange, I and R will know each other's real IP, the
> IP of the publicly accessible NAT they are behind and possiby a TURN
> server configured to relay the data traffic.  No connection for the
> traffic has however yet been established.

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.

> Ranking (dont know if this would actually be the ranking, but serves as 
> example):
> 1  (IP-I, IP-R)
> 2  (IP-I, IP-NAT-R)
> 3  (IP-NAT-I, IP-R)
> 4  (IP-NAT-I, IP-NAT-R)
> 5  (IP-I, IP-TURN-I)
>    (IP-I, IP-TURN-R)

Good!

> Open issues:
>
>  - In what order are the addresses tried?
>
>    Perhaps reverse compared to ICE - from the least-optimal (last) to
>    most-optimal (first).  In practice this would mean the TURN-server
>    based (if such exist) first, which would establish *some* sort of
>    connection quickly.  After that, the NAT-based would be tried,
>    following by the real IPs (in case I & R are in the same subnet.

Yes, I think the order should be:

The most reliable first (TURN-relay), then fastest (private address) and 
finally the address of the outernmost NAT.

> - What is the suitable parameter for providing the TURN servers' info
>   (where VIA_RVS_NAT was used in the example)?

We probably want to say explicitly also the RVS address, so we need a 
separate parameter.

> - Is there any race-condition problems when both are trying the
>   alternatives.  Maybe the initiator should only try to establish the
>   connections or something similar?  ICE might provide something for
>   this.

There is no race condition at least for HIP base exchange because it has 
been designed to support simultaneous initiators.

> - Can all be tried at once to try to speed up the process. The first
>   that gets through would be used until another one is responded to
>   which is ranked better than the one currently used.

I think the address probes can be sent simultaneously. Maybe with 
different SPIs?

> - Should the RVS-R be automatically used as the first proxy used for
>   starting the data traffic?  As Miika noted, this could be
>   controlled using HIT acl's at the RVS combined with some policies.
>
> - Can the RVS-R automatically / transparently add a proxy server
>   (TURN or similar) to the *2- packets of the base exchange?

I think it should automatic only if the RVS appends a "TURN parameter" to 
the base exchange. Alternatively, the RVS has informed responder upon 
registration that it is offering a relay and the responder tells this to 
the initiator.

-- 
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: Fri, 30 Mar 2007 16:46:34 -0400

Folks:
I am new to HIP, so please excuse any comments that show an ignorance  
of HIP.
However, I am rather familiar with ICE and NAT Traversal in general.

My comments are inline.

On 30-Mar-07, at 12:27 , Miika Komu wrote:

>>   |   |        |    |         |       |            |    |         
>> |   |
>>   |   |        |    |         |       |            |    |         
>> |   |
>>   |   |<-(4a)--+ N  |         |       |            | N  +--(4b)- 
>> >|   |
>

I don't see any reason for these from a NAT Traversal standpoint.

> We have to remember that the responder has registered already to  
> the RVS, so there is already state for that. The question is that  
> do we need state for the initiator as well in the RVS.
>
> I think the answer is "not necessarily". The state information is  
> not necessary for forwarding base exchange packets because it is  
> possible to piggypack all the necessary addresses to the packets.  
> I'd say the state information is mostly needed for the case when  
> the RVS acts as a TURN-like relay or suggests another TURN-like  
> relay. The RVS or relay needs know where to forward the UDP  
> encapsulated ESP traffic.

I agree that the answer is "not necessarily". In fact, I would go  
further and say that it should be a design goal to not require the  
RVS be stateful. I wrote, with two colleagues, a draft that described  
how to solve a very similar problem in a very similar manner where  
the signaling protocol was SIP (rather than I1,I2,R1,R2) and we were  
able to do this with the RVS replaced with a stateless SIP proxy (see  
draft-matthews-p2psip-bootstrap-mechanisms-00).

> If both (1) and (2) are done, we can have asymmetrically routed  
> traffic going one way through the relay of initiator and trough the  
> relay of the responder the other way. At least the mobility and  
> multihoming draft does not prefer this kind of operation because of  
> IPsec window issues.

This is a problem/fact with the way ICE works with TURN. Even if both  
I and R use the same TURN server, the traffic will still pass through  
different ports on the server unless we invent new mechanisms to  
solve this problem.

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

>
>> Ranking (dont know if this would actually be the ranking, but  
>> serves as example):
>> 1  (IP-I, IP-R)
>> 2  (IP-I, IP-NAT-R)
>> 3  (IP-NAT-I, IP-R)
>> 4  (IP-NAT-I, IP-NAT-R)
>> 5  (IP-I, IP-TURN-I)
>>    (IP-I, IP-TURN-R)
>
> Good!
>
>> Open issues:
>>
> The most reliable first (TURN-relay), then fastest (private  
> address) and finally the address of the outernmost NAT.

This was roughly the recommended ordering of ICE up until the ICE-10  
draft. However, ICE now recommends "most-desirable" to "least- 
desirable".

I would recommend following the order specified in ICE unless there  
are very good reasons to do something different. Note that ICE does  
give some leeway in the ordering. If ICE-15, the algorithm for  
assigning priority to candidates is at RECOMMENDED strength, while  
the algorithm for computing candidate pair orderings is at MUST  
strength.

> We probably want to say explicitly also the RVS address, so we need  
> a separate parameter.
>
> There is no race condition at least for HIP base exchange because  
> it has been designed to support simultaneous initiators.

ICE specifies exactly how the alternatives are tried. In many cases,  
it requires that both ends try to establish connections more-or-less  
simultaneously in order to establish the proper NAT permission entries.

> I think the address probes can be sent simultaneously. Maybe with  

I believe you are talking about the ICE connectivity checks. If so,  
then ICE specifies the spacing of these checks.  It is important that  
these not happen too fast for two reasons:
- The first is that there is an attack, known as the ICE Hammer  
Attack, where ICE can be used to flood a third-party node with  
packets in a form of denial of service attack. Spacing the checks out  
reduces this problem.
- The second is that some NATs have a limit on how fast they can set  
up new bindings. Running the checks too fast overwhelms the NATs and  
results in indeterminate behavior.

> I think it should automatic only if the RVS appends a "TURN  
> parameter" to the base exchange. Alternatively, the RVS has  
> informed responder upon registration that it is offering a relay  
> and the responder tells this to the initiator.

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.

Second, ICE is expressed in terms of an "offer" and an "answer". In  
ICE-15, these are encoded in SDP, but I think the right way is to  
work out a different encoding that is more appropriate for HIP. I  
think this will be straight-forward.  However, there is the question  
of which HIP messages carry the offer and the answer. From the  
discussion that a number of us had on Friday afternoon after the HIP  
RG meeting, it seems that I2 and R2 are the most appropriate messages  
for the following reasons:
- R is supposed to be able to generate R1 with very little effort,  
and I see some problems in R generating an offer or an answer quickly.
- ICE requires the secure exchange of a password and user-name  
fragments, and I2 and R2 seems to provide a way to do this, while I1  
and R1 do not.

- Philip