Hi Pekka,
On 10 Jan 2008, at 13:45 Pekka Nikander wrote:
Hi Ali,
On 10 Jan 2008, at 01:19, Ali Fessi wrote:
<snip>
Simlarly, you can use the P2P protocol to resolve a HIP ORCHID to a
Locator, and then when you get the Locator start the HIP handshake.
And in fact, this is maybe something confusing in the HIP BONE draft
[...] because HIP BONE says that a I1 message is transported
hop-by-hop in the overlay. I would let the P2P protocol resolve the
HIP Identifier to a Locator first, and then send the I1 message
directly to the HIP Responder.
That has been tried and there is even a prototype working on PlanetLab
using OpenDHT, but unfortunately there appears to be two problems.
First, OpenDHT latencies appear to be too long and unpredictable,
sometimes minutes and often exceeding 10 seconds. But that may be an
implementation problem that can be fixed.
yes indeed, this is a OpenDHT specific problem. (we also had similar
performance problems when experimenting with P2PSIP on OpenDHT)
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.
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.
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.
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.
- The peer protocol needs to cope with the NAT traversal by itself.
Cheers,
Ali
--Pekka Nikander
--
Ali Fessi
Computer Networks and Internet
University of Tuebingen, Germany
Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220
EMail: [EMAIL PROTECTED]
Web: http://net.informatik.uni-tuebingen.de/~fessi/
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
