Subject: [Hipsec] ICE-for-HIP design choice: STUN or HIP?

From: Philip Matthews <[email-masked]>
Date: Fri, 22 Jun 2007 21:48:31 -0400

Now that there are two competing proposals for how to do ICE-for-HIP:
	http://tools.ietf.org/id/draft-ietf-hip-nat-traversal-01.txt
and
	http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt
it seems to me that it would be good to step back for a moment and  
have a discussion on some basic design choices. Discussing these  
individually would help the design process, in my opinion.

One of these basic questions is whether to use STUN or an enhanced  
version of HIP for binding discovery and for connectivity checks.
Miika's document proposes to use an enhanced version of HIP, while  
Hannes's document proposes to use STUN.

Here is what I see as being the pros and cons of the two approaches:

STUN:
+ Protocol is already defined and deployed.
+ The usage of STUN in ICE is already defined.
- STUN has to be run over the same port as HIP, and the only way to  
distinguish the two protocols is by header inspection. There are a  
few bits of difference, but this is not exactly a beautiful design.
- HIP-aware NATs must be able to do a fairly complete decode of STUN  
packets. (more on this below)

Enhanced HIP:
+ Fits much more naturally with the rest of HIP.
-  Requires more work to define how ICE works.
+ No weird header inspection
+ Natural behavior at HIP-aware NATs.
- Not currently defined
? Not currently deployed

Let me discuss two of these in more detail.

The first is the question of deployment. STUN is currently deployed  
today, so there are STUN servers that a HIP node could use. But is  
this really important? If we build enhanced HIP functionality into  
HIP and into RVSes, then I think there will always be a public server  
around that a HIP node could use to discover its reflexive address.

The rest of this message discusses the question of how to handle HIP- 
aware NATs.  With a HIP-aware NAT, we could get rid of the UDP  
encapsulation, and run HIP directly over IP. This, in my opinion, is  
an important design goal. If HIP is successful, then we should assume  
that NATs will be upgraded to understand HIP, and this will allow us  
to get rid of the irritating UDP encapsulation.

To understand how this might work, we need to agree how a HIP-aware  
NAT would operate.
Let's consider a HIP packet sent from node X which is behind a HIP- 
aware NAT
to a node Y which is in the public Internet, and a response coming  
back from Y to X.
[For now, I am ignoring the fact that most of the traffic on HIP  
associations
is actually ESP traffic and not HIP traffic. I will discuss this below.]

Let's look at the IP addresses and HITs in the packets as they flow  
through the NAT.
        At X                            At N                   At Y
src: (X-IP, X-HIT)                (N-IP, X-HIT)
dst: (Y-IP, Y-HIT)  ------------> (Y-IP, Y-HIT)---------->

src:                              (X-IP, X-HIT)            (Y-IP, Y-HIT)
dst:                              (Y-IP, Y-HIT) <--------- (N-IP, X-HIT)

At the top, X sends a packet with its (private) IP address and Y's  
public IP address
in the IP header, and its HIT and Y's HII at the HIP layer.
At the NAT, X's private IP address is replaced by N's public address.
When Y replies, it sends to N's public address, which gets replaced  
by the NAT
with X's private address.

Thus the NAT stores:
	mapping entry:   X-HIT  --> X-IP   (i.e., the node identified by HIT  
X-HIT is at IP address X-IP)
	filtering entry: X-HIT  <-- Y-HIT  (i.e., the node identified by HIT  
X-HIT can receive packets from
                                                   the node  
identified by Y-HIT).

All this works very well if we use enchanced HIP.

But how does this work if we use STUN instead?
In this case, the packet would consist of a STUN message riding  
directly over IP
(but where the IP protocol field would specify HIP rather than STUN).
In order for the NAT to create the appropriate bindings, the STUN  
message would need
to contain the source and destination HITs somewhere in the message.  
The only place
to carry these in STUN is in some STUN attribute.
So this means that the NAT has to be able to do a fairly complete  
parse of a STUN message.

Requiring a HIP-aware NAT to do a fairly complete parse of a STUN  
message
concerns me a bit. It seems quite unnatural to me.

Comments?

- Philip

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

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 23 Jun 2007 10:31:39 -0700

The important difference with draft-tschofenig-hip-ice isn't the
encoding on-the-wire.  

Rather, the important difference is performing ICE.  Those steps
are:

  Initiator:
    * gather candidate addresses
    * send candidate addresses to remote peer (terminator)
      via a rendezvous protocol (HIP, in this case; SIP in 
      the traditional case of ICE)
   
  Terminator:
    * gather its own candidate addresses
    * perform connectivity checks with the remote peer 
      (initiator) to find a functional path to the initiator
    * send candidate addresses to remote peer (initiator) via
      a rendezvous protocol (HIP)
   
  Initiator:
    * perform connectivity checks with the remote peer
      (terminator)
    * prioritize successful checks and determine which path
      is preferred (for example: avoid UDP encapsulation,
      take a path over only HIP-aware NATs if that's desirable,
      avoid NATs and take direct path, etc.).  This choice is
      communicated to the remote peer (terminator), so it can
      make the same choice so bi-directional traffic can be
      assured (which is necessary to keep all the NATs open).

