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