Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00
"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Tue, 23 February 2010 18:20 UTC
Return-Path: <thomas.r.henderson@boeing.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 D39AF28C160 for <hipsec@core3.amsl.com>; Tue, 23 Feb 2010 10:20:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level:
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 UkcXXj52BY8f for <hipsec@core3.amsl.com>; Tue, 23 Feb 2010 10:20:03 -0800 (PST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id E5F323A8182 for <hipsec@ietf.org>; Tue, 23 Feb 2010 10:20:02 -0800 (PST)
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1NIM2MY029491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Feb 2010 10:22:03 -0800 (PST)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1NIM2hR003569; Tue, 23 Feb 2010 10:22:02 -0800 (PST)
Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1NIM2T2003556 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 23 Feb 2010 10:22:02 -0800 (PST)
Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 23 Feb 2010 10:22:02 -0800
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: 'Ari Keranen' <ari.keranen@nomadiclab.com>
Date: Tue, 23 Feb 2010 10:22:01 -0800
Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00
Thread-Index: Acq0m8psUmMMlj7ySieabZ/YHac9pwAF/Qxw
Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7D1@XCH-NW-10V.nw.nos.boeing.com>
References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7C0@XCH-NW-10V.nw.nos.boeing.com> <4B83F243.6070208@nomadiclab.com>
In-Reply-To: <4B83F243.6070208@nomadiclab.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 18:20:05 -0000
> -----Original Message----- > From: Ari Keranen [mailto:ari.keranen@nomadiclab.com] > Sent: Tuesday, February 23, 2010 7:21 AM > To: Henderson, Thomas R > Cc: 'Gonzalo Camarillo'; HIP > Subject: Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00 > > 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. OK, I suggest to add this clarification to the draft. > > >> 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? > > >> 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. > OK, I'll have a look at the revisions when they are published. Regards, Tom
- [Hipsec] WGLC: HIP-based overlays Gonzalo Camarillo
- Re: [Hipsec] WGLC: HIP-based overlays Henderson, Thomas R
- Re: [Hipsec] WGLC: draft-ietf-hip-via-00 Henderson, Thomas R
- Re: [Hipsec] WGLC: draft-ietf-hip-hiccups-01 Henderson, Thomas R
- Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance… Henderson, Thomas R
- Re: [Hipsec] WGLC: draft-ietf-hip-bone-04 Henderson, Thomas R
- Re: [Hipsec] WGLC: HIP-based overlays Gonzalo Camarillo
- Re: [Hipsec] WGLC: draft-ietf-hip-via-00 Ari Keranen
- Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance… Ari Keranen
- Re: [Hipsec] WGLC: HIP-based overlays Henderson, Thomas R
- Re: [Hipsec] WGLC: draft-ietf-hip-via-00 Henderson, Thomas R
- Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance… Henderson, Thomas R
- Re: [Hipsec] WGLC: HIP-based overlays Gonzalo Camarillo
- Re: [Hipsec] WGLC: draft-ietf-hip-via-00 Ari Keranen
- Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance… Ari Keranen
- Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance… Henderson, Thomas R
- Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance… Ari Keranen
- Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance… Henderson, Thomas R
- Re: [Hipsec] WGLC: draft-ietf-hip-bone-04 Ari Keranen
- Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance… Ari Keranen
- Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance… Henderson, Thomas R
- Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance… Ari Keranen
- Re: [Hipsec] WGLC: draft-ietf-hip-hiccups-01 Jan Melen
- Re: [Hipsec] WGLC: draft-ietf-hip-hiccups-01 Jan Melen
- Re: [Hipsec] WGLC: draft-ietf-hip-hiccups-01 Jan Melen