Subject: [Hipsec] Rebuilding ICE

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Jun 2007 14:00:45 +0200

I am really concerned about the current HIP NAT traversal work since one 
of the authors tries to re-build the ICE specification step-by-step 
without noticing that one could easily make us of it.

I agree that you can turn any protocol in any other one if you just work 
hard enough. It took more than a years to figure out that there is 
something like ICE. How long will it take to copy it?

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

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 25 Jun 2007 19:25:17 +0300

Just for the record:

Firstly,  I would be very worried about blindly adopting ICE for HIP  
as it.  I don't see them as an architecturally nice fit.  They have  
grown from different starting points, and that shows.

Secondly,  someone from the "ICE camp" claimed that the wire formats  
don't matter.  If they indeed don't, what's wrong with adopting the  
ICE semantics but using HIP wire formats?

--Pekka Nikander

On 25 Jun 2007, at 15:00, Hannes Tschofenig wrote:

> I am really concerned about the current HIP NAT traversal work  
> since one of the authors tries to re-build the ICE specification  
> step-by-step without noticing that one could easily make us of it.
>
> I agree that you can turn any protocol in any other one if you just  
> work hard enough. It took more than a years to figure out that  
> there is something like ICE. How long will it take to copy it?
>
>
>

---

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

Also for the record:

I have no clue why everyone is totally focused on the wire format.

The ICE document has 100+ pages
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt
and the most important considerations are not about the wire format.

Ciao
Hannes

Pekka Nikander wrote:
>> I am really concerned about the current HIP NAT traversal work since 
>> one of the authors tries to re-build the ICE specification 
>> work hard enough. It took more than a years to figure out that there 
>> is something like ICE. How long will it take to copy it?
>>
>>
>>

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 25 Jun 2007 22:45:44 +0300

Hannes,

First, I may be completely wrong here since I haven't had time to  
read any of the in question drafts and most probably won't have that  
time, either.  However, as far as I've understood, what Miika et al  
have done is pretty straightforward adoption of ICE, with the  
exception of the wire formats.  Hence, my (perhaps very flawed)  
understanding of their draft is that they are relying on the ICE  
spec, basically adopting it to the HIP environment by re-using the  
mechanisms and semantics and re-defining new wire formats and messages.

But maybe I'm wrong.  I'm sure Miika can clarify.

Personally, I don't see how a protocol changes if the protocol  
machine is kept the same and there are semantically equivalent  
messages and parameters.  At least the formal model of the protocol  
nor the formal characteristics don't change from such re-labeling of  
the messages and parameters.  Yes, sure, its interactions with the  
environment may changes, but as I have already explained, my  
understanding of the goal here is to make HIP to work with legacy  
NATs.  HIP-aware NATs are then a different story -- they have already  
been implemented; you are yourself a co-author of the SecureComm  
SPINAT paper.

Why I'm giving my opinions here is that I'm (perhaps surprisingly)  
still interested about the sanity and cleanliness of HIP, in terms of  
implementation and architecture.  I don't want it to be  
*unnecessarily* messed with non-suitable wire formats or additional,  
avoidable messages.  However, if there are clear, quantifiable  
*reasons* why doing the thing differently that what Miika et al have  
done so far, sure, we need to learn that.  And adopt accordingly.

I've tried to explain my reasons, as clearly as I can.  I haven't  
seen much *well-founded* reasoning yet from you, but maybe I'm just  
blind and doesn't see it at the front of my eyes.

--Pekka

On 25 Jun 2007, at 22:21, Hannes Tschofenig wrote:

>> Firstly,  I would be very worried about blindly adopting ICE for  
>> HIP as it.  I don't see them as an architecturally nice fit.  They  
>> have grown from different starting points, and that shows.
>>
>> Secondly,  someone from the "ICE camp" claimed that the wire  
>> formats don't matter.  If they indeed don't, what's wrong with  
>> adopting the ICE semantics but using HIP wire formats?
>>
>> --Pekka Nikander
>>
>>> I agree that you can turn any protocol in any other one if you  
>>> just work hard enough. It took more than a years to figure out  
>>> that there is something like ICE. How long will it take to copy it?
>>>
>>>
>>>

---

From: Miika Komu <[email-masked]>
Date: Tue, 26 Jun 2007 00:04:59 +0300 (EEST)

On Mon, 25 Jun 2007, Pekka Nikander wrote:

> Hannes,
>
> First, I may be completely wrong here since I haven't had time to read any of 
> the in question drafts and most probably won't have that time, either. 
> However, as far as I've understood, what Miika et al have done is pretty 
> straightforward adoption of ICE, with the exception of the wire formats. 
> Hence, my (perhaps very flawed) understanding of their draft is that they are 
> relying on the ICE spec, basically adopting it to the HIP environment by 
> re-using the mechanisms and semantics and re-defining new wire formats and 
> messages.
>

You are correct. I'd be happy to discuss if there is something 
essential still missing from the draft.

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

---

From: "Marcus Brunner" <[email-masked]>
Date: Mon, 25 Jun 2007 20:58:30 +0200

Sorry, but I don't get where the problem really is. Looks both approaches are sort of an ICE adaptation to HIP (I assume Hannes not proposing the ICE for SDP encoding for HIP or?).

If this is true, the details of both approaches must be on the table. Then we can discuss. 

Kind regards,

Marcus

---------------------------------------------------

Dr. Marcus Brunner
NEC Laboratories Europe
Network Division

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Monday, June 25, 2007 2:01 PM
> To: 'HIP WG'
> Subject: [Hipsec] Rebuilding ICE
> 
> I am really concerned about the current HIP NAT traversal 
> work since one of the authors tries to re-build the ICE 
> specification step-by-step without noticing that one could 
> easily make us of it.
> 
> I agree that you can turn any protocol in any other one if 
> you just work hard enough. It took more than a years to 
> figure out that there is something like ICE. How long will it 
> take to copy it?
> 
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Jun 2007 09:41:23 +0200

Hi Marcus,

Thanks to Phillip Matthews and Dan Wing who actually pointed the group 
to ICE. Without them there would not be a single line in the current WG 
NAT traversal draft.

Instead of being thankful that the group receives input from other 
groups in the IETF a few individuals switched to the panic mode.

Hello?

In the IETF it is quite common to receive input from people that have a 
different background.

Ciao
Hannes

 > -----Ursprüngliche Nachricht-----
 > Von: Marcus Brunner [mailto:[email-masked]]
 > Gesendet: Montag, 25. Juni 2007 20:59
 > An: Hannes Tschofenig; HIP WG
 > Betreff: RE: [Hipsec] Rebuilding ICE
 >
 > Sorry, but I don't get where the problem really is. Looks
 > both approaches are sort of an ICE adaptation to HIP (I
 > assume Hannes not proposing the ICE for SDP encoding for HIP or?).
 >
 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria
 > Road, London W3 6BL | Registered in England 2832014
 >
 >  
 >

---

From: Andrew McGregor <[email-masked]>
Date: Tue, 26 Jun 2007 19:47:01 +1200

Hannes, there was quite a long conversation in Prague about the  
relationship between ICE and HIP, and IIRC that's where the approach  
of taking ICE mechanism into HIP packet formats came from.  I think  
the approach is valid, as the ICE formats were evolved in a  
completely different context.  It's also fairly clear that there is  
reason to somewhat adapt ICE anyway; it does provide us with a very  
well researched set of mechanisms for traversing NATs, but it also  
brings along some SIP-specific baggage that could be removed without  
harming the NAT traversal.

Andrew

On 26/06/2007, at 7:41 PM, Hannes Tschofenig wrote:

> Hi Marcus,
>
> Thanks to Phillip Matthews and Dan Wing who actually pointed the  
> group to ICE. Without them there would not be a single line in the  
> current WG NAT traversal draft.
>
> In the IETF it is quite common to receive input from people that  
> have a different background.
>
> Ciao
> Hannes
>

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 26 Jun 2007 10:11:31 +0200

Hi all,

I think that the discussion slipped off the actually topic a bit. The  
main questions are basically:
1. the current HIP NAT traversal draft (draft-ietf-hip-nat-traversal-01)
2. using ICE and HIP in one way or the other

For 1:
There is some disagreement between the authors of the draft on how to  
continue with the draft as the WG approved approach (draft-ietf-hip- 
nat-traversal-01) and the current approach in the upcoming draft are  
fundamental different. We have asked the chairs about their opinion  
on this but have not received any answer.
IMHO I do not like the approach taken right now on rebuilding ICE and  
something different. I do like much more the simple approach take in  
draft-ietf-hip-nat-traversal-01 as we need to get a start on HIP's  
NAT traversal.

