Host Identity Protocol Architecture
draft-ietf-hip-rfc4423-bis-20

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

Thank you for addressing the rtg-dir review: https://mailarchive.ietf.org/arch/msg/rtg-dir/wNRwnOCELE2lvz4Gy_YKy-Bkz0A

I have mostly just reviewed the diff from RFC4423. My comments are mostly editorial.

First, a minor rant that I don't expect to be addressed at this point in the process; I mainly say this to try to discourage it future bis drafts: There are quite a few changes from 4423 that are entirely stylistic, but do not materially change the content or improve readability. I wish people wouldn't do that, because it makes it harder to review material changes with the diff tools. (I will only point out such changes where I think the original was more correct.)

-General: There seems to have been a systematic attempt to remove hyphens from compound adjectives. There also seems to be a systematic attempt to change headings from title case to normal sentence case.  I suspect the RFC editor will change those all back.

Abstract: The abstract manages to completely avoid saying what this namespace is _for_. (Yes, I realize that is old text :-) )

§1, first paragraph: s/ "try and do"/"try to do"

§4.2: Please mention the HIT abbreviation in the text, not just the heading. (The text should make sense even without the headings.)

§5: 
- third paragraph: Missing articles before "Left" and "right".
- 2nd to last paragraph: Missing article before "HIP layer" (multiple instances).

I share Eric's concerns about the need for
second-preimage-resistance from the hash, and in particular with the
birthday bound, it's unclear that using a 128-bit hash leaves a very
large margin for growth.

Some other section-by-section notes follow.

Section 1

   [...] HIP provides for limited forms of trust between systems,
   enhance mobility, multi-homing and dynamic IP renumbering, aid in
   protocol translation / transition, and reduce certain types of
   denial-of-service (DoS) attacks.

I think that something is weird here with singular vs. plural in the
list elements.


Section 4

I agree with the secdir reviewer's not about "SHOULD NOT [implement
non-cryptographic HIP]"


Section 5.1

   At the client side, a host may have multiple Host Identities, for
   instance, for privacy purposes.  Another reason can be that the
   person utilizing the host employs different identities for different
   administrative domains as an extra security measure.  If a HIP-aware
   middlebox, such as a HIP-based firewall, is on the path between the
   client and server, the user or the underlying system should carefully
   choose the correct identity to avoid the firewall to unnecessarily
   drop HIP-based connectivity [komu-diss].

In addition to the firewall case, choosing the correct identifier
can also impact the privacy considerations, as a given identifier
would be trackable by on-path entities.


Section 6.2

   When a node moves while communication is already on-going, address
   changes are rather straightforward.  The peer of the mobile node can
   just accept a HIP or an integrity protected ESP packet from any
   address and ignore the source address.  However, as discussed in
   Section 12.2 below, a mobile node must send a HIP UPDATE packet to
   inform the peer of the new address(es), and the peer must verify that
   the mobile node is reachable through these addresses.

Am I reading this right that from a technical perspective, the peer
can just accept stuff from wherever, but from a policy/protocol
perspective the UPDATE requirement is included?  The text could
probably be a bit more clear, potentially even without using RFC
2119 language.


Section 10

   There are a number of variables that influence the HIP exchange that
   each host must support.  All HIP implementations should support at
   least 2 HIs, one to publish in DNS or similar directory service and
   an unpublished one for anonymous usage.  Although unpublished HIs

I suggest a parenthetical that the unpublished one should expect to
be rotated frequently in order to disrupt linkability/trackability.

   will be rarely used as responder HIs, they are likely to be common
   for initiators.  Support for multiple HIs is recommended.  [...]

If multiple means "more than two", it's probably better to say that.
(If multiple means "more than one", this is just a weaker version of
"should support at least 2", above.)  And it's rather tempting to
make it a MUST, anyway.

   Many initiators would want to use a different HI for different
   responders.  The implementations should provide for a policy mapping
   of initiator HITs to responder HITs.  This policy should also include
   preferred transforms and local lifetimes.

"mapping of initiator to responder" is potentially confusing, in
that in practice the procedure will be "I want to talk to responder
A, so let me look up that I use HIT X to talk to responder A", which
is the opposite direction from this text.


Section 11.1

I'd consider replacing "is an attempt to" with "attempts to" -- for
example, IPv6 tries to do a lot of things in addition to killing
NAT!


