Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00

Ari Keranen <ari.keranen@nomadiclab.com> Thu, 25 February 2010 14:29 UTC

Return-Path: <ari.keranen@nomadiclab.com>
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 8DCD828C333 for <hipsec@core3.amsl.com>; Thu, 25 Feb 2010 06:29:09 -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=[AWL=0.000, 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 wiknSh3d5UMj for <hipsec@core3.amsl.com>; Thu, 25 Feb 2010 06:29:08 -0800 (PST)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 4D51B28C141 for <hipsec@ietf.org>; Thu, 25 Feb 2010 06:29:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 8A3ED4E6CD; Thu, 25 Feb 2010 16:31:13 +0200 (EET)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdyxuZNpnVO2; Thu, 25 Feb 2010 16:31:12 +0200 (EET)
Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id EAF5A4E67D; Thu, 25 Feb 2010 16:31:12 +0200 (EET)
Message-ID: <4B8689B0.50704@nomadiclab.com>
Date: Thu, 25 Feb 2010 16:31:12 +0200
From: Ari Keranen <ari.keranen@nomadiclab.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7C0@XCH-NW-10V.nw.nos.boeing.com> <4B83F243.6070208@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7D1@XCH-NW-10V.nw.nos.boeing.com>
In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7D1@XCH-NW-10V.nw.nos.boeing.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: HIP <hipsec@ietf.org>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00
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/mail-archive/web/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>
X-List-Received-Date: Thu, 25 Feb 2010 14:29:09 -0000

Henderson, Thomas R wrote:
>> -----Original Message----- From: Ari Keranen
>> [mailto:ari.keranen@nomadiclab.com]
>>>> 3. Peer Protocol
>>>> 
>>>> The peer protocol to be used is RELOAD, which is specified in 
>>>> [I-D.ietf-p2psip-base].  When used with RELOAD, HIP replaces
>>>> the RELOAD's Forwarding and Link Management Layer (described in
>>>> Section 5.5. of [I-D.ietf-p2psip-base].
>>> RELOAD also has a Topology Plugin module that is responsible for 
>>> maintaining the routing tables; from the RELOAD draft: "   The 
>>> Topology Plugin is responsible for maintaining the overlay
>>> algorithm Routing Table, which is consulted by the Forwarding and
>>> Link Management Layer before routing a message."
>>> 
>>> can you define how this relates to the HIP-specific
>>> implementation?
>> HIP replaces the Forwarding layer, so it consults the Topology
>> plugin module as the Forwarding layer would have done.
>> 
>>> Does an interface exist between a HIP forwarding process and the 
>>> topology plugin of RELOAD?
>> The details about the interface (if any) between HIP and RELOAD
>> modules are left up to implementations. Our goal was not to define 
>> APIs in this document, but such APIs can be later defined in, e.g.,
>> advanced HIP native API document.
> 
> OK, I suggest to add this clarification to the draft.

OK. I thought that would be implicitly clear. But I can add the 
following to the end of the intro section:

    [...] The
    details on how different RELOAD modules would be integrated to a HIP
    implementation and what kind of APIs are used between them are left
    as implementation details or to be defined by other documents.

>>>> 4. Peer ID Generation
>>>> 
>>>> In the other Peer ID mode, namely "RELOAD", all 128 bits are 
>>>> generated as defined in [I-D.ietf-p2psip-base] resulting in a 
>>>> larger usable address space.
>>> If the RELOAD node IDs are not HITs (ORCHIDs), then a
>> mapping between
>>> the node id and the HITs is necessary.  Section 5.6.1 of RELOAD 
>>> suggests that certificates are to be used in this case; I
>>> expected that this draft would discuss the HIP certificate model
>>> for this binding.
>> In this case the 128-bit ID would be your "HIT" so there is no need
>> for mapping (and in that sense the assumptions in Section 5.6.1.1 
>> of RELOAD draft are not really correct).
> 
> My understanding is that there are two main modes of Node ID
> generation in (non-HIP-based) RELOAD: 1) centralized 2)
> self-generated, self-signed
> 
> When you say "In the other Peer ID mode, namely "RELOAD",..." which
> case do you mean?  Just the self-generated case?  If it is the
> centralized case, the Node IDs can't be used as HITs, and then the
> Node IDs and the HITs are not related to one another and need to be
> bound by some kind of certificate framework.  This is what I think
> section 5.6.1.1 of the base draft refers to.  Or am I
> misunderstanding something?

We mean both cases.  I'm sorry but I don't follow why couldn't the 
non-ORCHID Node IDs be used as "HITs" (i.e., in the HIP header, VIA 
lists and certificates) in the centralized case?

The CERT parameter used to prove that a host can use certain Node ID 
contains the hosts real HIT (i.e., hash of the host ID) which binds the 
Host ID to the Node ID.

But I guess this needs some further clarification in the draft; I'll add 
some text about this.

>>>> 8. Enrollment and Bootstrapping
>>>> 
>>>> The RELOAD HIP BONE instance uses the enrollment and bootstrap 
>>>> procedure defined by RELOAD [I-D.ietf-p2psip-base] with the 
>>>> exceptions listed below.
>>> It was not clear to me how initial bootstrapping occurred,
>> or whether
>>> HIP Relay/Rendezvous servers can be used in the absence of
>> HIP routes
>>> being in the node's Topology plugin table.  I am assuming that
>>> upon first join, HIP nodes must either use the "well known public
>>> IP address" technique of bootstrap nodes to join, and then
>>> subsequently they will forward all of their HIP messages over the
>>> overlay-- is that correct?   Does the AttachReq have a set of
>>> suggested locators for initial contact?
>> The idea is to re-use the bootsrapping possibilities defined in the
>>  RELOAD spec; including downloading the config file using HTTP from
>> a server discovered using DNS. But perhaps this would need some 
>> clarification. I'll see what I can do. AttachReqs are not used with
>> the instance spec.
>> 
>>>> 9. NAT Traversal
>>>> 
>>>> 
>>>> RELOAD relies on the Forwarding and Link Management Layer
>>>> providing NAT traversal capabilities.  Thus, the RELOAD HIP
>>>> BONE instance implementations MUST implement some reliable NAT
>>>> traversal mechanism. To maximize interoperability, all
>>>> implementations SHOULD implement at least
>>>> [I-D.ietf-hip-nat-traversal].
>>> RELOAD specifies that nodes MUST implement full ICE.  (Section 
>>> 5.5.1.3).  Can you clarify whether that MUST should be avoided in
>>>  this instance (i.e. how to avoid RELOAD ICE layered on top of
>>> HIP ICE-like NAT traversal)?
>> Yes, the whole 5.5. section of RELOAD is replaced by what is 
>> defined in 5 of the instance spec. I'll clarify in that section
>> that this also includes all the ICE stuff. Now the section 5 starts
>> with:
>> 
>> RELOAD HIP BONE replaces the RELOAD protocol primitives taking care
>>  of connection establishment with the HIP base exchange, where as
>> the rest of the RELOAD messages are conveyed within HIP messages.
>> The Forwarding and Link Management Layer functionality of RELOAD
>> defined in Section 5.5. of [I-D.ietf-p2psip-base], including all
>> the NAT traversal functionality, is replaced by HIP and the
>> extensions defined in this document.
>> 
> 
> OK, I'll have a look at the revisions when they are published.
> 

OK, thanks. We'll make a new revision before the cut-off date.


Cheers,
Ari