For 2:
Using something as ICE (must not be directly ICE, i.e., subject to  
further discussions) could be helpful for HIP's NAT traversal. BUT:  
The WG has agreed on the approach in draft-ietf-hip-nat-traversal-01  
and not on something different. Furthermore, I do think it is much  
more worth on completing existing work and to bring it to the field  
for further testing and studying (remember it is an experimental  
draft only!).
So, why not finishing things up first and going than for something  
different?

Thanks,

   Martin

Am 26.06.2007 um 09:47 schrieb Andrew McGregor:

> relationship between ICE and HIP, and IIRC that's where the  
> approach of taking ICE mechanism into HIP packet formats came  
> from.  I think the approach is valid, as the ICE formats were  
> evolved in a completely different context.  It's also fairly clear  
> that there is reason to somewhat adapt ICE anyway; it does provide  
> us with a very well researched set of mechanisms for traversing  
> NATs, but it also brings along some SIP-specific baggage that could  
> be removed without harming the NAT traversal.
>
> Andrew
>

[email-masked]
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,  
London W3 6BL | Registered in England 2832014

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 26 Jun 2007 09:03:10 +0200

Hi Marcus, 

Thanks to Phillip Matthews and Dan Wing who actually pointed the group to ICE. Without them there would not be a single line in the current WG NAT traversal draft. 

Instead of being thankful that the group receives input from other groups in the IETF a few individuals swiched to the panic mode.

Hello? 

In the IETF it is quite common to receive input from people that have a different background.

Ciao
Hannes

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 26 Jun 2007 10:00:05 +0200

Hi Andrew, 

> of taking ICE mechanism into HIP packet formats came from.

I tried to find the meeting minutes. 

  I think  
> completely different context.

ICE is a methodology. We suggest to make extensive use of it. 
The only "format" the ICE document suggests is the encoding of candiates. 
I have stated many times that one can think about a more optimized encoding. That's OK. 

>  It's also fairly clear that there is  
> reason to somewhat adapt ICE anyway;

That's fine. For example, I wrote that you could use the RVS as a reverse tunneling mechanism (in the spirit of TURN) to avoid using TURN. In an upcoming draft I will explain why it still makes a lot of sense to use TURN but that's another story. 

 it does provide us with a very  
> well researched set of mechanisms for traversing NATs,

That's also my line of thinking. Let's make use of this good work.

> but it also  
Jonathan tried to re-write the spec in such a way that the SIP content is focused on a few places. He did a fairly good job although there is still potential for improvement. I have noted (in the document) which parts are not applicable. There aren't too many of them. 

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Jun 2007 10:25:00 +0200

Hi Andrew,

  I think  

ICE is a methodology. We suggest to make extensive use of it.
The only "format" the ICE document suggests is the encoding of candiates.
I have stated many times that one can think about a more optimized 
encoding. That's OK.

 > reason to somewhat adapt ICE anyway;

That's fine. For example, I wrote that you could use the RVS as a 
reverse tunneling mechanism (in the spirit of TURN) to avoid using TURN. 
In an upcoming draft I will explain why it still makes a lot of sense to 
use TURN but that's another story.

 > harming the NAT traversal.
Jonathan tried to re-write the spec in such a way that the SIP content 
is focused on a few places. He did a fairly good job although there is 
still potential for improvement. I have noted (in the document) which 
parts are not applicable. There aren't too many of them.

Ciao
Hannes

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 26 Jun 2007 11:26:28 +0200

Hannes,

> I have stated many times that one can think about a more optimized  

I think we all understand the basic idea of ICE being a methodology.   
At least I am not objecting to using it, as a methodology.  However,  
in addition to defining the SDP encoding for the candidates, it also  
defines how to use STUN and TURN, so there are, indirectly, more  
formats and network nodes (TURN and STUN servers) built into ICE.

Now, from my point of view an important architectural is not to make  
HIP dependent on TURN and STUN servers, nor the UDP encapsulation  
formats used in STUN, nor any other such details.

HIP has already the rendezvous servers defined, and a well-defined  
mechanism for contacting hosts using the rendezvous servers.  It also  
already has a mobility mechanism, and a rudimentary mechanism for  
multi-homing.

