[Int-area] Re: [Hipsec] Re: Last Call: 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)' to Experimental RFC (draft-laganier-ipv6-khi)

[Pekka Savola <[e-mail]>]

Tailing down the Cc: a bit..

On Mon, 30 Oct 2006, Jari Arkko wrote:
> We are last calling this document for the second time, for
> two reasons. The first reason is to make sure that the
> last call has been circulated widely enough in the
> community.

I believe a document such as this is needed, though the allocation 
could be made from some other block; I don't have strong opinions on 
that.

At least Geoff asked whether these need to be drawn from the IPv6 
unicast block.  I'd like to better understand what would be the 
alternatives. Presumably this might refer to a different prefix such 
as ::/16. That might be better because that way it would be clearer 
that the prefixes are not meant to be routable as they would be more 
easily distinguished as special.  I'd suspect that at some point 
implementations or operators filter out most of ::/16 which might ease 
the leakage issues.

Others already commented about undefined 'temporary' allocation part.

A few comments,

In section 1.1:

 In practice, allocation of a separate
   prefix for ORCHIDs seems to suffice, making them compatible with IPv6
   addresses at the upper layers while simultaneously making it trivial
   to prevent their usage at the IP layer.

==> 'making it trivial' sounds too easy to be true.  How exactly do you
prevent their usage at the IP layer -- by filtering source/destination
addresses of the prefix coming in/going out of the wire?  But that was
exactly what you prohibited from doing (by default).  What you seem to be
saying that it might be trivial to prevent IP layer usage _at the consenting
hosts_, but the current statement is broader than that and causes potential
problems as Ted Hardie and maybe others pointed out.

In section 2,

   Encode_n( ): An extraction function which output is obtained by
                extracting the middle 100-bits long bitstring from the  
                argument bitstring.

==> I don't understand what you mean by "the middle 100-bits long
bitstring".  The sentence doesn't seem to parse very well.  I also don't
understand what "middle" might mean here -- it'd probably require a more
specific definition if it stays.

7.  IANA Considerations

==> draft-huston-ipv6-iana-specials includes a list of things IANA 
needs to know (updated slightly by RFC-editor note in the 
announcement) in Section 3.  I believe this is something that every 
requestor should fill in the document itself rather than leave it to 
be done during the IANA stage.  If that process is used here, it might 
be useful to include a filled template in this section.

   We propose sharing the name space introduced for CGA Type Tags.
   Hence, defining new values would follow the rules of Section 8 of  
   [RFC3972], i.e., on a First Come First Served basis.  The policy will
   require updating the policy for assignment in the CGA Message Type 
   name space.

==> I'm not sure if I understand the last sentence.  First of all, you refer
first to 'CGA Type Tags' and then 'CGA Message Type name space'.  Do 
you refer to the same thing or not?  I assume yes (please reword): if 
so, it's not clear why the assignment policy requires updating as it's 
already FCFS.  Further, even if it did, you use passive voice -- it 
isn't clear if this document is meant to update the policy (but 
doesn't adequately specify that), or whether that is done later.


editorial
---------

   As of today, SHA1 [RFC3174] is considered as satisfying the second-
   preimage resistance requirement Hash output of 100 bits is considered
   to have a low enough probability of collisions.

==> period missing before 'Hash'.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6   
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

==> RFC4291 is a later version of this.

   [Hi3]      Nikander, P., Arkko, J., and B. Ohlman, "Host Identity
              Indirection Infrastructure (Hi3)", November 2004.

  [NodeID]   Ahlgren, B., Arkko, J., Eggert, L., and J. Rajahalme, "A
              Node Identity Internetworking Architecture (NodeID)",
              April 2006.

==> it wouldn't hurt if the reference was a bit more specific.  I guess
these are scientific publications.  The journal/conference should at 
least be mentioned.  URL is optional.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area