Re: [P2PSIP] New draft: HIP BONE

Ali Fessi <ali.fessi@uni-tuebingen.de> Fri, 11 January 2008 15:53 UTC

Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDMCW-00058O-Mx; Fri, 11 Jan 2008 10:53:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDMCV-00058J-Jl for p2psip@ietf.org; Fri, 11 Jan 2008 10:53:43 -0500
Received: from u-173-c156.cs.uni-tuebingen.de ([134.2.173.156] helo=smtp.cs.uni-tuebingen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDMCT-0007KJ-JZ for p2psip@ietf.org; Fri, 11 Jan 2008 10:53:43 -0500
Received: from u-172-c174.cs.uni-tuebingen.de ([134.2.172.174]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from <iinfe01@ri.uni-tuebingen.de>) id 1JDMC8-0004A4-1A; Fri, 11 Jan 2008 16:53:20 +0100
Message-ID: <478790EE.4050301@uni-tuebingen.de>
Date: Fri, 11 Jan 2008 16:53:18 +0100
From: Ali Fessi <ali.fessi@uni-tuebingen.de>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Pekka Nikander <pekka.nikander@nomadiclab.com>
Subject: Re: [P2PSIP] New draft: HIP BONE
References: <476BA8D9.4010203@ericsson.com> <20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> <476E2B7C.9070601@ericsson.com> <20d2bdfb0801081416t41b9b84atb3a147659771036@mail.gmail.com> <77F357662F8BFA4CA7074B0410171B6D04049B22@XCH-NW-5V1.nw.nos.boeing.com> <086801c8530e$611d8030$6601a8c0@china.huawei.com> <4785566F.7000700@uni-tuebingen.de> <833EB4F9-41EE-41E5-A951-DE2AF0FE9FF8@nomadiclab.com>
In-Reply-To: <833EB4F9-41EE-41E5-A951-DE2AF0FE9FF8@nomadiclab.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: P2PSIP Mailing List <p2psip@ietf.org>
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org

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: ali.fessi@uni-tuebingen.de
Web: http://net.informatik.uni-tuebingen.de/~fessi/

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip