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

Robert Moskowitz <> Wed, 28 February 2018 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 834B012426E; Wed, 28 Feb 2018 12:18:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tlbYVEBQ4hwZ; Wed, 28 Feb 2018 12:18:24 -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 38F70120227; Wed, 28 Feb 2018 12:18:24 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D02116224C; Wed, 28 Feb 2018 15:18:22 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id V--KsPSpBdYQ; Wed, 28 Feb 2018 15:18:18 -0500 (EST)
Received: from (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D2E8362244; Wed, 28 Feb 2018 15:18:16 -0500 (EST)
To: Joel Halpern <>,
References: <>
From: Robert Moskowitz <>
Message-ID: <>
Date: Wed, 28 Feb 2018 15:18:09 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
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: Wed, 28 Feb 2018 20:18:27 -0000

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


On 02/18/2018 12: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.
>      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 ..."
> _______________________________________________
> Hipsec mailing list