Subject: 6MAN WG Last Call: <draft-ietf-6man-stable-privacy-addresses-12>

From: Ole Troan <[email-masked]>
Date: Mon, 19 Aug 2013 11:11:00 +0200

All,

This message starts the second two week 6MAN Working Group on advancing:

	Title           : A Method for Generating Semantically Opaque Interface Identifiers with
                           IPv6 Stateless Address Autoconfiguration (SLAAC)
	Author(s)    : F. Gont
	Filename    : draft-ietf-6man-stable-privacy-addresses-12
	Pages        : 25
	Date          : 2013-08-19

      http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-12

as a Proposed Standard.  Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors.  This last call will end on September 2, 2013.

The chairs would like to solicit one or two people in the working group to do a detailed review of the document. We would also encourage volunteers to act as document shepherds. Please contact the chairs directly.

Regards,

Bob Hinden & Ole Trøan

---

From: Erik Kline <[email-masked]>
Date: Mon, 19 Aug 2013 18:40:15 +0900

I pre-apologize, as always, for my ignorance, but...is there an
implementation of this?  Specifically, I'm mildly concerned about this
for link-local addresses.

Compliant implementations cannot even begin any IPv6 link-local
operations until the secret key has been loaded from stable storage.
They also should load the DAD_Counter from non-volatile memory before
starting link-local operations.  And they MUST NOT fallback to other
link-local autoconfig implementations (last paragraph of section 4).

I agree that this all seems fine in theory.  Are we collectively
convinced this will not lead to tragically (IPv6-)orphaned machines in
certain scenarios?

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Aug 2013 06:57:17 -0300

Erik,

> convinced this will not lead to tragically (IPv6-)orphaned machines in

Sorry, what are the scenarios you have in mind?

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 19 Aug 2013 04:19:46 -0700 (PDT)

Hi,

Going by the title, it seems my comment was missed about not implying that this address generation technique is limited to SLAAC slack scenarios, but could be useful with any address configuration method (i.e, SLAAC, DHCPv6, static, +future.) There seemed to be some support for decoupling the concepts of address generation from address configuration.

Here's my original email:

https://www.ietf.org/mail-archive/web/ipv6/current/msg18758.html

Regards,
Mark.

----- Original Message -----
> From: Ole Troan <[email-masked]>
> To: 6man WG <[email-masked]>
> Cc: "[email-masked] Chairs" <[email-masked]>
> Sent: Monday, 19 August 2013 7:11 PM
> Subject: 6MAN WG Last Call: <draft-ietf-6man-stable-privacy-addresses-12>
> 
> All,
> 
> as a Proposed Standard.  Substantive comments and statements of support for 
> advancing this document should be directed to the mailing list. Editorial 
> suggestions can be sent to the authors.  This last call will end on September 2, 
> 2013.
> 
> The chairs would like to solicit one or two people in the working group to do a 
> detailed review of the document. We would also encourage volunteers to act as 
> document shepherds. Please contact the chairs directly.
> 
> Regards,
> 
> Bob Hinden & Ole Trøan
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Erik Kline <[email-masked]>
Date: Tue, 20 Aug 2013 17:55:54 +0900

> Sorry, what are the scenarios you have in mind?

Well, I guess first I wasn't 100% sure I could think of all the
link-local uses and how they would interact with needing to load
parameters before starting essential functions for higher layer IPv6
and application things.  However, as I said I can't see a problem with
it in theory.  It's one more thing to wait for before waiting for DAD
to complete.  No theoretical change; fine.

But secondly, how would you implement this in, say, Linux?  Right now
link-local IPv6 things can begin as soon as the module is loaded or as
soon as an interface becomes active if it's already loaded.

To support this scheme as I understand it, the Linux kernel ipv6 code
would need to take some module parameters at boot or load time, so as
to force it to not do link-layer-derived link-local autoconfig but
instead load up the required parameters from non-volatile storage.  Is
my understanding correct?  If so, has anyone written this and gotten
feedback from net maintainers?

I guess I just think that all of the concerns about addresses raised
in draft-cooper-6man-ipv6-address-generation-privacy *don't*
meaningfully apply to link-local addresses.  That document's section
4.2.2 says that the addresses are basically available to an on-link
adversary anyway.  So I guess I don't see the point of "fixing"
something that I don't think is actually broken in this specific
context (speaking of link-local use case specifically).

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Aug 2013 21:01:44 -0300

Hi, Erik,

On 08/20/2013 05:55 AM, Erik Kline wrote:
> and application things. 

Well, at the point you're going to load v6, you certainly had plenty of
chances of loading any "parameters". For instance, you probably have a
kernel running, already (which requires many more parameters than just a
secret).

> However, as I said I can't see a problem with

Please see above. I'm not that savvy in Linux internals. I'd note,
though, that besides the above comment, BSD people didn't find any issues.

> my understanding correct?  

You need to have some secret available before you configure IPv6
addresses. Most likely, you'd get this secret from some config file --
but that's up to the implementation.

> If so, has anyone written this and gotten

Not written, yet. But there have been a number of develeopers that have
looked at this, and didn't find this "load a secret" thing a show-stopper.

> meaningfully apply to link-local addresses.

That's assuming such IPv6 addresses will not leak out -- which I think
you cannot guarantee. Stupid example (certainly not the best): your node
contacting an MTA with a link local address, which leaks in the mail
headers. (again, not the best example, but simply a proof of how
addresses can leak, no matter whether they are link-local).

> That document's section

Please see above. Moral of the story: be proactive. A bad idea is... a
bad idea. So if you don't find a scenario where a bad idea can be
harmful, that doesn't mean attacker won't find it, or that such scenario
doesn't exist.

Cheers,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Aug 2013 07:35:51 +0200 (CEST)

On Tue, 20 Aug 2013, Erik Kline wrote:

> would need to take some module parameters at boot or load time, so as to 
> force it to not do link-layer-derived link-local autoconfig but instead 
> load up the required parameters from non-volatile storage.  Is my 
> understanding correct?  If so, has anyone written this and gotten 

Actually this would be good if it was fixed because the way it was done 
caused other problems. It's really hard to make a linux (debian 6.0 for 
instance) come up and *not* do RS and then create EUI64 based addresses.

I have this in sysctl.conf:

net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.eth0.accept_ra=0
net.ipv6.conf.eth1.accept_ra=0
net.ipv6.conf.eth2.accept_ra=0
net.ipv6.conf.eth3.accept_ra=0
net.ipv6.conf.eth4.accept_ra=0

At least in debian 6.0 this didn't kick in until too late in the boot 
process, the kernel had already brought up the interfaces and done RS and 
created addresses and routing. It didn't listen to RAs after that, the 
manual static config kicked in, and I had to use "ip -6 address delete" to 
get rid of the EUI64 based addresses and privacy addresses.

Actually I upgraded to debian 7.0 the other week and I don't remember 
having to delete the EUI64 based addresses, so this might have been fixed, 
or I just forgot to check and they timed out after a while when the kernel 
ignored RAs after the above config kicked in.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 22 Aug 2013 04:39:38 -0700 (PDT)

----- Original Message -----
> From: Mikael Abrahamsson <[email-masked]>
> To: Erik Kline <[email-masked]>
> Cc: 6man WG <[email-masked]>
> Sent: Wednesday, 21 August 2013 3:35 PM
> Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-stable-privacy-addresses-12>
> 

RAs are necessary to indicate prefix on-link or off-link status, as per RFC5942. If you want to stop hosts using PIO announced prefixes to generate SLAAC addresses, you'd switch off the A bit in the PIO option.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 22 Aug 2013 18:58:49 -0300

On 08/19/2013 08:19 AM, Mark ZZZ Smith wrote:
> 
> Going by the title, it seems my comment was missed about not implying
> that this address generation technique is limited to SLAAC slack
> scenarios, but could be useful with any address configuration method
> (i.e, SLAAC, DHCPv6, static, +future.) There seemed to be some
> support for decoupling the concepts of address generation from
> address configuration.

How about something like:

"While the method specified in this document is meant to be used with
SLAAC, this doesn not preclude the same algorithm from being used with
other address configuration mechanisms, such as DHCPv6 or static address
confguration"

at the end of Section 1, right before the "terminology" paragraph?

