Subject: [Gen-art] Genart last call review of draft-ietf-hip-rfc4423-bis-18

From: Joel Halpern <[email-masked]>
Date: Sat, 17 Feb 2018 21:33:42 -0800

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.

    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.

    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.

    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.

    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.

Nits/editorial comments:
    Section 4.2 third sentence "It is possible to for ..." should be "It is
    possible for ..."

---

From: Miika Komu <[email-masked]>
Date: Mon, 26 Feb 2018 13:56:08 +0200

Hi Joel,

thanks for the nice review! My suggested changes for HIP architecture 
document are below (in "diff" format).

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

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

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

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

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

>      Section 4.2 third sentence "It is possible to for ..." should be "It is

Good catch, will fix this too.

Joel, should I go ahead and submit a new version (bis-19) of the document?

---

From: "jmh.direct" <[email-masked]>
Date: Mon, 26 Feb 2018 09:39:53 -0500

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 <[email-masked]> Date: 2/26/18  06:56  (GMT-05:00) To: Joel Halpern <[email-masked]>, [email-masked] Cc: [email-masked], [email-masked], [email-masked] Subject: Re: Genart last call review of draft-ietf-hip-rfc4423-bis-18 
Hi Joel,

...and the following:

@@ -712,6 +721,14 @@

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 28 Feb 2018 15:18:09 -0500

Mail folder problems.  I will be catching up with all of this starting 
Friday (Purim tonight and tomorrow).

Bob

On 02/18/2018 12:33 AM, Joel Halpern wrote:
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>