Re: [Hipsec] HIP Mobile Router draft

Jan Mikael Melen <Jan.Melen@nomadiclab.com> Wed, 12 November 2008 14:56 UTC

Return-Path: <hipsec-bounces@ietf.org>
X-Original-To: hip-archive@lists.ietf.org
Delivered-To: ietfarch-hip-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64083A6A9F; Wed, 12 Nov 2008 06:56:31 -0800 (PST)
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55D623A6A9F for <hipsec@core3.amsl.com>; Wed, 12 Nov 2008 06:56:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYWKfFN22hHQ for <hipsec@core3.amsl.com>; Wed, 12 Nov 2008 06:56:30 -0800 (PST)
Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 0390C3A68A9 for <hipsec@ietf.org>; Wed, 12 Nov 2008 06:56:30 -0800 (PST)
Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1DB0C1EF12C; Wed, 12 Nov 2008 16:56:23 +0200 (EET)
Received: from despair.unknown.com (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id DB4271EF12B; Wed, 12 Nov 2008 16:56:22 +0200 (EET)
Message-ID: <491AEE96.7070003@nomadiclab.com>
Date: Wed, 12 Nov 2008 16:56:22 +0200
From: Jan Mikael Melen <Jan.Melen@nomadiclab.com>
User-Agent: Thunderbird 2.0.0.7pre (X11/20080131)
MIME-Version: 1.0
To: orlie.t.brewer@boeing.com
References: <1225155863.13213.3.camel@crescent.rt.cs.boeing.com>
In-Reply-To: <1225155863.13213.3.camel@crescent.rt.cs.boeing.com>
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: "hipsec@ietf.org" <hipsec@ietf.org>
Subject: Re: [Hipsec] HIP Mobile Router draft
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: hipsec-bounces@ietf.org
Errors-To: hipsec-bounces@ietf.org

Hi,

Orlie Brewer wrote:
> We have been implementing portions of the HIP mobile router draft to
> OpenHIP:
>
> <<http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Dhttp://tools.ietf.org/id/draft-melen-hip-mr-01.txt>>
>
> Below are a few questions and comments about our effort.
>
> In section 5.1 of the draft, the "mobile router adds its self-signed
> locator set information to the I1 message" and "its signed LOCATOR TLV
> and ESP_INFO TLV to the I2 message."  This only seems useful if the peer
> node has the host identity public key of the mobile router to verify the
> signature, but there is no mention of the mobile router passing that
> information to the peer node or establishing a HIP connection with the
> peer node.  

Yes the mobile router could add its own HI in to the I2 message as well 
or the the HI might be fetched from some directory service such DHT in 
which case the MR should add its HIT.

> Also, these would have to be added after the portion of the
> message signed by the mobile node.  We have defined a ESP_INFO_UNSIGNED
> parameter to place the SPINAT info after the portion of the message
> signed by the mobile node in the I2 message.
>   

Yes, this was the plan that we introduce new parameters which are added 
after the signature.

> Also, in that section, "the mobile router adds an encrypted 'echo
> request' parameter to the I1 message."  We are assuming that it is an
> ECHO_REQUEST_UNSIGNED parameter that would be placed after the portion
> of the message signed by the mobile node.
>   

Yes.

> Another question with signatures is with the UPDATE packet.  The HIP
> RFC5201, section 5.3.5, say that an HMAC parameter and a HIP_SIGNATURE
> parameter are mandatory.  Again, is this suppose to be the mobile
> router's signature?  The draft does not mention signatures in relation
> to the UPDATE packet.
>   

If the MR is sending the packet then it is supposed to be the MR 
signature and when the MR is generating the UPDATE there wont be any 
HMAC as the MR doesn't have common keying material with the peer.

> A general comment is that the draft seems to consider two cases, a
> mobile node with existing SAs moving behind a mobile router and a mobile
> node already behind a mobile router establishing an SA through a mobile
> router.  However, it is a little confusing which case is being discussed
> at times as the draft seems to jump between the two cases.  It would be
> clearer if it were explicitly stated when the different cases were begin
> discussed.
>   

Yes it is considering two cases and I think your suggestion sounds good 
that there would be a statement in each section that to which case this 
applies to.

   Regards,
     Jan
 
_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec