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!
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
