Subject: [Hipsec] NAT Traversal in HIP

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 27 Aug 2007 16:29:35 +0300

Folks,

NAT traversal in HIP in one of our chartered items and, so, we need to 
make some progress. At this point, we have three different proposals:

http://www.watersprings.org/pub/id/draft-ietf-hip-nat-traversal-01.txt

http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-02.txt

http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt

The first one uses a simple algorithm that does not probably work in 
some network topologies. The second one uses the ICE methodology so that 
it can work in most network topologies. Instead of using STUN to perform 
connectivity checks and keep alives, it uses HIP messages. The third one 
also uses the ICE methodology. Additionally, it uses STUN to perform 
connectivity checks and keep alives.

We have to make a few decisions:

1) Shall we use the ICE methodology or not? Simplifying the ICE 
methodology would result in a simpler protocol that does not work in 
certain network topologies. The fact that the NAT traversal mechanism we 
come up with works in most situations seems to be an important property. 
Therefore, it seems that using the ICE methodology would be the way to 
go. In any case, feel free to discuss this point on this list?

The following draft is an example on how to apply ICE to a protocol:

http://www.ietf.org/internet-drafts/draft-jennings-p2psip-asp-00.txt

2) Shall we use STUN to gather addresses, and perform connectivity 
checks and keep alives or shall we use HIP messages for that? Using STUN 
has the advantage that HIP could use all the installed base of STUN 
servers, which may have been deployed for other purposes (e.g., VoIP). 
However, we would need to analyze the security implications of using 
STUN in the HIP architecture, which has been designed with security in 
mind from the start. Some folks claimed that, architecturally, it made 
more sense to use HIP than STUN. We need to have further discussions on 
these issues.

Comments are welcome.

Thanks,

Gonzalo
HIP co-chair

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

---

From: Philip Matthews <[email-masked]>
Date: Mon, 27 Aug 2007 13:43:06 -0400

On 27-Aug-07, at 09:29 , Gonzalo Camarillo wrote:

> methodology would result in a simpler protocol that does not work  
> in certain network topologies. The fact that the NAT traversal  
> mechanism we come up with works in most situations seems to be an  
> important property. Therefore, it seems that using the ICE  
> methodology would be the way to go. In any case, feel free to  
> discuss this point on this list?

I strongly think that the ICE methodology is the right way to go for  
HIP.
I understand that some people are interested in a short-term solution  
so that they can do experiments, and I don't have any problems with  
that. However,I think that, if HIP is to be successful, it must have  
a solid NAT Traversal solution, so I strongly think that the long- 
term solution should be based on ICE.

- Philip

---

From: Lars Eggert <[email-masked]>
Date: Tue, 28 Aug 2007 16:46:41 +0900

Hi,

> discuss this point on this list?

ICE is currently with the IESG. One issue that came up is the pacing  
of its connectivity checks, because they can introduce quite a bit of  
traffic and indiscriminately spraying UDP packets around is obviously  
problematic. Basically, ICE needs to pace and congestion control its  
connectivity checks for two reasons. (1) In order to avoid trampling  
over concurrent traffic, and (2) because there is the potential for  
self-interference: If ICE connectivity probes are sent too  
aggressively and end up being dropped, ICE will erroneously eliminate  
candidates, because it thinks that the loss is due to a middlebox  
rather than congestion. The flipside is that sending connectivity  
checks at a lower rate will take longer, which is undesirable.

In any event, the latest ICE draft tries to sidestep this issue by  
shaping the connectivity probes to a rate that tries to be identical  
to the RTP traffic that will follow the ICE exchange. So ICE may  
still not be too friendly to concurrent traffic, but at least it  
won't be more unfriendly than the RTP that follows.

By now you're probably guessing what I'm getting at: If ICE is used  
for HIP, that rate shaping can't take place, because ICE has no idea  
what traffic will be carried inside HIP. (Even HIP has no clue about  
that at the time of the base exchange.) So a critical mechanism will  
need to be defined.

Note: I'm _not_ arguing against using ICE with HIP. All I'm saying is  
that there is a bit of work that needs to be done before it safely can.

Lars

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 28 Aug 2007 10:52:32 +0300

Gonzalo, all,

> 1) Shall we use the ICE methodology or not?

In the long run, I think we should use ICE *methodology*.  On the  
other hand, I think it would be *good* for people to experiment with  
lesser functionality very soon, i.e., now.  But the latter can be  
done by the experimenters agreeing on some interim draft and working  
from that.  The WG doesn't need to be directly involved.

> checks and keep alives or shall we use HIP messages for that?

 From an architectural point of view, my *personal* opinion is that  
we should work very hard to make sure that HIP *can* work (even  
through NATs) without any non-HIP infrastructure.  HIP is designed to  
be a layer 3.5 protocol.  It should work without any reliance on  
protocols above, just like IP and ICMP work without any protocols  
above.  Consequently, my current, perhaps flawed understanding of  
the  offered design options is that we should primarily use HIP  
messages and not STUN.

Optimisations and optional features are a different case.  If it  
makes HIP to work more optimally in some environments, I cannot see  
any reason why specific HIP implementations couldn't utilise STUN  
servers whenever they have access to one, as an optional feature.

My EUR 0.02

--Pekka Nikander

---

From: Miika Komu <[email-masked]>
Date: Wed, 29 Aug 2007 07:51:16 +0300 (EEST)

On Tue, 28 Aug 2007, Pekka Nikander wrote:

> In the long run, I think we should use ICE *methodology*.  On the other 
> hand, I think it would be *good* for people to experiment with lesser 
> functionality very soon, i.e., now.  But the latter can be done by the 
> experimenters agreeing on some interim draft and working from that. 
> The WG doesn't need to be directly involved.

ICE is the state of the art for legacy NAT traversal.

On lesser functionality, the draft already addresses this question 
in section 3.10:

3.10.  Communication with HIP Hosts without NAT Traversal Support

    The UDP encapsulation of HIP and ESP control packets has not been
    defined in any other IETF document and legacy hosts drop all UDP
    encapsulated HIP and ESP traffic.  Processing of unknown locator
    types terminates the base exchange or UPDATE.  As such, the
    extensions defined in this document are not completely backwards
    compatible and require a minimal support in implementations.

    A minimal implementation MUST provide UDP encapsulation of HIP and
    ESP packets.  In such a case, the minimal NAT traversal
    implementation MUST silently discard the processing of type 3
    locators to allow communication with implementations supporting NAT
    traversal defined in this document.  The minimal implementation MUST
    support UDP keepalives to refresh state of the NAT(s).

    Hosts that conform to [I-D.ietf-hip-mm] respond to UPDATE messages
    containing an ECHO_REQUEST with an UPDATE message containing an
    ECHO_RESPONSE.  This completes the connectivity tests for the host
    supporting the extensions defined in this document.  As long as the
    implementation supports UDP encapsulation of HIP control packets,
    this requires no changes.

    The Relay extensions defined in this document do not work with
    minimalistic implementations.  When there is a Relay between the
    hosts, both the Initiator and Responder MUST support the extensions
    defined in this document.  The presence of RELAY_TO and RELAY_FROM
    parameters denotes the precence of a relay.

Looking forward for more feedback on this topic.

>> 2) Shall we use STUN to gather addresses, and perform connectivity checks 
>> and keep alives or shall we use HIP messages for that?
>
> From an architectural point of view, my *personal* opinion is that we 
> should work very hard to make sure that HIP *can* work (even through 
> NATs) without any non-HIP infrastructure.  HIP is designed to be a layer 
> 3.5 protocol.  It should work without any reliance on protocols above, 
> just like IP and ICMP work without any protocols above.  Consequently, 
> my current, perhaps flawed understanding of the offered design options 
> is that we should primarily use HIP messages and not STUN.
>
> Optimisations and optional features are a different case.  If it makes 
> HIP to work more optimally in some environments, I cannot see any reason 
> why specific HIP implementations couldn't utilise STUN servers whenever 
> they have access to one, as an optional feature.

Agree. Nothing in the current draft-ietf-hip-nat-traversal-02.txt prevents 
the use STUN for HIP:

* End-host may use STUN to discover the outernmost NAT address and port
   even though is not redundant. The relay server registration also tells
   this to end-host.
* Both end-hosts AND relays can use STUN servers to allocate ports for
   ESP relaying. End-host can communicate this address in a LOCATOR
   parameter to peer and a relay can send this address during
   registration.

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

---

From: Miika Komu <[email-masked]>
Date: Wed, 29 Aug 2007 08:13:20 +0300 (EEST)

On Tue, 28 Aug 2007, Lars Eggert wrote:

Hi Lars,

