[Hipsec] Some concerns regarding legacy NAT traversal solution

[Tobias Heer <heer at cs.rwth-aachen.de>]

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)?

Will STUN replace parts of the BEX or/and UPDATE procedure for  
optimizing RTTs? If yes, how will these changes look like? 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)?

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?

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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