Re: [Hipsec] Genart last call review of draft-ietf-hip-rfc4423-bis-18

"" <> Mon, 26 February 2018 14:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84AF81242F5; Mon, 26 Feb 2018 06:40:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DZ3d9n3IYPyu; Mon, 26 Feb 2018 06:39:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D875120725; Mon, 26 Feb 2018 06:39:58 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D988B240469; Mon, 26 Feb 2018 06:39:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A672D2405C0; Mon, 26 Feb 2018 06:39:56 -0800 (PST)
Date: Mon, 26 Feb 2018 09:39:53 -0500
In-Reply-To: <>
Importance: normal
From: "" <>
To: Miika Komu <>, Joel Halpern <>,
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=""
Message-Id: <>
Archived-At: <>
Subject: Re: [Hipsec] Genart last call review of draft-ietf-hip-rfc4423-bis-18
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Feb 2018 14:40:00 -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 <> Date: 2/26/18  06:56  (GMT-05:00) To: Joel Halpern <>, Cc:,, 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
> <>.
> 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 

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