Re: 3484bis and privacy addresses

[Ray Hunter <[e-mail]>]

Thanks for the reply.

I understand the rush, but I don't think the current document is ready 
for production yet, and would expect a need for RFC3484ter, which should 
obviously be avoided if possible.

I have already seen at least two customers who have experienced fairly 
major incidents and service outages due to the behaviour of end nodes 
and servers changing between OS versions. I use Windows as an example as 
you know the code, but it could have been any OS to be fair. Moving from 
Windows XP + Windows Server 2003 to Windows 7 + Windows Server 2008 and 
leaving default values in place can trigger massive changes in traffic 
flows literally within minutes via use of 6to4 tunnels (e.g. when the 
server end is upgraded to the new OS), and which directly breaks MPLS 
DSCP Quality of Service settings, or firewall throughput. I've seen 
customer's mission-critical platinum applications suddenly get dumped in 
the default queue as the routers no longer set the DSCP bits on network 
ingress and so the downstream routers cannot act on the DSCP bits of the 
traffic in the tunnel, even if they can look inside the tunnel. And I've 
seen firewalls and other devices choke as they have a different 
switching path for IPv6 traffic, or worse still, it hits a 100% block 
rule. These incidents are very difficult to track, as the servers may be 
managed by completely different groups to the network, and it would not 
be obvious to most change and problem managers that the changes and 
problems were directly related.

So I understand very well the urgency of lowering the preference of 6to4.

I would submit that lowering the preference of 6to4 could actually be 
implemented much quicker in production by 
progressingdraft-ietf-6man-addr-select-opt-03 and allowing end users to 
configure their own machines, rather than waiting for implementors to 
ship new code based on 3484bis. As an end user, I therefore think 
draft-ietf-6man-addr-select-opt-03 is actually more urgent than RFC3484bis.

But 6to4 is just the first example of where implementers will 
incorrectly second guess an end user's requirements. There'll certainly 
be more similar examples, including operational problems caused by use 
of temporary addresses.

Forgive me if I read your reply wrongly, but you seem to point the blame 
for there being an incomplete solution for remote management squarely at 
draft-ietf-6man-addr-select-opt-03.

Yet I could equally point out that RFC3484/RFC3484bis defines the prefix 
policy table, and all draft-ietf-6man-addr-select-opt-03 does is 
transport the contents of the prefix policy table via DHCPv6.


So what would I like to see happen?
===========================

What about defining a conceptual "address selection policy table" in 
RFC3484bis in addition to the "prefix policy table"?

It would contain a complete list of the conceptual knobs and switches 
that influence the behaviour of RFC3484bis end nodes, conceptual 
variable names, conceptual variable type, what behaviour the variable 
sets (cross referenced to the section), default settings (where these 
are already agreed in the WG) etc.

Then draft-ietf-6man-addr-select-opt-03 would simply define how to 
transport those options over DHCPv6, rather than having to define the 
options themselves.

Equally, if an implementor wanted to set these options via a config 
file, or AD group policy, or any other management process, they'd have a 
check list of things to do as well.

And if there are ever future extensions to RFC3484bis (e.g. a new rule 
to introduce dollar cost of network links or QoS factors into the 
address selection process), any new switches or new default behaviour 
could also be added to this conceptual "address selection policy table". 
If we'd already done this in RFC3484 it would have probably avoided a 
lot of pain with divergent implementations.

To be clear: I don't necessarily see the need to define new knobs or 
switches right now: just to clarify what existing knobs or switches will 
conceptually be called, what their conceptual types are (e.g. boolean), 
how/when they're set, what behaviour they influence, and their default 
behaviour (if agreed), plus a hint of how to add new knobs and switches 
in the future. This conceptual approach has been used very successfully 
in ND (RFC4861) and other standards, and I think it would address my 
current concerns of there being too much hard coding in address selection.

regards,
RayH
> Dave Thaler <mailto:[e-mail]>
> 13 April 2012 23:57
> Hi Ray,
>
> I appreciate the detailed response.  Thanks.
>
>> 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.
>
> Windows Server absolutely prefers temporary addresses to source sessions,
> whenever temporary addresses are enabled.   Generation of temporary addresses
> (which isn't related to RFC 3484) is not enabled by default, but the RFC 3484
> implementation in Windows Server definitely prefers temporary addresses
> over public addresses.
>
>> 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.
>
> Correct.   We don't have WG consensus on making such a distinction.
> And Windows doesn't either (it only makes a distinction on whether
> RFC 3041 is enabled or disabled, where it's enabled by default on client
> OSs and disabled by default on server OS's).
>
>> If an implementor follows the current text, this would change default
>> behaviour of some current implementations e.g. Windows Server.
>
> As the person responsible for that implementation, I can assure you
> that's not the case.
>
>> 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.
>
> You cannot do "anything you like".  You're limited to two behaviors:
> (a) Prefer public, and (b) Prefer temporary.  Both are legal and an implementation
> can do either one.  That was already the case with RFC 3484, nothing new
> here except which one is the MAY vs the SHOULD.
>
>> 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.
>
> Already true with RFC 3484.   Left up to the individual implementer.
>
> If you want to know, then you want to configure it to use (possibly non-default)
> values.
>
>> Does the new version exhibit the same default behaviour as the previous
>> version based on RFC3484? No idea.
>
> Already true with RFC 3484.   If you upgrade an OS, it may or may not
> choose a different set of RFC 3484-compliant options.
>
> If you want to know, then you want to configure it to use (possibly non-default)
> values.
>
>> Does the implementor have any idea what my or my employer's view is on
>> privacy addresses (either default ON or default OFF)? Nope.
>
> Actually the implementor often does due to proprietary mechaniams
> (like Group Policy or manual configuration or whatever else), but
> neither RFC 3484 nor 3484bis specifies configuration mechanisms,
> that's the job of companion docs like the DHCP option doc.   The core
> doc can't mandate a specific mechanism, but needs to work independent
> of what specific mechanism is being used to configure policy.
>
>> 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.
>
> Your points here are not about RFC 3484bis per se, they're about a configuration
> mechanism being standardized.   That's being done in parallel.
>
> [...]
>>> 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.
>> 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?
>
> Same reason for the other rules.
> a) there's only two options that are understood enough to reason about:
>      basically prefer privacy, and prefer stability.   Having a rule shows the
>      precedence order among such rules in terms of when the difference
>     matters.   And we have consensus on that.
> b) they're implemented and deployed already, so we want to minimize
>     changes from RFC 3484.
>
>> 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).
>
> The current text provides freedom to reverse the sense of the rule.
> The policy table isn't needed for that, the two are both configurable.
>
>> 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.
>
> Again your comments seem to be about failings with the current
> draft-ietf-6man-addr-select-opt document, not about RFC 3484bis.
> I would agree with you here that draft-ietf-6man-addr-select-opt is
> not ready for WGLC until it addresses more than just the prefix policy table.
> But that need not hold up RFC 3484bis itself, which just defines the knobs
> and leaves it for other docs to define a protocol to set the knobs via
> DHCPv6, SNMP, netconf, CLI, and/or whatever else.
>
>>>> Align and package all 3 together, and you have a far better solution.
>
> I disagree that we need to hold publication of RFC3484bis for any other
> protocol documents.   We need normative references in the reverse
> direction, not from RFC3484bis to any protocol document.
>
> The WG wants to get RFC3484bis out asap because it actually
> fixes problems that were in RFC 3484.
>
> -Dave
>
> Ray Hunter <mailto:[e-mail]>
> 13 April 2012 09:25
> 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
>>
>>
>>
>> ------------------------------------------------------------------------
>
> 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?
>
>> 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
>
>> 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
>
>
>
> ------------------------------------------------------------------------