Re: [Hipsec] Some concerns regarding legacy NAT traversal solution

[Philip Matthews <philip_matthews at magma.ca>]

Sorry to be slow in responding.
A few comments inline.
Hope this helps.
- Philip

On 5-Dec-07, at 00:21 , Tobias Heer wrote:

> Hello,
>
> After following the discussions about HIP, ICE/STUN, and NAT  
> traversal today in the WG, I had some concerns regarding possible  
> solutions. Of course, I trust in the judgement of the NAT team (you  
> have all been working on the issue for quite some time), however, I  
> wonder how a possible solution could (will) look like. I'm not  
> asking for details about an yet unspecified solution but I'm rather  
> interested in the design space (specifically what tradeoffs seem  
> acceptable/realistic). I'm specially interested in the opinion of  
> the TURN people in the design team as you probably have the best  
> knowledge to answer the questions.
>
> In case STUN will be used for HIP, will there be a penalty in terms  
> of RTTs for running the additional protocol (first one, then the  
> other, or partially parallel)? If yes, will this additional time  
> also be required if no NAT is present (e.g. when moving from behind  
> a NAT to an un-NATed location)?

I don't believe that any penalty will be required.
> Will STUN replace parts of the BEX or/and UPDATE procedure for  
> optimizing RTTs? If yes, how will these changes look like?

STUN will just be used for connectivity checks. There are changes  
needed in the BEX and UPDATE procedure for NAT Traversal, regardless  
of the connectivity check protocol.

> Will existing work based on HIP still be valid or will we have to  
> live with an entirely new BEX or UPDATE message exchange? Will  
> things like HIP aware NATs / Firewalls, etc. be harder to implement  
> because they must support both (STUN + HIP)?

HIP-aware NATs and FWs might also need to understand STUN. However,  
there are other reasons to suspect that STUN-aware NATs and FWs might  
be produced.

> Concluding, is consistency with the MM and Base draft one of the  
> design goals of the NAT design team or may parts of these documents  
> be obsoleted by the NAT traversal approach?

We will try to kept things fairly close, but changes WILL be required.
> To state it clearly: I'm not advocating any of the approaches...  
> I'm just interested what's possible and what's not. I hope I'm not  
> being too nosy. Thanks in advance.
>
> Best regards,
>
> Tobias
>
>
>
>
>
>
> -- Dipl.-Inform. Tobias Heer, Ph.D. Student
> Distributed Systems Group
> RWTH Aachen University, Germany
> http://ds.cs.rwth-aachen.de/members/heer
>
>
>
>
>
> _______________________________________________
> Hipsec mailing list
> Hipsec at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/hipsec


_______________________________________________
Hipsec mailing list
Hipsec at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hipsec