Re: [Hipsec] Last Call: <draft-ietf-hip-rfc4843-bis-05.txt> (An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)) to Proposed Standard

[Julien Laganier <[e-mail]>]

On Sat, Jun 7, 2014 at 8:22 AM, S Moonesamy <[e-mail]> wrote:
> At 09:04 28-05-2014, The IESG wrote:
>>
>> The IESG has received a request from the Host Identity Protocol WG (hip)
>> to consider the following document:
>> - 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers
>>    Version 2 (ORCHIDv2)'
>>   <draft-ietf-hip-rfc4843-bis-05.txt> as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> [e-mail] mailing lists by 2014-06-11. Exceptionally, comments may be
>
>
> I took a quick look at the draft.
>
> In Section 1.1:
>
>   "While being technically possible to use ORCHIDs between consenting
>    hosts without any co-ordination with the IETF and the IANA, the
>    authors would consider such practice potentially dangerous."
>
> The document is intended as an IETF RFC.  I suggest framing the about from
> an IETF perspective instead of the authors' perspective.

s/the authors/the IETF/ ?

>   "A specific danger would be realised if the IETF community later
>    decided to use the ORCHID prefix for some different purpose.  In
>    that case, hosts using the ORCHID prefix would be, for practical
>    purposes, unable to use the prefix for the other new purpose."
>
> My reading of the above is that the working group is trying to make a case
> for some free IPv6 addresses.  According to the sixth paragraph in that
> section ORCHIDs are about allowing people to experiment.  The question that
> arises is why is an intended Proposed Standard being used to describe an
> experiment.  I don't understand the "danger" argument.  Is the ORCHID
> request for an experiment or for a prefix to be set aside for people using
> the technology?

HIP _was_ an experiment supported by ORCHIDs. The experiment has
concluded and HIP is going to proposed standard, requiring a propose
standard ORCHID, so the sixth paragraph can be adapted accordingly:

OLD:

ORCHIDs are
   designed to address this situation: to allow people to experiment
   with protocol stack extensions, such as secure overlay routing, HIP,
   or Mobile IP privacy extensions, without requiring them to update
   their applications.  The goal is to facilitate large-scale
   experiments with minimum user effort.


NEW:

ORCHIDs are
   designed to address this situation: to allow people to implement
   protocol stack extensions, such as secure overlay routing, HIP,
   or Mobile IP privacy extensions, without requiring them to update
   their applications.  The goal is to facilitate large-scale
   deployments with minimum user effort.

> In Section 3:
>
>   "Router software MUST NOT include any special handling code for
>    ORCHIDs.  In other words, the non-routability property of ORCHIDs, if
>    implemented, MUST be implemented via configuration and NOT by
>    hardwired software code.  At this time, it is RECOMMENDED that the
>    default router configuration not handle ORCHIDs in any special way.
>    In other words, there is no need to touch existing or new routers due
>    to ORCHIDs.  If such a reason should later appear, for example, due
>    to a faulty implementation leaking ORCHIDs to the IP layer, the
>    prefix can be and should be blocked by a simple configuration rule."
>
> There is, in my opinion, excessive usage of RFC 2119 key words in the above.
> I suggest using RFC 2119 key words for the main points.

Specific suggestions would be welcome w.r.t. to what is excessive, and
the proposed remedy.

> The IANA Considerations in Section 6 could do with a few changes.  Please
> see RFC 6890 for the information requirements for having a reservation in
> the IPv6 Special-Purpose Address Registry.

IANA considerations will be clarified based on the forthcoming IANA review.

> The termination date for the ORCHID assignment is March 2014.  It may be
> easier to note the fact that the experiment has ended instead of saying that
> the prefix is to be returned to IANA in 2014.

This provides useful information on the need for an allocation for
the time being, and I believe can be edited as you suggest as an
editorial change during AUTH48 once the draft has been approved by
IESG.

--julien