Subject: [Int-area] Progress on draft-laganier-ipv6-khi-01.txt

From: Jari Arkko <[email-masked]>
Date: Fri, 02 Jun 2006 16:18:46 +0300

Sometime ago we discussed the allocation of an IPv6 prefix
for the purposes of legacy applications using HIP (the
ORCHID proposal). The key question in that discussion was
whether a /8 allocation is justified for this type of an
experiment. Since then we've had some off-line discussions
with the folks who commented on this topic, to come up
with alternatives to solve this issue. The proposal that
seemed to be acceptable is to allocate a longer prefix
(e.g. /28) as an IETF experimental allocation through
IANA. The implication is that the public key hash would
be truncated to 100 bits, presumably still within
an acceptable range.

If you have an opinion about this matter, please send
mail either here or on the HIP list before June 9th
so that Julien can update his draft.

Thanks,

--Jari

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

---

From: "Dave Thaler" <[email-masked]>
Date: Sat, 3 Jun 2006 15:51:27 -0700

I think for this experiment a longer prefix is fine,
even /40 or /48 unless there's some strong reason it needs
to be shorter during the experiment.

Personally, I'd eventually like to see something like a /8
followed by an org id (like ULAs have).  Since ULAs have 32
bits for such an id, that's how I get /40 (or /48 if eventually
there were a /16 like ULAs use, followed by 32 bit org id).
This would solve some problems HIP doesn't solve today,
which were pointed out in the SHIM6 meeting in Dallas.
(e.g., PTR records for HITs aren't feasible today since
the reverse zone would be flat).

The use of a long prefix for the present experiment could
be consistent with such an eventuality in the sense that
the hash would be truncated to about the same number of bits 
(like 80 or 88).

-Dave

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Friday, June 02, 2006 6:19 AM
> To: Internet Area
> Subject: [Int-area] Progress on draft-laganier-ipv6-khi-01.txt
>

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 4 Jun 2006 09:04:59 +0300

As we discuss in the draft, there are two reasons for making the hash  
as long as possible.  First, a longer hash is more secure to brute  
force attacks made possible by advances in hardware.  Some time ago  
Hugo Krawczyk recommended us to us use at least 96 bits of a hash.   
Second, the longer the hash the lower the probability of collisions.

Of course, being secure against brute force attacks is a two-edged  
sword.  From an architectural point of view, ORCHIDs should be  
considered as a medium-term (10-20 years) transition mechanism that  
allows legacy IPv6 applications to securely use HIP and other similar  
protocols.  In the longer run, such a practise should be discouraged;  
we should encouraged people to update from the IPv6 API to some new  
API that makes the security properties more transparent.  However,  
there is a long long way ahead before we get there, if ever.  I just  
want to note that while there are socially-beneficial incentives for  
making the ORCHID hash as long as possible, there are also other,  
longer-term incentives for making it not too long.

In my personal opinion, having ORCHIDs that are considered secure now  
and could be estimated to be secure for the next 20 years or so might  
be about the right size.

Considering the second property, or collisions, I think it is  
important to experiment with completely flat name spaces.  While I do  
see the value of having an organisation ID embedded in an identifier,  
I do also see the value of having completely opaque flat  
identifiers.  Both have their pros and cons, especially if you  
consider privacy and privacy-related externalities, like price  
discrimination potential.

--Pekka

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 4 Jun 2006 10:42:21 +0300

> and could be estimated to be secure for the next 20 years or so might 

but in that case, you need to make ORCHIDs to support multiple hash 
functions, since i guess it is not that clear that we will stick to 
sha-1 for the next 20 years right?

Regards, marcelo

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 4 Jun 2006 18:02:30 +0300

>> In my personal opinion, having ORCHIDs that are considered secure  
>> now and could be estimated to be secure for the next 20 years or  
>> so might be about the right size.
>

ORCHIDs do support multiple hash functions, through different  
prefixes.  What comes to SHA-1, it is not clear whether it would last  
for 20 years for the ORCHID purpose or not, but the same applies  
pretty much to any other hash function.

--Pekka

---

From: Tim Shepard <[email-masked]>
Date: Sun, 04 Jun 2006 18:44:19 -0400

> the reverse zone would be flat).

Many people think along those lines when thinking about
HIP.   But there are some architectural assumptions made
before you head down that road.

With different architectural assumptions, there would not
necessarily be any need to solve the problem of looking up
a HIT in some distributed database.

