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

Miika Komu <miika.komu@ericsson.com> Tue, 27 February 2018 11:18 UTC

Return-Path: <miika.komu@ericsson.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 003B91273B1 for <gen-art@ietfa.amsl.com>; Tue, 27 Feb 2018 03:18:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level:
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Tfn6PAKGlggR for <gen-art@ietfa.amsl.com>; Tue, 27 Feb 2018 03:18:31 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 0D3CB12783A for <gen-art@ietf.org>; Tue, 27 Feb 2018 03:18:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519730307; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lL4fwM8RvFSu5HHsbpRYpgTt8WioSgm8a+hrO+hSinU=; b=QHCvHDf4Z/IFRrJkrljQtx+Jnq8rAnKHpVvl3qnaQdi1gj/FOl9NqMP+VMBEPko9 PWeG3EPqrUNoqLKsmsjIuLtR2J3gY4BQCIB2Ef/dS+ULqRjPLw2B/687pkj3+JPI kUCkOt3nGJX4ytAAvr5+e63ZAOskmUSS1q03UudjMn4=;
X-AuditID: c1b4fb25-083ff70000002d5f-b3-5a953e834163
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C3.C2.11615.38E359A5; Tue, 27 Feb 2018 12:18:27 +0100 (CET)
Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.352.0; Tue, 27 Feb 2018 12:18:27 +0100
To: "jmh.direct" <jmh.direct@joelhalpern.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
References: <34.48.17338.F3C149A5@sessmg11.ericsson.net>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <30a11644-ebb9-54e8-2d2e-465a0f35852c@ericsson.com>
Date: Tue, 27 Feb 2018 13:18:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <34.48.17338.F3C149A5@sessmg11.ericsson.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM2J7uG6z3dQog22tMhbnThxjtbj66jOL xdRFk5ktnm2cz2KxbdF6ZouPp94wObB5LFnyk8nj3JTvjAFMUVw2Kak5mWWpRfp2CVwZU4/N Yyw4n1pxqH8LcwPj2ZAuRk4OCQETiYlXepi6GLk4hAQOM0p8eXKADcJZwyixdO4URpAqYQFX ibVHGtlBbBGBVIlFWyeBxZkFgiWOzfrCAmILCVhIrNixAMxmE9CSWHXnOjOIzS8gKbGhYTeY zStgL7H1+FOwGhYBVYlJ+xeC2aICERKdK+ezQNQISpyc+QTM5hSwlPi1ZyEbxC4LiZnzz0Pt FZe49WQ+E4StLbFs4Wug+RxAN6hIXDwWPIFRaBaSSbOQdM9C0j0LSfcCRpZVjKLFqcVJuelG xnqpRZnJxcX5eXp5qSWbGIFxcHDLb9UdjJffOB5iFOBgVOLhjdaeGiXEmlhWXJl7iFGCg1lJ hHfl4slRQrwpiZVVqUX58UWlOanFhxilOViUxHnnCLdHCQmkJ5akZqemFqQWwWSZODilGhit Fi6xTehdYHpCYttNrW6W+8tjrvdkWwp+4uDo4a8561aW8frCOQn+XYwp/PEJubXqu3U7p86q kn/0IjQpbUdoEb/+sWylptuvVQwXB35+4v/h9mFf3qbfVYsrZ/+8dDbhQY2Wx6TejodyO06I +36ZaM5yXv2oCOu+xvm6skzzdt1+ZSXlt12JpTgj0VCLuag4EQBbtwmsfwIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/rb3HLbU19dDpbaJ84U7N66ckDYI>
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: Tue, 27 Feb 2018 11:18:33 -0000

Hi Joel,

done! The new version with your suggested changes and diff are here:

https://www.ietf.org/internet-drafts/draft-ietf-hip-rfc4423-bis-19.txt
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc4423-bis-19

P.S. I took the liberty to fix a small typo from the text:

drop HIP-base connectivity -> drop HIP-based connectivity

On 02/26/2018 04:39 PM, jmh.direct wrote:
> 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?