I may have misunderstood, but from my point of view, using ICE  
terminology, HIP already seems to have the necessary mechanisms form  
Encoding, Offering and Answering, and Completing (I'm drawing these  
terms from the ICE tutorial, my apology if the spec uses other terms).

What HIP is primarily missing is Gathering and Prioritising, which  
BTW are not a real protocol issues, and therefore most probably could  
be quite easily adopted from ICE, and Checking, where the past idea  
was to use the SHIM6 protoocol.  For checking, the fact that native  
HIP uses both a separate protocol number of HIP control and ESP (or  
something else) for data traffic necessitates the ICE checking  
methodology to be modified anyway.  The same applies, as far as I can  
see, also to the NAT traversal case, where HIP is using the IPsec  
encoding of UDP, not generic UDP.  Hence, I don't think STUN applies  
there directly.

Remember, when HIP is used the UDP and TCP messages are carried  
encoded somehow, typically in ESP wrappers, and therefore some of the  
problems specific to ICE/STUN (like port reuse) don't apply or apply  
in a different form.

> reverse tunneling mechanism (in the spirit of TURN) to avoid using  
> TURN. In an upcoming draft I will explain why it still makes a lot  
> of sense to use TURN but that's another story.

For TURN I don't understand why it would make any sense to use it,  
but maybe I don't understand it, again.  Anyway, I would consider it  
undesirable to make HIP dependent on TURN.

If you would like to allow *optional* use of TURN, them I'm fine.  As  
long as the base HIP mechanisms would work with only one new piece of  
infrastructure, the RVS servers.

But I really would like to hear your detailed list of issues on the  
table.

--Pekka

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Jun 2007 10:35:01 +0200

Hi Martin,

thanks for your feedback and the assessment.

I also believe that the problems stated somewhere along the lines of 
modifying the scope of draft-ietf-hip-nat-traversal-01.

Here is what other working groups did. They essentially split the 
problem parts into separate chunks:

a) UDP Encapsulation of data traffic and signaling traffic
b) Allowing signaling messages to traverse a NAT (or firewall)
This would essentially be the communication between the end host and the 
RVS.
c) Traversal of NATs (and firewalls) when it comes to end-to-end 
communication for data traffic

ICE focuses on item (c). In SIP (a) and (b) are handled differently and 
also covered by different documents (i.e., outside the scope of ICE). In 
SIP, for example,
STUN is not used to perform NAT traversal of the SIP messages exchanged 
between the SIP UA and the outbound proxy.

With the discussions regarding ICE for HIP we focused on item (c) only. 
For example, there is nothing wrong with defining UDP encapsulation of 
signaling messages and data traffic as suggested in 
draft-ietf-hip-nat-traversal-01.

Ciao
Hannes

Martin Stiemerling wrote:
> continue with the draft as the WG approved approach 
> (draft-ietf-hip-nat-traversal-01) and the current approach in the 
> upcoming draft are fundamental different. We have asked the chairs 
> about their opinion on this but have not received any answer.
> draft-ietf-hip-nat-traversal-01 as we need to get a start on HIP's NAT 
> traversal.
>
> For 2:
> for further testing and studying (remember it is an experimental draft 
> only!).
> ------------------------------------------------------------------------
>

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 26 Jun 2007 13:26:47 +0200

Am 26.06.2007 um 10:35 schrieb Hannes Tschofenig:

> I also believe that the problems stated somewhere along the lines  
> of modifying the scope of draft-ietf-hip-nat-traversal-01.
>
> This would essentially be the communication between the end host  
> and the RVS.
> ICE focuses on item (c). In SIP (a) and (b) are handled differently  
> and also covered by different documents (i.e., outside the scope of  
> ICE). In SIP, for example,
> STUN is not used to perform NAT traversal of the SIP messages  
> exchanged between the SIP UA and the outbound proxy.
>
> With the discussions regarding ICE for HIP we focused on item (c)  
> only. For example, there is nothing wrong with defining UDP  
> encapsulation of signaling messages and data traffic as suggested  
> in draft-ietf-hip-nat-traversal-01.

It seems that we are on the same line :)

I also see draft-ietf-hip-nat-traversal-01 along the lines of a) and  
b). Point c) is out of scope of the WG draft draft-ietf-hip-nat- 
traversal-01, as we targeting to a nice, small solution to get some  
first hand experience with HIP and NATs.

Cheers,

   Martin

>> I think that the discussion slipped off the actually topic a bit.  
>> The main questions are basically:
>> There is some disagreement between the authors of the draft on how  
>> to continue with the draft as the WG approved approach (draft-ietf- 
>> hip-nat-traversal-01) and the current approach in the upcoming  
>> draft are fundamental different. We have asked the chairs about  
>> their opinion on this but have not received any answer.
>> IMHO I do not like the approach taken right now on rebuilding ICE  
>> and something different. I do like much more the simple approach  
>> take in draft-ietf-hip-nat-traversal-01 as we need to get a start  
>> on HIP's NAT traversal.
>>
>> For 2:
>> further discussions) could be helpful for HIP's NAT traversal.  
>> BUT: The WG has agreed on the approach in draft-ietf-hip-nat- 
>> traversal-01 and not on something different. Furthermore, I do  
>> think it is much more worth on completing existing work and to  
>> bring it to the field for further testing and studying (remember  
>> it is an experimental draft only!).
>>> evolved in a completely different context.  It's also fairly  
>>> clear that there is reason to somewhat adapt ICE anyway; it does  
>>> provide us with a very well researched set of mechanisms for  
>>> traversing NATs, but it also brings along some SIP-specific  
>>> baggage that could be removed without harming the NAT traversal.
>>>
>>> Andrew
>>>
>>>> group to ICE. Without them there would not be a single line in  
>>>> the current WG NAT traversal draft.
>>>>
>>>> Instead of being thankful that the group receives input from  
>>>> other groups in the IETF a few individuals switched to the panic  
>>>> mode.
>>>>
>>>> Hello?
>>>>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 26 Jun 2007 17:56:16 +0300

On 2007-6-26, at 10:03, ext Tschofenig, Hannes wrote:
> groups in the IETF a few individuals swiched to the panic mode.

I'm still catching up on this thread, but in several email messages  
I've read so far, Miika has acknowledged that the idea of adopting  
ICE concepts for HIP NAT traversal originated with Phillip. The  
acknowledgment section of his draft also credits Phillip.

To me, this looks like the editor of the WG document is giving credit  
where credit is due, on behalf of the working group.

Lars

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Jun 2007 17:15:46 +0200

Hi Martin,

Martin Stiemerling wrote:
>> This would essentially be the communication between the end host and 
>> the RVS.
>> encapsulation of signaling messages and data traffic as suggested in 
> b). Point c) is out of scope of the WG draft 
> draft-ietf-hip-nat-traversal-01, as we targeting to a nice, small 
> solution to get some first hand experience with HIP and NATs.
>
That's a good point. The scope of the document changed a bit. Maybe the 
first thing to think about is the scope of the work.

Ciao
Hannes

>>> to continue with the draft as the WG approved approach 
>>> take in draft-ietf-hip-nat-traversal-01 as we need to get a start on 
>>> HIP's NAT traversal.
>>>
>>> For 2:

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Jun 2007 17:13:44 +0200

That's certainly good.

Maybe the entire discussion start wasn't that great....
Let's see how we move forward.

Ciao
Hannes

Lars Eggert wrote:
> I've read so far, Miika has acknowledged that the idea of adopting ICE 
> concepts for HIP NAT traversal originated with Phillip. The

---

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

On Tue, 26 Jun 2007, Martin Stiemerling wrote:

> Hi all,
>
> I think that the discussion slipped off the actually topic a bit. The main 
> questions are basically:
> (draft-ietf-hip-nat-traversal-01) and the current approach in the upcoming 
> draft are fundamental different. We have asked the chairs about their opinion 

There is one severe, technical problem with 
draft-ietf-hip-nat-traversal-01. It is supposed to work with legacy NATs, 
but it does not really work with all legacy NATs. The approach requires 
that there are no p2p-unfriendly NATs between the hosts. Think about the 
challenging (common?) case where both peers are behind two NATs, one for 
ISP and one for the ADSL... which totals four NATs. Just one of them needs 
to be p2p-unfriendly and the NAT traversal fails There is no way in to 
fallback to full HIP+ESP relay in the draft.

There are some other, minor problems with the draft that related to the 
optimization, like choosing optimal paths for multihomable 
hosts and properly detecting when the hosts are behind the same NAT.

