inline IMVHO [long answer]
Dave Thaler <mailto:dtha...@microsoft.com>
11 April 2012 21:17
-----Original Message-----
From: Ray Hunter [mailto:v6...@globis.net]
Sent: Wednesday, April 11, 2012 6:51 AM
To: Dave Thaler
Cc: Brian E Carpenter; ipv6@ietf.org
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:v6...@globis.net>
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
------------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
