[Hipsec] Adam Roach's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)

Adam Roach <adam@nostrum.com> Wed, 09 May 2018 23:34 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: hipsec@ietf.org
Delivered-To: hipsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FA012DA17; Wed, 9 May 2018 16:34:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-hip-rfc4423-bis@ietf.org, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, hip-chairs@ietf.org, gonzalo.camarillo@ericsson.com, hipsec@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.80.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152590886238.10463.9438651181532889998.idtracker@ietfa.amsl.com>
Date: Wed, 09 May 2018 16:34:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/hDn2DscBah0NqAs7lhg10zeriaM>
Subject: [Hipsec] Adam Roach's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 May 2018 23:34:22 -0000

Adam Roach has entered the following ballot position for
draft-ietf-hip-rfc4423-bis-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for everyone's work on updating RFC 4423.

In general, I agree with Mirja's point that section 11 seems a bit disjoint
from the rest of the document, and would be better served as an appendix. It's
also somewhat jarring to have a document whose abstract talks about a "new
namespace" and a "new protocol layer," which goes on to describe conclusions
from twelve years of deployment experience. I would recommend re-working all
uses of the word "new" (which, in most cases, can be achieved by either
removing the word "new" from sentences, or replacing it with "HIP").

The remainder of my comments are editorial nits.

---------------------------------------------------------------------------

§2.1:

>  +---------------+---------------------------------------------------+
>  | Term          | Explanation                                       |
>  +---------------+---------------------------------------------------+
>  | Public key    | The public key of an asymmetric cryptographic key |
>  |               | pair.  Used as a publicly known identifier for    |
>  |               | cryptographic identity authentication.  Public is |
>  |               | a a relative term here, ranging from "known to    |
>  |               | peers only" to "known to the world."              |

Nit: this text contains a doubled "a" ("...a a relative...").

---------------------------------------------------------------------------
§2.2:

Nit: The change in spacing in this table makes certain terms difficult to read
(e.g., "HIP base exchange HIP packet" appears to be a single term until the
table is closely examined.) Consider reverting to the spacing from RFC 4423.

---------------------------------------------------------------------------

§3.1:

>  o  The names should have a fixed length representation, for easy

Nit: "fixed-length" is a compound adjective, and should be hyphenated.
cf. https://www.google.com/search?q=compound+adjective

>     (e.g the TCB).

Nit: The conventional form would call for "(e.g., the TCB)"
cf. https://www.google.com/search?q="e.g."+punctuation+comma

> o The names should be long lived, but replaceable at any time. This

"long-lived"

> designed, it can deliver all of the above stated requirements.

"above-stated"

---------------------------------------------------------------------------

§4:

>  In theory, any name that can claim to be 'statistically globally
>  unique' may serve as a Host Identifier.  In the HIP architecture, the
>  public key of a private-public key pair has been chosen as the Host
>  Identifier because it can be self managed and it is computationally

"self-managed"

---------------------------------------------------------------------------

§6.5:

>  The control plane between two hosts is terminated using a secure two
>  message exchange as specified in base exchange specification

"two-message"

---------------------------------------------------------------------------

§7:

>  control plane, protected by asymmetric key cryptography.  Also, S-RTP
>  has been considered as the data encapsulation protocol [hip-srtp].

"SRTP" rather than "S-RTP".

---------------------------------------------------------------------------

§8:

>  Besides this "native" NAT traversal mode for HIP, other NAT traversal
>  mechanisms have been successfully utilized, such as Teredo
>  [varjonen-split].

Please cite RFC 4380 for "Teredo." e.g.:

   Besides this "native" NAT traversal mode for HIP, other NAT traversal
   mechanisms have been successfully utilized, such as Teredo [RFC4380],
   as described in [varjonen-split].



---------------------------------------------------------------------------

§8:

>  can map to a single IP address on a NAT, simplifying connections on
>  address poor NAT interfaces.  The NAT can gain much of its knowledge

"address-poor"

---------------------------------------------------------------------------

§11.1:

>     Considering such human errors, a site
>     employing location-independent identifiers as promoted by HIP may
>     experience less problems while renumbering their network.

"...experience fewer problems..."

>  o  HITs (or LSIs) can be used in IP-based access control lists as a
>     more secure replacement for IPv6 addresses.  Besides security, HIT
>     based access control has two other benefits.

"HIT-based"

>     environments.  For instance, the benefits of HIT based access

"HIT-based"

---------------------------------------------------------------------------

§11.2:

>  The key exchange introduces some extra latency (two round trips) in
>  the initial transport layer connection establishment between two

"transport-layer"

>  keys and Diffie-Hellman key derivation at the control plane, but this
>  occurs only during the key exchange, its maintenance (handoffs,
>  refreshing of key material) and tear down procedures of HIP

"tear-down"

---------------------------------------------------------------------------

§11.3.1:

>  Networks [henderson-vpls] to facilitate, e.g, supervisory control and

"e.g.,"

---------------------------------------------------------------------------

§11.4:

>         A HI is a cryptographic public key.  However, instead of using
>         the keys directly, most protocols use a fixed size hash of the
>         public key.

"fixed-size"

>         HIP provides both stable and temporary Host Identifiers.
>         Stable HIs are typically long lived, with a lifetime of years

"long-lived"

>         network services.  Additionally, the Host Identifiers, as
>         public keys, are used in the built in key agreement protocol,

"built-in"

>         HIP reduces dependency on IP addresses, making the so called

"so-called"

---------------------------------------------------------------------------

§12.1:

>  Other types of MitM attacks against HIP can be mounted using ICMP
>  messages that can be used to signal about problems.  As a overall

"...an overall..."

>  be aborted after some retries).  As a drawback, this leads to an
>  6-way base exchange which may seem bad at first.  However, since this

"...a 6-way..."