Subject: RE: AW: [Hipsec] Rebuilding ICE

From: "Marcus Brunner" <[email-masked]>
Date: Mon, 9 Jul 2007 17:39:09 +0200

Hannes, et al.

The basic idea behind HIP NAT version 00 and version 01 was on getting a first quick hack to experiment with HIP over NATs, for distributed tests etc. Also version 01 seamed to technically work, for most cases, but not all of them. Now going down the ICE path, I project another 2-3 years of discussion on getting it resolved. 

My proposal would be to have a quick 01 follow-up draft trying to close that way of doing HIP over legacy NATs, and at the same time really do a HIP ICE draft, probably in the HIP RG first, because I am not completely sure whether all the 100 pages of ICE are applicable right away to HIP (not only the encoding part).

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: Thursday, June 28, 2007 8:14 PM
> To: Marcus Brunner
> Cc: Pekka Nikander; Tschofenig, Hannes; HIP WG
> Subject: Re: AW: [Hipsec] Rebuilding ICE
> 
> 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
> >
> > ---------------------------------------------------
> >
> > 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: 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,
> >>
> >>     
> >>> 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.
> >>>       
> >> 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.
> >>
> >>     
> >>>>  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.
> >>>       
> >> 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
> >>
> >>
> >> _______________________________________________
> >> Hipsec mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/hipsec
> >>
> >>     
> 
> 

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 10 Jul 2007 16:44:34 -0700

Yes, it is clear that not all 100 pages of ICE would apply to HIP.

The first version of ICE (draft-rosenberg-sipping-ice-00.txt, Feb-2003) was
34 pages.  That is only one page longer than
draft-ietf-hip-nat-traversal-00!  In four and a half years of design, ICE is
now 110 pages long and is used on the Internet (Google, MSN, and Yahoo use
ICE for their interactive audio and video features).

I expect the HIP working group (or IRTF, as you are proposing) could
re-invent ICE in less than 4.5 years -- afterall, ICE can be used as a
design guide.  However, what is the value in spending IETF/IRTF time and
energy re-inventing ICE?  Any shortcuts may not work well, whereas ICE was
designed (and works) in all NAT scenarios after significant peer review.
Those additional 70 pages in ICE weren't added because the author's fingers
needed the exercise!  There are already ICE libraries available with
reasonable licensing terms.  There are people willing to help HIP (and MIP,
and RTSP) get ICE specified.

My attempt to improve HIP's NAT traversal are clearly undesired by the
working group.  If and when HIP desires a functional, robust, and
incrementally-deployable NAT traversal mechanism, that works on the
Internet, hopefully someone will drop me an email and I can engage with HIP
again.

-d

> From: Marcus Brunner [mailto:[email-masked]] 
> Sent: Monday, July 09, 2007 8:39 AM
> To: Hannes Tschofenig
> Cc: HIP WG; Tschofenig, Hannes
> Subject: RE: AW: [Hipsec] Rebuilding ICE
> 
> Hannes, et al.
> 
> The basic idea behind HIP NAT version 00 and version 01 was 
> on getting a first quick hack to experiment with HIP over 
> NATs, for distributed tests etc. Also version 01 seamed to 
> technically work, for most cases, but not all of them. Now 
> going down the ICE path, I project another 2-3 years of 
> discussion on getting it resolved. 
> 
> My proposal would be to have a quick 01 follow-up draft 
> trying to close that way of doing HIP over legacy NATs, and 
> at the same time really do a HIP ICE draft, probably in the 
> HIP RG first, because I am not completely sure whether all 
> the 100 pages of ICE are applicable right away to HIP (not 
> only the encoding part).
> 
> Kind regards,
> 
> Marcus
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria 
> Road, London W3 6BL | Registered in England 2832014
> 
>  
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 12 Jul 2007 22:46:46 +0300

Hi Dan,

> Internet, hopefully someone will drop me an email and I can engage with HIP

many people in the HIP WG appreciate your input very much. It is just 
that some people are not familiar with ICE and have a gut feeling that 
it is too complex. I hope that the ICE tutorial to be held in Chicago 
helps everybody understand where the complexity of ICE comes from and 
why it is there (i.e., it resolves a complex problem).

I also hope that, after that tutorial, technical discussions on this 
topic are somewhat more fruitful than the ones we have had so far.

Cheers,

Gonzalo

---

From: "Marcus Brunner" <[email-masked]>
Date: Sun, 15 Jul 2007 16:41:26 +0200

> My attempt to improve HIP's NAT traversal are clearly 
> undesired by the working group.  If and when HIP desires a 
> functional, robust, and incrementally-deployable NAT 
> traversal mechanism, that works on the Internet, hopefully 
> someone will drop me an email and I can engage with HIP again.

Dan,

I am definitly not against improving HIP's NAT traversal, and I am greatful for good ICE knowledge on board. My main concern is the timing. I would have liked an RFC on an easy NAT traversal (which does not work in all circumstances) by now. Because now its time to experiment with HIP, which is explicitly an experimental RFC. We only gain more knowledge if we use HIP, which is realistically not possible without NAT traversal.

Marcus

> on getting 
> > a first quick hack to experiment with HIP over NATs, for 
> distributed 
> > tests etc. Also version 01 seamed to technically work, for 
> most cases, 
> > but not all of them. Now going down the ICE path, I project another 
> > 2-3 years of discussion on getting it resolved.
> > 
> > My proposal would be to have a quick 01 follow-up draft trying to 
> > close that way of doing HIP over legacy NATs, and at the same time 
> > really do a HIP ICE draft, probably in the HIP RG first, 
> because I am 
> > not completely sure whether all the 100 pages of ICE are applicable 
> > right away to HIP (not only the encoding part).
> > 
> > Kind regards,
> > 
> > Marcus
> > 
> > > my opinion, so they could be discussed, whether they 
> apply to HIP. 
> > > The benefit naturally is that people seam to understand ICE.
> > > >
> > > at node-multi-homing, becasue it seams there are 
> similarities like 
> > > offered IP addresses/ports/.. to the responding peer.
> > > >
> > > >
> > > > Kind regards,
> > > >
> > > > Marcus
> > > >

---

From: Andrew McGregor <[email-masked]>
Date: Mon, 16 Jul 2007 02:49:38 +1200

Having NAT traversal that actually works is more important to have in  
published form than NAT traversal that kinda, sorta works, downhill  
with a tail wind.

I think it's worth having the existing draft, but the ICE mechanism  
is simply required for it to work well enough to be worth putting  
through the full publication process, which is after all extremely  
expensive.

So, I don't think Dan's attempts are undesired.  I think this issue  
is important enough to do right rather than quickly, which makes ICE  
important.

Andrew

On 16/07/2007, at 2:41 AM, Marcus Brunner wrote:

> I am definitly not against improving HIP's NAT traversal, and I am  
> greatful for good ICE knowledge on board. My main concern is the  
> timing. I would have liked an RFC on an easy NAT traversal (which  
> does not work in all circumstances) by now. Because now its time to  
> experiment with HIP, which is explicitly an experimental RFC. We  
> only gain more knowledge if we use HIP, which is realistically not  
> possible without NAT traversal.
>
> Marcus
>
>>
>> -d
>>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Sun, 15 Jul 2007 23:40:16 -0700

> is important enough to do right rather than quickly, which makes ICE  

+1.  Before we get too far down the specification path, it would be nice
to have good running code, and ICE libraries are worth a serious look.
It would also be nice to discuss detailed application-based HIP use
cases for NAT traversal, especially in the peer-to-peer scenarios.

Tom