Encoding:

The connectivity checks need to be done using the same encapsulation and
protocol that HIP and IPsec will subsequently use for their communication
between the two peers.  There are two cases:

  * HIP-over-UDP.  Here, it makes sense to use STUN-over-UDP for 
    those checks.  

  * HIP directly over IP.  Here, I concur with your email that it 
    may be useful to perform connectivity checks using HIP itself.  
    However, HIP would need encode much of the same information that 
    STUN encodes into HIP TLVs; thus, an opaque object that contains 
    a STUN message could make sense for the non-UDP HIP-over-IP case.
    Failure to encode those same parameters and failure to do the
    same steps as ICE will cause HIP's legacy NAT traversal to fail.

But if we step back slightly it becomes apparent that non-HIP protocols
would benefit from this same encoding -- NSIS comes immediately to mind (it
needs to also work with non-NSIS-aware NATs).  MIP (Mobile IP) comes to
mind, as well (it would be useful to make sure you have connectivity before
you switch to a new IP address, otherwise you won't be successful).

Two other things in your email I'm not worried about:  (a) HIP-aware NATs
having to parse the STUN messages and (b) demultiplexing STUN and HIP.
There are no HIP-aware NATs that I'm aware of, so there isn't an installed
base of devices or software.  If there is sufficient value in multiplexing
STUN and HIP over the same UDP port, and someone wants to build a HIP-aware
NAT, they can incur the slight difficulty in pulling a HIT out of a STUN
message.  This is perhaps 20 lines of code.  Demultiplexing STUN and HIP is
3-4 lines of code, and has no false positives (where the demultiplexing
fails).

That said, I would really like to first concentrate on the *steps* involved
in ICE, and how to make them work with HIP.  Because that must first be
agreed upon before we can reasonably discuss HIP parameter encoding.

-d

> -----Original Message-----
> From: Philip Matthews [mailto:[email-masked]] 
> Sent: Friday, June 22, 2007 6:49 PM
> To: Miika Komu; Dan Wing; Hannes Tschofenig
> Cc: HIP WG
> Subject: ICE-for-HIP design choice: STUN or HIP?
>

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 23 Jun 2007 22:32:42 +0300

Firstly, I don't have any opinion on how to perform ICE, since I  
don't know ICE sufficiently well.  Hence, I will leave that issue for  
others.

What comes to the other issue, encoding on the wire, I'd like to  
express the following opinions:

1. In general, reusing encoding from Protocol X rarely works well  
when embedded in Protocol Y.  The code-reuse argument given doesn't  
really hold, since it is rarely possible to simply port a part of an  
implementation of X into the implementation of Y.  Even when that is  
possible, it results in a larger amount of total code.  Instead,  
converting protocol X messages into protocol Y message format often  
leads to the minimal amount of total code.  When re-encoded wisely,  
the additional amount of programming code in a cleverly implemented Y  
is not that larger.  For example, our HIP implementation is fully  
modular and it is very easy to add new parameter types.

2. Security is a crucial issue here.  All HIP messages are signed,  
and a NAT box (or a firewall) can verify the signatures, if provided  
with the public keys (or if it can learn them from the R1 and I2).   
That is a feature that I'd like to see preserved when working on NAT  
traversal for HIP.

For these reasons, I'd be inclined to think that if one wants to use  
HIP-based NAT traversal for other protocols, such as NSIS, it would  
be best either to run the other protocol on the top of HIP, as a  
separate "layer", or re-encode in HIP terms, benefitting from the  
signatures.

So, I cannot see why it would make sense to re-use STUN-over-UDP for  
HIP.  It would increase code bloat in the HIP implementations, and it  
would reduce the overall security of the system, AFAICS.

Finally, whether it would make sense to simply embed a STUN message  
into a HIP parameter (TLV), IMHO that mainly depends on whether the  
HIP TLV encoding/decoding engines can be easily augmented to handle  
STUN messages, i.e., the actual embedded content.  If it can, then  
fine.  If that doesn't make sense, e.g. because the STUN messages are  
ASN.1 BER encoded or TLVs in a different format or even XML, then  
IMHO it would be best to define new separate HIP parameters (TLVs),  
with the same samantics as the original STUN messages do have.  [As  
you can see from the previous text, I haven't got a slighest idea of  
how STUN messages are encoded.]

--Pekka Nikander

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 23 Jun 2007 21:51:46 +0200

Hi Pekka,

I think that main point you raised is that you would like to have a NAT 
that understands the HIP messages in the future and this unfortunately 
impacts the current protocol design of the HIP-unaware NAT traversal 
work. Hence, you don't really like the concept of using STUN/ICE instead.

Ciao
Hannes

PS: The entire stuff has nothing todo with NSIS.

 Pekka Nikander wrote:
> Firstly, I don't have any opinion on how to perform ICE, since I don't 
> know ICE sufficiently well.  Hence, I will leave that issue for others.
>
> 1. In general, reusing encoding from Protocol X rarely works well when 
> embedded in Protocol Y.  The code-reuse argument given doesn't really 
> hold, since it is rarely possible to simply port a part of an 
> 2. Security is a crucial issue here.  All HIP messages are signed, and 
> a NAT box (or a firewall) can verify the signatures, if provided with 
> the public keys (or if it can learn them from the R1 and I2).  That is 
> a feature that I'd like to see preserved when working on NAT traversal 
> for HIP.
>
> HIP-based NAT traversal for other protocols, such as NSIS, it would be 
> best either to run the other protocol on the top of HIP, as a separate 
> "layer", or re-encode in HIP terms, benefitting from the signatures.
>
> ASN.1 BER encoded or TLVs in a different format or even XML, then IMHO 
> it would be best to define new separate HIP parameters (TLVs), with 
> the same samantics as the original STUN messages do have.  [As you can 
> see from the previous text, I haven't got a slighest idea of how STUN 
> messages are encoded.]
>
> --Pekka Nikander
>
>
>

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 23 Jun 2007 23:03:46 +0300

Dear WG,

 From my point of view, Mr. Tschofenig is trying to read my words in  
a way that I wasn't intending.  I'm taking that off-line, and will  
try to come back here once this misunderstanding has been cleared.

I tried to say that IMHO using HIP packet formats makes sense from  
both security and implementation point of view, even for the HIP- 
tunneled-over-UDP case.  Nothing more and nothing less.

My reference to NSIS was only due to Mr. Wing's reference to that.

--Pekka Nikander

On 23 Jun 2007, at 22:51, Hannes Tschofenig wrote:

> Hi Pekka,
>
> I think that main point you raised is that you would like to have a  
> NAT that understands the HIP messages in the future and this  
> unfortunately impacts the current protocol design of the HIP- 
> unaware NAT traversal work. Hence, you don't really like the  
> concept of using STUN/ICE instead.
>
> Ciao
> Hannes
>
>> don't know ICE sufficiently well.  Hence, I will leave that issue  
>> for others.
>>
>> when embedded in Protocol Y.  The code-reuse argument given  
>> doesn't really hold, since it is rarely possible to simply port a  
>> part of an implementation of X into the implementation of Y.  Even  
>> when that is possible, it results in a larger amount of total  
>> code.  Instead, converting protocol X messages into protocol Y  
>> message format often leads to the minimal amount of total code.   
>> When re-encoded wisely, the additional amount of programming code  
>> in a cleverly implemented Y is not that larger.  For example, our  
>> HIP implementation is fully modular and it is very easy to add new  
>> parameter types.
>>
>> and a NAT box (or a firewall) can verify the signatures, if  
>> provided with the public keys (or if it can learn them from the R1  
>> and I2).  That is a feature that I'd like to see preserved when  
>> working on NAT traversal for HIP.
>>
>> For these reasons, I'd be inclined to think that if one wants to  
>> use HIP-based NAT traversal for other protocols, such as NSIS, it  
>> would be best either to run the other protocol on the top of HIP,  
>> as a separate "layer", or re-encode in HIP terms, benefitting from  
>> the signatures.
>>
>> So, I cannot see why it would make sense to re-use STUN-over-UDP  
>> for HIP.  It would increase code bloat in the HIP implementations,  
>> and it would reduce the overall security of the system, AFAICS.
>>
>> Finally, whether it would make sense to simply embed a STUN  
>> message into a HIP parameter (TLV), IMHO that mainly depends on  
>> whether the HIP TLV encoding/decoding engines can be easily  
>> augmented to handle STUN messages, i.e., the actual embedded  
>> content.  If it can, then fine.  If that doesn't make sense, e.g.  
>> because the STUN messages are ASN.1 BER encoded or TLVs in a  
>> different format or even XML, then IMHO it would be best to define  
>> new separate HIP parameters (TLVs), with the same samantics as the  
>> original STUN messages do have.  [As you can see from the previous  
>> text, I haven't got a slighest idea of how STUN messages are  
>> encoded.]
>>
>> --Pekka Nikander
>>
>>
>>

---

From: Philip Matthews <[email-masked]>
Date: Sat, 23 Jun 2007 21:40:57 -0400

On 23-Jun-07, at 15:32 , Pekka Nikander wrote:
> As you can see from the previous text, I haven't got a slighest  
> idea of how STUN messages are encoded.]
>

