Subject: Re: [Int-area] Re: KHIs and SHA-256

From: Pekka Nikander <[email-masked]>
Date: Tue, 15 Nov 2005 10:04:31 +0100

Christian,

>> => the draft is supposed to address both issues. For the first one
>> we can add more cautionary words if one believes there are not yet
>> enough. For the second one we already merged two very different
>> experiments into one request.
>
> Well, if that is what we want, then we can write a much simpler draft,
> "reserving a prefix for non routable identifiers". It will have
> essentially one or two paragraph of text, plus the usual ten pages of
> boiler text.

I would almost agree with you.  However, as we do discuss in the  
draft, we also want to use a hash function to securely bind  
information into the identifier.  Consequently, there is the tension  
of having as many bits as possible in the hash, and spending as few  
bits as possible in the prefix.

Consequently, if we want to share the prefix with multiple  
experiments, we either
   a) need to define some bits to define which experiment is going  
on, or
   b) define a means of encoding this information in the hash

We have chosen b), with the motivation of thereby getting a longer  
hash.  No explicit bits needed to differentiate the experiments,  
resulting in a slightly longer hash.

--Pekka

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

---

From: Geoff Huston <[email-masked]>
Date: Wed, 16 Nov 2005 05:40:51 +1100

>>essentially one or two paragraph of text, plus the usual ten pages of

Its a simple draft, but it still makes absolutely no sense to me to me in 
terms of relating to to an address allocation. If these token values are in 
fact "non routable identifiers" , which is what I read above, then you have 
no semantic intersection with the conventional address space and you can 
set up a "non-routeable identifier" register and allocate unique identifier 
tokens according to any distribution criteria that makes sense according to 
the intended use.

Geoff

---

From: Brian Haberman <[email-masked]>
Date: Tue, 15 Nov 2005 14:20:43 -0500

On Nov 15, 2005, at 13:40, Geoff Huston wrote:

> Its a simple draft, but it still makes absolutely no sense to me to me 
> in terms of relating to to an address allocation. If these token 
> values are in fact "non routable identifiers" , which is what I read 
> above, then you have no semantic intersection with the conventional 
> address space and you can set up a "non-routeable identifier" register 
> and allocate unique identifier tokens according to any distribution 
> criteria that makes sense according to the intended use.

Another benefit of a separate registry for IDs is the removal of the 
size
concern (mentioned as a reason for the request of a /3).  As completely
separate from addresses, these identifiers could be even larger than
128 bits.  And this would increase their strength as cryptographic
entities.

Regards,
Brian

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 15 Nov 2005 21:54:51 +0100

Dear Geoff and Brian,

> Its a simple draft, but it still makes absolutely no sense to me to  
> me in terms of relating to to an address allocation. If these token  
> values are in fact "non routable identifiers" , which is what I  
> read above, then you have no semantic intersection with the  
> conventional address space and you can set up a "non-routeable  
> identifier" register and allocate unique identifier tokens  
> according to any distribution criteria that makes sense according  
> to the intended use.

Geoff, to quote my longer message
http://www1.ietf.org/mail-archive/web/ipv6/current/msg05900.html,
"I fully agree with you that a new identifier name space should not  
be mixed with any existing locator space."  Hence, from what I called  
"an ideal architectural point of view", I agree with what you write  
above, with the difference that I don't see need for any registries.   
Statistical uniqueness seems to be enough.

The difference is that I try to be practical here, and pave way to  
such fully fledged, non-routable identifiers, which in fact are much  
larger than 128 bits, like Brian pointed out:

> Another benefit of a separate registry for IDs is the removal of  
> the size

As I wrote, I can't see how we could convince the world from going  
from where we are now to a world that requires people to change their  
network stack, add a new piece of infrastructure, and to change  
applications at the same time.  That won't happen, any more.  Even a  
"killer application" that requires a stack change and a piece of new  
infrastructure would be highly unlikely to succeed.  Hence, try to  
minimise the amount of change required at each step.

Doesn't that transition strategy make any sense to you?  What is  
wrong with it?

