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

[Miika Komu <[e-mail]>]

Hi Adam,

On 5/10/18 02:34, Adam Roach wrote:
> 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.

thanks for comments!

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

Agreed. I replaced "new" (namespace/layer) to "HI/additional" (depending 
on the context) throughout the document.

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

thanks

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

done

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

fixed, thanks

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

fixed

> ---------------------------------------------------------------------------
> 
> §6.5:
> 
>>   The control plane between two hosts is terminated using a secure two
>>   message exchange as specified in base exchange specification
> 
> "two-message"

fixed

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

fixed

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

changed this to:

  such as Teredo [RFC4380]
    (as described in further detail 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"

fixed

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

fixed

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

fixed

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

fixed

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

fixed

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

fixed

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

fixed. Thanks!