Thanks!

Cheers,

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 22 Aug 2013 20:57:35 -0700 (PDT)

Hi Fernando,

----- Original Message -----
> From: Fernando Gont <[email-masked]>
> To: Mark ZZZ Smith <[email-masked]>
> Cc: Ole Troan <[email-masked]>; 6man WG <[email-masked]>; "[email-masked] Chairs" <[email-masked]>
> Sent: Friday, 23 August 2013 7:58 AM

Happy with that.

Regards,
Mark.

---

From: Tim Chown <[email-masked]>
Date: Fri, 23 Aug 2013 11:56:09 +0100

> at the end of Section 1, right before the "terminology" paragraph?

I think that fits well with the advice in 5177 and its replacement to not use sequential IPs from a DHCP pool.

The difference for DHCP is perhaps that there may be some reason the pool is not the whole /64, in which case it would still be prudent to randomise from within the pool.

I think Mark's point though is that an address may be used for the initiation of incoming and/or outgoing communications, and how the address is generated should not necessarily be tied to how it is used. I would certainly agree with that.

I'm not sure what you mean by static address configuration in this context.

Tim

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 23 Aug 2013 05:15:19 -0700 (PDT)

Hi Tim,

----- Original Message -----
> From: Tim Chown <[email-masked]>
> To: Fernando Gont <[email-masked]>
> Cc: Mark ZZZ Smith <[email-masked]>; "[email-masked] Chairs" <[email-masked]>; 6man WG <[email-masked]>
> Sent: Friday, 23 August 2013 8:56 PM
> The difference for DHCP is perhaps that there may be some reason the pool is not 
> the whole /64, in which case it would still be prudent to randomise from within 
> the pool.
> 
> I think Mark's point though is that an address may be used for the 
> initiation of incoming and/or outgoing communications, and how the address is 
> generated should not necessarily be tied to how it is used. I would certainly 
> agree with that.
> 

Not quite.

I'm more coming from the point of view that generally address generation methods are or should be separate from address configuration methods (although influenced by them if necessary or useful), and neither of the methods should influence address expiry - IPv6 preferred and valid lifetimes are for that.

The reason I've been thinking about this is the recent identified behaviour in Windows where when the M bit was switched off in an RA, the Windows machine would tear down stateful DHCPv6 and immediately expire the IPv6 addresses that were configured by it, even though the addresses themselves still had non-zero valid and preferred lifetimes. This behaviour would prevent a smooth transition on a link from SLAAC address configuration to stateful DHCPv6 and vice-versa.

So it has seemed to me there are really 3 separate addressing related functions:

- address generation methods (e.g., derived from IEEE address, the method described in this ID, or others)

- address configuration methods, that configure addresses and their preferred and valid lifetime values (currently SLAAC, stateful DHCPv6 or static)

- the address expiring/aging method, using the preferred and valid lifetimes, but should not influenced by the method used to configure them (if you want to force address expiry, use your chosen address configuration method to set the preferred and valid lifetimes to their expiry values and then let the addresses immediately age out)

By keeping the address expiring/aging method independent from the address configuration method, it would then be possible to fairly smoothly transition between different address configuration methods, rather than the current disruption that would be suffered with Windows (and perhaps other OSes) today.

The above text is motivated by the idea that the addresses generated by the method described in the draft should be possible to configure using SLAAC, stateful DHCPv6 or manual static configuration, or any other future address configuration methods. This draft is describing both an address generation method and how the generated addresses can be configured using SLAAC. The proposed text leaves room to describe how the address generation method could be used with stateful DHCPv6 or just applied with static configuration if the addresses are generated manually (using a script, spreadsheet etc.). Off-list I suggested rather than a future draft specifying how to use the provided address generation method with DHCPv6, have a future draft called something like "A Generalised Method for Generating Semantically Opaque IPv6 Interface Identifiers", which might discuss how they can be used with DHCPv6 as a configuration method, but hopefully general enough that if
 there are future address configuration methods, they don't need to specify how  Semantically Opaque IPv6 Interface Identifiers are configured with them.

> I'm not sure what you mean by static address configuration in this context.

Is it clearer now?

Regards,
Mark.