If you are worried that once established such hook for an identifier  
space within the address space is likely to last for a long time,  
please say so.

--Pekka

---

From: Tony Li <[email-masked]>
Date: Tue, 15 Nov 2005 13:21:12 -0800

> from where we are now to a world that requires people to change  
> their network stack, add a new piece of infrastructure, and to  
> change applications at the same time.  That won't happen, any  
> more.  Even a "killer application" that requires a stack change and  
> a piece of new infrastructure would be highly unlikely to succeed.   
> Hence, try to minimise the amount of change required at each step.

If we follow that logic, how do we ever deploy any change?  Any kind  
of locator/identifier semantics is necessarily a change, just because  
it is not the status quo.  It will have impact somewhere in the stack  
and run into the brick wall of actual deployability.

I submit, rather, that we have the ability to deploy change, but that  
we only have one shot and we'd best do it right.  IPv6, while  
distributed, is not actually deployed in the sense of it being  
enabled and pervasive yet.  If we, as a body, reached consensus on a  
change, it would be tractable to deploy new stacks.  Obviously, it  
needs to be a worthwhile change.

Tony

---

From: Brian Haberman <[email-masked]>
Date: Tue, 15 Nov 2005 14:20:43 -0500

Regards,
Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 15 Nov 2005 21:54:51 +0100

Dear Geoff and Brian,

--Pekka

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 16 Nov 2005 14:31:09 -0800

Pekka Nikander wrote:

> "I fully agree with you that a new identifier name space should not  be 
> mixed with any existing locator space."  Hence, from what I called  "an 
> ideal architectural point of view", I agree with what you write  above, 
> with the difference that I don't see need for any registries.   

I think it would be wise to reserve from space for identifiers in the 
128-bit IPv6 space, whether they are statistically unique or whether 
they have internal hierarchy.
The KHI draft seems to assume that we would only ever need 128 
identifiers that have no internal hierarchy, which seems short-sighted 
as best, given how little we know about the feasibility of doing lookups 
in flat very large spaces.

One thing I didn't understand from the KHI draft is how we can remove 
the use of these identifiers if they are successful.
If folks use them (meaning that they appear in the appropriate places in 
the DNS, and that stacks know what is an identifier vs. a locator based 
on the prefix), how would they disappear from use?
Is the assumption that the applications would switch to some other API 
which explicitly passes HIs or HITs?
I don't see much benefits to move the applications to use the existing 
APIs (e.g., connect()) with a KHI, to some other API which passes a 
128-bit HIT without a KHI prefix.
So I must be missing something.

   Erik

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Nov 2005 14:47:41 -0800

I agree. I think any allocation should be considered experimental, 
particularly since there is a possibility that the identifiers might become 
longer in the future. However, it is also possible that 128 bit identifiers 
might become standard practice. At this point, we don't really know.

            jak

----- Original Message ----- 
From: "Erik Nordmark" <[email-masked]>
To: "Pekka Nikander" <[email-masked]>
Cc: "Christian Huitema" <[email-masked]>; "Internet Area" 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, November 16, 2005 2:31 PM
Subject: Re: [Int-area] Re: KHIs and SHA-256

> 128-bit IPv6 space, whether they are statistically unique or whether they 
> have internal hierarchy.
> The KHI draft seems to assume that we would only ever need 128 identifiers 
> that have no internal hierarchy, which seems short-sighted as best, given 
> how little we know about the feasibility of doing lookups in flat very 
> large spaces.
>
>
> One thing I didn't understand from the KHI draft is how we can remove the 
> use of these identifiers if they are successful.
> the DNS, and that stacks know what is an identifier vs. a locator based on 
> the prefix), how would they disappear from use?

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 17 Nov 2005 15:31:07 +0100

Tony and Erik,

>> more.  Even a "killer application" that requires a stack change  
>> and a piece of new infrastructure would be highly unlikely to  
>> succeed.  Hence, try to minimise the amount of change required at  
>> each step.
>
>
> If we follow that logic, how do we ever deploy any change?  Any  
> kind of locator/identifier semantics is necessarily a change, just  
> because it is not the status quo.  It will have impact somewhere in  
> the stack and run into the brick wall of actual deployability.
>
> I submit, rather, that we have the ability to deploy change, but  
> that we only have one shot and we'd best do it right.  IPv6, while  
> enabled and pervasive yet.  If we, as a body, reached consensus on  
> a change, it would be tractable to deploy new stacks.  Obviously,  
> it needs to be a worthwhile change.

I would find it very nice if we could change the IP layer, install  
infrastructure, and change the applications in one shot.  I just  
don't believe that we any more can do it -- we almost failed with  
IPv6, and IMHO would have failed without the _severe_ address  
scarcity outside of NA and EU.

People are replacing their computer and operating systems all the  
time.  Hence, a change to the stack *can* be fairly generally  
implemented in 5-7 years, which is the time of most hosts get  
replaced or at least undergo a software update.

Given a new stack is there, people *may* start to use a piece of new  
infrastructure.  Getting a new piece of DNS-like infra out there is  
relatively easy.  What is hard is to get people to generally use it  
and to provide to running the infrastructure by sharing part of the  
operational load.  I wasn't there when DNS was initially deployed,  
but as far as I have understood, it wasn't exactly painless.

If there is new functionality in the stack and new piece of  
infrastructure, it *may* be possible to provide sufficient incentives  
for upgrading the applications.   I would imagine that security might  
be such a feature in the long run.

> One thing I didn't understand from the KHI draft is how we can  
> remove the use of these identifiers if they are successful. If  
> folks use them (meaning that they appear in the appropriate places  
> in the DNS, and that stacks know what is an identifier vs. a  
> locator based on the prefix), how would they disappear from use?   
> Is the assumption that the applications would switch to some other  
> API which explicitly passes HIs or HITs?

Yes, that is what I hope to eventually happen.

> I don't see much benefits to move the applications to use the  
> existing APIs (e.g., connect()) with a KHI, to some other API which  
> passes a 128-bit HIT without a KHI prefix.

I don't see much incentive for for doing a KHI -> pure HIT  
transition, but I could imagine some incentive for KHI -> HI  
transition, where HI can assumedly be much longer and even variable  
size than a KHI or HIT.

But I do agree with you that we are missing some thinking here, i.e.,  
we are missing a convincing set of incentives.  Maybe we should go  
and try to create them artificially, by reducing the KHI hash size so  
that they will become insecure sooner that with the current design,  
and by not allowing the experiment to be continued, say, beyond 2015  
even with IETF consensus.  _Sort_ of similar to what we did with  
6bone, making it very clear from the beginning that people have to  
eventually move forward.

If the currently secure hash size is about 96 bits, 120 bits can be  
expected to become insecure in about 24 years....   Maybe that is too  
much; OTOH, given the recent advances in breaking SHA-1, we should  
have *some* marginal....

--Pekka

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 17 Nov 2005 15:22:28 -0800

Pekka Nikander wrote:

> infrastructure, and change the applications in one shot.  I just  don't 
> believe that we any more can do it -- we almost failed with  IPv6, and 
> IMHO would have failed without the _severe_ address  scarcity outside of 
> NA and EU.

Pekka,

I hope you didn't interpret my comments that we need to replace 
everything at once. For instance, I don't think we should change the 
applications and the APIs at all - the applications should continue to 
function using getaddrinfo() + connect()/sendto() using 128 bit names 
for their peers. [We might want to introduce an optional 
connect_by_name() call to make it easier/faster to handle the 
multiplicity of locators.)

Thus I see a need to evolve the stack (towards shim6 and hip like 
capabilities) as well as a way to handle ID->locator lookup when/if we 
have identifiers that are not also usable as locators.
But I don't see a need to change anything else.

> be such a feature in the long run.

But security of what? See below.

> we are missing a convincing set of incentives.  Maybe we should go  and 
> try to create them artificially, by reducing the KHI hash size so  that 
> they will become insecure sooner that with the current design,  and by 
> not allowing the experiment to be continued, say, beyond 2015  even with 
> IETF consensus.  _Sort_ of similar to what we did with  6bone, making it 
> very clear from the beginning that people have to  eventually move forward.

But for the 6bone there was a place to move to which had the same 
characteristics hence the cost to move is relatively low; the needed 
forcing function doesn't have to be that strong.

If the goal is to cause all the applications on the planet to be 
rewritten there is no forcing function strong enough; you'd need 
significant benefits to even get a small fraction of the applications to 
be ported to something new.

> much; OTOH, given the recent advances in breaking SHA-1, we should  have 
> *some* marginal....

My assumption is that anybody that cares about security of the content 
being communicated applies some security to that content; IPsec, TLS, 
whatever. And if folks care about www.example.com really mapping to an 
IP address and the routes pointing in that direction, we need DNSsec and 
some routing security.

AFAICT we need this even if HIP is used (even though HIP helps to get 
IPsec end-to-end).

I think this implies that the length of the hash is only there to 
protect against redirection attacks for off-path attackers; on path 
attackers e.g. somebody that can cut the wire or control the 
software/firmware in a router or switch can always redirect packets.

Thus in terms of the mobility and multihoming control protocol, the 
attacks for the important traffic would be limited to redirecting the 
encrypted payload to somewhere else. If the e2e encryption is good 
enough, this would be the same as redirecting it to a black hole i.e., 
a, possibly selective, DoS attack on some traffic.

How much effort would an attacker like to spend on such an attack?
And what are the different ways the attack could be performed?
The attacker could look for input that hashes to the same identifier, 
which will be feasible in the future, but will require significant 
compute cycles.
The attacker could also gain physical access to the path (break in, 
bribe somebody with access, etc). Comparing the cost/effort of a 
protocol attack vs. a physical attack is like comparing apples and 
oranges. But I still think we need to consider this so that we don't 
overengineer the protection against redirection attacks.

An attacker can use bribes to get physical access - take $10,000 to 
$100,000 as numbers out of a hat.
An attacker can attack the hash function for a single host - how many 
CPU hours are required to do this today? With what hash length would 
this be less than 10,000 to 100,000 CPU hours today?

I realize that HIP is a bit harder to analyze in this was than shim6, 
because HIP also uses the HIT/HI to secure the payload with ESP. But the 
above arguments would apply to shim6 and "ESP-less HIP".

    Erik

---

From: Jari Arkko <[email-masked]>
Date: Fri, 18 Nov 2005 06:25:18 +0200

Erik Nordmark wrote:

>> infrastructure, it *may* be possible to provide sufficient 
>> incentives  for upgrading the applications.   I would imagine that 
>> security might  be such a feature in the long run.
>
>
> ...
> IP address and the routes pointing in that direction, we need DNSsec 
> and some routing security.
>

Yes. One of the reasons why this is needed is that
the specific issues in applications typically need specific
security support that is easier to provide in application
or transport layer. Secondly, historically, we have struggled
in providing meaningful and universal information from IP
layer security mechanisms to applications. I do not
see any reason why the world would change in this regard,
particularly given the already developed and deployed
mechanisms.

> software/firmware in a router or switch can always redirect packets.

Agreed.

--Jari

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 18 Nov 2005 13:02:05 +0100

[Dropping IPv6 as this has nothing to do with IPv6 any more]

Jari and Erik,

>>> incentives  for upgrading the applications.   I would imagine  
>>> that security might  be such a feature in the long run.
>>
>>
>> My assumption is that anybody that cares about security of the  
>> content being communicated applies some security to that content;  
>> IPsec, TLS, whatever. And if folks care about www.example.com  
>> really mapping to an IP address and the routes pointing in that  
>> direction, we need DNSsec and some routing security.
>>
>> AFAICT we need this even if HIP is used (even though HIP helps to  
>> get IPsec end-to-end).
>

I think you may be missing one aspect of CGAs/KHIs/HITs/whatever,  
which is implicit channel bindings and the ability to continue  
identifiers for security purposes.

We have a long tradition of using IP addresses for security.  In the  
original architecture IP addresses used to act as very good  
approximations of host or end-point identifiers, making it natural to  
use IP addresses to make a difference between more and less trusted  
hosts.  The same design was adopted into IPsec, and is still used in  
many firewalls, configuration files, proxies, etc.

