[Hipsec] RFC4423bis review
"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Mon, 04 April 2011 14:33 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 23EEF28C128 for <hipsec@core3.amsl.com>; Mon, 4 Apr 2011 07:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.475
X-Spam-Level:
X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 a3AzZbTs8Ct3 for <hipsec@core3.amsl.com>; Mon, 4 Apr 2011 07:33:46 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id DCCC028C119 for <hipsec@ietf.org>; Mon, 4 Apr 2011 07:33:46 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p34EZBWb019408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2011 07:35:16 -0700 (PDT)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p34EZBW3011388; Mon, 4 Apr 2011 09:35:11 -0500 (CDT)
Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p34EZ8aT011286 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 4 Apr 2011 09:35:09 -0500 (CDT)
Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Mon, 4 Apr 2011 07:35:08 -0700
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: 'Robert Moskowitz' <rgm@htt-consult.com>
Date: Mon, 04 Apr 2011 07:35:07 -0700
Thread-Topic: RFC4423bis review
Thread-Index: Acvy1X6DR1qo/TycQtiXAIMwNoWQhw==
Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25B0F2@XCH-NW-10V.nw.nos.boeing.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: [Hipsec] RFC4423bis review
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: Mon, 04 Apr 2011 14:33:58 -0000
Robert, Here are some comments on RFC4423bis that I would be willing to provide specific text inputs if you and others agree. I also have editorial nits that can be handled offline. Section 1 --------- In paragraph 2, it would read better to introduce the concept of a Host Identity before talking about the Host Identifier. Also, clarify that there is exactly one Host Identifier for each Host Identity, but that there can be multiple Host Identities for each real computing platform. Also, the last sentence of this paragraph should probably refer to Identifiers and not identities. Suggested text: The proposed Host Identity namespace fills an important gap between the IP and DNS namespaces. A Host Identity conceptually refers to a computing platform, and there may be multiple such Host Identities per computing platform (because the platform may wish to present a different identity to different communicating peers). The Host Identity namespace consists of Host Identifiers (HI). There is exactly one Host Identifier for each Host Identity. While this text later talks about non-cryptographic Host Identifiers, the architecture focuses on the case in which Host Identifiers are cryptographic in nature. Specifically, the Host Identifier is the public key of an asymmetric key-pair. Each Host Identity uniquely identifies a single host, i.e., no two hosts have the same Host Identity. If two or more computing platforms have the same Host Identifier, then they are instantiating a distributed host. The Host Identifier can either be public (e.g. published in the DNS), or unpublished. Client systems will tend to have both public and unpublished Host Identifiers. In other drafts, we have gone out of our way to avoid referring to IPsec (because it is a whole suite of protocols) and instead specifically refer to ESP. Suggest a global change from IPsec to ESP in this document. Section 2.2 ----------- I would reorder Host Identity Hash to come before Host Identity Tag. Also, the Host Identity Tag in practice is not just the cryptographic bits but some other bits, so the definition should reflect that it is not soley hash bits. Section 3 --------- I was not sure about the statement that IP addresses are a confounding of two namespaces. I think it may be more accurate to say that the namespaces for endpoint identifiers and interface names overlap since IP addresses are used for both names (or that there is no separate namespace for endpoint identifiers, for historical reasons). Here is suggested replacement text for paragraph 3: The IP addressing namespace has been overloaded to name both interfaces (at layer-3) and endpoints (for the endpoint-specific part of layer-3, and for layer-4). In their role as interface names, IP addresses are sometimes called "locators" and serve as an address within a routing topology. In the last paragraph of section 3, IMO these sentences needs more clarification: Firstly, dynamic readdressing cannot be directly managed. Secondly, anonymity is not provided in a consistent, trustable manner. I did not try to rewrite them since I am not completely sure what is the intended point. Section 3.1 ----------- In Section 3.1, I would suggest to not use the terminology "IP kernel" when in other parts of the text, this is referred to as an endpoint. For this bulleted list, I would preface it by saying that these were the goals at the onset of the HIP work, since some of the speculation in these bulleted items actually came to pass. For this bullet: o It must be possible to create names locally. This can provide anonymity at the cost of making resolvability very difficult. Where names are created is not that relevant to whether they become published or remain anonymous. So I would suggest instead: o It must be possible to create names locally. When such names are not published, this can provide anonymity at the cost of making resolvability very difficult. Section 4 --------- I don't know what you mean by using X.509 to notarize the identity assertion. Do you mean to notarize the binding of an identity to other names? Section 4.2 ----------- This section shouldn't be limited to DNS, but to storing in databases and directories in general. Also, from a document flow perspective, this section mentions HIH while Section 4.4 below it introduces HIH, so suggest to move this after the HIH section. Section 4.3 ----------- Again, this text needs to be updated to cover the ORCHID bits. Section 5 --------- Host Identifiers are not slightly different from interface names; I would argue that they are substantially different. (paragraph 2) I suggest to change "Service" in Figure 1 to "Transport association" There seem to be two concepts missing from this section. First, the cost of moving to the right side of Figure 1 is that one needs to be able to securely bind IP addresses to Host Identifiers, and one may want to resolve Host Identifiers to IP addresses (the latter issue isn't a problem with today's architecture). However, a key aspect of this architecture is that the key management and signaling association set up by HIP provides the security context necessary to make this binding. Another subtle point with the architecture in Figure 1 is that there needs to be a demultiplexing from incoming IP address to host identity for incoming packets, and there is no such packet field to do this unless fields are added. This can be later mentioned in the IPsec section (that one fringe benefit of ESP is the use of SPI as indicies to this context, but if ESP is not used, something else would be needed here in this architecture). It probably bears mentioning somewhere in this section that the lack of reverse lookup mechanism for HITs, if no such infrastructure is provided, will possibly hinder referrals. There probably could be a section or few paragraphs here about APIs since there was work done on both a native API and on reusing legacy API. Section 7 -------- Similar comment here about "ESP" vs. "IPsec". It is vague to say that HIP is "friendly" to middleboxes (para. 3). Instead, suggest to say that HIP provides mechanisms for middlebox authentication to occur. In the fourth paragraph, there is some text on not setting up more than one SA pair between the same HITs. I don't think this is necessarily true in multihoming (especially if replay window concerns exist along different paths). In the next paragraph, it says that HIP is not for gateways, but at least for the VPLS implementation that we at Boeing are interested, this is not strictly true. Section 9 --------- Should mention that RFC5770 is scheduled to be replaced; perhaps just identify it as an "experimental" version of NAT traversal. Section 10 ---------- It states here that there are few concrete thoughts about HIP and multicast, yet there have been some studies about this. Perhaps summarize and reference? Section 11 ---------- Probably want to mention the tension here between anonymity and authentication, and describe how HIP provides new challenges for systems or users to decide which type of HI to expose when they start a new session. This is somewhat akin to source address selection in IP, but I would argue that it is a more serious policy concern at the HIP level than the robustness concern that exists at the IP level. Probably also want to discuss in this section the policy tradeoff for opportunistic mode (can provide some security benefits but may be subject to MITM). Section 13 ---------- This section remains to be written. Section 14.1 ------------ This section should describe that the flatness of HITs makes it a challenge for ACLs to be aggregated. Section 14.2 ------------ Rather than call this section "non-security considerations" I would suggest "Alternative HI considerations".
- [Hipsec] RFC4423bis review Henderson, Thomas R
- [Hipsec] Well back at this yet again -- Re: RFC44… Robert Moskowitz
- Re: [Hipsec] Well back at this yet again -- Re: R… Andrew McGregor
- Re: [Hipsec] Well back at this yet again -- Re: R… Henderson, Thomas R
- Re: [Hipsec] Well back at this yet again -- Re: R… Henderson, Thomas R
- Re: [Hipsec] Well back at this yet again -- Re: R… Henderson, Thomas R