This is the reasoning why we had a look at ICE because it seemed to solve 
these problems in a better way. I don't see how the 
draft-ietf-hip-nat-traversal-01 approach can move forwards without 
introducing relay support somehow.

---

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

On Tue, 26 Jun 2007, Lars Eggert wrote:

Hi Lars,

> I'm still catching up on this thread, but in several email messages I've read 
> so far, Miika has acknowledged that the idea of adopting ICE concepts for HIP 
> NAT traversal originated with Phillip. The acknowledgment section of his 
> draft also credits Phillip.
>
> To me, this looks like the editor of the WG document is giving credit where 
> credit is due, on behalf of the working group.

there have been also other people included in the ICE discussions, such as 
Andrey McGregor and Tim Sheppard. There has not been any WG sessions 
lately where to promote the ideas on the mike, so it has been carried in 
private and public email conversions.

I guess the whole discussion started publicly on the mailing lists already 
in March by Gonzalo, so I wonder why there was not feedback earlier:

http://www1.ietf.org/mail-archive/web/hipsec/current/msg01969.html

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Jun 2007 23:52:45 -0700

> From: Miika Komu [mailto:[email-masked]] 
> Sent: Tuesday, June 26, 2007 2:42 PM
> To: Martin Stiemerling
> Cc: HIP WG
> Subject: Re: [Hipsec] Rebuilding ICE
> 
> to be p2p-unfriendly and the NAT traversal fails There is no 
> way in to fallback to full HIP+ESP relay in the draft.

Actually, _both_ need to be behind p2p-unfriendly NATs 
before a HIP and ESP relay is necessary -- if ietf-hip-nat-
traversal-02pre does triggered checks.  (This is what
I was referring to in an earlier message about the 10%
Google number.)

> introducing relay support somehow.

Unless you discard the case of both users behind p2p-unfriendly
NATs, I agree.

-d

---

From: Philip Matthews <[email-masked]>
Date: Thu, 28 Jun 2007 09:30:11 -0400

On 26-Jun-07, at 10:56 , Lars Eggert wrote:

> To me, this looks like the editor of the WG document is giving  
> credit where credit is due, on behalf of the working group.

For the record, I want to say that I don't think my work in bringing  
ICE to the attention of the HIP community was that big a deal -- I am  
sure that someone else would have pointed that out if I hadn't.

In fact, it probably would not have happened if Miika had not  
attended the P2PSIP WG meeting in Prague and mentioned HIP and his  
document.

What struck me when talking with Miika afterwords is how HIP and  
P2PSIP were going down similar paths. P2PSIP (because of its  
participants' familiarity with MMUSIC's work on ICE) seem to have a  
better NAT traversal story, while HIP had a better story in other  
places. This is what lead to draft-matthews-p2psip-hip-hop-00.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Thu, 28 Jun 2007 09:42:52 -0400

On 26-Jun-07, at 17:41 , Miika Komu wrote:

> There is one severe, technical problem with draft-ietf-hip-nat- 
> traversal-01. It is supposed to work with legacy NATs, but it does  
> not really work with all legacy NATs. The approach requires that  
> there are no p2p-unfriendly NATs between the hosts. Think about the  
> challenging (common?) case where both peers are behind two NATs,  
> one for ISP and one for the ADSL... which totals four NATs. Just  
> one of them needs to be p2p-unfriendly and the NAT traversal fails  
> There is no way in to fallback to full HIP+ESP relay in the draft.
>
> There are some other, minor problems with the draft that related to  
> the optimization, like choosing optimal paths for multihomable  
> This is the reasoning why we had a look at ICE because it seemed to  
> solve these problems in a better way. I don't see how the draft- 
> ietf-hip-nat-traversal-01 approach can move forwards without  

I would like to point out one other problem with the approach in  
draft-ietf-hip-nat-traversal-01. That approach used STUN only. Dan  
and I are currently working with Jonathan Rosenberg on revising the  
STUN specification. Unless we are overruled by the BEHAVE working  
group (which I do not expect), the final version of the revised STUN  
specification will strongly caution against that approach, except for  
those very specific cases where that approach is OK. I think it is  
pretty clear that HIP is NOT one of those situations, so I think  
there might be some difficulty in getting the approach of draft-ietf- 
hip-nat-traversal-01 through the IESG.

- Philip

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 28 Jun 2007 20:13:58 +0200