STUN is defined in RFC 3489 with a significant update in draft-ietf- 
behave-3489bis.
It is a binary protocol consisting of a fixed header followed by zero  
or more TLVs (called Attributes in STUN).
The header from draft-ietf-behave-3489bis looks as follows:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |0 0|     STUN Message Type     |         Message  
Length        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |                         Magic  
Cookie                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
                                 Transaction ID
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
                                                                         
|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+

and each attribute has the usual TLV structure
         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |         Type                  |             
Length             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |                              
Value                 ....        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+

There are a number of different Attribute types defined,
and a typical STUN message usually contains a number of Attributes.

STUN messages are sent as part of "transactions". A transaction is  
either
a request/response transaction where a "client" sends a request and
"sever" replies with a response (=success) or an error response  
(=error);
or an indication, where a "client" sends an indication to a server,
but does not get back a response.

ICE uses STUN in two different ways:

1) To determine the public address and port that a NAT has allocated
that corresponds to the private address and port of an endpoint.
To do this, an endpoint sends a STUN BindingRequest message to a server
on the public Internet, which replies with a BindingResponse message.
The server places the source address and port it saw in the received
UDP message into an attribute in the BindingResponse message.
In this way, the endpoint learns the public address and port that the
NAT has assigned it.

2) To determine if two endpoints can communicate using a given 5-type
of (source IP address, source port, dest IP address, dest port,  
protocol).
To do this, both endpoints send STUN BindingRequest messages to each  
other
using the 5-tuple. If an end gets a response, it knows that the 5-tuple
works.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Sat, 23 Jun 2007 22:05:10 -0400

