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

[Joel Halpern <[e-mail]>]

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