[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Hipsec] Some concerns regarding legacy NAT traversal solution
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/
_______________________________________________
Hipsec mailing list
Hipsec at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hipsec