ICE is officially a extension of SDP (Session Description Protocol).
ICE is defined in draft-ietf-mmusic-ice,
and the current SDP definition is in RFC 4566.

SDP is a text-based protocol for describing multimedia sessions.
An SDP message consists of a number of lines, where each line
starts with a single letter and is followed by an equals sign.
For example:
        v=0
        o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
        s=
        c=IN IP4 192.0.2.3
        t=0 0
        a=ice-pwd:asd88fgpdd777uzjYhagZg
        a=ice-ufrag:8hhY
        m=audio 45664 RTP/AVP 0
        b=RS:0
        b=RR:0
        a=rtpmap:0 PCMU/8000
        a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
        a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx  
raddr 10.0.1.1 rport 8998

The two endpoints that want to communicate do an Offer-Answer exchange.
That is, one endpoint sends the other an SDP message (dubbed the Offer),
and the other end replies with a second SDP message (dubbed the Answer).
This is basically a standard capability exchange seen in many other  
protocols.

Neither SDP nor ICE define how the Offer and Answer are sent to the  
other end.
This is typically done using some out-of-band signaling mechanism.
One common example is SIP signaling through intermediate proxies.
For HIP, a Base Exchange through an RVS could do the trick,
where the Offer and Answer are carried in HIP messages.

With ICE, the Offer and Answer include one or more "candidates".
Each candidate is an (IP address, port, protocol) combination along  
with some related information.
For example, the line
        a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
specifies a UDP candidate with address 10.0.1.1 and port 8998, along  
with some other information.

Using the Offer/Answer exchange, the two endpoints exchange sets of  
candidates.
Each endpoint typically includes all the candidates that it knows  
about that can be used
to reach it. These are both its private (address,port) combinations,  
as well as public
(address,port) combinations which it learns by doing STUN  
BindingRequest/BindingResponse
exchanges with a server.
Each endpoint then forms all possible pairs of (local candidate,  
remote candidate),
sorts these pairs in a defined way, and then performs connectivity  
checks to see
if this pair can be used to communicate between the two endpoints.  
The connectivity
checks are also performed using STUN messages.

A longer, but still tutorial, introduction to ICE can be found in the  
Nov 2006 issue
of the IETF Journal:
      http://www.isoc.org/tools/blogs/ietfjournal/?p=117#more-117

- Philip

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 24 Jun 2007 09:11:32 +0300

On 24 Jun 2007, at 05:05, Philip Matthews wrote:
> specifies a UDP candidate with address 10.0.1.1 and port 8998,  
> along with some other information.

That kind of semantics is exactly why we made the HIP LOCATOR  
parameter extensible.  That is, the rationale back then was to be  
able to encode not only IP addresses but more complex and variable  
underlying addresses in a LOCATOR.  For details, see Section 4 of
http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-05.txt

Briefly, the LOCATOR carries one or more LOCATORS (candidates in  
ICE), each with the
following format:

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        | Traffic Type   | Locator Type | Locator Length | Reserved    
|P|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |                       Locator  
Lifetime                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |                             
Locator                            |
         
|                                                               |
         
|                                                               |
         
|                                                               |

Currently only the following locator types are defined:

    0:   An IPv6 address or an IPv4-in-IPv6 format IPv4 address [8] (128
       bits long).  This locator type is defined primarily for non-ESP-
       based usage.

    1:   The concatenation of an ESP SPI (first 32 bits) followed by an
       IPv6 address or an IPv4-in-IPv6 format IPv4 address (an  
additional
       128 bits).  This IP address is defined primarily for ESP-based
       usage.

