Re: [P2PSIP] New draft: HIP BONE

[Pekka Nikander <[e-mail]>]

>> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip