Subject: RE: [Hipsec] NAT Traversal in HIP

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 4 Sep 2007 09:01:31 -0700

Miika, some responses inline:

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]] 
> Sent: Thursday, August 30, 2007 11:14 PM
> To: Henderson, Thomas R
> Cc: Pekka Nikander; Gonzalo Camarillo; HIP
> Subject: RE: [Hipsec] NAT Traversal in HIP
> 
> On Wed, 29 Aug 2007, Henderson, Thomas R wrote:
> 
> Hi Tom,
> 
> >> Gonzalo, all,
> >>
> >>> 1) Shall we use the ICE methodology or not?
> >>
> >> In the long run, I think we should use ICE *methodology*.  On the
> >> other hand, I think it would be *good* for people to 
> experiment with
> >> lesser functionality very soon, i.e., now.  But the latter can be
> >> done by the experimenters agreeing on some interim draft 
> and working
> >> from that.  The WG doesn't need to be directly involved.
> >
> > I agree that there should be some experimental work done 
> before we can
> > reach a definitive conclusion.  From my perspective, I am 
> inclined to
> > try to take an existing ICE library and modify it as little 
> as possible
> > to make it work with our HIP implementation.
> 
> Yes, it seems tempting implementation wise, but I have 
> expressed several 
> concerns on this list which should be addressed first. 

I am not suggesting that existing ICE library is the answer, but that I
would rather look at the existing capabilities first of ICE and also the
Cornell NUTSS software to see how much is already there.  I guess that
my point is that if you start writing the HIP relay server from scratch,
you miss the opportunity to learn how existing approaches can be
leveraged.  That is why I just said that my inclination is to try the
existing approaches first and see where the holes may be.

> The 
> major problems 
> seem to be:
> 
> * HIP Relay server: this is needed for guaranteed NAT traversal.
>    The relay has to forward HIP control packets which contain 
> the transport
>    address candidates. So we can't use STUN servers for this.

I think that this is an open question that deserves further study.

> * HIP mobility and multihoming: this will get messy with ICE? This may
>    also reduce code reusability from ICE significantly.

This (messiness) is probably true, although code reuse ultimately is not
the main goal.

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

I think I would say the goal is to achieve interoperability, and whether
a single or multiple approaches leads to this is for further study.

I appreciate that you have already done a lot of work on this and maybe
I just need to catch up to your level of understanding.

Tom

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 7 Sep 2007 17:31:50 +0200

catching up....

>   also reduce code reusability from ICE significantly.

maybe true, but if you want to support mobility and multihoming on  
nated environments, you need extra functionality that currently is  
not there and then you need to add ICE like capabilities.

I mean, for example, for multihoming, you need failure detection.  
This probably involves sending some periodic probes. OTOH, in a nated  
environment, you need to send probes to keep the state alive. I guess  
it makes most sense to use the same probes for keeping the nat state  
alive and for failure detection. Bottom line is that this will get  
messy in any case, because there seems to be a lot of interactions  
between the multihoming mechanisms and the nat traversal mechanisms.

OTOH, my personal opinion at this stage, is that it will be easier to  
extend ICE to support the additional features needed like failure  
detection in mulithomed environments) than to extend current  
multihoming techniques to support all the nat traversal stuff. So  
from a practical perspective, i would start from ICE and extend it to  
support the additional features needed.

regards, marcelo

---

From: Miika Komu <[email-masked]>
Date: Mon, 10 Sep 2007 11:51:22 +0300 (EEST)

On Fri, 7 Sep 2007, marcelo bagnulo braun wrote:

Hi Marcelo,

> maybe true, but if you want to support mobility and multihoming on nated 
> environments, you need extra functionality that currently is not there and 
> then you need to add ICE like capabilities.
>
> I mean, for example, for multihoming, you need failure detection. This 
> probably involves sending some periodic probes. OTOH, in a nated environment, 
> you need to send probes to keep the state alive. I guess it makes most sense 
> to use the same probes for keeping the nat state alive and for failure 
> detection. Bottom line is that this will get messy in any case, because there 
> seems to be a lot of interactions between the multihoming mechanisms and the 
> nat traversal mechanisms.
>
> OTOH, my personal opinion at this stage, is that it will be easier to extend 
> ICE to support the additional features needed like failure detection in 
> mulithomed environments) than to extend current multihoming techniques to 
> support all the nat traversal stuff. So from a practical perspective, i would 
> start from ICE and extend it to support the additional features needed.

how would you suggest solving the rendezvous/relay problem using ICE?

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

---

From: Miika Komu <[email-masked]>
Date: Tue, 11 Sep 2007 17:08:24 +0300 (EEST)

On Tue, 4 Sep 2007, Henderson, Thomas R wrote:

Hi Tom,

> existing approaches first and see where the holes may be.

The NUTSS stuff is interesting but I think it belongs the RG for the time 
being.

> I think that this is an open question that deserves further study.

I have presented a concrete specification for a HIP-relay middlebox in the 
02 version of the draft. So far, nobody has presented an alternative. I 
think the Relay spec in 02 version of the draft could be used also if the 
WG wants ICE format for the messages.

> I just need to catch up to your level of understanding.

Well, one option could be to design an alternative NAT traversal mechanism 
in the RG, perhaps based on NUTSS architecture. Is this what you are 
suggesting?

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 11 Sep 2007 08:20:15 -0700

Miika,

> WG wants ICE format for the messages.

If you think of ICE/STUN running underneath HIP, rather than being
integrated with HIP, then the alternative is STUN used in conjunction
with existing HIP rendezvous/lookup services.

> in the RG, perhaps based on NUTSS architecture. Is this what you are 

No, I'm mainly suggesting trying to experiment with a few approaches
before deciding, and to see how far we could get before committing to an
explicit relay box.  If we get to the point where we need relays in the
data path, we should also look at Hi3 architecture again.

- Tom

---

From: Miika Komu <[email-masked]>
Date: Tue, 11 Sep 2007 19:17:19 +0300 (EEST)

On Tue, 11 Sep 2007, Henderson, Thomas R wrote:

Tom,

> with existing HIP rendezvous/lookup services.

I am sorry but this "high level" approach already hit the wall as 
explained details of the earlier emails. This has been already reasoned in 
several emails why this kind of "insulating" layering does not work. I 
tempt you to be more specific :)

> data path, we should also look at Hi3 architecture again.

We need a middlebox anyway to forward the address candidates. There is no 
way of circumvating this in a reliable manner.

The middlebox can be explicit or implicit. However, I argue that an 
completely implicit relay will mean triangular routing for ESP, which 
should be avoided at any cost.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 11 Sep 2007 09:46:22 -0700

Miika,

> tempt you to be more specific :)

draft-tschofenig-hip-ice-00.txt was suggested today to be within scope
of the design team.  

- Tom