However, it would be trivial to define a new format for UDP  
encapsulation; indeed, we had discussions about including it, but I  
don't remember the details of that discussion any more.  IIRC, back  
then we decided to delay the definition of that format until the NAT  
traversal discussions mature enough.

> Using the Offer/Answer exchange, the two endpoints exchange sets of  

The HIP MM exchange allows the endpoints to exchange LOCATOR sets.

> to reach it. These are both its private (address,port)  
> combinations, as well as public

To me, this sounds like the exchange could trivially map to the HIP  
mm exchange, but of course I may be completely wrong.

> checks are also performed using STUN messages.

That sounds quite similar to the SHIM6 connectivity checks, to me.  See
http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- 
detection-08.txt

(As an information point, one should notice that the SHIM6 and HIP  
protocols were explicitly designed to use the same packet formats, to  
ease sharing mechanisms between the two.)

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 24 Jun 2007 09:26:54 +0300

>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+-+
>        |         Type                  |             
> Length             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+-+
>        |                              
> Value                 ....        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+-+

The good news is that this is almost the same as the HIP parameter  
format:

5.2.1.  TLV Format

    ....

    All of the TLV parameters have a length (including Type and Length
    fields) which is a multiple of 8 bytes.  When needed, padding  
MUST be
    added to the end of the parameter so that the total length becomes a
    multiple of 8 bytes.  This rule ensures proper alignment of data.
    Any added padding bytes MUST be zeroed by the sender, and their
    values SHOULD NOT be checked by the receiver.

    Consequently, the Length field indicates the length of the Contents
    field (in bytes).  The total length of the TLV parameter (including
    Type, Length, Contents, and Padding) is related to the Length field
    according to the following formula:

    Total Length = 11 + Length - (Length + 3) % 8;

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type            |C|             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       /                          Contents                             /
       /                                               +-+-+-+-+-+-+-+-+
       |                                               |    Padding    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Therefore, mapping STUN Attributes to HIP Parameters should be a  
trivial task:

1. Define a mapping of Type values, if needed.  Of course, if an  
equality-based mapping would work, that would be excellent, but I doubt.

2. Use the HIP Length computation method in order to make the  
handling of all HIP parameters, including those based on STUN, to use  
the same method.

3. Use the STUN definition for Value as the HIP Contents.

Though, for some Attributes it might be better to use already defined  
HIP equivalents.  For example, I could imagine that it would make  
sense to use HIP Sequence Number and Acknowledgement parameters.  And  
as already discussed in my previous message, for ICE candidates it  
would probably be better to use the HIP LOCATOR parameter, extended  
in a suitable way to encode the required locator formats in a  
sensible way.

One benefit here might be that HIP contains mechanisms that can be  
used to allow "transactions" to overlap.

> on the public Internet, which replies with a BindingResponse message.

This could be mapped on the top of the HIP (RVS) Registration protocol.
The BindingRequest (or equivalent info mapped on the Registration  
protocol)
could be carried in a REG_REQ Parameter, or next to it.

Hence, I see here two choices:

1. Simply carry BindingRequest as an additional parameter wherever  
you carry a REG_REQ parameter, or
2. Map the BindingRequest into an equivalent HIP REG_REQ parameter.

> In this way, the endpoint learns the public address and port that the

Here there might be three different design choices:
1. Simply carry BindingResponse in any message responding to a  
previous message carring a BindingRequest.
2. Define a REQ_RES extension that carries the information in  
BindingResponse.
3. Define a variant of LOCATOR that carries the information in  
BindingResponse.

Of course, there might be other sensible alternatives in both cases.

> To do this, both endpoints send STUN BindingRequest messages to  
> each other

As an initial approximiation, I think that a variant of the HIP MM  
protocol, drawing from the ICE experience and SHIM6 exploration  
formats, might be the best way forward.  But here I might be  
completely wrong; there seems to be subtleties that I don't understand.

My main point here is that NAT such exploration should not be limited  
to the NAT traversal case but should allow any two HIP hosts to  
explore the characteristics of all paths, independent of whether the  
paths are based on IPv4, IPv6, and contain no, transparent, or  
explicit middle boxes.  From my point of view, most of the required  
components for such a mechanism are already there scattered over the  
various HIP drafts; what is missing is the algorithms and state  
machine definitions for utilising them.  But perhaps I'm too simple  
minded here.

--Pekka

---

From: Philip Matthews <[email-masked]>
Date: Sun, 24 Jun 2007 09:39:20 -0400

On 24-Jun-07, at 02:11 , Pekka Nikander wrote:

>> Each candidate is an (IP address, port, protocol) combination  
>> along with some related information.
>> For example, the line
>        | Traffic Type   | Locator Type | Locator Length |  
> Reserved   |P|
> then we decided to delay the definition of that format until the  
> NAT traversal discussions mature enough.

This is the approach that Miika takes. He defines a new LOCATOR  
format for UDP encapsulation.

