[Hipsec] RFC4423bis review

["Henderson, Thomas R" <[e-mail]>]

Robert,

Here are some comments on RFC4423bis that I would be
willing to provide specific text inputs if you and others agree.
I also have editorial nits that can be handled offline.

Section 1
---------
In paragraph 2, it would read better to introduce the concept of
a Host Identity before talking about the Host Identifier.  Also,
clarify that there is exactly one Host Identifier for each Host
Identity, but that there can be multiple Host Identities for each
real computing platform.  Also, the last sentence of this paragraph 
should probably refer to Identifiers and not identities.

Suggested text:

   The proposed Host Identity namespace fills an important gap between
   the IP and DNS namespaces.  A Host Identity conceptually refers
   to a computing platform, and there may be multiple such Host 
   Identities per computing platform (because the platform may wish
   to present a different identity to different communicating peers).
   The Host Identity namespace consists of Host Identifiers (HI).  
   There is exactly one Host Identifier for each Host Identity.  While
   this text later talks about non-cryptographic Host Identifiers,
   the architecture focuses on the case in which Host Identifiers are
   cryptographic in nature.  Specifically, the Host Identifier is the
   public key of an asymmetric key-pair.  Each Host Identity uniquely 
   identifies a single host, i.e., no two hosts have the same Host 
   Identity.  If two or more computing platforms have the same Host
   Identifier, then they are instantiating a distributed host.  The Host 
   Identifier can either be public (e.g.  published in the DNS), or 
   unpublished.  Client systems will tend to have both public and 
   unpublished Host Identifiers.

In other drafts, we have gone out of our way to avoid referring
to IPsec (because it is a whole suite of protocols) and instead
specifically refer to ESP.  Suggest a global change from IPsec
to ESP in this document.

Section 2.2
-----------

I would reorder Host Identity Hash to come before Host Identity Tag.
Also, the Host Identity Tag in practice is not just the cryptographic
bits but some other bits, so the definition should reflect that it
is not soley hash bits.

Section 3
---------
I was not sure about the statement that IP addresses are a confounding
of two namespaces.  I think it may be more accurate to say that
the namespaces for endpoint identifiers and interface names overlap
since IP addresses are used for both names (or that there is
no separate namespace for endpoint identifiers, for historical reasons).

Here is suggested replacement text for paragraph 3:

   The IP addressing namespace has been overloaded to name both 
   interfaces (at layer-3) and endpoints (for the endpoint-specific
   part of layer-3, and for layer-4).  In their role as interface
   names, IP addresses are sometimes called "locators" and serve
   as an address within a routing topology.

In the last paragraph of section 3, IMO these sentences needs more 
clarification:

   Firstly, dynamic readdressing cannot be directly managed.  Secondly,
   anonymity is not provided in a consistent, trustable manner.

I did not try to rewrite them since I am not completely sure what
is the intended point.

Section 3.1
-----------

In Section 3.1, I would suggest to not use the terminology
"IP kernel" when in other parts of the text, this is referred to as an
endpoint.  For this bulleted list, I would preface it by saying that
these were the goals at the onset of the HIP work, since some of the
speculation in these bulleted items actually came to pass.

For this bullet:
   o  It must be possible to create names locally.  This can provide
      anonymity at the cost of making resolvability very difficult.

Where names are created is not that relevant to whether they become
published or remain anonymous.  So I would suggest instead:

   o  It must be possible to create names locally.  When such names
      are not published, this can provide anonymity at the cost of 
      making resolvability very difficult.


Section 4
---------
I don't know what you mean by using X.509 to notarize the identity
assertion.  Do you mean to notarize the binding of an identity
to other names?

Section 4.2
-----------
This section shouldn't be limited to DNS, but to storing in
databases and directories in general.  Also, from a document flow
perspective, this section mentions HIH while Section 4.4 below it
introduces HIH, so suggest to move this after the HIH section.

Section 4.3
-----------
Again, this text needs to be updated to cover the ORCHID bits.

Section 5
---------

Host Identifiers are not slightly different from interface names;
I would argue that they are substantially different.  (paragraph 2)

I suggest to change "Service" in Figure 1 to "Transport association"

There seem to be two concepts missing from this section.  First,
the cost of moving to the right side of Figure 1 is that one needs
to be able to securely bind IP addresses to Host Identifiers,
and one may want to resolve Host Identifiers to IP addresses (the
latter issue isn't a problem with today's architecture).  However,
a key aspect of this architecture is that the key management and
signaling association set up by HIP provides the security context
necessary to make this binding.

Another subtle point with the architecture in Figure 1 is that there
needs to be a demultiplexing from incoming IP address to 
host identity for incoming packets, and there is no such packet
field to do this unless fields are added.  This can be later mentioned
in the IPsec section (that one fringe benefit of ESP is the 
use of SPI as indicies to this context, but if ESP is not used,
something else would be needed here in this architecture).

It probably bears mentioning somewhere in this section that
the lack of reverse lookup mechanism for HITs, if no such
infrastructure is provided, will possibly hinder referrals.

There probably could be a section or few paragraphs here about
APIs since there was work done on both a native API and on reusing
legacy API.

Section 7
--------

Similar comment here about "ESP" vs. "IPsec".

It is vague to say that HIP is "friendly" to middleboxes (para. 3).
Instead, suggest to say that HIP provides mechanisms for middlebox
authentication to occur.

In the fourth paragraph, there is some text on not setting up
more than one SA pair between the same HITs.  I don't think this
is necessarily true in multihoming (especially if replay window
concerns exist along different paths).

In the next paragraph, it says that HIP is not for gateways,
but at least for the VPLS implementation that we at Boeing are
interested, this is not strictly true.

Section 9
---------
Should mention that RFC5770 is scheduled to be replaced; perhaps
just identify it as an "experimental" version of NAT traversal.

Section 10
----------
It states here that there are few concrete thoughts about HIP and
multicast, yet there have been some studies about this.  Perhaps
summarize and reference?

Section 11
----------
Probably want to mention the tension here between anonymity and
authentication, and describe how HIP provides new challenges
for systems or users to decide which type of HI to expose when
they start a new session.  This is somewhat akin to source address
selection in IP, but I would argue that it is a more serious policy
concern at the HIP level than the robustness concern that exists at
the IP level.

Probably also want to discuss in this section the policy tradeoff
for opportunistic mode (can provide some security benefits but may
be subject to MITM).

Section 13
----------
This section remains to be written.

Section 14.1
------------
This section should describe that the flatness of HITs makes it 
a challenge for ACLs to be aggregated.

Section 14.2
------------
Rather than call this section "non-security considerations" I would
suggest "Alternative HI considerations".