Dave Thaler <mailto:[email protected]>
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:[email protected]>
13 April 2012 09:25
inline IMVHO [long answer]
Dave Thaler <mailto:[email protected]>
11 April 2012 21:17
-----Original Message-----
From: Ray Hunter [mailto:[email protected]]
Sent: Wednesday, April 11, 2012 6:51 AM
To: Dave Thaler
Cc: Brian E Carpenter; [email protected]
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:[email protected]>
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:[email protected]>
11 April 2012 21:17
-----Original Message-----
From: Ray Hunter [mailto:[email protected]]
Sent: Wednesday, April 11, 2012 6:51 AM
To: Dave Thaler
Cc: Brian E Carpenter; [email protected]
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:[email protected]>
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
------------------------------------------------------------------------