>
>> Using the Offer/Answer exchange, the two endpoints exchange sets  
>> of candidates.
>

Miika carries the Offer in the R1 packet, and the Answer in a Update  
packet,
which I believe more-or-less corresponds to your proposal.
However, I have some concerns with this approach, one of them being that
I think it would be nice to keep the number of messages in the  
message exchange down.

This is why I think we need a higher-level discussion of which  
messages are used
to convey the Offer and the Answer.

> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- 

I took a quick look at this document.
There seems to be some ideas similar to ICE here, but they seem to be  
missing
a number of ideas necessary for working with NATs.
The most important is the concept of having the probe response return  
the
address and port that it viewed the probe as having come from.
(This is known as the peer-reflexive address). This is important when  
working
with NATs that assign new address-and-port combinations to every  
destination.
Also, ICE ordered the connectivity checks in a particular way, and  
requires that
both endpoints use the same ordering. There are reasons to do this  
(though I have heard
the argument that the recent ICE change to add Controlling and  
Controlled endpoints
make this ordering much less important).
And I don't understand why the Probe message in the SHIM6 document is  
so huge?
Why include the "Nth probe sent" stuff? Or maybe I totally  
misunderstand the purpose
of the Probe message.

- Philip

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 24 Jun 2007 15:55:28 +0200

Hi Phillip,

just a minor comment:

~snip~

>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-08.txt 
>>
>
> The most important is the concept of having the probe response return the
This document is a good example of what happens if different groups in 
the IETF work independent of each other and they develop something 
similar twice. If you enhance this functionality to work in IPv4/IPv6 
environments etc. then you will get (some time later) get close to the 
functionality of ICE/STUN (with the minor difference that ICE and STUN 
is already deployed today and none of the SHIM6 protocols is).

Ciao
Hannes

---

From: Philip Matthews <[email-masked]>
Date: Sun, 24 Jun 2007 09:56:49 -0400

On 23-Jun-07, at 15:51 , Hannes Tschofenig wrote:

> unaware NAT traversal work.

Personally speaking, I don't see NATs going away very soon (as much  
as I might like them too ;-), and even if they do, I think we will  
still have firewalls that implement the filtering concept of NATs  
today. So I think that making NATs HIP-aware is a much easier thing  
to make happen.

So I personally think it is important that we work out a good story  
for how HIP-aware NATs work and make sure this integrates well with  
the rest of the NAT traversal for HIP work.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Sun, 24 Jun 2007 10:10:34 -0400

> having to parse the STUN messages and (b) demultiplexing STUN and HIP.

I agree that demultiplexing STUN and HIP can be done reliably.
(I wasn't actually worried about this).

If we put the source and destination HITs into the USERNAME attribute
(as you suggested), then building a HIP-aware NAT becomes more possible.
However, wouldn't the NAT also have to store the transaction id,
in order to route the BindingResponse message back to the endpoint,
since the USERNAME attribute is not included in the BindingResponse  
message?
Would this mean that the NAT would also have to duplicate the logic  
of the
endpoint's STUN state machine, in order to figure out when it could  
forget
the transaction id? What are the security implications of this?

- Philip

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 24 Jun 2007 16:06:39 +0200

Hi Phillip,

I agree that it might be nice to have a NAT traversal story where the 
NAT participates in the exchange. Dan tried to have a BOF at the next 
IETF meeting to get this work for STUN, as you might know.

A couple of us have tried to develop different protocols already that 
could interact with NATs and firewalls in order to control them. How 
many of them are deployed today? Not too many. You might want to look at 
a recently published document that tries to high-light some of the 
recent work in this field:

http://www.ietf.org/internet-drafts/draft-eggert-middlebox-control-survey-00.txt

Let me tell you that the reason that these protocols are not widely 
deployed is non-technical. Hence, I am not so sure about the widespread 
deployment you might see. I do, however, agree with you that we are 
going to see NATs, stateful packet filtering firewalls and similar boxes 
hanging around probably for ever.

Ciao
Hannes

PS: I have also contributed a document to the HIPRG on HIP-aware NAT 
traversal:
http://www.tschofenig.com/svn/draft-tschofenig-hiprg-hip-natfw-traversal/draft-tschofenig-hiprg-hip-natfw-traversal-05.txt
In earlier versions it also contained a solution but we removed that 
based on comments. In general the amount of feedback we got was pretty 
small.
Hence, I wasn't quite sure whether that doc will ever get progressed to 
an RFC.

Philip Matthews wrote:
>> unfortunately impacts the current protocol design of the HIP-unaware 
>> NAT traversal work.
>
> Personally speaking, I don't see NATs going away very soon (as much as 
> I might like them too ;-), and even if they do, I think we will still 
> have firewalls that implement the filtering concept of NATs today. So 
> I think that making NATs HIP-aware is a much easier thing to make happen.
>

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 24 Jun 2007 19:10:05 +0300

Phillip, Hannes, Dan,

How are you planning to address security?

Has anyone analysed the DoS/DDoS resistance properties of ICE/STUN?

Personally, I don't see any point in making HIP to support other than  
fully HIP-aware and legacy NATs.  For the HIP-aware case, I'd prefer  
if we could work out the NAT travesal in such a away that we could  
make the NATs to benefit from the DoS resistance of HIP and perhaps  
even DDoS resistance along some Hi3-like ideas.

--Pekka

---

From: Miika Komu <[email-masked]>
Date: Mon, 25 Jun 2007 12:03:31 +0300 (EEST)

On Fri, 22 Jun 2007, Philip Matthews wrote:

> it seems to me that it would be good to step back for a moment and have a 
> discussion on some basic design choices. Discussing these individually would 
> help the design process, in my opinion.

Just a reminder that the complete revised version has not submitted yet 
because there is still time to the submission DL. The revised version is 
here:

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

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

---

From: Miika Komu <[email-masked]>
Date: Mon, 25 Jun 2007 14:47:02 +0300 (EEST)

On Fri, 22 Jun 2007, Philip Matthews wrote:

> The first is the question of deployment. STUN is currently deployed today, so 
> there are STUN servers that a HIP node could use. But is this really 
> important? If we build enhanced HIP functionality into HIP and into RVSes, 
> then I think there will always be a public server around that a HIP node 
> could use to discover its reflexive address.

The use of a HIP-aware middlebox in reliable legacy NAT traversal is 
mandatory. If there is no HIP-aware middlebox, HIP NAT traversal cannot be 
guaranteed. Thus, a host at least one HIP-aware middlebox for successful 
NAT traversal. The middlebox can also server as a STUN-like server, so 
there is not much other benefit from STUN servers other than to provide 
redundant support for NAT detection.

It is also possible for the HIP middlebox to borrow bindings using regular 
STUN from regular STUN servers and communicate these to the client.

> But how does this work if we use STUN instead? In this case, the packet 
> would consist of a STUN message riding directly over IP (but where the 
> IP protocol field would specify HIP rather than STUN). In order for the 
> NAT to create the appropriate bindings, the STUN message would need to 
> contain the source and destination HITs somewhere in the message. The 
> only place to carry these in STUN is in some STUN attribute. So this 
> means that the NAT has to be able to do a fairly complete parse of a 
> STUN message.
>
> Requiring a HIP-aware NAT to do a fairly complete parse of a STUN message

Agree.

---

From: Miika Komu <[email-masked]>
Date: Mon, 25 Jun 2007 14:47:18 +0300 (EEST)

> The important difference with draft-tschofenig-hip-ice isn't the

Disagree. I think the debate is exactly about the format on the 
wire, see below.

>      assured (which is necessary to keep all the NATs open).

This functionality is already available in 
draft-ietf-hip-nat-traversal-02-pre6.txt, so I would insist that the 
debate is about the format-on-the-wire.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Jun 2007 13:51:32 +0200

What do you mean by "The use of a HIP-aware middlebox in reliable legacy 
NAT traversal is mandatory."?

A HIP aware middlebox is a NAT or a firewall that understands HIP. None 
of the drafts in the HIP working group address that topic.

Ciao
Hannes

Miika Komu wrote:
> mandatory. If there is no HIP-aware middlebox, HIP NAT traversal 
> cannot be guaranteed. Thus, a host at least one HIP-aware middlebox 
> for successful NAT traversal. The middlebox can also server as a 
> STUN-like server, so there is not much other benefit from STUN servers 
> other than to provide redundant support for NAT detection.
>
> It is also possible for the HIP middlebox to borrow bindings using 
> regular STUN from regular STUN servers and communicate these to the 
> client.
>
>> But how does this work if we use STUN instead? In this case, the 
>> packet would consist of a STUN message riding directly over IP (but 
>> where the IP protocol field would specify HIP rather than STUN). In 
>> order for the NAT to create the appropriate bindings, the STUN 
>> message would need to contain the source and destination HITs 
>> somewhere in the message. The only place to carry these in STUN is in 
>> some STUN attribute. So this means that the NAT has to be able to do 
>> a fairly complete parse of a STUN message.
>>

---

From: Miika Komu <[email-masked]>
Date: Mon, 25 Jun 2007 14:52:15 +0300 (EEST)

On Sun, 24 Jun 2007, Pekka Nikander wrote:

Pekka,

draft-ietf-hip-nat-traversal-02-pre6 already contains the HIP parameters 
that you talking about, such as REG_REQ of type "BindingRequest". The 
draft also contains path exploration similar to SHIM6 although I have to 
improve that part.

