Subject: [Hipsec] review of RFC4423-bis

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 26 Sep 2012 21:27:11 -0700

I had another read through of http://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/

I think it is nearly ready to publish; the main substantive comments that I have are:

1) Section 13 (Changes from RFC 4423) is incomplete as written; it should either be completed or deleted

2) it would be nice to describe how host identifiers are intended to be revoked/replaced over time.  However, the current text in Section 1 seems to be restrictive in this regard (more on this below).

3) it would be nice to go into a bit more detail of how HIP relates to multicast

Regarding whether it should be published as Informational or PS RFC, I don't have a strong opinion.  I guess I would lean towards Informational since it is not normative specification, but I would yield to whatever is best current practice in the IETF for documents such as these.

- Tom

Detailed comments below:

Section 1 (Introduction)

> There is exactly one Host Identifier for each Host Identity.

This document does not talk about replacing Host Identifiers over time; should it?  Also, couldn't multiple keys be associated with the same Identity (computing stack)?  I wonder whether this statement is too restrictive, especially since one can imagine times in which keys are replaced and two Host Identifiers may be active at the same time.

Section 2 (Terminology)

> (Public key)  Used as a publicly known identifier for cryptographic identity authentication. 

Does it need to be publicly known?  See later "Unpublished Host Identifier" definition.   Suggest "(typically publicly known)" instead.

Section 3 (Background)

> IP numbers

suggest "IP addresses" instead (many places in this section)

Section 4 (Host Identity namespace)

> As will be specified in the Host Identity Protocol Base EXchange (BEX) [RFC5201-bis] specification

Suggest instead:  "As specified in the Host Identity Protocol [RFC5201-bis] specification

Section 4.1 (Host Identifiers)

>    The actual Host Identities are never directly used in any Internet protocols.

I believe that this should instead be Identifier (Identities are abstract).

Section 4.2 (Host Identity Hash)

> It is possible to for the two Hosts in the HIP exchange to use different hashes.

Suggest "It is possible for the two hosts..."

Section 4.3 (Host Identity Tag)

s/perfers/prefers

Section 5 (New stack architecture)

> As discussed above, the IP addresses can be seen to be a confounding of routing direction vectors and interface names.

Is it routing direction vectors, or endpoint (or stack) names?  Is "routing direction vector" terminology used elsewhere; if so, suggest to add a reference, if not, suggest to change to end-point names.

Section 7 (HIP and ESP)

> As adding a new naming layer allows one to potentially add a new forwarding layer (see Section 9, below), it is very important that the HIP provides mechanisms for middlebox authentication.

Perhaps add reference to RFC 5207 here?

s/consistant/consistent

>  It should be noted that there are already BITW implementations.

Perhaps a clarification here:  "It should be noted that there are already BITW implementations of HIP providing virtual private network (VPN) services."

Section 10 (Multicast)

>    Since its inception, a few studies have looked at how HIP might affect IP-layer or application-layer multicast.

IMO, this section should be expanded with some more commentary about how HIP applies to multicast.  In particular, how amenable are multicast key management protocols and security associations to being able to leverage HIP?  Would HITs ever be put into source or destination address fields of multicast datagrams?

Section 13 (Changes from RFC 4423)

This section is not yet completed.  Either complete or delete.

Section 14 (Security considerations)

> There are more details on this process in the Host Identity Protocol under development.

Suggest to strike "under development" since the HIP protocol has now been developed.

> There has been no attempt to develop a secure method to issue the HIT revocation notice.

This is no longer true due to draft-irtf-hiprg-revocation-05; suggest to rephrase.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 27 Sep 2012 09:06:47 -0400

Great review.  Thank you.  Just some quick notes (Hoiidays through Oct 
11 and I only have a few work hours until then and I got kicked out of 
my office as it is also a guest room; working in my NOC).

> 1) Section 13 (Changes from RFC 4423) is incomplete as written; it should either be completed or deleted

What did I miss?  :)  Problem is I did it after changes and I am not 
good at remembering all I changed :(  So if you can help me, great. If 
the concensus is to delete it, I gladly will.

> 2) it would be nice to describe how host identifiers are intended to be revoked/replaced over time.  However, the current text in Section 1 seems to be restrictive in this regard (more on this belo…

Can add a few words here.  It is almost an anything goes within a 
framework.  A sensor will probably never get its HI revoked/replaced.  
Running out of counter is a good reason to r/r, or just on general 
principles.

> 3) it would be nice to go into a bit more detail of how HIP relates to multicast

And I am NOT well versed on multicast and would need help here. 
Basically we can have HIs for multicast, but what do we have in a 
multicast KMP?  I guess I should read the RFC again!

> Regarding whether it should be published as Informational or PS RFC, I don't have a strong opinion.  I guess I would lean towards Informational since it is not normative specification, but I would…

Same here.  These sorts of RFCs have traditionally been informational.  
Don't know what the current IESG position is.

> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 28 Sep 2012 11:34:50 -0400

I will publish an ID today with all changes so far.  Given my Holiday 
schedule through the 10th, I want to keep things current.

Will take a bit to work through a couple of these recommendations, but 
here is most:

> This document does not talk about replacing Host Identifiers over time; should it?  Also, couldn't multiple keys be associated with the same Identity (computing stack)?  I wonder whether this state…

Yes, this is 'old'.  With all the key algorithms and hashs, there will 
be more than one.  But I will have to think about the difference here 
being discussed between Identifier and Identity.  I will add to this in 
the next couple weeks; what with my holiday schedule.

> Does it need to be publicly known?  See later "Unpublished Host Identifier" definition.   Suggest "(typically publicly known)" instead.

I have added the following to the Explanation:

"Public is a relative term here, ranging from known to peers only to 
known to the World."

> suggest "IP addresses" instead (many places in this section)

Made this change but specifically changed:

"IP addresses are numbers that name networking interfaces"

> Suggest instead:  "As specified in the Host Identity Protocol [RFC5201-bis] specification

Thanks.  Hard to catch all of these tense changes that were necessitated 
due to the original IETF environment.

> I believe that this should instead be Identifier (Identities are abstract).

Changed.

> Suggest "It is possible for the two hosts..."

Changed.

> Section 4.3 (Host Identity Tag)

Fixed.

> Is it routing direction vectors, or endpoint (or stack) names?  Is "routing direction vector" terminology used elsewhere; if so, suggest to add a reference, if not, suggest to change to end-point n…

"Routing direction vector" is right.  This was highly debated back in 
the beginning.  It is the part of IP addressing that is tied into the 
routing infrastructure.  The people behind this distinct terminology 
have scattered to the winds.  I can work out an expansion of this term.  
I will check with my routing colleagues. As for EIDs, it is not even 
Interface names.  EIDs are higher stack things like HITs!

> Perhaps add reference to RFC 5207 here?

Or should it go in Section 9?

> s/consistant/consistent

fixed.

> Perhaps a clarification here:  "It should be noted that there are already BITW implementations of HIP providing virtual private network (VPN) services."

Done.

> IMO, this section should be expanded with some more commentary about how HIP applies to multicast.  In particular, how amenable are multicast key management protocols and security associations to b…

Need help here from some multicast people...

> This section is not yet completed.  Either complete or delete.

Got a decent diff tool?  Otherwise I will drop it.

> Suggest to strike "under development" since the HIP protocol has now been developed.

Done.

> This is no longer true due to draft-irtf-hiprg-revocation-05; suggest to rephrase.

Yes, but what is the status of this?  Will it hold up the RFC while we 
wait for it to come out as an RFC?

I can same something like:

"There has been research in developing a secure method to issue the HIT 
revocation notice."