Re: [Gen-art] Genart last call review of draft-ietf-hip-rfc4423-bis-18
"jmh.direct" <jmh.direct@joelhalpern.com> Mon, 26 February 2018 14:40 UTC
Return-Path: <jmh.direct@joelhalpern.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AF81242F5; Mon, 26 Feb 2018 06:40:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZ3d9n3IYPyu; Mon, 26 Feb 2018 06:39:58 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D875120725; Mon, 26 Feb 2018 06:39:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D988B240469; Mon, 26 Feb 2018 06:39:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1519655997; bh=1WbyyQ9yOnBkhMabiXstxJMsfAdio4gNKf/kARbsFA4=; h=Date:Subject:In-Reply-To:From:To:Cc:From; b=TfchX7e2IeflbNYPP8i5CFVxBkFdSX1p4KgJsUV7a+mqpWbjOHqSyeDT8uNEBhOAz jheAM7hKnpahmCzyfHJKGhAsHJDgOz4qcDqmddWp/GEK+yoypczEb2AbmpgN8Kv0Bi Eo/SPVrM/bZBSmhsmJ1mHlk2TciHcIx21JF/K7UM=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [172.20.100.97] (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A672D2405C0; Mon, 26 Feb 2018 06:39:56 -0800 (PST)
SavedFromEmail: jmh.direct@joelhalpern.com
Date: Mon, 26 Feb 2018 09:39:53 -0500
In-Reply-To: <51f4f14e-12ac-646e-2dc2-13adbd8390f9@ericsson.com>
Importance: normal
From: "jmh.direct" <jmh.direct@joelhalpern.com>
To: Miika Komu <miika.komu@ericsson.com>, Joel Halpern <jmh@joelhalpern.com>, gen-art@ietf.org
Cc: draft-ietf-hip-rfc4423-bis.all@ietf.org, hipsec@ietf.org, ietf@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_10905280141180150"
Message-Id: <20180226143958.2D875120725@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/AIrs9DCA9Qhe9D7Zc4Ge4cLOZ0E>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-hip-rfc4423-bis-18
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Feb 2018 14:40:01 -0000
These changes very nicely address my concerns.b You should check with your chair,and AD before submitting a,revision. Thank you,Joel Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone -------- Original message --------From: Miika Komu <miika.komu@ericsson.com> Date: 2/26/18 06:56 (GMT-05:00) To: Joel Halpern <jmh@joelhalpern.com>, gen-art@ietf.org Cc: draft-ietf-hip-rfc4423-bis.all@ietf.org, hipsec@ietf.org, ietf@ietf.org Subject: Re: Genart last call review of draft-ietf-hip-rfc4423-bis-18 Hi Joel, thanks for the nice review! My suggested changes for HIP architecture document are below (in "diff" format). On 02/18/2018 07:33 AM, Joel Halpern wrote: > Reviewer: Joel Halpern > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-hip-rfc4423-bis-18 > Reviewer: Joel Halpern > Review Date: 2018-02-17 > IETF LC End Date: 2018-02-26 > IESG Telechat date: Not scheduled for a telechat > > Summary: This document is ready for publication as an Informational RFCs. > The following comments may be useful for the authors to consider. > > Major issues: N/A > > Minor issues: > In the table in section 2.2 (Terms specific to this and other HIP > documents) the Host Identity Hash is defined as "The cryptographic hash > used in creating the Host Identity Tag from the Host Identity." I am > pretty sure the last word should be Identifier, not Identity,, which > matches the meanings and the usage in the following term. agreed. Suggested change: Host Identity Hash The cryptographic hash used - in creating the Host Identity Tag from the Host Identity. + in creating the Host Identity Tag from the Host Identifier. (I will move the definition of Host Identifier earlier so that the terms appear in chronological order) > In section 4.1 second paragraph, it seems odd to refer to the > public-private key pair as the structure of the abstract Host Identity. > Given that the earlier text refers to the Public key as the Host > Identifier, I am not sure how you want to refer to the public/private key > pair. But I do not think it "is" the structure of the Host Identity. Agree. Suggested rephrasing: - The only completely defined structure of the Host Identity - is that of a public/private key pair. In this case, the Host - Identity is referred to by its public component, the public + An identity is based on public-private key cryptography in HIP. + The Host Identity is referred to by its public component, the public key. > In the section 4.4 discussion of locally scoped identifier (LSI), it > appears that applications need to be modified to use this. Reading between > the lines of the stack architecture, the actual advantage of using HIP with > LSIs is that the application changes can be restricted to whatever > indication is to be used that the stack is to use HIP, rather than changing > the places that use sockaddrs, etc. But this is not clearly stated here. yes, you are correct. I would suggest the following changes to make this more clear: A Host Identity Tag is a 128-bit representation for a Host - Identity. It is created from an HIH, - an IPv6 prefix [RFC7343] and a hash identifier. + Identity. Due to its size, it is suitable to be used in the existing sockets API in + the place of IPv6 addresses (e.g. in sockaddr_in6 structure, sin6_addr member) without modifying applications. + It is created from an HIH, an IPv6 prefix [RFC7343] + and a hash identifier. ...and the following: An LSI is a 32-bit localized representation for a Host - Identity. The purpose of an LSI is to facilitate using Host + Identity. Due to its size, it is suitable to be used in the existing sockets API in + the place of IPv4 addresses (e.g. in sockaddr_in structure, sin_addr member) without modifying applications. + The purpose of an LSI is to facilitate using Host Identities in existing APIs for IPv4-based - applications. Besides facilitating HIP-based connectivity for + applications. + LSIs are never transmitted on the wire; when an application + sends data using a pair of LSIs, the HIP layer (or sockets + handler) translates the LSIs to the corresponding HITs, and + vice versa for receiving of data. + Besides facilitating HIP-based connectivity for legacy IPv4 applications, the LSIs are beneficial in two other scenarios [RFC6538]. @@ -712,6 +721,14 @@ to facilitate backward compatibility with existing networking APIs and stacks.</t> > In section 5.1 paragraph 3, the text talks about a connecting client not > specifying a responder identifier (HIP Opportunistic mode) in order to > enable load balancing. I think the text would be helped by an example of > how an initiator might know to do this, rather than just not using HIP. > Also, it would be good if the text was explicit as to whether or not there > was a way to support load balancing / multi servers without either using a > shared identity or sacrificing security by using Opportunistic HIP. agreed, the description of this was quite short. Would the following clarify your concerns? + At the server side, utilizing DNS is a better alternative than a + shared Host Identity to implement load balancing. A single FQDN entry can be configured + to refer to multiple Host Identities. Each of the FQDN entries + can be associated with the related locators, or a single + shared locator in the case the servers are using the same HIP rendezvous server + or HIP relay server. + Instead of duplicating identities, HIP opportunistic mode can be employed, where the initiator leaves out the identifier of the responder when initiating the key exchange and learns @@ -731,14 +766,21 @@ it upon the completion of the exchange. The tradeoffs are related to lowered security guarantees, but a benefit of the approach is to avoid publishing of Host Identifiers in any - directories [komu-leap]. The approach could also be used - for load balancing purposes at the HIP layer because the - identity of the responder can be decided dynamically during - the key exchange. Thus, the approach has - the potential to be used as a HIP-layer "anycast", either - directly between two hosts or indirectly through the - rendezvous service [komu-diss]. + directories [komu-leap]. Since many public + servers already employ DNS as their directory, opportunistic mode + may be more suitable for, e.g, peer-to-peer connectivity. + HIP opportunistic mode could be utilized in association + with HIP rendezvous servers or HIP relay servers + [komu-diss]. In such a scenario, the Initiator sends + an I1 message with a wildcard destination HIT to the locator of a HIP + rendezvous/relay server. When the receiving rendezvous/relay server is + serving multiple registered Responders, the server can choose + the ultimate destination HIT, thus acting as a HIP based load + balancer. However, this approach is still experimental and + requires further investigation. + (I can also remove the last paragraph if it is still unclear) > Given that section 5 is titled "New Stack Architecture", I think it would > be helpful if the section were explicit as to where the HIP logic lives > relative to the IP and UDP/TCP portions of the host stack. This would help > the reader have the right model for interpreting section 6.2 and 8.1. I would suggest to add a new paragraph in the end of the section to clarify this: + HIP layer is logically located at layer 3.5, between the + transport and network layers, in the networking stack. It acts + as shim layer for transport data utilizing LSIs or HITs, but + leaves other data intact. HIP layer translates between the two + forms of HIP identifiers originating from the transport layer + into routable IPv4/IPv6 addresses for the network layer, and + vice versa for the reverse direction. > Nits/editorial comments: > Section 4.2 third sentence "It is possible to for ..." should be "It is > possible for ..." Good catch, will fix this too. Joel, should I go ahead and submit a new version (bis-19) of the document?
- [Gen-art] Genart last call review of draft-ietf-h… Joel Halpern
- Re: [Gen-art] Genart last call review of draft-ie… Miika Komu
- Re: [Gen-art] Genart last call review of draft-ie… jmh.direct
- Re: [Gen-art] Genart last call review of draft-ie… Miika Komu
- Re: [Gen-art] [Hipsec] Genart last call review of… Robert Moskowitz