> Therefore, mapping STUN Attributes to HIP Parameters should be a trivial 
> task:
>
> 2. Use the HIP Length computation method in order to make the handling of all 
> HIP parameters, including those based on STUN, to use the same method.
>
> Though, for some Attributes it might be better to use already defined HIP 
> equivalents.  For example, I could imagine that it would make sense to use 
> HIP Sequence Number and Acknowledgement parameters.  And as already discussed 
> in my previous message, for ICE candidates it would probably be better to use 
> the HIP LOCATOR parameter, extended in a suitable way to encode the required 
> locator formats in a sensible way.
>
> One benefit here might be that HIP contains mechanisms that can be used to 
> allow "transactions" to overlap.
>
> The BindingRequest (or equivalent info mapped on the Registration protocol)
> 1. Simply carry BindingRequest as an additional parameter wherever you carry 
> a REG_REQ parameter, or
> 1. Simply carry BindingResponse in any message responding to a previous 
> message carring a BindingRequest.
>> of (source IP address, source port, dest IP address, dest port, protocol).
>> To do this, both endpoints send STUN BindingRequest messages to each other
> As an initial approximiation, I think that a variant of the HIP MM protocol, 
> drawing from the ICE experience and SHIM6 exploration formats, might be the 
> best way forward.  But here I might be completely wrong; there seems to be 
> subtleties that I don't understand.
>
> My main point here is that NAT such exploration should not be limited to the 
> NAT traversal case but should allow any two HIP hosts to explore the 
> characteristics of all paths, independent of whether the paths are based on 
> IPv4, IPv6, and contain no, transparent, or explicit middle boxes.  From my 
> point of view, most of the required components for such a mechanism are 
> already there scattered over the various HIP drafts; what is missing is the 
> algorithms and state machine definitions for utilising them.  But perhaps I'm 
> too simple minded here.
>
> --Pekka

---

From: Miika Komu <[email-masked]>
Date: Mon, 25 Jun 2007 14:52:24 +0300 (EEST)

On Sun, 24 Jun 2007, Philip Matthews wrote:

> So I personally think it is important that we work out a good story for how 
> HIP-aware NATs work and make sure this integrates well with the rest of the 
> NAT traversal for HIP work.

In draft-ietf-hip-nat-traversal-02-pre6, the story is that the NAT hosts 
send also non-UDP encapsulated messages to peers (unreflexive, reflexive 
peer and relay locators). Text needs some improving regarding to this.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Jun 2007 13:53:15 +0200

Hi Miika

Miika Komu wrote:
> Disagree. I think the debate is exactly about the format on the wire, 
> see below.
>
The encoding of the candidates that are exchanged is not really so 
important. The concept is important and to make use of work that was 
done elsewhere is (rather than reinventing the wheel).

Ciao
Hannes

---

From: Miika Komu <[email-masked]>
Date: Mon, 25 Jun 2007 15:11:00 +0300 (EEST)

On Mon, 25 Jun 2007, Hannes Tschofenig wrote:

> What do you mean by "The use of a HIP-aware middlebox in reliable legacy NAT 
> traversal is mandatory."?

There must be a middlebox that relays HIP control packets when the 
Responder or both peers are behind NATs. The relay is also very important 
when there are p2p-unfriendly NATs on the path.

> A HIP aware middlebox is a NAT or a firewall that understands HIP. None of 
> the drafts in the HIP working group address that topic.

draft-ietf-hip-nat-traversal-02-pre6 includes a HIP-relay for forwarding 
UDP-encapsulated HIP control packets.

Btw, I don't understand why the rendezvous servers need to talk each other 
as described in Figure 1 of draft-tschofenig-hip-ice-00 ? At least in the 
hip-rvs specification (and also nat-02-pre06), the Initiator contacts 
directly the RVS of the Responder.

---

From: Miika Komu <[email-masked]>
Date: Mon, 25 Jun 2007 15:15:16 +0300 (EEST)

On Mon, 25 Jun 2007, Hannes Tschofenig wrote:

>> Disagree. I think the debate is exactly about the format on the wire, see 
>> below.
>> 
> The encoding of the candidates that are exchanged is not really so important. 
> The concept is important and to make use of work that was done elsewhere is 
> (rather than reinventing the wheel).

Hi Hannes,

just to clarify, draft-ietf-hip-nat-traversal-02-pre6 does reinvent any 
wheel but rather is based on ICE concepts, similarly as 
draft-tschofenig-hip-ice-00.

---

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

> Disagree. I think the debate is exactly about the format on the  

I think it is partly about the format on the wire, but partly about  
other things,
such as which packets to  do the Offer/Answer exchange, what security  
mechanism
to use, and how we handle mobility.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Mon, 25 Jun 2007 13:11:38 -0400

On 25-Jun-07, at 08:11 , Miika Komu wrote:

>> What do you mean by "The use of a HIP-aware middlebox in reliable  
>> legacy NAT traversal is mandatory."?

I think Miika is using the term "middlebox" to mean any device that  
operates above the IP layer along the
path from the Initiator to the Responder.  This includes NATs, RVSs,  
etc.

I think that Hannes is using the term "middlebox" to refer to just  
NATs and Firewalls.

- Philip