Subject: Re: [Hipsec] WGLC: draft-ietf-hip-rfc4843-bis

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 11 Mar 2013 14:14:26 -0700

This is a WGLC review of RFC4843-bis.

In general, I only found what I regard to be minor issues, listed below.

Suggested change to abstract
OLD TEXT:
They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers.  To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level.
NEW TEXT:
They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers on networks that route based on IPv6 addresses.

Section 2 refers to the OGA ID.  In RFC 5201-bis, the term "OGA" is used to refer to the RFC4843-bis identifier, but in RFC4843-bis, it is called "OGA ID".  Suggest to modify RFC 5201-bis to rename "OGA" to "OGA ID", as appropriate to align with RFC4843-bis.  (Note that this is a proposal to change RFC5201-bis to align with RFC4843-bis, and no RFC4843-bis action is necessary)

I suggest to change Section 3 title from "Routing Considerations" to "Routing and Forwarding Considerations".  Also, I suggest to delete the second paragraph; we are no longer talking about experimental, and furthermore, the MUST NOT clause gets into implementation issues.  The first paragraph already recommends to handle this via configuration.

Perhaps it may also be clearer (in separating routing from forwarding in this section) to add a paragraph, after the existing first paragraph, dealing with routing:

"ORCHIDs are not designed for use in IPv6 routing protocols, since such routing protocols are based on the architectural definition of IPv6 addresses.  Future non-IPv6 routing systems, such as overlay routing systems, may be designed based on ORCHIDs.  Any such ORCHID-based routing system is out of scope of this document."

I would suggest to delete the Section 3.1 entirely, as it still refers to the RFC4843 experiment and the discussion is out of scope, IMO.

Section 4:  Could this section be moved to an appendix, or just refer back to RFC 4843?  I also do not agree that the probability of collision is negligible; it can happen trivially if a host's keys are reused (consider a copied virtual machine).    If this section is retained in some fashion, I recommend to delete the second paragraph, and to provide the caveat that "so long as keys are not reused" to the first paragraph.  I also don't recommend going into a discussion of a node-wide unified database of ORCHIDs, since it seems out of scope.

Nits:
Abstract:  Cryptographic is misspelled in the abstract.

Section 1: suggest to remove the adjective "vanilla", as it is colloquial terminology

Section 1.2:  
"Non-routability at the IP layer, by design."  By design, or by policy?

Section 2:  Prefix should be changed from (IANA TBD 2001:11::/28 ?) to perhaps (IANA TBD 2001:?::/28)

References:  I suppose it should refer back to 4843 as informative; also RFC5201-bis is now updated from draft version 9.

---

From: Julien Laganier <[email-masked]>
Date: Thu, 28 Mar 2013 14:01:44 -0700

Hi Tom,

Thanks for reviewing the document. My comments inline below:

> They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers on networks that route based on IPv6 addresses.

I'd rather not change the statement that they should not appear in
actual IPv6 headers as this could become a red herring to our argument
that ORCHID allocation is useful and _harmless_. As per your comment
below a will replace vanilla by normal or regular.

> Section 2 refers to the OGA ID.  In RFC 5201-bis, the term "OGA" is used to refer to the RFC4843-bis identifier, but in RFC4843-bis, it is called "OGA ID".  Suggest to modify RFC 5201-bis to rename…

Ok.

> I suggest to change Section 3 title from "Routing Considerations" to "Routing and Forwarding Considerations".  Also, I suggest to delete the second paragraph; we are no longer talking about experim…

While I agree we are no longer talking about experimental, are we sure
we want to leave out the recommendation that the ORCHID prefix not be
hardcoded into data path? Seems to me it is still valuable.

> "ORCHIDs are not designed for use in IPv6 routing protocols, since such routing protocols are based on the architectural definition of IPv6 addresses.  Future non-IPv6 routing systems, such as over…

Ok.

> I would suggest to delete the Section 3.1 entirely, as it still refers to the RFC4843 experiment and the discussion is out of scope, IMO.

Ok.

> Section 4:  Could this section be moved to an appendix, or just refer back to RFC 4843?  I also do not agree that the probability of collision is negligible; it can happen trivially if a host's key…

Ok. Will move to appendix, and add the key reuse caveat, as well as
remove the discussion on the node-wide database.

> Abstract:  Cryptographic is misspelled in the abstract.

Ok.

> Section 1: suggest to remove the adjective "vanilla", as it is colloquial terminology

Ok. Will replace by normal or regular.

> "Non-routability at the IP layer, by design."  By design, or by policy?

I guess by design, since we are not providing the means to route at
the IP layer - they do not have prefix on which longest prefix match
can occur...

> Section 2:  Prefix should be changed from (IANA TBD 2001:11::/28 ?) to perhaps (IANA TBD 2001:?::/28)

Ok.

> References:  I suppose it should refer back to 4843 as informative; also RFC5201-bis is now updated from draft version 9.

Ok.

--julien