Re: [P2PSIP] HIP performance concerns (was HIP pros and cons)

Philip Matthews <philip_matthews@magma.ca> Tue, 18 December 2007 00:46 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 1J4Qbm-0002bd-0L; Mon, 17 Dec 2007 19:46:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Qbk-0002b3-K7 for p2psip@ietf.org; Mon, 17 Dec 2007 19:46:52 -0500
Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Qbj-0005r9-6v for p2psip@ietf.org; Mon, 17 Dec 2007 19:46:52 -0500
Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from <philip_matthews@magma.ca>) id 1J4Qbi-0001py-2w; Mon, 17 Dec 2007 19:46:51 -0500
In-Reply-To: <4766A124.4080906@uni-tuebingen.de>
References: <001201c83fd6$58430e80$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE412@namail5.corp.adobe.com> <000001c84058$fabe14c0$da07740a@dellwei> <FB26C309-7AC0-4E0D-B39A-4FA58D96EDA9@magma.ca> <4766A124.4080906@uni-tuebingen.de>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <6191EB54-4A0F-4D97-9F26-CEEE88CBB2B7@magma.ca>
Content-Transfer-Encoding: 7bit
From: Philip Matthews <philip_matthews@magma.ca>
Subject: Re: [P2PSIP] HIP performance concerns (was HIP pros and cons)
Date: Mon, 17 Dec 2007 19:27:54 -0500
To: Ali Fessi <ali.fessi@uni-tuebingen.de>
X-Mailer: Apple Mail (2.752.2)
X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
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

Before answering your question, I think it is important to point out  
the following:
* There is HIP as specified in documents just approved by the IESG.  
This version of HIP does not work in an overlay and does not include  
NAT Traversal. I will call this "basic HIP"
* There is HIP with NAT Traversal, which is an official work item of  
the HIP WG, but is not yet finished.
* Then there are three proposals in P2PSIP:
	- HIP-HOP: Proposes to extend HIP to allow it to set up connections  
in the overlay
	- WITH-HIP: Proposes to use run HIP over the Peer Protocol to set up  
connections in the overlay
	- ID-LOC: Proposes to take ideas from HIP and include them in the  
Peer Protocol
   All three drafts are just individual submissions.

Also note that there are two HIP groups: a HIP working group and a  
HIP research group.
The Working Group is looking at the NAT Traversal issues.
The Research Group is the one looking at applications of HIP.

On 17-Dec-07, at 11:17 , Ali Fessi wrote:

> Hi all,
>
> some questions for the HIP experts among us:
>
> - HIP uses a Base Exchange (BEX) with 4 messages, and the BEX  
> contains a diffie hellman key exchange. (as you know, diffie  
> hellman might cause some performance problems on small devices)

Yes.
I believe that tests with a Nokia Tablet (a small mobile device) have  
shown that the Diffie-Hellman is not a problem in practice. For  
details, ask on the HIP RG list (see below).


>
> Do i need a HIP BEX each time before I can exchange any message  
> with another peer in the overlay? for example P2P routing messages?

No.
All three proposals mentioned above propose to use the scheme first  
described in draft-matthews-p2psip-nats-and-overlays whereby there  
are permanent connections to various other peers in the overlay.  
RELOAD now also uses this scheme.


>
> as you know, P2P networks have generally the property that you need  
> to exchange messages frequently with other peers, for routing  
> purposes, for DHT maintenane, etc. So, it wouldn't be very  
> efficient if i need to perform a HIP BEX each time before I can  
> exchange any other message, in particular under high churn conditions.

Luckily, this is not required.
See previous answer.

>
> - if you do mobility with HIP, you will need to update the IPSec  
> SAs in the kernel when a handover occurs. Is that correct? How well  
> does this work? Has there been some experiments that show that HIP  
> can provide seamless mobility? If yes, please provide a reference.

For "basic HIP", I understand the answer is no.
For other forms of HIP, I believe the answer will be the same.
However, I will say that I am not a security expert, nor am I an  
expert on HIP.

For more details on HIP mobility, I suggest you ask your question on  
the HIP RG mailing list:
    hipsec-rg@listserv.cybertrust.com

- Philip


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