Subject: Re: draft-yhb-6man-ra-privacy-flag-01

From: RJ Atkinson <[email-masked]>
Date: Fri, 4 Mar 2011 12:41:44 -0500

Mikael Abrahamsson wrote:
% The proposed solution doesn't solve the problem described.

Hmm.

IPv6 addresses formed using any MAC address belonging to a given 
node (i.e. in modified EUI-64 form per the RFCs) does entirely 
meet the user audit needs for the users I am aware of (and 
previously summarised).  

One might or might not like the proposal, but the above quote 
from Mikael is NOT accurate, at least for the user deployment
audit needs that I am aware of.

Yours,

Ran

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Mar 2011 19:10:36 +0100 (CET)

On Fri, 4 Mar 2011, RJ Atkinson wrote:

> IPv6 addresses formed using any MAC address belonging to a given node 
> (i.e. in modified EUI-64 form per the RFCs) does entirely meet the user 
> audit needs for the users I am aware of (and previously summarised).

And how do you know the host didn't make up a new address because it 
needed to for some reason? It doesn't have to be privacy extension. SLAAC 
leaves it up to the host to do what it want, it can take any address not 
currently in use by someone else.

> audit needs that I am aware of.

SLAAC is by definion host-controlled. You use the term "audit" in a way I 
don't really understand (though I am not a native english speaker so I 
could very well be wrong).

If you want to be sure who did what when, you need centrally controlled 
IPv6 address hand-out (DHCPv6 is the only one I am aware of for IPv6) plus 
something that makes sure user can't source any other traffic, such as the 
SAVI-WG functionality IP/MAC address verification schemes.

Please do not put more functionality into RA than what is absolutely 
needed. If you need to know what host had what IP address at what time, 
disallow SLAAC and run DHCPv6.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 4 Mar 2011 13:55:48 -0500

On 04  Mar 2011, at 13:10 , Mikael Abrahamsson wrote:
> SLAAC is by definion host-controlled.  

Existing RA flags control whether SLAAC is allowed
or DHCP is required, so this proposal is not a significant 
architectural change either to IPv6 or to RA flag use.

Any proposal to the WG might or might not meet one's 
personal definition of "sufficient need to justify 
changing/adding specs" -- I gather you think it does not 
meet your definition of sufficient need (jhw and some others 
seem to have a similar view :-).

> You use the term "audit" in a way I don't really understand 

At least for these users, "audit" has a meaning quite similar
to the ordinary business usage (e.g. when a CPA or Chartered Accountant 
audits a public firm's financial records).  

In many countries, public firms aren't required to have 
flawless financial records, merely "good enough" (reportedly
this is often expressed as a sufficient "confidence interval").

> If you want to be sure who did what when, you need centrally
> controlled IPv6 address hand-out plus something that makes sure
> user can't source any other traffic, such as the SAVI-WG
> functionality IP/MAC address verification schemes.

My apologies if I was unclear.  
This is NOT access-control, but instead merely audit.  

As with audits of financial records, perfection is not required,
but a certain confidence interval IS desired/required/needed.

As near as I can  tell, different user organisations target 
different confidence intervals.  

If a significant number of systems use the "privacy-mode" addressing, 
that confidence interval is not achievable.  If a tiny number use 
that mode, a large deployment reportedly can meet the required 
confidence interval.

Again, this is audit, not access control, and absolute perfection
is not a requirement.

> If you need to know what host had what IP address at what time,

I'm told that some users already are using implementation-specific
configuration mechanisms (e.g. apparently a MS-Windows "Registry"
setting) that allow SLAAC, but disallow the privacy extension.

I'm further told that when configured to disable "privacy-mode",
such hosts then create the EUI-64 based on some MAC address 
in the host.  

I'm told that outcome is quite sufficient for audit purposes, 
but is expensive and tedious to deploy -- primarily because
the configuration is platform-dependent.

This proposal would provide an platform-independent way 
to configure that sort of knob, which knob apparently exists 
now within an interesting number of deployed end systems. 

I hope the situation is more clear now.  Thanks for your
follow-up questions and comments.

Cheers,

Ran

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Mar 2011 20:15:17 +0100 (CET)

On Fri, 4 Mar 2011, RJ Atkinson wrote:

> I hope the situation is more clear now.  Thanks for your follow-up 
> questions and comments.

Well, I still oppose it. Either we have SLAAC and then the host is allowed 
to choose any address it sees fit, or we don't.

If an organisation wants to disallow privacy extensions and still use 
SLAAC (and trust the host to just allocate one tracable IPv6 address and 
nothing else), then I hope they have sufficient control over the host and 
thus can afford to do the registry setting to disallow privacy extensions.

I would have more understanding of your case if the proposal was to 
implement a flag which said "only use a single EUI64 based IPv6-address 
and nothing else when doing SLAAC" which by definition would do what you 
want, but I still don't like this.

I'd much rather make sure vendors implement proper support for DHCPv6 
(stateless and stateful) than to fiddle with RAs where the router vendor 
also has to implement this functionality. Let's try to change RA as few 
times as possible, please. Let the routers do forwarding of 
policy-required queries and handle these in a server that is not on the 
local subnet.

---

From: Karl Auer <[email-masked]>
Date: Sat, 05 Mar 2011 09:49:47 +1100

On Fri, 2011-03-04 at 13:55 -0500, RJ Atkinson wrote:
> or DHCP is required

I don't think they do. They inform the host about whether SLAAC *should*
be done, or whether DHCP *could* be done, but do not *control* the host
in any way.

> that confidence interval is not achievable.

In my ignorance I may be being over-confident, but it seems to me that
some very basic NDP snooping in routers would enable logging of every
active address - when it became active and the last time it was seen,
along with layer-2 info for the address. Such features don't exist yet,
of course... er, do they?

> setting) that allow SLAAC, but disallow the privacy extension.

