Re: 3484bis and privacy addresses

[Ray Hunter <[e-mail]>]

inline IMVHO [long answer]
> Dave Thaler <mailto:[e-mail]>
> 11 April 2012 21:17
>> -----Original Message-----
>> From: Ray Hunter [mailto:[e-mail]]
>> Sent: Wednesday, April 11, 2012 6:51 AM
>> To: Dave Thaler
>> Cc: Brian E Carpenter; [e-mail]
>> Subject: Re: RE: 3484bis and privacy addresses
>>
>> With all due respect to everyone concerned, there's no way an end user or IT
>> department can buy a bunch of machines based on the text currently contained
>> in this proposed Standard Track document and
>>
>> 1) be able to predict how each machine will behave by defaultin advance of
>> actually plugging it in.
>>
>> 2) be able to effectively manage a machine's behaviour remotely via an IETF
>> defined control mechanism, because the various MAYs and SHOULDs cannot be
>> overridden by the two things that are actually reasonably well defined by the
>> IETF i.e.
>> the prefix policy table + draft-ietf-6man-addr-select-opt-03 for transporting that
>> policy table.
>
> I don't follow.  Can you provide a specific example of something you are concerned
> about?
Yes.

The new text:

If SA is a temporary address and SB is a public address, then prefer
    SA.  Similarly, if SB is a temporary address and SA is a public
    address, then prefer SB.

Sessions originated from a server on today's implementations e.g. 
Windows server OS currently do NOT use temporary addresses to source 
sessions.
RFC3484 does NOT prefer temporary addresses as default behaviour today.

The current text does not make a distinction between a server and a 
client node, and says a machine should always prefer temporary addresses.

If an implementor follows the current text, this would change default 
behaviour of some current implementations e.g. Windows Server.

That will almost certainly break stuff in production when new software 
versions are introduced.

Example: firewall access between a management server and a bunch of 
machines it manages in a data centre environment.
Example: DSCP bit setting based on ACL in MPLS environments.
Example: PCI credit card processing standards (Fixed IP address or 
static DHCP must be used for computers involved in credit card processing)
Example: helpdesk procedures for correlating long term problems via logs

Implementations for which application compatibility
    considerations outweigh these privacy concerns MAY reverse the sense
    of this rule and by default prefer public addresses over temporary
    addresses.

Ah: but now there is a MAY which effectively allows the implementor to 
do anything they like if the implementor doesn't think Rule 7 is 
appropriate.

Now imagine that I (as an end user) buy a machine of brand X that 
complies 100% with the RFC3484bis Standards Track document (or update an 
existing operating system version that implemented RFC3484 but now 
implements RFC3484bis).

Does the new version use temporary addresses by default? No idea. That 
was left up to the individual implementor.
Does the new version exhibit the same default behaviour as the previous 
version based on RFC3484? No idea.
Does the implementor have any idea what my or my employer's view is on 
privacy addresses (either default ON or default OFF)? Nope.
Does the implementor have any idea what my or my employer's operational 
requirements are? e.g. ACLs? Nope.
Is there a very good chance of taking the incorrect setting as default 
(in either direction)? Yes.

Is there a switch to reverse behaviour: either to turn it on when it 
should be off or off when it should be on?
Sure, but the end user or system manager has to dig around in Brand X's 
proprietary mechanism to figure out how to change it.
In mobile environments, they may not even have direct management access.

Can the system manager change this setting remotely for machines that 
hop between networks e.g. a laptop that moves between work and home and 
various company networks? Undefined.

>> That suggests to me that we're not yet completely on the right track.
>>
>> IMHO If there's an implementation option in 3484bis, there should always be a
>> corresponding control option in the (prefix) policy table, plus a way to
>> effectively transport that policy table in e.g.
>> draft-ietf-6man-addr-select-opt-03.
>
> No, the prefix policy table is for configuring a specific subset of rules (the ones
> using labels and preference).  Configurability for other rules isn't part of
> the "prefix policy table", but is still configurable.
>
> -Dave

Yes. That's exactly my problem. As you say, the prefix policy table can 
only control a specific subset of the end node's behaviour.

The current text effectively gives complete freedom for implementors to 
do what they like on Rule 7: either Default ON or default OFF.

So why have Rule 7 at all?

The current text also only provides a subset of that freedom to system 
managers and end users (the policy table does not effect rule 7). 
Especially for influencing the setting by remote configuration e.g. from 
a trusted DHCPv6 server. The prefix policy table could be updated by 
DHCPv6 via draft-ietf-6man-addr-select-opt-03, but the behaviour of rule 
7 can't be.

Meanwhile the implementor has zero idea of what policies an end user or 
system manager has to comply with, nor an end user's other production 
requirements (including compliance laws, firewalls, ACLs, help desk 
processes, or log processing).

Why should implementors have more freedom to decide on what is 
appropriate behaviour for address selection than the machine's system 
manager or end user?

On the flip side, why even bother with the prefix policy table if an end 
user or system manager still cannot make the machine behave according to 
their local operational requirements?

All I'm saying is that if you define a switch in a standard that an 
implementor can throw, give that same switch to the end user/system 
manager, and make sure the switch setting can also be transported over a 
commonly implemented non-proprietary management mechanism like DHCPv6. 
The end user can still decide whether he or she trusts the DHCPv6 server 
or the content of the DHCPv6 option as a local management preference.




>> Align and package all 3 together, and you have a far better solution.
>>
>> regards,
>> RayH
>>
>> Dave Thaler wrote:
>>> Brian Carpenter writes:
>>>>>>   >   The wording I propose to add is:
>>>>>>   >
>>>>>>   >        "There SHOULD be an administrative option to change this
>> preference, if the
>>>>>>   >        implementation supports privacy addresses.  If there is no such
>> option, there
>>>>>>   >        MUST be an administrative option to disable privacy addresses."
>>>>>>   >
>>>>>>   >   -Dave
>>>>>   That works for me. Perhaps there also needs to be a general
>>>>> statement in the security  considerations that all administrative changes
>> and options MUST be secured against illicit use.
>>> Done.   Draft-02  now includes the wording above, and adds a general
>> statement in the
>>> security considerations section as you suggested.
>>>
>>> -Dave
>
>
> Ray Hunter <mailto:[e-mail]>
> 11 April 2012 15:50
> With all due respect to everyone concerned, there's no way an end user 
> or IT department can buy a bunch of machines based on the text 
> currently contained in this proposed Standard Track document and
>
> 1) be able to predict how each machine will behave by defaultin 
> advance of actually plugging it in.
>
> 2) be able to effectively manage a machine's behaviour remotely via an 
> IETF defined control mechanism, because the various MAYs and SHOULDs 
> cannot be overridden by the two things that are actually reasonably 
> well defined by the IETF i.e.
> the prefix policy table + draft-ietf-6man-addr-select-opt-03 for 
> transporting that policy table.
>
> That suggests to me that we're not yet completely on the right track.
>
> IMHO If there's an implementation option in 3484bis, there should 
> always be a corresponding control option in the (prefix) policy table, 
> plus a way to effectively transport that policy table in e.g. 
> draft-ietf-6man-addr-select-opt-03.
>
> Align and package all 3 together, and you have a far better solution.
>
> regards,
> RayH
>
>
>
> ------------------------------------------------------------------------