Using something which looks and tastes like an IP addresses to an  
application (while not being it in the network) is able to build upon  
that tradition.  When we add strong security semantics to this,  
basically providing a much higher level of assurance that any packet  
sent to that identifier is not delivered to anyone else but the  
identified recipient, we just strengthen the semantics that we used  
to have and that many applications and practises still assume.

CGAs and KHIs can be seen as handles to public keys.  While CGAs are  
currently used only in SeND, both CGAs and KHIs could be used to  
provide, implicitly, the strong security semantics.  That is what HIP  
does with its HITs.  If you send a packet to a HIT, the underlying  
HIP layer will create an IPsec ESP association with the named host  
(authenticated with the public key bound to the HIT), and delivers  
the packet ESP protected, if at all.

Hence, the security I was referring to is the strength of the  
cryptographic binding from the IPv6-look-alike identifier to the  
public key.  If the hash is short, the binding is weak.  Even the  
currently-proposed 120-bits hash will become vulnerable during the  
lifetime of many of us, and using 128 bits doesn't help much there.   
Consequently, in the long run, I think there is some incentive to  
move using full public keys (or something similar) as host or end- 
point identifiers.

--Pekka

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 18 Nov 2005 10:56:02 -0800

>>> IPsec, TLS, whatever. And if folks care about www.example.com  really 
>>> mapping to an IP address and the routes pointing in that  direction, 
>>> we need DNSsec and some routing security.
>>>
> I think you may be missing one aspect of CGAs/KHIs/HITs/whatever,  which 
> is implicit channel bindings and the ability to continue  identifiers 
> for security purposes.

I suspect neither Jari or I have missed that.
I guess I don't understand what you are responding to; this particular 
part was about the need for DNSsec and routing security.
I don't think you are arguing that we don't need those if we have HIP, 
thus I don't understand what point you are making relative to what I and 
Jari said.

> cryptographic binding from the IPv6-look-alike identifier to the  public 
> key.  If the hash is short, the binding is weak.  Even the  
> Consequently, in the long run, I think there is some incentive to  move 
> using full public keys (or something similar) as host or end- point 
> identifiers.

The impact of the above was what I explicitly disclaimed in my email 
yesterday.
But to understand the security of the system, one would presumably need 
to start with a FQDN and take into account DNSsec and routing security, 
and see what the different threats are.

For instance, how would HIP (with its binding by having the hash in the 
HIT) compare with getting both AAAA and IPSECKEY RRs from (the secured) DNS?
I certainly don't understand all the tradeoffs to make such a comparison.

    Erik

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 18 Nov 2005 21:14:13 +0100

Erik,

I must have been reading your and Jari's yesterday's messages  
carelessly.  My apologies.  I'll try to find time to read them  
again.  I agree that as we are in general dependent on DNS names, we  
need to worry about DNS security, too.  Where KHIs and the like may  
help there is the possibility of using leap-of-faith kind of methods,  
in a way similar to what SSH does today.

--Pekka

You wrote:
> I guess I don't understand what you are responding to; this  
> particular part was about the need for DNSsec and routing security.

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 14 Nov 2005 09:24:37 -0800

boiler text:

"Various experiments require encoding a non routable identifier in the
format of an IPv6 address. To avoid confusion with regular use of IPv6
address, we instruct the IANA to reserve the prefix xxxx:yyyy::/n for
that purpose. (TBD IANA: specific value of xxxx:yyyy; TBD working group:
specific value of n). The addresses will have the following format:

+---------------+---------------------------------------------+
| n bits prefix | (128-n) bits identifier                     |
+---------------+---------------------------------------------+

Different experiments are expected to construct the identifier in
different ways. Each experiment is expect to specify how the identifier
is constructed and verified, e.g. using experiment-specific
cryptographic procedures. Each experiment MUST specify an identifier
verification method that will validate properly allocated identifiers
according to this experiment, and invalidate incompatible identifiers
allocated according to different experiments."

-- Christian Huitema