Section 11.3.1

   [...]Second, a
   data plane component is needed.  Most HIP implementations utilize the
   so called BEET mode of ESP that has been available since Linux kernel
   2.6.27, but is included also as a userspace component in a few of the
   implementations.

Nit: "but ESP is included", I think.


Section 12.1

I don't understand the usage of "a-priori" in:
   The need to support multiple hashes for generating the HIT from the
   HI affords the MitM to mount a potentially powerful downgrade attack
   due to the a-priori need of the HIT in the HIP base exchange.


   In HIP, the Security Association for ESP is indexed by the SPI; the
   source address is always ignored, and the destination address may be
   ignored as well.  Therefore, HIP-enabled Encapsulated Security
   Payload (ESP) is IP address independent.  This might seem to make
   attacking easier, but ESP with replay protection is already as well
   protected as possible, and the removal of the IP address as a check
   should not increase the exposure of ESP to DoS attacks.

It seems like there's still some potential incrased exposure, as
validating the ESP crypto is presumably more expensive than
validating source/destination IP addresses.


Section 12.3

   [...] At middleboxes, HIP-aware
   firewalls [lindqvist-enterprise] can use HITs or public keys to
   control both ingress and egress access to networks or individual
   hosts, even in the presence of mobile devices because the HITs and
   public keys are topologically independent. [...]

Nit: I think that just "topology independent" is what's intended.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3709


Maybe I'm missing something important, but I don't see in this
document how you go from a HI (or HIT) to the corresponding IP
locator. That seems pretty critical to making this work. Can you point
me in the right direction?



IMPORTANT
S 11.3.1.
>      avoiding manual configurations.  The three components are further
>      described in the HIP experiment report [RFC6538].
>   
>      Based on the interviews, Levae et al suggest further directions to
>      facilitate HIP deployment.  Transitioning the HIP specifications to
>      the standards track may help, but other measures could be taken.  As

This confuses me, because we seem to be looking to advance some of the
HIP specs (e.g., hip-dex) at PS

COMMENTS
S 3.1.
>         were obtained.  For 64 bits, this number is roughly 4 billion.  A
>         hash size of 64 bits may be too small to avoid collisions in a
>         large population; for example, there is a 1% chance of collision
>         in a population of 640M.  For 100 bits (or more), we would not
>         expect a collision until approximately 2**50 (1 quadrillion)
>         hashes were generated.

It's not just a matter of collisions being hard, but also of being
difficult to produce an HI with a given name.


S 4.
>      'well known', some unpublished or 'anonymous'.  A system may self-
>      assert its own identity, or may use a third-party authenticator like
>      DNSSEC [RFC2535], PGP, or X.509 to 'notarize' the identity assertion
>      to another namespace.  It is expected that the Host Identifiers will
>      initially be authenticated with DNSSEC and that all implementations
>      will support DNSSEC as a minimal baseline.

This wasn't a very good assumption when 4423 was published, and it
seems even worse now, given the low rate of deployment of DNSSEC and
the fact that we know many middleboxes break DNSSEC.


S 4.3.
>      packet.  Consequently, a HIT should be unique in the whole IP
>      universe as long as it is being used.  In the extremely rare case of
>      a single HIT mapping to more than one Host Identity, the Host
>      Identifiers (public keys) will make the final difference.  If there
>      is more than one public key for a given node, the HIT acts as a hint
>      for the correct public key to use.

How do you handle second-preimage attacks on the hash?


S 5.1.
>      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 Section 6.3 or HIP relay server Section 6.4.

This is becoming a less common practice. How do you handle anycast,
which is the modern practice?


S 7.
>   
>      The encapsulation format for the data plane used for carrying the
>      application-layer traffic can be dynamically negotiated during the
>      key exchange.  For instance, HICCUPS extensions [RFC6078] define one
>      way to transport application-layer datagrams directly over the HIP
>      control plane, protected by asymmetric key cryptography.  Also, S-RTP

Nit: SRTP, no hyphen

A few minor high-level comments/questions:

1) To me it feels that sec 11 doesn't really belong in this bis doc. Maybe that is rather an own report or can just go in the appendix?

2) Should this document maybe discuss connection migration as used by QUIC as an alternative (based on short term connection identifiers instead of course)? Background: to provide identities between two endpoints, I'd say that TLS is sufficient or even the more appropriate solution. However, this document does not talk very much about cases where the identify of other IP hosts (not endpoints) is important. Oft course it covers the mobility use case but that also seems less relevant with migration support in QUIC.