Subject: [addr-select-dt] about on/off switch of privacy extension

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 16 Jul 2010 19:27:51 +0900

All,

this may be a trivial issue, but let me post it before I forget. :)

What do you think about putting a on/off bit in the distributing policy
for controlling client's behavior of privacy address extension.

I know the privacy extension does harm a lot in a lot of circumstances.
And, if it is possible, why not provide a way to solve this problem
at the same time ?

---

From: Tim Chown <[email-masked]>
Date: Fri, 16 Jul 2010 11:57:26 +0100

> And, if it is possible, why not provide a way to solve this problem

Interesting.

So my personal view with a campus enterprise hat on is I'd like to avoid use of privacy addresses.   The main reason is the same as the reason to use DHCPv6, for accountability.    Of course if use of 802.1x and/or SAVI provides that for autoconf or privacy addresses, we can reconsider.   At the moment 802.1x is common on wireless network but not wired ones.

For managed desktops (or laptops), we can configure privacy addresses off by default in the system build.    Likewise, we *can* configure RFC3484 default policy in our managed desktop builds.    But that is only useful if the same policy applies at all points of attachment on the network and at all times of day.   For RFC3484 policy is may well not do.   For privacy address policy, it probably does.  

If the RFC3484 policy table could distinguish privacy addresses, then their use or prioritisation can be set.   At our site we'd probably like to say in the policy table NEVER use privacy addresses or 6to4 addresses as source addresses.

Tim

---

From: Mohacsi Janos <[email-masked]>
Date: Fri, 16 Jul 2010 13:14:13 +0200 (CEST)

On Fri, 16 Jul 2010, Tim Chown wrote:

> So my personal view with a campus enterprise hat on is I'd like to avoid use of privacy addresses.   The main reason is the same as the
> reason to use DHCPv6, for accountability.    Of course if use of 802.1x and/or SAVI provides that for autoconf or privacy addresses, we
> can reconsider.   At the moment 802.1x is common on wireless network but not wired ones.
> 
> For managed desktops (or laptops), we can configure privacy addresses off by default in the system build.    Likewise, we *can*
> configure RFC3484 default policy in our managed desktop builds.    But that is only useful if the same policy applies at all points of
> attachment on the network and at all times of day.   For RFC3484 policy is may well not do.   For privacy address policy, it probably
> does.  
> 
> If the RFC3484 policy table could distinguish privacy addresses, then their use or prioritisation can be set.   At our site we'd
> probably like to say in the policy table NEVER use privacy addresses or 6to4 addresses as source addresses.

This policy distribution can be done in Windows domain today. You can 
disable privacy enhanced address usage in domain group policy. I don't 
think that you can automatically distinguish between privacy enhanced or 
autoconfigured or dhcpv6 assigned addresses, except if you have other 
administrative rules for interface id generation. RFC 4941, the new 
privacy enhanced address draft, is explicitly stating the privacy address 
not to be used by default. Although RFC 4941 is not widely implemented - I 
did not see any ;-).

By the way, what 3484 policy table stanza you would use to forbid use 6to4 
or some other kind of prefix?

Best Regards,
 		Janos Mohacsi

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 22 Jul 2010 20:35:22 +0900

>> probably like to say in the policy table NEVER use privacy addresses or 6to4 addresses as source addresses.

To define a kind of macro for privacy address description is one idea.
However, it is not a straightforward approach to use policy table to reverse/keep the meaning of another rule, that is source address selection rule 7 here.

   Rule 7:  Prefer public addresses.
   If SA is a public address and SB is a temporary address, then prefer
   SA.  Similarly, if SB is a public address and SA is a temporary
   address, then prefer SB.

Of course, we have to use policy table to implement finer-grained policy, such as for destination site A, prioritize privacy address, and for site B, de-prioritize it.

So, what I'm proposing is to put a toggle for reverse/keep the meaning of Rule 7 in source address selection.

> This policy distribution can be done in Windows domain today. You can disable privacy enhanced address usage in domain group policy. I don't think that you can automatically distinguish between privacy enhanced or autoconfigured or dhcpv6 assigned addresses, except if you have other administrative rules for interface id generation. RFC 4941, the new privacy enhanced address draft, is explicitly stating the privacy address not to be used by default. Although RFC 4941 is not widely implemented - I did not see any ;-).

RFC 3484 source address selection rule 7 also proposes the same.

I don't know why the OS vendor does not follow these RFCs.

> 
> By the way, what 3484 policy table stanza you would use to forbid use 6to4 or some other kind of prefix?

Basically, we are working on address selection related issues.
If our activity is based on RFC 3484, what we can define/change is just ordering rules of destination/source addresses.

In this sense, to forbid use of some specific address is not within the scope of RFC 3484.

--
Arifumi Matsumoto
  Secure Communication Project
  NTT Information Sharing Platform Laboratories
  E-mail: [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Thu, 22 Jul 2010 13:33:41 +0100

> In this sense, to forbid use of some specific address is not within the scope of RFC 3484.

Well, we have some prioritisation that occurs through the (ordered) algorithm described in the RFC, that may be fine tuned by the policy table.

If a site wished to forbid the use of certain source addresses, where else would this be done?

One example might be privacy addresses.    Another might be 6to4 addresses (since these currently are almost always rogue RA prefixes in an enterprise network) for non-6to4 destinations.

Tim