Hi Marcus,

which parts of ICE do you consider an overkill?

Ciao
Hannes

Marcus Brunner wrote:
> Pekka,
>
> Well put. I agree with you statement. 
>
> Some parts of the ICE methodoldy are a bit an overkill in my opinion, so they could be discussed, whether they apply to HIP. The benefit naturally is that people seam to understand ICE.
>
> Actually, I would even propose that we should have a look at node-multi-homing, becasue it seams there are similarities like offered IP addresses/ports/.. to the responding peer.
>
>
> Kind regards,
>
> Marcus
>
>> From: Pekka Nikander [mailto:[email-masked]] 
>> Sent: Tuesday, June 26, 2007 11:26 AM
>> To: Tschofenig, Hannes
>> Cc: HIP WG; Hannes Tschofenig; Marcus Brunner
>> Subject: Re: AW: [Hipsec] Rebuilding ICE
>>
>> Hannes,
>>
>>     
>> At least I am not objecting to using it, as a methodology.  
>> However, in addition to defining the SDP encoding for the 
>> candidates, it also defines how to use STUN and TURN, so 
>> there are, indirectly, more formats and network nodes (TURN 
>> and STUN servers) built into ICE.
>>
>> Now, from my point of view an important architectural is not 
>> to make HIP dependent on TURN and STUN servers, nor the UDP 
>> encapsulation formats used in STUN, nor any other such details.
>>
>> HIP has already the rendezvous servers defined, and a 
>> well-defined mechanism for contacting hosts using the 
>> rendezvous servers.  It also already has a mobility 
>> mechanism, and a rudimentary mechanism for multi-homing.
>>
>> I may have misunderstood, but from my point of view, using 
>> ICE terminology, HIP already seems to have the necessary 
>> mechanisms form Encoding, Offering and Answering, and 
>> Completing (I'm drawing these terms from the ICE tutorial, my 
>> apology if the spec uses other terms).
>>
>> What HIP is primarily missing is Gathering and Prioritising, 
>> which BTW are not a real protocol issues, and therefore most 
>> probably could be quite easily adopted from ICE, and 
>> Checking, where the past idea was to use the SHIM6 protoocol. 
>>  For checking, the fact that native HIP uses both a separate 
>> protocol number of HIP control and ESP (or something else) 
>> for data traffic necessitates the ICE checking methodology to 
>> be modified anyway.  The same applies, as far as I can see, 
>> also to the NAT traversal case, where HIP is using the IPsec 
>> encoding of UDP, not generic UDP.  Hence, I don't think STUN 
>> applies there directly.
>>
>> Remember, when HIP is used the UDP and TCP messages are 
>> carried encoded somehow, typically in ESP wrappers, and 
>> therefore some of the problems specific to ICE/STUN (like 
>> port reuse) don't apply or apply in a different form.
>>
>>     
>>>>  It's also fairly clear that there is reason to somewhat adapt ICE 
>>>> anyway;
>>>>         
>>> TURN. In an upcoming draft I will explain why it still 
>>>       
>> makes a lot of 
>>     
>>> sense to use TURN but that's another story.
>>>       
>> For TURN I don't understand why it would make any sense to 
>> use it, but maybe I don't understand it, again.  Anyway, I 
>> would consider it undesirable to make HIP dependent on TURN.
>>
>> If you would like to allow *optional* use of TURN, them I'm 
>> fine.  As long as the base HIP mechanisms would work with 
>> only one new piece of infrastructure, the RVS servers.
>>
>> But I really would like to hear your detailed list of issues 
>> on the table.
>>
>> --Pekka
>>
>>

---

From: "Marcus Brunner" <[email-masked]>
Date: Thu, 28 Jun 2007 20:13:09 +0200

Pekka,

Kind regards,

Marcus

Dr. Marcus Brunner
NEC Laboratories Europe
Network Division

---

From: Pekka Savola <[email-masked]>
Date: Fri, 29 Jun 2007 10:34:29 +0300 (EEST)

On Thu, 28 Jun 2007, Marcus Brunner wrote:
> Some parts of the ICE methodoldy are a bit an overkill in my 
> opinion, so they could be discussed, whether they apply to HIP. The 
> benefit naturally is that people seam to understand ICE.
>
> Actually, I would even propose that we should have a look at 
> node-multi-homing, becasue it seams there are similarities like 
> offered IP addresses/ports/.. to the responding peer.