>> 1) Shall we use the ICE methodology or not? Simplifying the ICE methodology 
>> would result in a simpler protocol that does not work in certain network 
>> topologies. The fact that the NAT traversal mechanism we come up with works 
>> in most situations seems to be an important property. Therefore, it seems 
>> that using the ICE methodology would be the way to go. In any case, feel 
>> free to discuss this point on this list?
>
> ICE is currently with the IESG. One issue that came up is the pacing of its 
> connectivity checks, because they can introduce quite a bit of traffic and 
> indiscriminately spraying UDP packets around is obviously problematic. 
> Basically, ICE needs to pace and congestion control its connectivity checks 
> for two reasons. (1) In order to avoid trampling over concurrent traffic, and 
> (2) because there is the potential for self-interference: If ICE connectivity 
> probes are sent too aggressively and end up being dropped, ICE will 
> erroneously eliminate candidates, because it thinks that the loss is due to a 
> middlebox rather than congestion. The flipside is that sending connectivity 
> In any event, the latest ICE draft tries to sidestep this issue by shaping 
> the connectivity probes to a rate that tries to be identical to the RTP 
> traffic that will follow the ICE exchange. So ICE may still not be too 
> friendly to concurrent traffic, but at least it won't be more unfriendly than 
> the RTP that follows.
>
> By now you're probably guessing what I'm getting at: If ICE is used for HIP, 
> that rate shaping can't take place, because ICE has no idea what traffic will 
> be carried inside HIP. (Even HIP has no clue about that at the time of the 
> base exchange.) So a critical mechanism will need to be defined.
>
> Note: I'm _not_ arguing against using ICE with HIP. All I'm saying is that 
> there is a bit of work that needs to be done before it safely can.

This issue seems to apply for both of the drafts. Philip told me earlier 
that this thing was prone to change in ICE which is the reason why 
draft-ietf-hip-nat-traversal-02 is merely referencing ICE draft on pacing 
issues.

Can you tell or reference more on (1) ?

---

From: Lars Eggert <[email-masked]>
Date: Wed, 29 Aug 2007 14:56:47 +0900

On 2007-8-29, at 14:13, ext Miika Komu wrote:
>> ICE is currently with the IESG. One issue that came up is the  
>> pacing of its connectivity checks, because they can introduce  
>> quite a bit of traffic and indiscriminately spraying UDP packets  
>> around is obviously problematic. Basically, ICE needs to pace and  
>> congestion control its connectivity checks for two reasons. (1) In  
>> order to avoid trampling over concurrent traffic, and (2) because  
>> there is the potential for self-interference: If ICE connectivity  
>> probes are sent too aggressively and end up being dropped, ICE  
>> will erroneously eliminate candidates, because it thinks that the  
>> loss is due to a middlebox rather than congestion. The flipside is  
>> that sending connectivity checks at a lower rate will take longer,  
>> which is undesirable.
>>
>> shaping the connectivity probes to a rate that tries to be  
>> identical to the RTP traffic that will follow the ICE exchange. So  
>> ICE may still not be too friendly to concurrent traffic, but at  
>> least it won't be more unfriendly than the RTP that follows.
>>
>> By now you're probably guessing what I'm getting at: If ICE is  
>> used for HIP, that rate shaping can't take place, because ICE has  
>> no idea what traffic will be carried inside HIP. (Even HIP has no  
>> clue about that at the time of the base exchange.) So a critical  
>> mechanism will need to be defined.
>>
>> Note: I'm _not_ arguing against using ICE with HIP. All I'm saying  
>> is that there is a bit of work that needs to be done before it  
>> safely can.
>
> This issue seems to apply for both of the drafts.

Yes.

> Philip told me earlier that this thing was prone to change in ICE  
> which is the reason why draft-ietf-hip-nat-traversal-02 is merely  
> referencing ICE draft on pacing issues.

My point was that what the ICE draft currently says on this only  
works if you use ICE with RTP. (Or, more generally, when ICE knows  
something about the data traffic it is trying to set up a path for.)

> Can you tell or reference more on (1) ?

By "(1)" you mean "avoid trampling over concurrent traffic?"

That's what RFC2914 (BCP on congestion control principles) is all  
about. Basically, congestion control in the Internet serves two  
purposes: avoiding congestion collapse (i.e., having some way to  
reduce load in the presence of congestion losses) and being somewhat  
fair to concurrent traffic.

You can argue that because ICE is only sending for a short period of  
time, it cannot and doesn't really need to do much about the former,  
and I'd probably buy that.

I'm on purpose leaving the second part (fairness) pretty undefined,  
because there is some wiggle room there for what mechanisms would be  
OK. But the idea is that, for example, bursting traffic such that it  
causes excessive losses to established flows is probably bad. What  
sort of sending scheme is OK and which isn't? Depends on the  
scenario, which makes this the hard part.

Lars

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 29 Aug 2007 00:01:17 -0700

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Tuesday, August 28, 2007 12:53 AM
> To: Gonzalo Camarillo
> Cc: HIP
> Subject: Re: [Hipsec] NAT Traversal in HIP
> 
> Gonzalo, all,
> 

I agree that there should be some experimental work done before we can
reach a definitive conclusion.  From my perspective, I am inclined to
try to take an existing ICE library and modify it as little as possible
to make it work with our HIP implementation. 

Some areas where I have questions are:

- does HIP need to go further to provide connectivity in asymmetric path
environments? As Marcelo has pointed out, in a multihoming situation,
sometimes your routing will give you asymmetric paths and you need to
deal with it.  ICE assumes symmetric paths, from what I understand.
- what is going to happen when HIP is running ICE and some application
is running ICE on top of that in an uncoordinated fashion?

These questions suggest to me that it would be nice to define a few
deployment/implementation scenarios that we are trying to support and
prioritize.  

> the  offered design options is that we should primarily use HIP  

It seems to me that these goals are in opposition at least for IPv4 and
likely also for IPv6, since working through legacy NATs seems to require
running over transport. 

It seems that there are two main issues that perhaps can be decoupled:
- how to learn (and maintains with keepalives where applicable) locator
candidates somehow (some of which may be UDP locators), and how to
prioritize among them
- given (possibly UDP or IP) locators, HIP implements mechanisms to
handle operation over them

where the first issue may be solved by ICE, STUN, RVS, out-of-band
techniques, etc. 

Tom

---

From: Philip Matthews <[email-masked]>
Date: Wed, 29 Aug 2007 06:37:08 -0400

On 28-Aug-07, at 03:46 , Lars Eggert wrote:

> for HIP, that rate shaping can't take place, because ICE has no  
> idea what traffic will be carried inside HIP. (Even HIP has no clue  
> about that at the time of the base exchange.) So a critical  

I agree with this analysis. My current opinion is that we should  
select some fixed but acceptable sending rate and use that.

- Philip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 30 Aug 2007 13:19:23 +0300

Hi,

I would like the WG to agree on a general direction for this work. Then, 
I would like to put together a small design team to work on this.

Therefore, I would like to encourage folks to try and reach some 
conclusions so that the design team can start working.

Cheers,

Gonzalo

---

From: Miika Komu <[email-masked]>
Date: Fri, 31 Aug 2007 09:14:25 +0300 (EEST)

On Wed, 29 Aug 2007, Henderson, Thomas R wrote:

Hi Tom,

> to make it work with our HIP implementation.

Yes, it seems tempting implementation wise, but I have expressed several 
concerns on this list which should be addressed first. The major problems 
seem to be:

* HIP Relay server: this is needed for guaranteed NAT traversal.
   The relay has to forward HIP control packets which contain the transport
   address candidates. So we can't use STUN servers for this.
* HIP mobility and multihoming: this will get messy with ICE? This may
   also reduce code reusability from ICE significantly.

I have also expressed other concerns, such as security related, in my 
earlier emails and won't repeat them here. I hope that people address the 
issues that have been presented on this list on a technical level. In the 
end, we should select single approach to support interoperability.

> deal with it.  ICE assumes symmetric paths, from what I understand.

I guess it is still possible to have asymmetric paths with the network 
even though ICE enforces both end-hosts to select the same address pairs.

We have remember that the nat draft uses ICE prioritization algorithm to 
make the hosts to converge towards same locator pairs. This is not 
enforced like in ICE because I felt it was artificial for HIP. However, we 
can change this if really needed.

There is a RFC related to this topic:

ftp://ftp.rfc-editor.org/in-notes/bcp/bcp69.txt

I could take an action point of this to see how this applies with 
UDP+IPsec encapsulation in practice.

> deployment/implementation scenarios that we are trying to support and

Good questions!

First, can we assume that ICE stuff is unnecessary when the application is 
running native HIP/IKE/IPsec APIs? Or should it first detect the 
underlying capabilities of the underlying implementation? This could be 
considered in either of the following drafts:

http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-btns-c-api-01.txt

Second, an application running ICE may still be enforced to use IPsec 
according to local policies. Initially, this seemed to suffer from 
three UDP encapsulations but I think it may work out nicely albeit the 
initial connectivity might be set-up slower:

* ICE triggers the connectivity checks
* Some of the checks may be subject IPsec processing and trigger HIP.
   This further triggers HIP NAT traversal. Here, HIP NAT traversal
   actually "overrides" upper layer ICE NAT traversal.
* As a result, some of the ICE checks create tunnels of
   UDP(IPsec(UDP(application data))) which does not really suffer from
   redundant encapsulation with legacy NATs.

However, a potential concern might be that ICE selects a locator which is 
not subject to local IPsec security policies because HIP introduces 
additional RTT to the connectivity checks. In such a case, plain ICE will 
be just used. Anyway, I don't know how valid this concern is because 
the prioritization algorithm is the primary selection method and RTT 
information is secondary.

Mobility and multihoming is problematic, but only when plain ICE is used 
without HIP. This is not a really concern for this WG, I believe.

For HIP-enabled multihoming, should there be "events" to userspace about 
NAT status? I am referring to this draft:

http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-03.txt

> where the first issue may be solved by ICE, STUN, RVS, out-of-band

(I think out-of-band techniques should be possible, but avoided for
automatization on behalf of the users.)