If that setting is on the host, it's toast in the hands of a Bad Guy.
But using your sense of "audit" I guess that's not too bad.

> now within an interesting number of deployed end systems. 

Again - a knob only useful for well-behaved systems hosts.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

---

From: james woodyatt <[email-masked]>
Date: Fri, 04 Mar 2011 15:03:09 -0800

> but a certain confidence interval IS desired/required/needed.

It seems to me that proper accounting of which hosts are using what IPv6 addresses is probably better achieved by enhancing routers with the capability to journal their neighbor discovery cache insertions to a secure repository for offline review.  That combined with authorization logs from EAPOL ought to provide sufficient confidence for most civilian audits.  Am I missing something?

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Cutler James R <[email-masked]>
Date: Fri, 4 Mar 2011 18:14:51 -0500

On Mar 4, 2011, at 6:03 PM, james woodyatt wrote:

> --james woodyatt <[email-masked]>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

Playing my favorite refrain regarding separation of functions and powers:

James, you are missing the need for routers to tend to the business of routing.  

Placing the configuration and accounting and audit mechanisms elsewhere greatly benefits network performance and separates router software and configuration from the non-trivial end system management functions.

If I were responsible for transporting IP packets, I would insist on distancing my self from attempts to complicate my life beyond trying to keep up with software updates from A, C, HP, J, HP and etc. while keeping the network running well.  Tuning BGP should be enough.  No mas!

James R. Cutler
[email-masked]

---

From: Mark Smith <[email-masked]>
Date: Mon, 7 Mar 2011 23:48:46 +1030

On Fri, 04 Mar 2011 15:03:09 -0800

> It seems to me that proper accounting of which hosts are using what IPv6 addresses is probably better achieved by enhancing routers with the capability to journal their neighbor discovery cache ins…

+1

I think a router (or some other appropriate device) could be enhanced to
specifically listen for DAD attempts, insert the preliminary info
sourced from the DAD attempt(s) into it's neighbor cache, and then let
NUD determine if the address passes DAD. Once that occurs, it could
generate e.g. an SNMP trap towards an auditing device. When NUD detects
that the device has disappeared, another SNMP trap would occur.

Influencing behaviour via e.g. forcing DHCPv6 or trying to switch
off privacy addresses is a reasonable method to try to use to address
this issue, but ultimately you're trusting the device to behave as
specified. You really also need to be trying to detect when devices
don't behave. Financial accounting and auditing follows this model -
defined accounting procedures, and audits to detect when they haven't
been complied with.

Regards,
Mark.

---

From: james woodyatt <[email-masked]>
Date: Mon, 07 Mar 2011 07:48:49 -0800

On Mar 7, 2011, at 6:08 AM, RJ Atkinson wrote:
> 
> Again, it is only audit, not full blown accounting or access control
> or what not.  Perfection is not a requirement here.
> 
> On Fri, 04 Mar 2011 15:03:09 -0800, james woodyatt <[email-masked]> wrote:
>> is probably better achieved by enhancing routers with the capability
>> to journal their neighbor discovery cache insertions to a secure
>> repository for offline review.  
> 
> That is tremendously complicated, and there is no requirement for
> a "secure" anything.  We're only talking about audit and confidence
> intervals, not malicious users or malicious hosts.

Then it's much simpler.  Just deploy the routers that have the capability I propose, but forget about SAVI and/or EAPOL and don't sweat the security of the journal logs so much.  There is no need to rev the specs to support the network audit you're talking about.  Just buy routers that support journaling.  Done.

Later, when the security of your audits are something you have to take more seriously, then you add the EAPOL and you secure the journal repository better.  It's incremental.  The "DisablePrivacy" flag adds nothing but additional complexity and transition friction.