Subject: [arch-d] Last Call comments on draft-laganier-ipv6-khi-05 ORCHID

From: <[email-masked]>
Date: Tue, 21 Nov 2006 11:01:16 +0200

All,

I presented these thoughts on the [email-masked] list
yesterday, and was told it would be useful to send these in as Last Call
comments for draft-laganier-ipv6-khi-05 (ORCHID). I have thought a bit
more about this, so this is a bit more developed than what I wrote
yesterday.

I think ORCHID is asking for too little, and is in no way facilitating
effective lookups, or localizing identities (which I expect to be a
requirement in some jurisdictions). IMO, ORCHID is also plainly wrong:

- 1st of all, the ORCHID proposal is contradicting itself. It calls
  for conformity with RFC 3513 section 2.5.4, but breaks this:

"All global unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), "

- Therefore it is wrong to ask for allocation under IANA Special 
  Purpose Address Block (which starts with binary 001).

- ORCHID should ask for something like 0400::/6 (binary 0000 01),
  claiming 1/8 of the address space starting with binary 000

 - Maybe should be asked for limited time experimentation (e.g. 5 
   years), and all systems could be mandated to cease using these 
   addresses after the dead line. Unless the status is changed 
   before expiration?

- If bit 7 is clear, the whole ID MUST be registered (see below)

- If bit 8 is clear, the bits 9-28 are used for regional/national
  (RIRs/NIRs? and/or DNS top level domain structure?) level
  aggregation for efficient, localized lookups.

  Here is an example what DNS records for an identity could look
  like:

$ORIGIN 5.4.3.2.1.4.0.ip6.arpa

0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.e.d.c.b.a.9.8.7.6 IN PTR
example.test.com
                               IN AAAA 3ffe:400:10:100:201:2ff:feb5:3806
                               IN A 153.43.23.1
...

 - the $ORIGIN part has the bits 1-28 (7 nibbles). Nibbles
   "5.4.3.2.1" are the bits 9-28 for regional aggregation.
 - PTR points to a FQDN for the ID (if any), and AAAA and/or A records
   give locators for the identity
 - New RR type would be needed to map from a FQDN or a locator to an
   identity (e.g. "ID")

- If the bit 8 is set, the bits 9-28 are used for experimentation
  and collaborative, independent global lookup provision??

- bits 29-128 would be self assigned identity, as in ORCHID 
  (exept the hash will need to change, see below). See the PTR,
  AAAA, and A RRs in the example above.

- If bit 7 is set, the ID MUST not be registered on any registry.
  In this case the bit 8 would be reserved (set to zero), and use
  bits 9-128 for a 120-bit identifier hashes for better security
  and lower chance for statistical collisions

The hash function will need to be changed to include the prefix
as input. But note that this in NOT network topology dependent 
prefix. If we are lucky this difference will be enough to get
past some of the existing IPR on CGAs.

If I recall right, one of the expressed concerns against ORCHID has 
been semantical overloading. By using address space starting with 
binary 000 this overloading is avoided.

If what I propose above is too much, please feel free to 
utilized what you find useful (if any).

Regards,

	Jarno Rajahalme

Some context for the above:

Pekka Nikander wrote:
>Rajahalme Jarno wrote:
>
>> Thus it would be beneficial to allocate part of the reserved IPv6 
>> address space (with some of the first couple of bits) for the ID 
>> usage.
>> This way they would be unambiguous. Have sufficient number of bits in
>> an "ID prefix" to enable scalable reverse lookup (might be useful), 
>> and most (e.g. at least 100) bits for the "random" ID part(more bits
>> for higher security).
>
>Do you mean
>
>http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-05.txt
>https://datatracker.ietf.org/public/idindex.cgi?command=id_deta
>il&id=13628
>
>Currently in an extended IETF Last Call for 4 weeks, on its last week.
>
>Some apps folks have voiced their concerns, but most people seem to be 
>supportive for such an experiment.
>
>Or do you have something else in your mind?
>

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 23 Nov 2006 08:36:43 +0200

Jarno,

Thanks for your valuable comments.  While I largely agree with you,  
I'm afraid that what you ask below, and what we originally asked for  
in the first versions of the ORCHID draft, are just too much for the  
wider IETF community to swallow at this point of time.  In other  
words, the original version of the ORCHID draft asked for more than  
the current one; not exactly in the way you did in your message, but  
still.  The current draft represents a consensus that was achieved at  
the Internet Area mailing list.  A watered down consensus if you  
will, but, hey, this is the IETF.  :-)

>   claiming 1/8 of the address space starting with binary 000

We originally asked for 1000::/8 (binary 0001 0000), which falls  
within the binary 000.  Then there would have been 120 bits of the  
hash, instead of the kind-of regional structure that you propose.   
Personally, I still think that the 100 bits of hash is problematic.   
It won't take that long before it will be vulnerable to brute force  
attacks.  By Moore's law, 120 bits would give us some 20-30 years more.

But that was deemed unsuitable by some old-time IETFers, including a  
former member of the IAB.  Basically, if I understood correctly, the  
original proposal was felt to overstep the RIR policies.  Secondly,  
apparently, some people feared that it would open up the floodgates  
to the 0000::/3 space, which was considered politically very bad.   
There were corridor rumours of fears that if this experiment was  
given something, then other SDOs would come and ask for similar  
pieces of space for non-addressing purposes.  Personally, I don't  
understand what would be so bad there.  But hey, apparently I don't  
understand the IETF power politics in any case; that I have bitterly  
felt enough of times.

Hence, as I stated above, the current proposal is the compromise we  
were able to reach.

Personally, I still think that allocation from 0000::/3 would be  
better than what we ask for in the current draft.  As you indicated  
later, it would to make a distinction between ORCHIDs/Identifiers and  
"mere" addresses.  However, at least one of the IESG members seems to  
think that there is no difference on where the prefix is allocated,  
from the apps point of view, and apparently not worth doing due to  
the reasons stated above.  But I may be misreading people's words.   
On the other hand, personally, I think RFC 3513 makes a potential  
difference.

>    addresses after the dead line. Unless the status is changed

That is exactly what we asked for originally: a time-limited  
experiment, with by-default cease of use.  Again, that was removed as  
a part of the drafting process.

> as input.

I think that change was already done as per security review, but my  
memory may fail here.  Julien took care of that change.

> binary 000 this overloading is avoided.

I completely agree with you here, but some other people seem to  
bitterly disagree.

--Pekka Nikander

PS.  I don't read ietf-discuss.  If you want your replies to reach  
me, please include my personal address in the CC/To field.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 24 Nov 2006 13:55:48 +0200

Pekka, Jarno,

Thank you Jarno for the comments. A few observations:

1) You are right Jarno that the document is inconsistent
with its claim of RFC 3513 compliance. The document
needs to change in some manner to resolve this.

2) Nevertheless, as we discussed this draft in the IESG,
it was felt that while there are issues in the choice
of the location of the prefix in the address space,
it is more important to first look at the higher level
issue that Ted Hardie raised. For discussion, see these
e-mails:

http://www1.ietf.org/mail-archive/web/ietf/current/msg44187.html
http://www1.ietf.org/mail-archive/web/ietf/current/msg44183.html

and please state your opinion! If we can't agree that
this type of use of addresses is a good idea to begin
with, arguing about the details make little difference.

My personal opinion is that the benefits from
this type of an allocation far outweigh the
risks of referral leakage etc (and the
type of leakage is already occurring from
RFC 1918 address space).

3) Does the move to a different starting bits
remove the above concern? Personally, I
don't think it makes a lot of difference.
Applications do not look at the bits. It
is definately easier from a debugging
point of view, however.

4) When I looked at the issue of prefix size I did not
find any evidence that you would actually need
more bits than the 100-or-so that the current
draft states. But I'm not an expert in key
lengths. Perhaps you have some specific arguments
that we could look at? But lets still stay focused
on the idea that this is an experiment and
targeted for IP layer operations. This isn't
your banking records archival system. And
I don't think its a good idea to keep the same
IP layer identifiers for decades; the required
safety margins need to be designed accordingly.

And its a temporary experiment. I do not
think we should allocate more address space
for this than is really necessary. And yes,
it is a good idea to not to set a precedent that
we can allocate more address space than
needed.

But if there's an argument that we actually
DO need more bits, this can certainly be
considered.

5) The suggested localized, DNS-based lookup
scheme: none of this has ever been in the
draft. I think we should experiment with ideas
like the one that you have Jarno. And there
are many ways to do it.

But isn't the right approach for you to write
a draft about it? I understand that there are
many needs beyond the one that the khi
draft is addressing. But it is not clear to me
that we should hold up HIP experiments
until we've decided how to do identifier
lookups. And there are many ways to do
it.

I would also recommend experimenting
and testing these techniques before
we standardize them. Experimental
allocations, experimental protocols in
this space would be very welcome. Once
we have some evidence that they
actually work and are useful, we
can start discussing moving them to
real use and standards track.

--Jari

Pekka Nikander kirjoitti:
> Jarno,
>
> Thanks for your valuable comments. While I largely agree with you, I'm
> afraid that what you ask below, and what we originally asked for in
> the first versions of the ORCHID draft, are just too much for the
> wider IETF community to swallow at this point of time. In other words,
> the original version of the ORCHID draft asked for more than the
> current one; not exactly in the way you did in your message, but
> the Internet Area mailing list. A watered down consensus if you will,
> but, hey, this is the IETF. :-)
>
> A few details:
> Personally, I still think that the 100 bits of hash is problematic. It
> won't take that long before it will be vulnerable to brute force
> apparently, some people feared that it would open up the floodgates to
> the 0000::/3 space, which was considered politically very bad. There
> were corridor rumours of fears that if this experiment was given
> something, then other SDOs would come and ask for similar pieces of
> space for non-addressing purposes. Personally, I don't understand what
> would be so bad there. But hey, apparently I don't understand the IETF
> power politics in any case; that I have bitterly felt enough of times.
>
> from the apps point of view, and apparently not worth doing due to the
> reasons stated above. But I may be misreading people's words. On the
> other hand, personally, I think RFC 3513 makes a potential difference.
>
> experiment, with by-default cease of use. Again, that was removed as a
> part of the drafting process.
>
> PS. I don't read ietf-discuss. If you want your replies to reach me,
> please include my personal address in the CC/To field.
>
>
>
>