Subject: CGA issues

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 9 May 2004 15:54:10 +0200

Gentlemen and gentle ladies,

Let me dive right in...

At the instigation of Brian Carpenter, one of the chairs of the site 
multihoming in IPv6 (multi6) wg, I've had a look at the CGA draft. 
There are two issues I want to bring up with regard to what's happening 
in multi6, and a third, unrelated issue.

Presently, the multi6 wg is looking at multihoming mechanisms that 
involve a host receiving regular provider aggregatable addresses from 
two or more different ISPs, and switch addresses in mid-session if 
necessary. (As opposed to the current IPv4 way of achieving multihoming 
through the use of provider independent addressing, which won't scale.)

The main issue is that for multi6, we are considering several 
mechanisms that work much more effeciently if the lower 80 or 64 bits 
of the IPv6 address stays the same when a rehoming event occurs. Since 
one of the inputs for CGA generation is the subnet prefix, it's not 
possible to generate an interface identifier value that is a valid CGA 
in two different subnets.

Second, some form of cryptographically generated addresses could also 
be very useful for securing the interactions necessary to achieve 
multihoming. However, this would require those CGAs to be globally 
unique (at least statistically) and much longer-lived than what seems 
to be assumed in the current CGA draft.

Finally, the draft doesn't specify the value of the universal/local and 
group bits in the cryptographically generated interface identifier. 
Obviously it's important that naive implementations don't adopt a link 
address that happens to have the group bit set, as will be the case in 
approximately 50% of all CGAs. Additionally, it is probably prudent to 
set the u/l bit to 1, as CGAs aren't "universal".

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 9 May 2004 22:42:58 +0200

On 9-mei-04, at 17:57, Jari Arkko wrote:

>> of the IPv6 address stays the same when a rehoming event occurs.  
>> Since one of the inputs for CGA generation is the subnet prefix, it's  
>> not possible to generate an interface identifier value that is a  
>> valid CGA in two different subnets.

> That's right, but can you explain how multi6 works better
> if the interface identifier stays the same?

We are considering having routers rewrite the upper 48 bits of the IPv6  
address. Also, solutions that require an address mapping database are  
more efficient to implement if only the top 48 bits are different: this  
requires one entry per site, rather than one entry per host.

> Presumably, a
> multi6 solution would have to have some sort of a "handle" --
> interface identifier, fqdn, ephemeral key (wimp hash chain
> or HIP HIT) to be able to correlate the sessions from the
> multiple addresses. Where SEND (or RFC 3041) is used, the
> interface identifier keeps changing.

There are many proposals on the table, and they differ widely in this  
regard. However, when addresses change this requires communication, so  
it's better to avoid such a change if it's not strictly necessary.

> However, if you assume
> that SEND is being used, the key pair behind the CGA might
> be a better alternative for the handle than the interface
> identifier.

I agree. See  
http://www.ietf.org/internet-drafts/draft-van-beijnum-multi6-cbhi 
-00.txt I obviously wasn't aware of CGA when I wrote this draft.

> Are you trying to see how existing multi6
> solutions would work together with SEND, or are you trying
> to see whether CGA could be used as a multi6 solution?

CGA on it's own can't be a multihoming solution. I think it would be  
useful to reuse CGA as a security mechanism in a multihoming solution,  
but mostly I'm concerned with making SEND and multi6 work together  
without getting in each other's way.

> Note that if you rely on the same IID across rehoming
> events, you are precluding multihomed hosts, and just
> talking about site multihoming. Multihomed hosts would
> likely have a different IID on different interfaces.

If a host has multiple interfaces, it is indeed likely that these will  
have different interface identifiers. However, this isn't strictly  
required and/or subject to change. Moreover, most hosts would have  
multiple addresses on one interface, in which case the same interface  
identifier is reused by the current IPv6 implementations I'm aware of.

>> However, this would require those CGAs to be globally unique (at  
>> least statistically) and much longer-lived than what seems to be  
>> assumed in the current CGA draft.

> Hmm... why? Do you want the interface identifier to be unique
> or the public key to be unique? The former is much harder to
> achieve, but I'm not sure it is needed. If you want to tell
> your peer that you are now using a new IP address X, you'll
> just sign a statement to this effect using your private
> address. The peer verifies the signature and also ensures
> that the public key is the same one you were using before.

In this scenario you need to negotiate keys before a rehoming event  
occurs. This isn't very desirable, for two reasons:

1. Some applications use very many very short lived sessions (ie, HTTP)
2. Connectivity may temporarily run over an insecure link so that an  
attacker gets to set up malicious state that can be abused later

A system where a crypto-based identifier is embedded in the IPv6  
address has the advantage that after a rehoming event, the host can  
prove that it's still the same host as before, without the need to  
exchange key information before the rehoming event happens.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 09 May 2004 23:55:25 +0300

> In this scenario you need to negotiate keys before a rehoming event  

Not necessarily. Lets assume that you and I have communicated
for a while, and that I have used the address Y. You don't know
that Y = prefix1 | hash(my public key | ...), but it is. Then
I move to prefix2, and adopt the address X = prefix2 |
hash(my public key | ...). I'll tell you about it by sending
you the following information:

   - Y
   - X
   - my public key
   - my signature

At this point you will become aware that even my previous address
was a CGA. And you can verify that both addresses have come from
the same public key (even if the addresses are completely different).
And you can verify my signature. And no information had to be
communicated before the rehoming event occurred.

> exchange key information before the rehoming event happens.

Yes, but in the scheme that I outlined above there's no need
for prior exchanges.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 09 May 2004 18:57:20 +0300

Iljitsch,

Thanks for opening this discussion. Some comments
inline:

> multihoming in IPv6 (multi6) wg, I've had a look at the CGA draft. There 
> are two issues I want to bring up with regard to what's happening in 
> multi6, and a third, unrelated issue.
> 
> The main issue is that for multi6, we are considering several mechanisms 
> that work much more effeciently if the lower 80 or 64 bits of the IPv6 
> address stays the same when a rehoming event occurs. Since one of the 
> inputs for CGA generation is the subnet prefix, it's not possible to 
> generate an interface identifier value that is a valid CGA in two 
> different subnets.

That's right, but can you explain how multi6 works better
if the interface identifier stays the same? Presumably, a
multi6 solution would have to have some sort of a "handle" --
interface identifier, fqdn, ephemeral key (wimp hash chain
or HIP HIT) to be able to correlate the sessions from the
multiple addresses. Where SEND (or RFC 3041) is used, the
interface identifier keeps changing. However, if you assume
that SEND is being used, the key pair behind the CGA might
be a better alternative for the handle than the interface
identifier. Are you trying to see how existing multi6
solutions would work together with SEND, or are you trying
to see whether CGA could be used as a multi6 solution?

> Second, some form of cryptographically generated addresses could also be 
> very useful for securing the interactions necessary to achieve 

Right. I guess this is what I was referring to above.

> unique (at least statistically) and much longer-lived than what seems to 
> be assumed in the current CGA draft.

> set the u/l bit to 1, as CGAs aren't "universal".

Tuomas, can you say something about this?

--Jari

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 May 2004 08:38:49 +0300 (EEST)

> communicated before the rehoming event occurred.

Doesn't this require you share a trust anchor with everyone in the
Internet (the dreaded global PKI! :)?  Unless I'm missing something,
this has an entirely different set of assumptions than SEND currently
has?

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 10 May 2004 10:55:56 +0200

> communicated before the rehoming event occurred.

Excellent, this alleviates the "negotiate in advance" issue.

Still, I don't see the value in having the subnet prefix in the hash, 
and there's still the issue of address rewriting.

Are there any attacks that can be fended off this way? If it's just a 
privacy thing I don't think that's enough justification, as it's 
already possible to generate a new hash based on an existing key by 
selecting a new "modifier" value. The only problem here is that this is 
more expensive when a "Sec" is in effect. But that's pretty much a 
feature rather than a downside.

BTW, I'm no statistician and I don't play one on tv, but isn't there a 
significant chance that you're going to run into statistical anomalies 
when searching for a SHA-1 hash with a certain number of 0 bits in it? 
I mean, the chance of getting a SHA-1 with all 0 bits in the lowest 16 
bits would be 1 in 65536. But that doesn't automatically mean that if 
you try 65536 times you hit one. Has anyone done the math on this?

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 May 2004 10:51:25 -0700

> > set the u/l bit to 1, as CGAs aren't "universal".

I believe we agreed in the WG that these bits aren't set. The group bit
isn't set for the reason Iljtsch has mentioned. The universal bit isn't set
because the interface identifier (as opposed to the address itself) isn't of
global scope. Unlike EUI-64 addresses, CGA identifiers aren't handed out by
a controlling authority that is trying to keep them universally unique. They
might be expected to be statistically unique globally, but that is different
from a specific intent to make them unique, which is what the WG interpreted
RFC 3513 to mean.

Section 4 Step 6 in draft-ietf-send-cga.txt specifies how the 'u' and 'g'
bits are handled in CGAs:

   6.  Form an interface identifier from Hash1 by writing the value of
       Sec into the three leftmost bits and by setting bits 6 and 7
       (i.e., the "u" and "g" bits) both to zero.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 May 2004 11:44:30 -0700

Iljitsch,

> without getting in each other's way.

First off, the CG properties of addresses are not expected to be checked by
hosts off of the owning host's last hop link.  That is, CGAs are not
expected to be used for any purpose other than SEND, which is only concerned
with the last hop link. Therefore, if a router somewhere in the path is
rewriting the 48 bit routing domain specific prefix, this change should not
affect packets sent between hosts on the local link, unless the rewriting is
being done for packets on the local link (i.e. not being forwarded) by the
last hop router, which seems unlikely to me.

Secondly, from a practical standpoint, CGAs are heavily IPR-encumbered. The
SEND WG was able to obtain a nonRAND IPR release from the IPR owners for the
purpose of SEND *only*. If the multi6 working group is interested in using
CGAs for multi6, it would need to ask the IPR holders about what their
licensing terms are for multi6. That process is likely to take a long time,
and may run into ideological opposition from the Open Source community and
others who believe that IPR is bad in principle, or even people who don't
object to IPR in principle if it is nonRAND but would if RAND licensing
terms are required for multi6 because the multi6 WG doesn't manage to obtain
a nonRAND release (this was one of the major issues in the SEND WG). It is
truely unfortunate that CGAs are so heavily encumbered, since they are
really useful in a wide variety of situations and one would just like to use
them where they work, but that is reality.

As Jari mentioned, the prefix is included to make guessing attacks more
difficult, and Tuomas can comment on the guessing probability with 0's in
specific bits. The WG has thought long about how to make CGAs work for SEND
and we have something that we think should work for SEND. Rather than delay
SEND, I would like to take the current draft to PS as is. If the multi6 WG
works through the IPR issue with CGAs and comes up with a different way to
prevent guessing attacks that doesn't contain the prefix, then at that time,
the draft can be revised. But, for now, delaying the draft for another 6
months to a year in order to make CGAs work for other purposes than SEND,
when no WG has specific plans to use them nor has worked through the IPR
issues, doesn't seem to make sense to me.

Anyone else in the WG want to comment?

            jak

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 May 2004 22:59:29 +0300

> Anyone else in the WG want to comment?

I agree that SEND should not wait for Multi6 design, nor should
SEND drafts pay much attention to the use of CGA technology for
other purposes than SEND. I'm not sure Iljitsch was proposing
that we do that though.

By the way, I'm pretty sure that we can't improve the
current solution for preventing precomputation.

It may be an interesting topic to figure out if CGAs can be made
to work for Multi6, however. And certainly any Multi6 solutions
should be designed so that they can live with other IPv6 features
like EUI-64 IIDs, RFC 3041, or SEND. Or at the very least the
IETF should be aware of the limitations of proposed Multi6
solutions, if we can't make all features work together.

Regarding IPRs, I have a nit: when you James say "non-RAND",
I think someone might mistake that for non-reasonable and
discriminatory licensing ;-). I think you meant that its
better than RAND. If someone wants to look at the license
conditions, they are below. I'm not a lawyer but I think
they say roalty free unless you demand money for your own
patents on the same thing. Or something like that. Too
bad that's not good enough for KAME, maybe it has something
to do with allowing the use of their code for any purpose
and not just SEND? Or the requirements of their copyleft?
Or just ideological opposition, even when the use would be
allowed? It would be interesting to know if there have
been cases like this in the past with PD, and what happened
in them.

   http://www.ietf.org/ietf/IPR/ericsson-send-ipsec.txt
   http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-send-ipsec.txt

--Jari

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 10 May 2004 22:06:36 +0200

On 10-mei-04, at 19:51, James Kempf wrote:

> isn't set for the reason Iljtsch has mentioned.

Actually I don't think it's necessary to specifically clear the bit per 
se, as long as there is a good strong warning that the generated 
interface identifier may not be used as a link address. But currently 
the interface identifier namespace is used up for all instances where 
either the u/l bit is set to local, or the u/l bit is set to universal 
and the group bit is cleared. This leaves the instances where the u/l 
bit is universal and the group bit is set free for future use, which is 
probably a good thing.

> The universal bit isn't set

Agree.

>        (i.e., the "u" and "g" bits) both to zero.

I think it's important to mention that this procedure results in an 
interface identifier without the intermediate steps mentioned in RFC 
2464 (= flipping the u/l bit in the MAC address which has the opposite 
meaning in the IEEE OUI).

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 May 2004 13:13:58 -0700

> meaning in the IEEE OUI).

If you have any specific proposals for text and where to put that text into
the draft, I believe we could accommodate a last minute change to clarify
this issue.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 May 2004 13:27:55 -0700

Jari,

>    http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-send-ipsec.txt

Yes, sorry, I meant "better than RAND".

W.r.t. KAME, I suspect that the opposition is ideological. The WG chairs
managed to secure the release from both IPR holders, and went out of their
way to obtain a statement from one IPR holder about their requirement for
notification for implementors v.s. no requirement for users in response to a
complaint from the KAME community, but it was insufficient, due to the
possibility that notification might be required for derivative works (even
though the release places no requirement on derivative works, just on
implementors).

W.r.t. past cases, the case I'm most familiar with is IBM's release of the
IPR for Photuris (RFC 1822) in which IBM granted IETF the right to use a
patent in IPSec/IKE. I'm not familar with exactly what the IPR was that was
released, but it seems as if it hasn't stopped the Open Source community
from implementing IKE and IPsec. The ideological oppositions seems to have
arisen recently in response to the increased use of IPR in IETF and the
increased visibility of Open Source.

            jak

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 10 May 2004 22:28:48 +0200

On 10-mei-04, at 20:44, James Kempf wrote:

> hosts off of the owning host's last hop link.

In multi6 we're pretty much changing everything, details like this 
won't stop us.  :-)

> That is, CGAs are not

No, it doesn't work like that. Suppose a site is multihomed, and two 
prefixes (one from ISP X, one from ISP Y) are available on a subnet. So 
host A with key K creates two addresses for itself: X.CGA(K+X) and 
Y.CGA(K+Y). (Simplifying, of course). Now the A starts to communicate 
with B. It chooses the X address for this and all is well. But after a 
while there the link to X fails, and now the router reroutes the 
packets over Y. In order to avoid problems with ingress filtering by Y, 
the router rewrites all addresses with the X prefix into addresses with 
an Y prefix. So B now gets packets from Y.CGA(K+X). The problem with 
this is that Y.CGA(K+X) isn't a valid SEND address so A is unable to 
receive packets for this address.

> Secondly, from a practical standpoint, CGAs are heavily IPR-encumbered.

Do you have a pointer towards more information about this?

> It is

Is it? I find it ridiculous that someone can claim ownership of 
completely obvious ideas. (If someone spends a lot of time and money on 
developing something specific, that's different. (And I find it 
surprising that in these discussions the actual subject matter of the 
patent never comes up.)) Hasn't anyone looked into challenging this?

> difficult,

Is this important enough to risk problems with multihoming?

And couldn't the same results be reached by allowing all prefixes that 
are on-link, rather than just one?

> The WG has thought long about how to make CGAs work for SEND
> SEND, I would like to take the current draft to PS as is.

The IETF has spent much more time on stuff that turned out to be 
problem-riddled. I appreciate your concern about delays, but a slight 
delay isn't going to matter in the long run, while any problems with 
the implementation are going to be around forever. It's important to 
get things right the first time if at all possible.

Note that I'm only talking about the interaction between SEND and 
multi6 here, NOT about re-using CGA for multihoming.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 May 2004 18:43:32 -0700

> the router rewrites all addresses with the X prefix into addresses with

Which router? The border router or the last hop (access) router or some
other router?

> Do you have a pointer towards more information about this?

Jari sent out links to the IPR release notices. If you have access to any
patent database software, you can additionally search for the patent
applications, as it is more than a year since they have been filed.

> Is this important enough to risk problems with multihoming?

Yes, the WG though it serious enough (note to WG members: if anyone in the
WG thinks it isn't, please speak up now).

As for problems with multihoming, as I mentioned, if there are problems,
then the RFC can be revised. RFCs are revised all the time. Please correct
me if I am wrong, but as far as I know, multihoming is nowhere near being
finalized to RFC status. Or is that not so? Is the multi6 WG, as is the case
with SEND, about to finalize this proposal you've presented for address
rewriting and publish it as a Proposed Standard RFC?

> are on-link, rather than just one?

I'm not sure I understand. Could you clarify?

> multi6 here, NOT about re-using CGA for multihoming.

As I hope my questions should indicate, perhaps I still don't understand the
particular multi6 scheme you're proposing to see the problem. I've studied
NOID in some minor amount of depth, but not this address rewriting proposal.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Tue, 11 May 2004 07:44:19 +0300

> I'm not sure I understand. Could you clarify?

I think Iljitsch is thinking that instead of one prefix as an
input to the CGA generation, you would use all the prefixes
on the link. This would work, I think, even if there's a lot
of details to worry about when, e.g., one of the prefixes is
deprecated.

The Extension Fields part of the CGA parameters structure
(Sect 3 in draft-ietf-send-cga-06.txt) can be used to add other
inputs to the CGA generation. This would allow all prefixes to
be included in the hash. It still doesn't make the IID part of
the addresses be the same across different prefixes; the selected
prefix has a special place in the hash too. Revving the CGA
RFC would be needed for that. Even so, the address would
presumably change when the set of prefixes changes, so I'm not
sure we would end up with a practical solution this way.

--Jari

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 11 May 2004 11:52:57 +0200

> on the link.

No. What I mean is that you still create the CGA the same way, but when 
checking it on another system, this system doesn't require the prefix 
to be the actual prefix used in the address, but also allows the prefix 
to be any other prefix that is on-link for this subnet.

So if you have a link with prefixes 2001:0:0:1::/64 and 3ffe:0:0:1:/64, 
and a host generates a CGA that is 2001:0:0:1:0:dead:0:beaf, then it 
can also use the address 3ffe:0:0:1:0:dead:0:beaf. The current rules 
don't allow this as the prefix used in generating the CGA is 
2001:0:0:1::/64, but the modified rule does allow this, as the prefix 
used in the CGA generation is on-link.

This fixes the problem in instances where a host has one interface with 
multiple addresses, but it doesn't in the cases where a host uses 
multiple interfaces...

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 11 May 2004 19:27:00 +0300

Iljitsch,

> No. What I mean is that you still create the CGA the same way, but 
> when checking it on another system, this system doesn't require the 
> prefix to be the actual prefix used in the address, but also allows 
> the prefix to be any other prefix that is on-link for this subnet.
>
> So if you have a link with prefixes 2001:0:0:1::/64 and 
> 3ffe:0:0:1:/64, and a host generates a CGA that is 
> 2001:0:0:1:0:dead:0:beaf, then it can also use the address 
> 3ffe:0:0:1:0:dead:0:beaf. The current rules don't allow this as the 
> prefix used in generating the CGA is 2001:0:0:1::/64, but the modified 
> rule does allow this, as the prefix used in the CGA generation is 
> on-link.

I don't understand why the host has ever to see your Y.CGA(K+X) address.
If I understand correctly, the peer will definitely see it, but why has
to host itself see it?  Assumedly, the multi6 state at the peer could 
list
all the possible addresses that the peer may receive, namely Y.CGA(K+Y),
X.CGA(K+X) as well as Y.CGA(K+X) and X.CGA(K+Y), but mark that only the
first two ones can be used as destination addresses?

--Pekka

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 May 2004 09:36:11 -0700

Iljitsch,

> used in the CGA generation is on-link.

So I think I understand your proposal now, and I think your proposal
requires deeper changes than just to SEND. To use your example, suppose a
node, call it A, on a link with the prefixes 2001:0:0:1::/64 and
3ffe:0:0:1:/64 generates an address (it need not be a CGA) as
2001:0:0:1:0:dead:0:beaf. Now, suppose some router prior to the last hop
router changes the prefix on the address so it become
3ffe:0:0:1:0:dead:0:beaf, as you say, in response to the ISP routing prefix
2001:0:0:1::/64 going down. The packet would arrive at the last hop router
OK, but the last hop router would look into its Neighbor Cache and see that
it doesn't have a mapping corresponding to 3ffe:0:0:1:0:dead:0:beaf. Then,
it would do Neighbor Discovery to find out what node on the link claims that
address.

Why should Node A respond positively to the Neighbor Discovery request? It
didn't generate 3ffe:0:0:1:0:dead:0:beaf in the first place, it generated
2001:0:0:1:0:dead:0:beaf. This problem will occur regardless of whether the
address is a CGA or not.

What your proposal requires is what in the IPv6 WG has been called DIID
(Duplicate Interface Identifier Discovery) rather than DAD (Duplicate
Address Detection). Your proposal requires that a node doing address
autoconfiguration use the same interface identifier for each address
configured on an interface, and to check the interface identifier rather
than the address when doing duplicate detection (it need check only once for
one prefix if this rule is in effect, typically the prefix will be the link
local address prefix since that is the first address configured). The node
would be required to respond to Neighbor Discovery messages for any on-link
prefix containing the interface identifier. Probably the easiest way to do
this would be to require a node to generate addresses for each prefix it
sees on the link, using the same interface identifier, so that the access
router has Neighbor Cache mappings for all addresses corresponding to that
interface identifier. The IPv6 WG has discussed DIID a couple times (since
it does provide some other benefits, like reducing how often a node needs to
do duplicate detection), but I believe it has been rejected each time.

Your proposal would, additionally, make RFC 3041 privacy address impossible
to use, as Tuomas has stated, because RFC 3041 privacy addresses require the
ability of the node to randomly generate interface identifiers. This is
unlikely to be acceptable to the Security Directorate, unless you are
prepared to offer an alternative that provides the same level of privacy as
RFC 3041 addresses.

            jak

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 May 2004 12:48:16 +0200

>> prefix used in generating the CGA is 2001:0:0:1::/64, but the 
>> modified rule does allow this, as the prefix used in the CGA 
>> generation is on-link.

> first two ones can be used as destination addresses?

You make a good point. Still, I would be much happier if hosts could 
have the same interface identifier within different prefixes. This 
would make some issues such as ICMP packets generated for rewritten 
addresses easier to deal with.

BTW, what's the deployment scenario for CGA anyway? I guess it's 
somewhat useful that an attacker can't spoof packets and make them seem 
to come from another host or router, but how does this stop a malicious 
system from presenting itself as a legitimate router?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 May 2004 13:55:43 +0200

On 11-mei-04, at 18:36, James Kempf wrote:

>> What I mean is that you still create the CGA the same way, but when

>> 3ffe:0:0:1:/64,

> requires deeper changes than just to SEND.

Of course.

> To use your example, suppose a
> 2001:0:0:1::/64 going down.

[I think you're omitting the part that the packet is delivered at the 
correspondent, which then sends back a packet to the rewritten 
address.]

> The packet would arrive at the last hop router

> 2001:0:0:1:0:dead:0:beaf. This problem will occur regardless of 

Obviously the idea is that the host DOES configure the address 
3ffe:0:0:1:0:dead:0:beaf for itself after generating the CGA 
2001:0:0:1:0:dead:0:beaf. Note that today, hosts (at least the ones 
I've seen) will combine all advertised prefixes with all interface 
identifiers so this behavior would be fairly natural.

> ability of the node to randomly generate interface identifiers.

How would this be impossible? The only requirement is that the 
interface identifier is used with all available prefixes. Win XP (for 
instance) already does this.

> This is unlikely to be acceptable to the Security Directorate, unless 
> you are prepared to offer an alternative that provides the same level 
> of privacy as RFC 3041 addresses.

Note that the privacy concern that led to the creation of RFC 3041 is 
that a MAC address could be tracked when it moves from site to site. As 
such, only changing interface identifiers when moving from site to site 
would be enough to alleviate privacy concerns, and this doesn't get in 
the way of multihoming.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 May 2004 08:40:59 -0700

> system from presenting itself as a legitimate router?

CGA isn't used for that. There's another part of SEND that involves routers
having certificates which are used to sign Router Advertisements. The host
checks the signature.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 May 2004 09:15:54 -0700

> would be enough to alleviate privacy concerns, and this doesn't get in

RFC 3041 currently puts no restrictions on how the random interface
identifiers are generated. Thus if a user felt that someone was watching
their traffic, the user could force a change in interface identifiers at any
time and without restriction to try to break the correlation. In addition,
if more than one address has the same interface identifier, it provides a
snooper with an additional data point about the host. While current practice
on many operating systems (for example Linux) is to claim addresses with the
same interface identifier for all prefixes, RFC 3041 is really only 3 years
old, and widespread deployment of IPv6 has yet to occur, so ISPs and others
concerned with deployment may not have faced up to the issue yet.

The proposal you've described would establish a correlation between
addresses having different prefixes. If a host wants to use different
prefixes with different interface identifiers to obscure its traffic, for
example by routing particular kinds of traffic over one prefix in order to
foil monitoring, that would not be possible. This would result in a net
reduction in address privacy.

Speaking with my WG chair hat off and operator hat on, in Japan privacy, in
particular address and location privacy, is a major concern primarily
because the social and legal concern with privacy in Japan is considerably
higher than in the US and perhaps even than in Europe(for example, they have
nothing like a Social Security number, due to concerns about it being
misused). Japan had strong regulations governing misuse of location
information from mobile devices such as cell phones and laptops years before
the EU, and the regulations in the US even now are laughable by comparison.*
Any proposal that would result in a net reduction in privacy would not be to
the benefit of DoCoMo's Japanese customers.

Speaking with my WG chair hat on again, my concern is that the net effect of
the proposal, both for CGA and for RFC 3041, would result in a net reduction
in address privacy and security of CG addresses from guessing attacks.
Should the proposal reach Last Call (which, from the lack of response to my
previous question about where it is in the process, I would guess is not
imminent) I or someone else is sure to bring these questions up. In
addition, I know that there are alternate multi6 proposals, such as NOID,
that don't have these issues. As such, I don't believe at this time that
changes in the CGA draft are wise. Should the Security Directorate feel that
the proposal is acceptable, and all raised questions be addressed, the CGA
draft can be revise at that time.

Anyone else in the WG care to comment?

            jak

* For a short comparison of location privacy regulation in the US, Europe,
and Japan see the ISOC Member Briefing at:
http://www.isoc.org/briefings/015/index.shtml

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 May 2004 18:58:05 +0200

On 13-mei-04, at 18:15, James Kempf wrote:

> identifiers are generated.

If people want to change their interface identifier every minute, I 
don't care. (Don't expect me to jump through hoops because of this 
behavior, though.) But it is NOT a good idea to make impossible the 
current practice and possible required future requirement that host 
creates an address for each available prefix using a certain interface 
identifier.

> In addition,
> snooper with an additional data point about the host.

Only in theory. Describe for me a realistic scenario where a host would 
be required to leak this information that would otherwise be 
unavailable.

> foil monitoring, that would not be possible.

Of course this would be possible. What you say is that it must be 
mandatory. That is a completely different thing.

> This would result in a net reduction in address privacy.

0. End-users will in most cases be identifyable by the first 48 or 64 
bits of their address
1. NOT requiring hosts to NOT use the same interface identifier for 
different prefixes in and of its own doesn't impact privacy
2. Multihoming may lead to leakage of much more information anyway
3. The tradeoff between privacy and other issues doesn't automatically 
fall towards privacy

> the EU, and the regulations in the US even now are laughable by 

Hm, strange that there is no RFC 3041 support in the KAME-derived IPv6 
stacks I'm familiar with then.

> in address privacy and security of CG addresses from guessing attacks.

Your concern is unfounded. Please take the time to familiarize yourself 
with the issues.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 14 May 2004 12:06:49 +0900

A couple of quick clarifications.

>>>>> On Thu, 13 May 2004 18:58:05 +0200, 
>>>>> Iljitsch van Beijnum <[email-masked]> said:

> stacks I'm familiar with then.

FreeBSD (which should definitely have a "KAME-derived" IPv6 stack) has
had support for RFC3041 for a certain period (at least FreeBSD 4.8R
has it).  KAME snapshots have supported RFC3041 since February 2001.

Secondly, even if no KAME-derived stacks support RFC3041, I would say
it's irrelevant to what James said.  KAME's target has been the entire
Internet community all over the world from the beginning, and has
never been limited to the Japanese community (the project does even not
have Japanese web pages except developers's local ones under kame.net
or a mailing list limited to Japanese users).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------