The second, bigger problem is that if both the initiator and the
responder are behind NATs, the you just cannot send the I1 message
directly to the HIP responder.
The latter is the reason why we chose to use a Berkeley i3 -like
system in both Hi3 and in HIP BONE, i.e., to forward HIP messages
through the overlay instead of using it in a typical DHT put/get
manner.
i3, Secure-i3 and Hi3 have however an assumption that does not hold
here. The overlay consitutes of i3 servers which are considered to
be trustworthy, have public addresses and can converge as rendez-
vous points for "clients" behind NATs. This assumption does not
hold for P2PSIP, since there is not such an overlay.
I understand what you say, but I don't understand the reasons behind,
i.e., why exactly the assumption does not hold. Nor do I understand
how you can make such a system to work in the first place. In
particular, I don't understand how you can bootstrap an overlay if
all nodes are behind NATs.
So, when the I1 message is forwarded on the overlay, the NAT
traversal problem needs to solved for each link on the path between
the Initiator and the Responder. And this is not solved by HIP,
unless you run HIP for each link on the overlay (including the HIP
handshake and ICE for NAT traversal) which would be proably too
much overhead.
Indeed we do assume that you typically have an open HIP association
with each of the nodes in your peer table; see the second paragraph
in Section 3.2. Note that once you have an HIP association open, in
principle it can be open an arbitrary long time. Hence, the overhead
is not that big unless you have to keep NAT mappings open or
whatever, which you would need to do anyway for reachability
purposes. Secondly, having an open HIP association allows the nodes
to inform each others about mobility or multi-homing events and
maintain connectivity.
Moreover, the peer protocol needs to cope with NAT traversal for
other type of messages for the overlay maintenance, e.g. joins and
leaves, anyway. and again this is not solved by HIP, unless you do
HIP hop-by-hop.
Well, that depends on how you implement joins and leaves. Our
assumption was that you would establish an HIP association as a part
of a join procedure. For example, first do an I1-R1 exchange for DoS
protection, and then piggyback the join messages and ICE candidate
exchange starting from the I2-R2 exchange (and using UPDATEs if more
messages are needed.)
My conslusions from these facts here (please feel free to heavily
disagree and let me know if i am wrong) would be that:
- *HIP actually does not solve the NAT traversal problem for
P2PSIP*, as it has been assumed.
I would say that it solves it in a particular way, which is not much
different from using plain ICE. The message formats are somewhat
different, and the STUN/TURN servers are unified with the HIP BONE
routing system (as they would be HIP rendezvous servers in the case
of HIP).
- The peer protocol needs to cope with the NAT traversal by itself.
Well, IMHO the peer protocol does not need to cope with NAT, if you
always establish a HIP association first and let HIP to do it.
Of course, one crucial question is what are the tradeoffs there. In
particular, would the added support for security, multi-homing,
mobility, and the architectural features to pay off for the four
message exchange and the public key signatures. OTOH, if you would
be relying on public key crypto for security anyway, then the
overhead is minimal, and IMHO the question boils down merely into
architectural factors.
--Pekka Nikander
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