Not speaking to rebuilding ICE.. but even earlier (let's say about 
1.5-2 years ago, on this list) I recall commenting that HIP NAT 
traversal work would be non-trivial and would end up reinventing 
Teredo.

It's disturbing that most protocols seem to have a need to rebuild 
their own NAT traversal mechanisms, but the IETF doesn't seem very 
good at tackling these kinds of issues.  I was suggesting that BEHAVE 
WG would be unnecessary if we just focused on IPv6 and IPv6-over-NAT 
transition mechanisms but that didn't seem to gain traction..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

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

On 29-Jun-07, at 03:34 , Pekka Savola wrote:

> good at tackling these kinds of issues.  I was suggesting that  
> BEHAVE WG would be unnecessary if we just focused on IPv6 and IPv6- 
> over-NAT transition mechanisms but that didn't seem to gain traction..

Isn't this exactly the problem that we are trying to solve with NAT  
traversal for HIP??

If all protocols ran over HIP, and if we solve the NAT traversal for  
HIP problem, then application protocols do not need to worry about  
NAT traversal.

This is one of the arguments made for using HIP for P2P overlays  
given in draft-matthews-p2psip-hip-hop-00.

- Philip

---

From: JiangXingFeng <[email-masked]>
Date: Sat, 30 Jun 2007 10:03:50 +0800

Hi, :

Solving NAT traversal issues at relative lower level protocol is a good
option, so that applications riding on this protocol could not care about
the existence of the NAT. 

HIP may be a choice to do this work. 

Regards!
--
Jiang XingFeng

> From: Philip Matthews [mailto:[email-masked]]
> Sent: Saturday, June 30, 2007 12:47 AM
> To: Pekka Savola
> Cc: Tschofenig, Hannes; HIP WG; Hannes Tschofenig; Marcus Brunner
> Subject: Re: [Hipsec] Every protocol in the IETF needs its own NAT
> traversalmechanism
> 
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 30 Jun 2007 10:32:51 +0200

Hi Jiang, 

I guess you misunderstood Pekka's comment a bit. 

He says that a number of protocols need to provide support for NAT traversal. He seems to believe that there is a potential for re-use.

You still need to provide NAT traversal support on the higher layers because you cannot assume lower layers to offer the support since there is no universal deployment for any of the lower layer protocols. 

P2P filesharing and gaming environments have the largest deployment from a NAT traversal support. They just use existing libraries that use very similar techniques as ICE (since that's the area where the ideas for ICE came from). I would be able to play any of my favorite games in case they would have waited for HIP, MIP etc. to come up with a lower layer mechanism ...

Technically speaking there is also a difference between the NAT traversal support at the lower layer and at higher layers because lower layers don't have a "flow" semantic. That is also the reason why we didn't see how to make use of the frozen candidates with ICE when applying them to HIP and MIP (but maybe we just need to think a bit more about it).

Ciao
Hannes

---

From: Miika Komu <[email-masked]>
Date: Sat, 30 Jun 2007 19:26:24 +0300 (EEST)

On Sat, 30 Jun 2007, Hannes Tschofenig wrote:

Hi Hannes,

> You still need to provide NAT traversal support on the higher layers 
> because you cannot assume lower layers to offer the support since there 
> is no universal deployment for any of the lower layer protocols.

I agree that there it would be nice that have libraries for applications 
doing NAT-traversal, and better yet, a standardized interface for it. 
However, deploying such a library will have even more difficult deployment 
hurdle than HIP, because it requires that the application using it will be 
modified.

> P2P filesharing and gaming environments have the largest deployment from 
> a NAT traversal support. They just use existing libraries that use very 
> similar techniques as ICE (since that's the area where the ideas for ICE 
> came from). I would be able to play any of my favorite games in case 
> they would have waited for HIP, MIP etc. to come up with a lower layer 
> mechanism ...

The problem is that there are too many "hacks" around to get around NATs. 
Some of them work better than others. I believe this is one of the main 
reasons for standardizing ICE (and now, HIP-ICE).

Also, I think it is quite possible that a game vendor could bundle its 
product along with a HIP-ICE implementation. This would bring additional 
benefits in terms of global end-to-end addressing and autenticating paying 
customers with public-key cryptography...