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

From: Robert Moskowitz <[email-masked]>
Date: Thu, 01 Sep 2011 13:51:12 -0400

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.

---

From: Andrew McGregor <[email-masked]>
Date: Fri, 2 Sep 2011 09:46:42 +1200

On 2/09/2011, at 5:51 AM, Robert Moskowitz wrote:

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

Isn't the exact word you are looking for 'conflation'?  As in, using the same name for multiple different ideas?

Andrew

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 1 Sep 2011 22:00:44 -0700

> Isn't the exact word you are looking for 'conflation'?  As in, using
> the same name for multiple different ideas?
> 

Yes, 'conflation' works well here.

- Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Sat, 3 Sep 2011 08:02:21 -0700

> -----Original Message-----
> From: Robert Moskowitz [mailto:[email-masked]]
> Sent: Thursday, September 01, 2011 10:51 AM
> To: Henderson, Thomas R
> Cc: HIP
> Subject: Well back at this yet again -- Re: RFC4423bis review
> 

This section doesn't pertain to hashes or HITs, but to the relationship between host identifier (the public key) and host identity (the abstract notion of identity).  

My proposed text was trying to make this section more internally consistent, but I think the main issue to resolve still is whether you can have multiple keys refer to the same identity, or just a single key per identity.  That is, there is already a statement in the draft that there can be multiple host identities, in the abstract sense, (e.g. an anonymous and a public identity) for a computing platform.  The question is whether each of these identities themselves can have multiple identifiers (keys).  If so, is there a need to be able to bind these host identifiers together somehow?

I'll try to provide some suggested text for the other points requiring more input by next week.

- Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 6 Sep 2011 08:43:33 -0700

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Henderson, Thomas R
> Sent: Saturday, September 03, 2011 8:02 AM
> To: 'Robert Moskowitz'
> Cc: HIP
> Subject: Re: [Hipsec] Well back at this yet again -- Re: RFC4423bis
> review
> 
> 
> 
> This section doesn't pertain to hashes or HITs, but to the relationship
> between host identifier (the public key) and host identity (the
> abstract notion of identity).
> 
> My proposed text was trying to make this section more internally
> consistent, but I think the main issue to resolve still is whether you
> can have multiple keys refer to the same identity, or just a single key
> per identity.  That is, there is already a statement in the draft that
> there can be multiple host identities, in the abstract sense, (e.g. an
> anonymous and a public identity) for a computing platform.  The
> question is whether each of these identities themselves can have
> multiple identifiers (keys).  If so, is there a need to be able to bind
> these host identifiers together somehow?
> 

I had some off-list discussion of this issue over the weekend so I would like to propose a resolution.  The proposed text would replace the second and third paragraphs of section 1 of rfc4423-bis-03, and it is the last paragraph below that tries to clarify the relationship between Host Identity and Host Identifier:

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

   There is a subtle but important difference between Host Identities
   and Host Identifiers.  An Identity refers to the abstract entity that
   is identified.  An Identifier, on the other hand, refers to the
   concrete bit pattern that is used in the identification process.

   It is intended that no two hosts have the same Host Identity; each 
   Host Identity and corresponding Host Identifier uniquely
   identifies a single host.  If two or more computing platforms have
   the same Host Identifier, then either they are instantiating a 
   distributed host, or there has been an accidental or intentional
   violation of the uniqueness property of a Host Identity (e.g., due
   to malicious host impersonation arising from key theft).  The
   architecture also allows for multiple Host Identifiers to be
   associated with the same abstract identity, such as due to 
   key revocation and renewal procedures over time.  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.