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

Ari Keranen <ari.keranen@nomadiclab.com> Tue, 23 February 2010 15:18 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 5D6CA3A848B for <hipsec@core3.amsl.com>; Tue, 23 Feb 2010 07:18:41 -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 IXK09ZOxQ-yq for <hipsec@core3.amsl.com>; Tue, 23 Feb 2010 07:18:40 -0800 (PST)
Received: from gw.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id E29063A8490 for <hipsec@ietf.org>; Tue, 23 Feb 2010 07:18:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 0D4004E6D4; Tue, 23 Feb 2010 17:20:37 +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 wPhxCdPZ7Af8; Tue, 23 Feb 2010 17:20:36 +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 05D0F4E67D; Tue, 23 Feb 2010 17:20:36 +0200 (EET)
Message-ID: <4B83F243.6070208@nomadiclab.com>
Date: Tue, 23 Feb 2010 17:20:35 +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>
In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7C0@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: Tue, 23 Feb 2010 15:18:41 -0000

Hi Tom,

Once again, thanks for the comments; responses inline.

Henderson, Thomas R wrote:
>> 2. Terminology
>> 
>> 
>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>> this document are to be interpreted as described in RFC 2119
>> [RFC2119].
> 
> This section is empty; probably at the very least it should point to
> the normative references that define the terminology in use later in
> the document.

Makes sense; added pointers to 5201, HIP BONE and RELOAD.

>> 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.

>> 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).

>> 5. Mapping between Protocol Primitives and HIP Messages
>> 
>> ...Block are replaced with HIP header, HIP VIA lists
>> [I-D.ietf-hip-via], and CERT [I-D.ietf-hip-cert], TRANSACTION_ID,
>> OVERLAY_ID and OVERLAY_TTL [I-D.ietf-hip-bone] parameters.
> 
> TRANSACTION_ID is specified in hiccups, not hip-bone.

Good catch; fixed.

>> 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.


Cheers,
Ari