For example, ssh host keys are used for identity purposes
in the ssh protocol.  But we have no way, given a bare ssh
host key, of looking it up anywhere (except perhaps in the
user's ~/.ssh/known_hosts file).  So HITs could be used in
similar ways, where referals are never done with HITs alone.

So before trying to "solve some problems HIP doesn't solve today",
we should think about the architectural possibilities.  (E.g. see
the FARA paper at http://www.isi.edu/newarch/ for one think-through.)

In any case, we should not confuse (a) the allocation within the
IPv6 address space for a place to pass handles across interfaces
that today take (only) routable IPv6 addresses with (b) the
structure of HITs (which may in fact be 256-bits long at some point)
or other hash-based identities.  A completely local table could be
kept within any one system to map from the first to the second.

			-Tim Shepard
			 [email-masked]

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Sun, 4 Jun 2006 21:35:03 -0700

> kept within any one system to map from the first to the second.

It is not only local handles where this matters; in fact, as you point
out, it may not matter much there at all.  However, think about using
HITs instead of IPv6 addresses in ACLs; here, referrals may not matter
so much but it would be nice if the HIT were 128 bits and relatively
immune to attacks on its one-wayness.  

I also agree with the points made by Dave (it would be nice to allow
room for experimenting with centrally managed HITs, previously known as
type 2 HITs) and Marcelo (we need to encode the hash algorithm
somewhere), so it seems to me that a compromise that might satisfy
everyone is to define an experimental /28 for ORCHIDs, use a bit to
denote type 1 (flat) or type 2 (structured), and three bits for encoding
the hash algorithm used.  This leaves 96 bits for the hash in the flat
HIT, while the type 2 could use more bits beyond the upper 32 for the
structured id.

Tom

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 5 Jun 2006 19:20:38 +0300

Hi Tom,

a question about this point...

El 05/06/2006, a las 7:35, Henderson, Thomas R escribió:
> HITs instead of IPv6 addresses in ACLs;

I am not sure if i understand in which situations this can be 
practical...

there are at least two things that i am not sure how to deal with in 
this case:
- First, HITs are not carried in every packet (as opposed to IP 
addresses) so you could only have ACLs based on HITs on the endsystem 
(meaning that you cannot have e.g. an ACL on a firewall that is 
inspecting traffic to verify what is filtered, right?) or are you 
considering the case where the firewall keeps track of the hip 
exchange?
- Second, i guess that in order to be usefull it should be possible to 
aggregate the HITs so that you could define blocks in the ACL. I mean a 
plain namespace like HITs seem kind of unpractical since you would need 
to detail each and every host in the ACL. I guess that for this, the 
type 2 HITs would be really needed...

Regards, marcelo

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 5 Jun 2006 10:54:29 -0700

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Monday, June 05, 2006 9:21 AM
> To: Henderson, Thomas R
> Cc: Internet Area; Tim Shepard
> Subject: HIT and ACLs (was Re: [Int-area] Progress on 
> draft-laganier-ipv6-khi-01.txt 
> 
> Hi Tom,
> 

I am considering the case where the firewall/end system keeps track of the HIP exchange.  See, for example, the following draft:
http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-hip-natfw-traversal-04.txt

> type 2 HITs would be really needed...

There is a section in the IRTF NSRG report that describes this issue:

   "Additionally, HIP raises an issue regarding other uses for
   aggregation of IP addresses.  Today, they are not only aggregated for
   purposes of reduced routing, but also for reduced administration.  A
   typical access list used on the Internet will have some sort of a
   mask, indicating that a group of hosts from the same subnet may
   access some resource.  Because the value of a HIT is a hash in part,
   only the administratively assigned value can be aggregated,
   introducing an allocation limitation and authorization concerns."

But in practice today, there is a similar lack of aggregation in ssh key-based access controls.  I think it depends on what you are trying to accomplish with the ACL.  If you really want to write ACL policies based on address prefixes, then continue to do so, but if you want to do it based on host identifiers, then I agree that either they would need to be enumerated or there would need to be some structure added for aggregation (as well as some means to authenticate that the host is authorized to use those structured id bits).  

If a distinct prefix is allocated for ORCHIDs, then it makes it straightforward for a system to determine by inspection whether the entry is an address or a HIT, and finer granularity controls are then possible at the network layer.

Tom

---

From: Tim Shepard <[email-masked]>
Date: Mon, 05 Jun 2006 14:04:12 -0400

> But in practice today, there is a similar lack of aggregation in ssh
> key-based access controls.  I think it depends on what you are
> trying to accomplish with the ACL.  If you really want to write ACL
> policies based on address prefixes, then continue to do so, but if
> you want to do it based on host identifiers, then I agree that
> either they would need to be enumerated or there would need to be
> some structure added for aggregation (as well as some means to
> authenticate that the host is authorized to use those structured id
> bits).

But a bare HIT which happens to have some prefix does not imply that
it was created with the permission of the authority that controls the
reverse mapping for that prefix.  Seems like you need to do an on-line
lookup or have a full blown certificate anyway.  In that case, there's
no value (that I can see) in having a prefix.

(Should this be on the hip-rg mailing list instead of int-area?)

			-Tim Shepard
			 [email-masked]