Subject: [Hipsec] HIP-NAT and ICE: moving forward

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Jun 2007 10:01:16 -0700

I was asked by several people to point out what deficiencies I saw
in hip-nat-traversal-02-pre6 that caused Hannes and I to write an
alternate approach:

* ICE works in all NAT situations; some of this functionality I didn't 
  see in hip-nat-traversal-02-pre6.

  ONE EXAMPLE of something I didn't see is what ICE calls a 'triggered
  check'; this is necessary so that you can traverse a 'Symmetric NAT'
  without a relay.  The only occurrence of the word 'trigger' was in
  the Connectivity Tests section (in 02-pre6), but it referred to
  sending the connectivity checks towards the relay (rather than to
  the peer's Locator address).  This won't be helpful with 'Symmetric
  NATs', and will cause a relay to be used when it could have been
  avoided.  Relays cost someone money to operate, reduce overall
  availability, and increase jitter and delay.  It has long been the
  design consideration with ICE that relays are always to be avoided.
  Does hip-nat-traversal-02-pre6 share that design consideration, or
  is there a different design consideration?

  (Removing this design requirement would simplify procedures
  somewhat, at the expense of going through relays.  The latest
  figures from Google indicate 10% of their ICE traffic is going
  through relays.  This might translate into 20% of NATs used by their
  subscribers are Symmetric NAT, which would mean 20% of the time you
  will relay traffic.  With the additional triggered check procedure,
  you'll reduce that by half.)

  (Below I provide a suggestion for how hip-nat-traversal-02-pre6 
  might show how it maps to ICE.)

* ICE was designed designed to be backwards-compatible with
  non-ICE-aware endpoints.  Likewise, I expect that
  hip-nat-traversal-02-pre6 needs to work with HIP endpoints that do
  not implement draft-ietf-hip-nat-traversal.  Is that accurate?  If
  so, we need to ensure that hip-nat-traversal-02-pre6 works well in
  such a situation where there won't be connectivity checks performed
  by the remote peer.  I haven't found where hip-nat-traversal-02-pre6
  discusses this situation.

* I consider it necessary that ESP avoid UDP encapsulation where
  possible, and not force UDP encapsulation because a HIP host is
  behind a NAT.  This can be accomplished, if there is consensus and
  interest in doing this.  Is there consensus that doing ESP-over-UDP
  is always okay, especially when both HIP hosts are behind the same 
  NAT (consider an enterprise, where all of their hosts are behind a 
  NAT but those hosts routinely communicate with each other, throw in 
  some 802.11 and T1s and other bandwidth-constrained links)?  
  Currently, hip-nat-traversal-02-pre6 does not attempt to detect 
  if UDP encapsulation can be avoided.

* It's difficult to determine how hip-nat-traversal-02-pre6 diverges 
  from ICE, and thus difficult to understand if it will be as 
  successful as ICE in handling various weird NATs and various
  network topologies.  As I recently posted on the BEHAVE mailing 
  list, ICE is used by Yahoo, Google Chat, AOL, and MSN for their 
  peer-to-peer voice chat between users of their respective 
  networks.  This is millions of endpoints and, I would guess, 
  hundreds of thousands of successful peer-to-peer connections 
  per day.  I know there is a lot of "ICE is for voice" and 
  "ICE is for SIP" religion.  Google Chat uses XMPP (Jabber), 
  not SIP.

  Because hip-nat-traversal-02-pre6 is re-inventing parts of
  ICE, it would be helpful if it showed how it does ICE's steps 
  -- or that hip-nat-traversal-02-pre6 decided they were 
  unnecessary.  The steps of ICE are described in section 2 
  of the ICE specification:
  
    2.1.  Gathering Candidate Addresses 
    2.2.  Connectivity Checks 
    2.3.  Sorting Candidates  
    2.4.  Frozen Candidates 
    2.5.  Security for Checks 
    2.6.  Concluding ICE  
    2.7.  Lite Implementations  

  For HIP, the outline would be something more like:

    - Gathering Locator Addresses
    - Connectivity Checks
    - Sorting Candidates (choosing ESP-over-IP instead 
                          of ESP-over-UDP, for example)
    - Frozen Candidates (probably not necessary for 
                         HIP -- I don't think HIP needs 
                         to establish multiple HIP 
                         connections at the same time 
                         between two HIP hosts, does 
                         it????)
    - Security for Checks (HITs)
    - Concluding HIP Connection Establishment
    - Lite Implementations (HIP hosts that aren't 
                            behind a NAT)
  
* I have noticed some terminology collision around 'middlebox',
  'rendezvous server', and 'relay server'.  We need to resolve these
  collisions to continue intelligent and respectful exchange of 
  ideas amongst IETF members.

  I will begin by explaining that in SIP and in ICE, 'rendezvous
  server' is where both peers can exchange control messages -- that is
  where they can "get together".  In SIP, such servers are SIP 
  proxies.  Rendezvous servers do not ever forward anything but 
  SIP between the two endpoints.

  In ICE, a 'relay' is controlled by one endpoint and forwards UDP
  packets to/from that endpoint to/from its peer.  The protocol
  that defines this control mechanism is
  draft-ietf-behave-turn-03.txt ("TURN").

-d

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

---

From: Miika Komu <[email-masked]>
Date: Wed, 27 Jun 2007 01:27:35 +0300 (EEST)

On Tue, 26 Jun 2007, Dan Wing wrote:

Hi Dan and others,

you can find an updated version of the document from here:

http://www.iki.fi/miika/docs/draft-ietf-hip-nat-traversal-02-pre7.txt

I have updated the document based on comments from various people. Quick 
summary:

* Rewrote the base exchange section (LOCATOR already in I2)
* Rewrote connectivity tests to look more like ICE
* The above two bullet points affected mobility which I updated also
* Added an ICE-to-HIP translation dictionary to the appendix

>  you'll reduce that by half.)

Added to ICE dictionary. See also section 3.5. Connectivity Tests and the 
return routability tests, which can be used as triggered checks.

>  discusses this situation.

Good point. I guess the thing would be to detect unsupported types of 
locators (type 3 which contains the port + address) and to skip processing 
of them. Would this do for you?

>  if UDP encapsulation can be avoided.

I guess this does the trick:

3.5.  Connectivity Tests

UPDATE packets destined to the unreflexive locators are sent directly
over IP.  UPDATE packets destined for reflexive peer, relay and
leased locators are sent transport layer encapsulated.

>  of the ICE specification:

See Appendix A.  Differences to ICE

>    - Lite Implementations (HIP hosts that aren't

Mimicing the ICE structure would make it readable to ICE folks. However, 
we are standardizing this work (at least for now) at the HIP WG. 
Therefore, I have preferred a more HIP oriented view on the contents. Due 
to my time constraints, it is currently oriented towards people who have 
developed and read base exchange, mobility and rvs drafts. I hope that it 
could be more standalone in the following versions.

>  ideas amongst IETF members.

There is a ICE-to-HIP termilogy in the appendix since there seemed to be a 
need for it. Please suggest changes if you have some better terms. As I 
said before, the current standardization forum is HIP, and we don't have 
to cling to ICE terminology.

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Jun 2007 16:24:04 -0700

> * Added an ICE-to-HIP translation dictionary to the appendix

Thanks.  Sorry for the extra work, but I do think this will help
with eventual IETF last call and certainly helps the ICE Camp people,
as I guess we have been labeled.

I'll read that revision on Wednesday.

> Added to ICE dictionary. See also section 3.5. Connectivity 
> Tests and the return routability tests, which can be used as 
> triggered checks.

Thanks. 

> locators (type 3 which contains the port + address) and to 
> skip processing of them. Would this do for you?

What ICE does for its backwards-compatibility is place the most-likely-
to-work transport address into the field that every endpoint understands
(even non-ICE endpoints).  

It's my understanding that HIP endpoints don't have to understand or
support HIP-over-UDP at all; is that accurate?  If so, I agree that
having them quietly ignore Locators they can't use seems what those
hip-nat-traversal-unaware HIP hosts will need to do.  Furthermore,
it will be important for a hip-nat-traversal-aware HIP host to be
sure to provide a Locator that is a "pure" HIP locator (without
UDP encapsulation), through a HIP relay of some sort (which can
convert HIP-over-IP to HIP-over-UDP).  Someone will have to pay
for the costs of running and operating that relay, of course.
A hip-nat-traversal-aware HIP host, when initiating a connection 
to another HIP host will always need to do that, because 
unfortunately it cannot know, a priori, if the remote HIP host
is hip-nat-traversal-aware or not.  Nor can it know if the remote
HIP host is, right now, behind a HIP-unaware NAT, a HIP-aware
NAT, or has a publicly-routable IP address.

> leased locators are sent transport layer encapsulated.

That requires any packet that traverses a NAT to be UDP-encapsulated.
There are many NATs which don't require UDP encapsulation for ESP
traffic.  I'm at a hotel right now, and I can establish a plain
IPsec connection from behind their NAT, and my Linksys WRT54G also
supports IPsec connections.

Another thing which I'm not clear on from -pre6 was this case,
where there are two hosts that want to communicate, and they are 
both behind their own legacy NATs, and there are adjacent
hosts with the intended peer's IP address.  

Here is an example.  In the following diagram, host-a wants to 
communicate with host-d:

             +---------Internet---------------+
             |                                |
           NAT-1                            NAT-2
             |                                |
     +-------+-------+                 +------+----+
     |               |                 |           |     
   host-a          host-b            host-c      host-d
  192.168.1.1   192.168.1.128      192.168.1.1  192.168.1.128

They will exchange each others unreflexive locators (that is,
their local IP addresses), and they'll do connectivity checks
with each other -- those connectivity checks need to fail when
they communicate with their adjacent host (that is, when host-a
does a connectivity check with host-b, we want to know that
host-b is _NOT_ the desired endpoint).  We want the connection
to be established with host-c.  

I expect this is clearer in -pre7, but I won't have time to read
it until tomorrow.

> See Appendix A.  Differences to ICE

Thanks.

> could be more standalone in the following versions.

While it may appear that I am only participating to cause
some sort of mischief, I am participating to ensure that
the years of effort that went into developing ICE will help
HIP's legacy NAT traversal be successful.  

> said before, the current standardization forum is HIP, and we 
> don't have to cling to ICE terminology.

Yes, I clearly understand that the HIP working group is not 
the MMUSIC working group.

Please understand that my efforts in the HIP working group
are voluntary.  My intent is to ensure a well-functioning
legacy NAT traversal for HIP.  I believe that is your intent,
as well.  Let us please all work together on our mutual 
common interest.

Thanks for your quick revision of the WG document; my 
apologies that I will not have time to review it until 
tomorrow.

-d

---

From: Miika Komu <[email-masked]>
Date: Wed, 27 Jun 2007 14:22:42 +0300 (EEST)

On Tue, 26 Jun 2007, Dan Wing wrote:

> support HIP-over-UDP at all; is that accurate?

Yes, from standardization point of view. However, I know that the three 
well-known implementations are already using UDP encapsulation for 
client-side NAT traversal, but this has not really been standardized.

> If so, I agree that having them quietly ignore Locators they can't use 
> seems what those hip-nat-traversal-unaware HIP hosts will need to do. 
> Furthermore, it will be important for a hip-nat-traversal-aware HIP host 
> to be sure to provide a Locator that is a "pure" HIP locator (without 
> UDP encapsulation), through a HIP relay of some sort (which can convert 
> HIP-over-IP to HIP-over-UDP).

The relay in the current draft does not support conversion from IP to UDP 
and vice versa because it would have handle fragmentation issues also. 
However, this could be a nice feature in the following versions of the 
draft in addition to IPv4-IPv6 conversion...

We can do conversion in the relay quite automatically if we would require 
connectivity checks also when registering to a relay. This way, the client 
would establish IPv4, IPv6 or UDPv4 connectivity with the relay. Anyway, 
this requires a little more though, especially on how it reacts with
mobility.

> Someone will have to pay for the costs of running and operating that 
> relay, of course.

Yes, the fragmentation, transport layer conversion and IP address 
conversion definitely involve a computational cost. Maybe this could 
provided with new registration values, but I don't know if they would just 
complicate things and maybe require a new locator type for registered 
locator, I am not sure yet.

> A hip-nat-traversal-aware HIP host, when initiating a connection to 
> another HIP host will always need to do that, because unfortunately it 
> cannot know, a priori, if the remote HIP host is hip-nat-traversal-aware 
> or not.  Nor can it know if the remote HIP host is, right now, behind a 
> HIP-unaware NAT, a HIP-aware NAT, or has a publicly-routable IP address.

These things can be detected using the connectivity tests.

> supports IPsec connections.

Are you proposing a scheme where HIP traffic is UDP encapsulated, but 
IPsec is not? I have thought about this before, but I thought that the 
benefits would be smaller than the drawbacks on extra protocol handling.

>             +---------Internet---------------+

I think this requires an extra statement somewhere that the host-b will 
just drop the I1 packet because of the HIT belongs to host-c. This is 
where the naming and security of HIP fits nicely in..

Another statement should be added about opportunistic mode. In 
opportunistic mode, the destination HIT in I1 is NULL. Host-b would answer 
to host-a even though this was not the intended purpose.

---

From: Miika Komu <[email-masked]>
Date: Thu, 28 Jun 2007 14:36:47 +0300 (EEST)

On Wed, 27 Jun 2007, Miika Komu wrote:

>> Furthermore, it will be important for a hip-nat-traversal-aware HIP host to 
>> be sure to provide a Locator that is a "pure" HIP locator (without UDP 
>> encapsulation), through a HIP relay of some sort (which can convert 
> The relay in the current draft does not support conversion from IP to UDP and 
> vice versa because it would have handle fragmentation issues also. However, 
> this could be a nice feature in the following versions of the draft in 
> addition to IPv4-IPv6 conversion...
>
> would establish IPv4, IPv6 or UDPv4 connectivity with the relay. Anyway, this 
> requires a little more though, especially on how it reacts with
> mobility.
>
>> Someone will have to pay for the costs of running and operating that relay, 
>> of course.
>
> Yes, the fragmentation, transport layer conversion and IP address conversion 
> definitely involve a computational cost. Maybe this could provided with new 
> registration values, but I don't know if they would just complicate things 
> and maybe require a new locator type for registered locator, I am not sure 
> yet.

Replying to my own question here: I think the most modular approach to the 
fragmentation etc issues is to allow the Relay to select how many locators 
it will include. If the relay includes only IP address(es) with UDP 
port(s), the reachability tests cannot select a plain IPv4 or IPv6 address 
and the relay does not have to care about fragmentation etc. If the relay 
includes also plain IPv4 or IPv6 address, it has to be able to deal with 
fragmentation, address family conversion and UDP (de)tunneling issues.

Will be added for the next version unless there are other comments.

---

From: Philip Matthews <[email-masked]>
Date: Fri, 29 Jun 2007 12:36:27 -0400

On 26-Jun-07, at 19:24 , Dan Wing wrote:

> hip-nat-traversal-unaware HIP hosts will need to do.

Wouldn't this be a change from the way ICE works today?
Right now, both endpoints have to agree on the list of checks to perform
and the order they are going to do them in.

I am not sure this is a fatal flaw: I suspect that the introduction
of Controlling/Controlled endpoints into ICE has substantially decreased
the importance of doing checks in the same order. However, we would need
to think about this carefully.

- Philip