Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt

From: Suresh Krishnan <[email-masked]>
Date: Thu, 21 Oct 2004 10:56:49 -0400 (EDT)

Hi Brian,
  That sounds fair to me. I will come up with text with SHOULD language 
for per-prefix enabling of privacy addresses. I just have to figure out 
how it will interact/override with the global enable/disable option. 

Pekka,
  If I make this change, would you still like me to add specific defaults 
for ULAs?

Thanks
Suresh

On Thu, 21 Oct 2004, Brian E Carpenter wrote:

>Suggestion at the end...
>
>Pekka Savola wrote:
>> On Wed, 20 Oct 2004, Suresh Krishnan wrote:
>> 
>>>>o  An attacker who is in the path between the node in question and
>>>>      the peer(s) it is communicating to, and can view the IPv6
>>>>      addresses present in the datagrams.  
>>>>
>>>>                                  However, note that such on the path 
>>>>      attacks are likely able to perform significant correlation 
>>>>      even with RFC 3041 addresses especially if the payloads are not 
>>>>      encrypted.
>>>
>>>I would rather state something like this
>>>
>>>"However, note that an attacker, who is on path, may be able to
>>> perform significant correlation based on the payloads of the packets
>>> on the wire. Use of temporary addresses will not prevent such payload
>>> based correlation"
>>>
>>>This clearly indicates that the correlation is done using data present 
>>>in the payload. Is this text acceptable to you?
>> 
>> 
>> That's fine.
>> 
>> 
>>>>>>As far as I can see, it's exactly the opposite -- privacy extensions 
>>>>>>should not be enabled by default for ULAs.
>>>>>
>>>>>This is already the case. Privacy extensions are disabled by default for 
>>>>>ALL types of global addresses (including the ULA). 
>>>>
>>>>Yes, it's not default -- but what I want to have is being able to 
>>>>distinguish between "enabling privacy for all prefixes" and "enabling 
>>>>privacy for global range prefixes".
>>>>
>>>>I.e., the implementations, when privacy is enabled, should not start
>>>>using privacy extensions by default for ULA addresses, but doing so
>>>>might be configurable.
>>>>
>>>>I think that would be in line with most ULA users' goals.. too bad 
>>>>it's relatively difficult to unambugously say what those global, 
>>>>non-ULA addresses should be called..
>>>
>>>One way to go about this will be to attach a disable flag for specific 
>>>prefix ranges. i.e. fc00::/7 in case of ULAs. This flag will override the 
>>>global enable setting if present for the fc00::/7 range.
>>>
>>>I will add the following text after the first paragraph of 
>>>"Deployment Considerations"
>>>
>>>"Additionally, sites might wish to disable the use of temporary 
>>> addresses for some prefixes while still using them for other global 
>>> prefixes. For example, a site might wish to disable temporary address 
>>> generation for "Unique local" [ULA] prefixes while still generating
>>> temporary addresses for all other global prefixes.To support this behavior,
>>> implementations MAY provide a way  to disable generation of temporary
>>> addresses for specific prefix subranges. This setting, if present, 
>>> MUST override the global settings on the node with respect to the
>>> specified prefix subranges."
>> 
>> 
>> I'm slightly unconformtable with this approach for a couple of
>> reasons.  First, by default, privacy addresses are generated for ULAs
>> as well.  Second, such a flag is just a MAY.
>> 
>> What I'd propose is specify that ULAs SHOULD be excluded by default
>> when privacy addresses are enabled, but that there MAY [or SHOULD] be 
>> a flag to enable privacy addresses for ULAs.
>> 
>> Would that be reasonable?
>> 
>> Note that this will create a dependency on ULA spec(s) becoming RFC
>> before this one does (so that the IANA assigns the prefix range), but
>> that might not be a problem, as AFAIR they're relatively far in the
>> process.  There's no need for normative reference as we want just to
>> know the prefix(es).
>> 
>
>I think it would be better to RECOMMEND that an implementation should
>support netmasks for privacy addresses to be enabled, e.g. enable
>them for 2001::/16 and 2002::/16 only, else disable. Then you don't
>have to call out ULAs at all.
>
>     Brian
>

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Oct 2004 20:17:06 +0300 (EEST)

>   If I make this change, would you still like me to add specific defaults 

I can live with 2001::/16 + 2002::/16, but I think that's a bad choice 
for multiple reasons.  What if we invent 6to4v2 which uses 2005::/16 
and we'd like to automatically apply these semantics to it?  What if 
we run out of 2001::/16 for native allocations?  -- actually we've 
already 1/3 used it up.

Thus being generic and excluding just those that we _know_ aren't
really, really global might seem as a better approach -- one that we
might not need to tweak e.g., 2-3 years down the road..

-- 
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: Suresh Krishnan <[email-masked]>
Date: Fri, 22 Oct 2004 00:05:12 -0400 (EDT)

Hi Pekka/Brian,
  I was thinking of enable/disable flags for separate prefixes which 
override the global settings. 

Let's say you want privacy addresses for everything but ULA 
you would have the following settings

Global   -> Enabled
fc00::/7 -> Disabled

Let's say Brian just wants to enable them for 2001::/16 and 2002::/16

Global    -> Disabled
2001::/16 -> Enabled
2002::/16 -> Enabled

I think that should address both your concern and Brian's concern.

Thanks
Suresh