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

From: Tobias Heer <[email-masked]>
Date: Wed, 5 Dec 2007 09:21:59 +0100

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

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

---

From: Miika Komu <[email-masked]>
Date: Wed, 5 Dec 2007 21:49:35 +0200 (EET)

On Wed, 5 Dec 2007, Tobias Heer wrote:

Hi Tobias,

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

Yes there is some penalty. This is what we discussed earlier on nat design 
team list but it is somewhat modified (SEQ needs a separate ACK):

STUN-based approach:

L                       Relay(R)                         R
| UPDATE(LOCATOR,SEQ, SPI) |                             |
+------------------------->+                             |
|                          |                             |
|                          +---------------------------->|
|                          |                             |
|                          | UPDATE(LOCATOR,SPI,SEQ,ACK) |
|                          |<----------------------------|
|<-------------------------+                             |
|                          |                             |
|    UPDATE(ACK)           |                             |
+------------------------->|                             |
|                          |                             |
|                          +---------------------------->|
|                          |                             |
|               ICE connectivity tests                   |
|<------------------------------------------------------>|
|                          |                             |
|                         ESP                            |
|<------------------------------------------------------>|
|                                                        |

HIP-based approach:

L                       Relay(R)                         R
| UPDATE(LOCATOR,SEQ, SPI) |                             |
+------------------------->+                             |
|                          |                             |
|                          +---------------------------->|
|                          |                             |
|                          | UPDATE(LOCATOR,SPI,SEQ,ACK) |
|                          |<----------------------------|
|<-------------------------+                             |
|                          |                             |
|   UPDATEs(ECHO_REQUESTs, ACK and ECHO_RESPONSEs)       |
|<------------------------------------------------------>|
|                          |                             |
|                         ESP                            |
|<------------------------------------------------------>|
|                                                        |

So, the STUN approach has one extra packet going through the relay. In 
HIP, we can piggypack the ACK in the ECHO_REQUEST.

Here we are assuming that ICE connectivity tests replace the return 
routability tests of HIP. This has a security problem related to 
middleboxes because STUN messages don't include public keys and 
signatures. The middlebox needs them in order to protect itself against 
replay attacks as described in your draft:

http://www.ietf.org/internet-drafts/draft-heer-hip-middle-auth-00.txt

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

Yes they will be harder to implement because the middlebox has to...

1) Support two protocols instead of one
2) Be able to map the two protocols to each other

My comment is based on that we have actually implemented a HIP-based 
firewall:

http://www.usenix.org/events/usenix07/posters/lindqvist.pdf
http://infrahip.hiit.fi/papers/essi_dippa.pdf

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

So far we have only concluded that the RVS design is inadequate for the 
NAT traversal. It is self-evident that the mobility part needs some 
changes independently of whether we use STUN or HIP for the connectivity 
tests. Personally, I would like to keep those changes minimal and 
compatible with the mobility draft.

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

---

From: Philip Matthews <[email-masked]>
Date: Tue, 11 Dec 2007 15:15:49 -0800

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

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

> wonder how a possible solution could (will) look like. I'm not  
> asking for details about an yet unspecified solution but I'm rather  
> acceptable/realistic). I'm specially interested in the opinion of  
> the TURN people in the design team as you probably have the best  
> 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.
> 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.

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