[Hipsec] Well back at this yet again -- Re: RFC4423bis review

[Robert Moskowitz <[e-mail]>]

Finally completed an update of 4423-bis.

now to NOT get bogged down in minutia in 5201-bis...

On 04/04/2011 10:35 AM, Henderson, Thomas R wrote:
> 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.

Is there? Can there be multiple hashes applied to a single Host Identity 
making for multiple Host Identifiers?

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

IPsec left in two places. Please review these and check that all ESP 
usages are correct. I think I got it all.

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

done.

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

I grant your point. I have a particular attachment to the term 
'confounding', as one of my Stat profs was always confounding us with it!

But I will go with this due to the evolution of the discussion of IP 
address 'meaning' with one change:

as an endpoint within a routing topology.

> In the last paragraph of section 3, IMO these sentences needs more
> clarification:
>
>     Firstly, dynamic readdressing cannot be directly managed.

Predates neighbor discovery and use of MAC addr for 64bits of IPv6 
address, so not so true anymore. The impact on the app space in managing 
address for binding purposes.

>    Secondly, anonymity is not provided in a consistent, trustable manner.

Use of MAC addr makes anonymity 'harder' than when this was written. An 
ephemeral HIT provides anonymity.

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

Given this any additional comment?

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

This was a 'big debate' in the Namespace Research Group: "What are you 
naming?" In the end the 'IP Stack' was deemed the named entity. Endpoint 
was considered too vague. So 'IP kernel' equates to the 'IP stack' and 
thus this terminology.

Does anyone have any feelings on this?

I did change one instant of kernel to stack.

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

I tried but could not come up with anything readable.

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

Done.

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

X.509 to 'notarize' the identity assertion to another namespace.

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

Fixed.

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

Kind of fixed. I don't say ORCHID, but include the 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"
Done.
> 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.

Help? Nothing done yet on this....

> 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.
it is very important that the HIP provides mechanisms for middlebox 
authentication.

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

Cleaned up. Please review.

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

I have added a para:

It should be noted that there are already BITW implementations.
This is still consistant to the SA bindings above.

> Section 9
> ---------
> Should mention that RFC5770 is scheduled to be replaced; perhaps
> just identify it as an "experimental" version of NAT traversal.
Done.
> 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?

Minimal change. Please provide references to include?

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

Text added, please review.

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

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

Added.

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

Much better! Though the thought of a non-security consideration fitted 
my whimsy at the time.