Subject: draft-ietf-6man-default-iids & DHCPv6

From: Fernando Gont <[email-masked]>
Date: Sat, 07 Feb 2015 23:35:33 -0300

Folks,

Mark Smith noted that we should recommend
draft-ietf-dhc-stable-privacy-addresses (DHCPv6's version of RFC7217) as
the default algorithm for the selection of IPv6 addresses by DHCPv6
servers (i.e., essentially doing for DHCPv6 what we're doing for SLAAC).

A few folks have already expressed support for this idea (in the
default-iids thread), but we wanted to raise this issue in a separate
thread for folks to not miss the opportunity to express their view.

Thoughts?

Thanks!

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 08 Feb 2015 19:31:37 +0100

On 08/02/2015 03:35, Fernando Gont wrote:
> draft-ietf-dhc-stable-privacy-addresses (DHCPv6's version of RFC7217)
> as the default algorithm for the selection of IPv6 addresses by
> DHCPv6 servers (i.e., essentially doing for DHCPv6 what we're doing
> for SLAAC).
>
> default-iids thread), but we wanted to raise this issue in a
> separate thread for folks to not miss the opportunity to express
> their view.
>
> Thoughts?

Hello,

Thank you for asking.

I wonder how difficult an implementation of DHCPv6 which does stable
privacy addresses would be?  Because with DHCPv6 an admin would list
manually the addresses in a config file, like ::1, ::2, ... With this
recommendation the software would have to fill in these config files?

The 'stability' in DHCPv6 terms would mean the same IPv6 address is
allocated to a particular node whose source is a particular MAC address.
  This matching (MAC-to-IP) is predefined in a dhcp config file.

I don't understand how will this work altogether: how a file can the
same IP address for a particular MAC address if it were not for a human
to fill it in.

Or maybe there is already implementation of this that I have not seen.

Alex

> Best regards,

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com

---

From: 神明達哉 <[email-masked]>
Date: Mon, 9 Feb 2015 11:20:59 -0800

At Sat, 07 Feb 2015 23:35:33 -0300,

> servers (i.e., essentially doing for DHCPv6 what we're doing for SLAAC).

Not a strong opinion, but my gut feeling is that stability/privacy
issues in case of DHCPv6 are not as critical as that of SLAAC, so
specifying it as the "default" sounds like a bit too strong.  I'd
rather prefer it leaving to implementors and operators.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Feb 2015 16:31:28 -0300

Hi, Alex,

> recommendation the software would have to fill in these config files?

No. What we would say is that "By default,
draft-ietf-dhc-stable-privacy-addresses  should be employed". But in a
scenario in which you do what you describe above, you're overriding such
default... and that's perfectly fine.

>  This matching (MAC-to-IP) is predefined in a dhcp config file.

Not necessarily: that would depend on the Client DUID an IAID.

> same IP address for a particular MAC address if it were not for a human

Please take a look at draft-ietf-dhc-stable-privacy-addresses.

The resaon fir which a server would lease yu the same address is the
same reason for which with RFC7217 you get the same IPv6 address in the
same network, even if you have not stored in persistent storage what was
the address that you got in that network the last time you were there.

Put another way. you get the same address because when the result of the
hash function is recomputed, all of it's parameters are the same --
hence you get the same result.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Feb 2015 08:33:09 +1300

> rather prefer it leaving to implementors and operators.

"Privacy" is rather relative in the case that an IID is allocated
from above by a DHCPv6 server. In this case you have to assume that
(a) the administrator knows in advance or can discover easily which device
is using the IID and (b) the administrator probably knows the user of the
device, and can be forced legally to reveal their name. This isn't
affected by how "random" the IID value is.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Feb 2015 16:35:30 -0300

Hi, Tatuya,

Thanks so much for weighing in. Please find my comments in-line...

On 02/09/2015 04:20 PM, 神明達哉 wrote:
> issues in case of DHCPv6 are not as critical as that of SLAAC,

Any reasons why the issues are less critical in DHCPv6 than in SLAAC?

> so

The thing is that right now there's no default algorithm for generating
the addresses to be leased. I recall recommendations in favor of
unpredictable IIDs, but no proposed way to achieve so.

draft-ietf-dhc-stable-privacy-addresses does not only bring you
unpredictable IIDs, but also stability of them, which tends to be a
desired property in enterprise scenarios.

Thanks,

---

From: James Woodyatt <[email-masked]>
Date: Mon, 9 Feb 2015 13:29:28 -0800

Everyone—

I don't see why this recommendation is necessary. Could someone help me
understand?

I see no reason why hosts should want the DHCPv6 server to assign them an
address unless it's because network administration wants to prevent them
from using SLAAC to generate stable privacy addresses. It seems to me that
the whole point of using DHCPv6 to assign stable addresses is to put the
network in control of how host addresses are numbered and to permit the
network to withdraw addresses from hosts when their leases expire. How
that's to be done should be an independent policy decision for network
administrators, and I don't see why IETF should be telling them what is a
good default policy.

Wouldn't it make more sense for us to recommend not using DHCPv6 for
address assignment in cases where RFC 7217 would provided necessary
security guarantees?

On Sat, Feb 7, 2015 at 6:35 PM, Fernando Gont <[email-masked]> wrote:

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

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Feb 2015 18:35:31 -0300

Hi, James,

Thanks for weighing in! lease find my comments in-line....

On 02/09/2015 06:29 PM, James Woodyatt wrote:
> I see no reason why hosts should want the DHCPv6 server to assign them
> an address unless it's because network administration wants to prevent
> them from using SLAAC to generate stable privacy addresses.

Well, e.g. some enterprises prefer to employ DHCPv6 for reasons ranging
from "DCHPv6 is the closest to their well-known IPv4" to "having a
centralized log of the leased IPv6 addresses".

> It seems to
> me that the whole point of using DHCPv6 to assign stable addresses is to
> put the network in control of how host addresses are numbered and to
> permit the network to withdraw addresses from hosts when their leases
> expire. How that's to be done should be an independent policy decision
> for network administrators, and I don't see why IETF should be telling
> them what is a good default policy.

When you don't have good default policy, what you get is a sloppy one --
e.g., low-byte/predictable addresses of the form 2001:db8::1,
2001:db8::2, etc.

> address assignment in cases where RFC 7217 would provided necessary

For some reason that would smell like yet another religious war? :-)

Thanks!

Best regards,

---

From: James Woodyatt <[email-masked]>
Date: Mon, 9 Feb 2015 15:07:56 -0800

This only makes me more confused.

If enterprises want a centralized log of all the host stable addresses,
then shouldn't they allow the hosts to configure their addresses themselves
with RFC 7217 then log which hosts are using which addresses by notifying
the DHCP server when they request leases for the rest of the configuration
data the network provides?

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Feb 2015 20:28:13 -0300

Hi, James,

On 02/09/2015 08:07 PM, James Woodyatt wrote:
> then shouldn't they allow the hosts to configure their addresses
> themselves with RFC 7217 then log which hosts are using which addresses
> by notifying the DHCP server when they request leases for the rest of
> the configuration data the network provides?

Not sure what you mean by "when they request leases for the rest of the
configuration data the network provides"...

The "additional configuration" bit of DHCPv6 is stateless. Many
implementations probably don't even keep a log of *these* requests (they
do keep a log of address leases, though).

That said, I noted two possible reasons for which an enterprise might
want to do DHCPv6.

In any case, since wehen you're ding stateful DHCPv6 you need to
implement *some* algorithm for generating the addresses, it seems to me
like a good idea to provide advice on what a good default is.

draft-ietf-dhc-stable-privacy-addresess brings these befenits (all
inclusive) for leased addresses:

* Unpredictability
* Stability (per network)
* Resiliency

(the later due to the fact that if you employ the same secret on all
servers, you can deploy as many DHCPv6 servers as you want, and they
will lease the same addresses to the same nodes, without the need of
synchronizing their leases' databases).

Thanks,

---

From: James Woodyatt <[email-masked]>
Date: Mon, 9 Feb 2015 16:52:02 -0800

> configuration data the network provides"...

To answer your question above: I'm saying hosts should use RFC 7217 to
generate the addresses they send in IA Address Options encapsulated in the
IA_NA Option they send in DHCP requests. If servers don't really care which
addresses hosts are assigned as long as they acquire and hold valid leases
for them, then this should be sufficient. If servers do care which
addresses hosts are assigned, then whatever method they choose for
generating the addresses should suffice so long as it doesn't embed the
link-layer hardware identifier. Even a monotonically increasing IID will
do, and might be preferable for many (most?) deployments.

p.s. I confess: I also don't see any pressing need for
I-D.dhc-stable-privacy-addresses like there was for RFC 7217 because of the
link-layer hardware identifier embedding it was meant to address. It seems
odd to me that DHC adopted it. I wasn't following the deliberations in DHC,
so maybe it would help me understand if you could provide a summary?

---

From: James Woodyatt <[email-masked]>
Date: Mon, 9 Feb 2015 16:58:41 -0800

> synchronizing their leases' databases).

I don't see how that's true.

All the elements of the DHCPv6 server array can have the same secret, but
the Counter parameter is source material in generating the RID, and this
information must be stored in the lease data and synchronized across the
array.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Feb 2015 14:09:17 +1300

>> On 02/09/2015 08:07 PM, James Woodyatt wrote:

...
> Even a monotonically increasing IID will

That's debatable, because it makes scanning attacks potentially much more successful.
We gave the argument in http://tools.ietf.org/html/rfc7421#section-5
paragraph 2.

     Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Feb 2015 22:27:13 -0300

On 02/09/2015 09:58 PM, James Woodyatt wrote:
> On Mon, Feb 9, 2015 at 3:28 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> All the elements of the DHCPv6 server array can have the same secret,
> but the Counter parameter is source material in generating the RID, and
> this information must be stored in the lease data and synchronized
> across the array.

Clearly, the COunter is there more for completeness sake than anything
else -- and, for instance, it's optional.

We expect the probability of collisions of IIDs in a 2**64 address space
rather negligible.

Thanks,

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 10 Feb 2015 17:10:41 +0100

> like a good idea to provide advice on what a good default is.

YEs.

But random generators are as good as simple incrementors at offering 
privacy of the IID.

On another hand, to ease sysadmin work, one would first agree on syntax 
to define textual representation of range, not just textual 
representation of single IPv6 addresses or prefixes.  In config files, 
and web forms, some people specify range as prefix::aa ... prefix::fe 
whereas others just by saying "prefix".  The former is finer grain, and 
gives more flexibility to deployer: make addresses between aa and fe, 
and dont do DHCP for ff which is manually assigned.

Once range is agreed one could qualify new algorithms to generate within 
a particular range: incrementers, random generators, dictionary-based 
selections, any.

This would be useful, I think.

> synchronizing their leases' databases).

I think the privacy advantage offered by a generator may come from 
issuing anew in each subnet, but not necessarily from its randomness.

More privacy can also be obtained from:
- not mandating publicly-documented behaviour about IID generation
- mandating the 64bit limit flexible such that attackers are less sure a
   64bit IID is always there to be tracked. (IPv4 offers more privacy in
   this respect, since IPv4 "IIDs" are variable length).

BEcause, here follows my rant:

RFC7217 says:
>    1.  Compute a random (but stable) identifier with the expression:
>
>        RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)

Is this generator run on same machine moving along same sequenc of 
bootup and networks to connect to 8am-9am every day generating the same 
sequence of RIDs?  I personally think yes, especially when the document 
suggests F to be a hash.  Same hash of same key produces same output.

If so, then once we know the algorithm it's sufficient to look at 
captured data and say that same person was there 8am-9am every day.

Unless, of course, the user manually changes the secret_key every 
morning, making sure s/he has not put an old key - this is in itself a 
difficult problem.

Alex

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Feb 2015 13:58:24 -0300

Hi, Alex,

> But random generators are as good as simple incrementors at offering

We're not just talking about privacy, but also e.g. resistance to
scanning attacks. Please see:
<https://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy>

> and dont do DHCP for ff which is manually assigned.

Makes sense. I bet this can be incorporated in
draft-ietf-dhc-stable-privacy-addresses with a small modification.

> issuing anew in each subnet, but not necessarily from its randomness.

Agreed. BUt privacy is just one problem we're tackling. See the
address-generation-privacy I-D.

> - not mandating publicly-documented behaviour about IID generation

I strongly disagree with that. If the strength of an algorithm is that
you don't know it... it's probably not that good. Besides, at the end of
the day, an open source implementation is some sort of documentation.

>   this respect, since IPv4 "IIDs" are variable length).

Well, this one is discussed in the why 64 I-D (now RFCxxxx).

> captured data and say that same person was there 8am-9am every day.

As noted in RFC7217 itself, RFC7217 is not a replacement for privacy
addresses.

Thanks,

---

From: James Woodyatt <[email-masked]>
Date: Tue, 10 Feb 2015 11:16:41 -0800

Do people who use DHCPv6 for address assignment consider resistance to
scanning a feature or a bug? If you consider it a bug, then you will need
to use DHCPv6 to solve it.

I guess I could see adding something to this draft spelling out the problem
that "some DHCP clients may not be using RFC 7217 to generate IA Address
Options for the IA_NA requests, and network administrators should therefore
use DHCP servers that implement I-D.ietf-dhc-stable-privacy-addresses if
resistance to address scanning is important."

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Feb 2015 19:05:09 -0300

Hi, James,

On 02/10/2015 04:16 PM, James Woodyatt wrote:
> scanning a feature or a bug? If you consider it a bug, then you will
> need to use DHCPv6 to solve it.

A few things:

1) I've never met anyone who has considered being resistance to scanning
attacks to be a bug.

2) Some DHCPv6 server software already default to random IIDs.
Unfortunately, addresses may be unstable within the same network.

3) We'd be specifying a default algorithm. An adinistrator that wants a
different thing may override such default.

> I guess I could see adding something to this draft spelling out the
> problem that "some DHCP clients may not be using RFC 7217 to generate IA
> Address Options for the IA_NA requests, and network administrators
> should therefore use DHCP servers that implement
> I-D.ietf-dhc-stable-privacy-addresses if resistance to address scanning
> is important."

Why would clients use RFC7217 to generate IA address Options? I mean, we
currently have no requirement for that to happen. *And*, it is
impossible to tell whether the client used R217 for that or not.

Thanks,

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 10 Feb 2015 23:36:30 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont

> 1) I've never met anyone who has considered being resistance to scanning

Maybe not scanning "attacks," but scanning. Yes, that could be considered a bug. If you are running a control system network with no DNS service, then you want to assign well known IP addresses to the control system hosts. And you want to allow for performance monitoring and fault localization service too.

Security, in this case, has to be far more robust than just making IP addresses hard to guess. The IP addresses can be assigned statically, or with DHCP-cum-client identifier option, and making them hard to figure out is a bug.

> different thing may override such default.

Fair enough.

Bert

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Feb 2015 16:23:06 -0800

> different thing may override such default.

The RFC 7217 algorithm seems like a very poor choice for a default DHCPv6
algorithm, because it prevents simultaneous use of DHCPv6 and SLAAC.

---

From: James Woodyatt <[email-masked]>
Date: Tue, 10 Feb 2015 17:49:04 -0800

I-D.ietf-dhc-stable-privacy-addresses specifies a different algorithm than
RFC 7217, even assuming they use the same hashing function and secret key.
It should be possible to use both simultaneously, in the case where you
want an array of multiple stable addresses to go along with your temporary
addresses. Which it would not be surprising to me if somebody somewhere
feels compelled to do.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Feb 2015 00:54:02 -0300

On 02/10/2015 09:23 PM, Lorenzo Colitti wrote:
> On Tue, Feb 10, 2015 at 2:05 PM, Fernando Gont <[email-masked]
> The RFC 7217 algorithm seems like a very poor choice for a default
> DHCPv6 algorithm, because it prevents simultaneous use of DHCPv6 and SLAAC.

Not sure what you mean. First of all, RFC7217 is meant just for SLAAC.
It is draft-ietf-dhc-stable-privacy-addresses the one meant for DHCPv6.

And in any case I don't see how RFC7217 or
draft-ietf-dhc-stable-privacy-addresses prevent the simultaneous use of
DHCPv6 and SLAAC.

Could you please elaborate a bit?

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Feb 2015 21:15:45 -0800

> It is draft-ietf-dhc-stable-privacy-addresses the one meant for DHCPv6.

The concern was that the two algorithms might produce the same result and
thus cause DHCPv6 address to collide with the SLAAC address.

For example, the following reasonable choices will cause collisions 100% of
the time:

- Client and server use same function and secret key. For example, they
pick SHA-1 because it's recommended by both documents and same secret key
because they are managed by the same organization.
- Client picks its MAC address as both the RFC 7217 Net_iface value (RFC
7217 option A.3) and its DHCPv6 DUID (RFC 3315 §9.4 option 3)
- Client chooses the same value for the Network_ID and the IAID

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 11 Feb 2015 05:57:44 +0000 (UTC)

So the points of view I'm starting from are:

(1) IIDs with good opaqueness/privacy by default are about protecting against external address scanning attacks and external threats to privacy (as per the view described in RFC7258/BCP188, "Pervasive Monitoring Is an Attack')

(2) IIDs should have good opaqueness/privacy properties by default, regardless of the method of how they're configured on a host (e.g., via SLAAC and/or DHCPv6 (and OpenWRT is currently providing/assigning via both methods by default)).

What is good for IIDs configured via SLAAC is also good for IIDs configured via DHCPv6, because an external threat won't know and won't care what address configuration method was used. (Currently, networks using DHCPv6 stateful addressing may be a better target for these attackers, because DHCPv6 servers may not be assigning addresses with the same sparseness etc. that SLAAC assigned addresses currently have).

Advising on good IID choice (and describing/referencing the risks of not choosing good IIDs) if manual/static configuration is chosen instead of SLAAC and/or DHCPv6 is consistent with (1) above.

(3) I'd say that most network operators, even if they want to use DHCPv6 for address assignment, would still desire the dynamic addresses given out by the DHCPv6 server (i.e., addresses that aren't mapped to a operator specified corresponding DUID) to be used with good privacy properties if those IIDs are exposed to parties outside of their network (and I think that would be most cases, except when an network is using application layer proxies for all external Internet access. Even IPv6 "NAT" a.k.a. NPT exposes IIDs on a one-to-one basis externally.)

Regards,
Mark.

________________________________
From: James Woodyatt <[email-masked]>
To: Fernando Gont <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Tuesday, 10 February 2015, 11:52
Subject: Re: draft-ietf-6man-default-iids & DHCPv6

>configuration data the network provides"...

To answer your question above: I'm saying hosts should use RFC 7217 to generate the addresses they send in IA Address Options encapsulated in the IA_NA Option they send in DHCP requests. If servers don't really care which addresses hosts are assigned as long as they acquire and hold valid leases for them, then this should be sufficient. If servers do care which addresses hosts are assigned, then whatever method they choose for generating the addresses should suffice so long as it doesn't embed the link-layer hardware identifier. Even a monotonically increasing IID will do, and might be preferable for many (most?) deployments.

p.s. I confess: I also don't see any pressing need for I-D.dhc-stable-privacy-addresses like there was for RFC 7217 because of the link-layer hardware identifier embedding it was meant to address. It seems odd to me that DHC adopted it. I wasn't following the deliberations in DHC, so maybe it would help me understand if you could provide a summary?

--

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 11 Feb 2015 06:20:18 +0000 (UTC)

----- Original Message -----
From: Brian E Carpenter <[email-masked]>
To: James Woodyatt <[email-masked]>; Fernando Gont <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Tuesday, 10 February 2015, 12:09
Subject: Re: draft-ietf-6man-default-iids & DHCPv6

...

* As a datapoint, the OpenWRT 14.07 stateful DHCPv6 server (enabled by default in addition to SLAAC assignment) has handed out addresses to my three Fedora 21 hosts that also enable both stateful DHCPv6 and SLAAC by default, addresses that are all within the lower 3400 addresses of the /64 on the Wifi subnet. As that /64 happens to be the first in my /56, not very hard to find.

     Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Feb 2015 03:37:58 -0300

Hi, Lorenzo,

On 02/11/2015 02:15 AM, Lorenzo Colitti wrote:
> On Tue, Feb 10, 2015 at 7:54 PM, Fernando Gont <[email-masked]
> The concern was that the two algorithms might produce the same result
> and thus cause DHCPv6 address to collide with the SLAAC address.

They will not.... for multiple reasons. Firstly, the expressions and
parameters employed for each algorithm are different. RFC7217 employs:

F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)

while draft-ietf-dhc-stable-privacy-addresses employs:

RID = F(Prefix | Client_DUID | IAID | Counter | secret_key)

Secondly, the secret key employed for each expression is going to be
different: the idea is that fo RFC7217, the secret key is a random
number selected at installation time. Whereas in the case of
draft-ietf-dhc-stable-privacy-addresses, it is manually selected by the
network admin (when he configures the rest of the parameters for the
DHCPv6 server).

> For example, the following reasonable choices will cause collisions 100%
> of the time:
> 
> pick SHA-1 because it's recommended by both documents and same secret
> key because they are managed by the same organization.

Since the secret for each client will be selected at installation time,
that's extremely unlikely. For instance, that would imply that all
clients in the same network employ the same secret -- something that
would be an extremely bad idea, since that would mean that any of such
systems could track any of the other systems across networks.

> - Client chooses the same value for the Network_ID and the IAID

The DUID Based on Link-layer Address contains a DUID type 3, and a two
octet network hardware type code which would not be present in the
RFC7217 case.

Besides, the IAID is composed of 4 octets. While you could certainly
have e.g. an SSID of such length, having the SSID be the same as the
IAID is extremely unlikely.

I think the above guarantees that it is extremely unlikely for the SLAAC
addresses to collide with the DHCPv6 addresses. That said, if that was a
concern (which I hope that it s not now), this could be fixed by
changing the order of the arguments of F() in
draft-ietf-dhc-stable-privacy-addresses.

Thanks,

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 11 Feb 2015 06:53:08 +0000 (UTC)

________________________________
From: Lorenzo Colitti <[email-masked]>
To: Fernando Gont <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Wednesday, 11 February 2015, 16:15
Subject: Re: draft-ietf-6man-default-iids & DHCPv6

>It is draft-ietf-dhc-stable-privacy-addresses the one meant for DHCPv6.

The concern was that the two algorithms might produce the same result and thus cause DHCPv6 address to collide with the SLAAC address.

For example, the following reasonable choices will cause collisions 100% of the time:

- Client and server use same function and secret key. For example, they pick SHA-1 because it's recommended by both documents and same secret key because they are managed by the same organization.
- Client picks its MAC address as both the RFC 7217 Net_iface value (RFC 7217 option A.3) and its DHCPv6 DUID (RFC 3315 §9.4 option 3)
- Client chooses the same value for the Network_ID and the IAID

* In that case, DAD would pick up the duplicate, and the loser would try again (SLAAC host: bump the DAD_Counter and then do RFC7217 again; DHCPv6 host: issue a Decline, and the DHCPv6 server can perform draft-ietf-dhc-stable-privacy-addresses again with the Counter variable incremented.)

(As a minor note, DHCPv6 makes duplicate address detection the client's responsibility rather than the servers, as was the common if not universal case with IPv4.)

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Feb 2015 23:02:31 -0800

> systems could track any of the other systems across networks.

But enterprise network administrators love tracking. They cite again and
again the requirement to track equipment that they see as enterprise
property. In fact, tracking is the most-frequently cited reason to use
DHCPv6 instead of SLAAC. Those enterprise network administrators might well
ask their vendors to implement the RFC 7127 text that says "An
implementation MAY provide the means for the system administrator to
display and change the secret key." and decide to use it.

> octet network hardware type code which would not be present in the

If the client chose to omit it and did not instead choose to use the same
8-byte value for both because "the code already supports it".

> IAID is extremely unlikely.

The Network_id is not an SSID. It is "network-specific data that identifies
the subnet to which this interface is attached". The client would be
entirely within its rights to use a sequential 32-bit number for the
Network_id, and then to use that number in the DUID as well "because the
code already supports it".

> draft-ietf-dhc-stable-privacy-addresses.

I think my point is that you need to cover the risks of collision in this
document. I gave you an example where there is a 100% risk, and you say
it's unlikely. Fine. What's the probability in the general case?

In general I think specifying the implementation details of how DHCPv6
assigns addresses is a bad idea. It's overspecified, it's not necessarily
for interoperability, and it encourages an algorithm monoculture which is
bad for security.

If what you want is for DHCPv6 addresses to provide privacy, then say they
should be random, period. Unlike SLAAC, it's not like they need to be
predictable; you can just remember them forever. After all, DHCPv6 is all
about logging.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Feb 2015 23:22:54 -0800

On Tue, Feb 10, 2015 at 10:53 PM, Mark ZZZ Smith <[email-masked]>
wrote:

> * In that case, DAD would pick up the duplicate, and the loser would try
> again (SLAAC host: bump the DAD_Counter and then do RFC7217 again; DHCPv6
> host: issue a Decline, and the DHCPv6 server can perform
> draft-ietf-dhc-stable-privacy-addresses again with the Counter variable
> incremented.)
>

The draft should say what happens in this case, then.

BTW: do you see any benefit of doing it this way rather than simply making
the IID be random?

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 11 Feb 2015 07:23:34 +0000 (UTC)

OFFLIST

----- Original Message -----
From: Fernando Gont <[email-masked]>
To: Lorenzo Colitti <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Wednesday, 11 February 2015, 17:37
Subject: Re: draft-ietf-6man-default-iids & DHCPv6

Hi, Lorenzo,

>     > The RFC 7217 algorithm seems like a very poor choice for a default

<snip>

* Hmm, this is an interesting point.

On the one hand, if there is only one DHCPv6 server on the link, then generating a secret key automatically would be better (so that e.g., the OpenWRT enabling DHCPv6 server by default scenario would work without operator intervention.)

On the other hand, if there are two or more DHCPv6 servers on the link, then using the same secret key is probably better, and to my mind, if you have two or more DHCPv6 servers on a link then you'd probably want their operation to be tightly coupled/co-ordinated/synchronised. That being said, I wonder how much of a requirement it is that they are tightly coupled/co-ordinated/synchronised, when the DHCPv6 clients will perform DAD on addresses the DHCPv6 server gives them.

Perhaps it would be ok to have them operate independently, allowing them to each choose their own secret key automatically (which is also likely to be a much better secret key than a human chosen one too!), and if an operator wants to couple/co-ordinate/synchronise their operation, then they copy the auto-generated secret key from one of the servers to the others.

While I'm still not completely sure of why somebody would want DHCPv6 other than familiarity (because DHCPv6 doesn't provide an audit log of all addresses in use), it seems that the combination of RA PIOs supplying the link prefixes so the DHCPv6 server can learn them, draft-ietf-dhc-stable-privacy-addresses-00 and the automatic generation of a secret key would allow a DHCPv6 server to bootstrap and provide addresses automatically, without operator intervention.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 11 Feb 2015 07:41:55 +0000 (UTC)

<<snip>
 After all, DHCPv6 is all about logging.
* We should really do something about this dangerous misconception.
Any attacker of any reasonable capability is going to have root on their host, ignore the DHCPv6 server and use a static address, from a prefix supplied either via RA PIOs, or determined by sniffing DAD, MLD or ND NS messages. They won't appear in the DHCPv6 server address binding database. They'll probably disable DAD too for their static address because they've got 2^64 choices and a low likelihood of collision if they pick a good static IID.
The one thing they can't really disable is responding to ND NS messages (unless their attack traffic is unidirectional). So if you want to have a far better method of logging address use on a link, logging ND NAs are the far superior method than using a DHCPv6 server (and I'd argue if unidirectional attack traffic is still an unacceptable risk, then you really need to authenticate uses before they can even send any inter-host traffic on the network using e.g., 802.1x.)

I generally think a false sense of security is worse than no security at all, because at least when you have no security you know you don't have any. DHCPv6 addressing (as does DHCPv4 addressing) gives people a false sense of security about their ability to know what addresses are actually in use when.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Feb 2015 04:43:32 -0300

Hi, Lorenzo,

On 02/11/2015 04:02 AM, Lorenzo Colitti wrote:
> DHCPv6 instead of SLAAC.

One thing is stable addressing or the ability to do activity correlation
when it comes to log files. Another one is host-tracking. The former
correlates activities within the same network. The later correlates
activities *across networks*. stable-privacy is meant to allow the
former, but not the later.

And since it's the DHCPv6 server that computes the address to be leased,
unless the "evil organization" controls all DHCPv6 servers,
dhc-stable-privacy-addresses will not help them with host-tracking.

> Those enterprise network administrators might
> well ask their vendors to implement the RFC 7127 text that says "An

That would typically imply admin privileges. At which point they could
just trojanize the host, and game over.

> If the client chose to omit it and did not instead choose to use the
> same 8-byte value for both because "the code already supports it".

The client cannot choose that, since it is the server the one computing
the address. And we require the DUID in the expression. There is no way
you can just include the MAC addres.

> The Network_id is not an SSID. It is "network-specific data that
> identifies the subnet to which this interface is attached". The client
> would be entirely within its rights to use a sequential 32-bit number
> for the Network_id, and then to use that number in the DUID as well
> "because the code already supports it".

The Network_ID MAY be the SSID. I wonder what'd be the policy with which
a client could use incremental values as "Network_ID".

> I think my point is that you need to cover the risks of collision in
> this document. I gave you an example where there is a 100% risk, and you
> say it's unlikely. Fine. What's the probability in the general case?

As noted above, your example assumes that the DUID can simply include
the MAC address. But it can't.

> assigns addresses is a bad idea. It's overspecified, it's not
> necessarily for interoperability, and it encourages an algorithm
> monoculture which is bad for security.

When you ask an implementation to do something, and you do not provide
advice regarding some sane algorithm, that results in flawed
implementations. We've seen that with, at least: TCP ephemeral ports,
TCP ISNs, IPv4 frag IDs, IPv6 frag IDs, DNS TIDs, etc., etc.

IMO, what you say about algorithm monoculture is incorrect. Security
tends to improve as there are more eyes on an algorithm, as opposed to
each one doing their own thing without much review.

> If what you want is for DHCPv6 addresses to provide privacy, then say
> they should be random, period. Unlike SLAAC, it's not like they need to
> be predictable; you can just remember them forever. After all, DHCPv6 is
> all about logging.

draft-ietf-dhc-stable-privacy-addresses provide random addresses.
However, the benefit over plain random() is that for the most part, you
don't even need to log which node is using what. And each address is
stable -- ven if you use multiple DHCPv6 servers for resiliency.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Feb 2015 04:46:50 -0300

On 02/11/2015 04:22 AM, Lorenzo Colitti wrote:
> On Tue, Feb 10, 2015 at 10:53 PM, Mark ZZZ Smith
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     * In that case, DAD would pick up the duplicate, and the loser would
>     try again (SLAAC host: bump the DAD_Counter and then do RFC7217
>     again; DHCPv6 host: issue a Decline, and the DHCPv6 server can
>     perform draft-ietf-dhc-stable-privacy-addresses again with the
>     Counter variable incremented.)
> 

draft-ietf-dhc-stable-privacy-addresses needs to be updated to explan
the DECLINE thing.

> BTW: do you see any benefit of doing it this way rather than simply
> making the IID be random?

Yes: addresses are stable per network.

Thanks,

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 11 Feb 2015 08:14:35 +0000 (UTC)

From: Lorenzo Colitti <[email-masked]>
 To: Mark ZZZ Smith <[email-masked]> 
Cc: Fernando Gont <[email-masked]>; "[email-masked]" <[email-masked]> 
 Sent: Wednesday, 11 February 2015, 18:22
 Subject: Re: draft-ietf-6man-default-iids & DHCPv6

On Tue, Feb 10, 2015 at 10:53 PM, Mark ZZZ Smith <[email-masked]> wrote:

The draft should say what happens in this case, then.
* I don't think it needs to be specified, although it should be briefly described/referenced (I think I already suggested that to Fernando a while ago for this draft), as existing RFCs already cover performing DAD on new addresses - RFC3315 does say SHOULD rather than must perform duplicate address detection on DHCPv6 assigned addresses, although it then refers to RFC2462, obsoleted by RFC4862 (SLAAC), which says,
"The Duplicate   Address Detection algorithm is performed on all addresses,   independently of whether they are obtained via stateless   autoconfiguration or DHCPv6."
There certainly are statements saying SLAAC and DHCPv6 can co-exist e.g., in RFC4862 (SLAAC).
"Both stateless address autoconfiguration and DHCPv6 may be used simultaneously."

BTW: do you see any benefit of doing it this way rather than simply making the IID be random?
* I suppose there isn't as much benefit as in the SLAAC case, although I think consistency with the SLAAC algorithm is of value, in particular if SLAAC and DHCPv6 addressing are both being used on the same link/within the same prefix.
As this algorithm generates stable IIDs dynamically, an advantage is that these dynamic DHCPv6 bindings wouldn't have to be stored to disk, which could be useful on lower end / storage constrained CPE. If there are no static DUID to address bindings, then there wouldn't be a need for any storage of a DHCPv6 binding database at all.
I think there is value in trying to make the outcomes of SLAAC and DHCPv6 operation as similar as possible, with the differences only occurring where SLAAC and DHCPv6 operation are different. In my experience, exceptions/differences are harder to remember, so it'd be easier to remember that this IID generation algorithm is used by default regardless of whether SLAAC and/or DHCPv6 are being used.

Regards,Mark.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 11 Feb 2015 08:15:35 +0000 (UTC)

Oh, well, on-list ;-) Nothing controversial, just a suggestion for the draft.

________________________________
From: Mark ZZZ Smith <[email-masked]>
To: Fernando Gont <[email-masked]>; Lorenzo Colitti <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Wednesday, 11 February 2015, 18:23
Subject: Re: draft-ietf-6man-default-iids & DHCPv6

OFFLIST

----- Original Message -----
From: Fernando Gont <[email-masked]>
To: Lorenzo Colitti <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Wednesday, 11 February 2015, 17:37
Subject: Re: draft-ietf-6man-default-iids & DHCPv6

Hi, Lorenzo,

<snip>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Feb 2015 06:42:41 -0300

Hi, Mark,

On 02/11/2015 05:15 AM, Mark ZZZ Smith wrote:
[....]
> draft-ietf-dhc-stable-privacy-addresses, it is manually selected by
> the network admin (when he configures the rest of the parameters for
> the DHCPv6 server).
> 
> 
> On the one hand, if there is only one DHCPv6 server on the link, then
> generating a secret key automatically would be better (so that e.g.,
> the OpenWRT enabling DHCPv6 server by default scenario would work
> without operator intervention.)

I guess one could argue that the secret key should be initialized to a
random string, and then note that when multiple DHCPv6 servers are
employed, an admin should override the default setting such that all
DHCPv6 servers employ the same secret key?

> On the other hand, if there are two or more DHCPv6 servers on the
> link, then using the same secret key is probably better, and to my
> mind, if you have two or more DHCPv6 servers on a link then you'd
> probably want their operation to be tightly
> coupled/co-ordinated/synchronised. That being said, I wonder how much
> of a requirement it is that they are tightly
> coupled/co-ordinated/synchronised, when the DHCPv6 clients will
> perform DAD on addresses the DHCPv6 server gives them.
> 
> Perhaps it would be ok to have them operate independently, allowing
> them to each choose their own secret key automatically (which is also
> likely to be a much better secret key than a human chosen one too!),
> and if an operator wants to couple/co-ordinate/synchronise their
> operation, then they copy the auto-generated secret key from one of
> the servers to the others.

Yes. I wrote the above before reading your comment. :-) -- Fully agree.

Thanks,

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Feb 2015 14:12:43 +0100

Le 10/02/2015 17:58, Fernando Gont a écrit :
>>> implement *some* algorithm for generating the addresses, it seems
>>> to me like a good idea to provide advice on what a good default
>>> is.
>>
>> YEs.
>>
>> But random generators are as good as simple incrementors at
>> offering privacy of the IID.
>

I looked at it.  There is a small nit: on pp3 "RFC2462" should be 2464
"IPv6-over-Ethernet", I think:
> Deriving the IID from a globally unique IEEE identifier [RFC2462]
> was one of the earliest mechanisms developed.

I have a general remark about the privacy.  One misses to mention how
address privacy is impossible in an open Internet, and how this open
Internet proved successful at other things like tracking badly-intended
actions.  We want this address to be visible, just like we want the
license plate be visible, our address visible on the postal box, and more.

With a visible address the 'privacy' is hardly possible; whatever the
new address generation mechanism there will always be a form of 
correlation, a dictionary attack.  Even the simple absence of traffic is 
a good indicator and a true privacy intruder.

Privacy tools are higher-level than at networking layer - IPsec.  And
even IPsec will not mangle an IP address in the src or dst field of a
packet.  Unless of course we want to tunnel - a supreme form of privacy.

When using Mobile IP one affords itself some privacy already.  Likewise
when using a VPN tunnel.  Is Mobile IP a privacy tool?

>> On another hand, to ease sysadmin work, one would first agree on
>> syntax to define textual representation of range, not just textual
>> representation of single IPv6 addresses or prefixes.  In config
>> files, and web forms, some people specify range as prefix::aa ...
>> prefix::fe whereas others just by saying "prefix".  The former is
>> finer grain, and gives more flexibility to deployer: make addresses
>> between aa and fe, and dont do DHCP for ff which is manually
>> assigned.
>

Ok, thanks.

>>> draft-ietf-dhc-stable-privacy-addresess brings these befenits
>>> (all inclusive) for leased addresses:
>>>
>>> * Unpredictability * Stability (per network) * Resiliency
>>>
>>> (the later due to the fact that if you employ the same secret on
>>> all servers, you can deploy as many DHCPv6 servers as you want,
>>> and they will lease the same addresses to the same nodes, without
>>> the need of synchronizing their leases' databases).
>>

I dont understand you.  I read the draft and it only talks privacy, or
privacy implications of correlating the time with address, privacy
implications of location tracking, privacy implications of address
scanning, vulnerability exploitation based on privacy violation
exhibiting manufacturer's name.

>> More privacy can also be obtained from: - not mandating
>> publicly-documented behaviour about IID generation
>
> I strongly disagree with that. If the strength of an algorithm is
> that you don't know it... it's probably not that good. Besides, at
> the end of the day, an open source implementation is some sort of
> documentation.

Well, as long as one specifies an algorithm publicly there is no means
to hide its weaknesses.

Also, as long as IP addresses are public and open in these packets there
is no means to block an attacker to look at them.

>> - mandating the 64bit limit flexible such that attackers are less
>> sure a 64bit IID is always there to be tracked. (IPv4 offers more
>> privacy in this respect, since IPv4 "IIDs" are variable length).
>

YEs, except that it does not recommend a flexible boundary.

If we had a flexible boundary then attacker would be less sure about
correlation, location tracking, OUI mfg name.  An attacker looking at a
packet would think impossible to be sure that that address is derived
from a MAC address.

Currently attacker is safe to assume the 64bit limit is there.

>> bootup and networks to connect to 8am-9am every day generating the
>> same sequence of RIDs?  I personally think yes, especially when the
>> document suggests F to be a hash.  Same hash of same key produces
>> same output.
>>

But it says 'privacy' all over?

Alex

---

From: 神明達哉 <[email-masked]>
Date: Wed, 11 Feb 2015 10:09:52 -0800

At Mon, 09 Feb 2015 16:35:30 -0300,

> Any reasons why the issues are less critical in DHCPv6 than in SLAAC?

In the case of SLAAC, the host can be tracked all over the world; it's
not the case for DHCPv6.

In the case of the initial solution to the privacy issue of SLAAC (i.e,
temporary addresses), the addresses are inevitably unstable since they
are given  pretty short lifetimes and will always change on
expiration.  This would normally not be the case for DHCPv6; as long
as the server that originally assigned the address keeps working, it's
quite likely that it allows to renew the same address.

*To me*, these points of SLAAC (and temporary address) can be
considered critical enough to justify changing the default.  And, *to
me*, not so in the case of DHCPv6.  I'd rather let the market decide
whether to implement/use the feature.

YMMV.  Hence "not a strong opinion".  If many others feel it's worth
the default, I wouldn't be opposed to it.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Thu, 12 Feb 2015 10:05:00 -0800

At Tue, 10 Feb 2015 08:33:09 +1300,

> affected by how "random" the IID value is.

Hmm, I'm not sure how I should interpret this as a response to my
message...do you mean you disagree with what I said?

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Thu, 12 Feb 2015 10:49:31 -0800

At Mon, 9 Feb 2015 16:52:02 -0800,

> so maybe it would help me understand if you could provide a summary?

You can find the adoption call discussion starting at:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg15879.html

I don't remember all the details of that discussion, but the reason
why I supported the adoption
(http://www.ietf.org/mail-archive/web/dhcwg/current/msg15881.html)
was because I can imagine *some people* may want to ensure that
a client is always assigned the same address for a particular link.
And the proposed approach seemed to be a reasonable algorithmic way to
achieve that, while addressing some paranoia's privacy concern on a
simpler approach like just embedding DUID in lower bits of the
address.

But, to me, it just looks a thing that may be nice for some people
to have.  And that's why I thought it's too much to make it the
default.

--
JINMEI, Tatuya

---

From: James Woodyatt <[email-masked]>
Date: Thu, 12 Feb 2015 11:47:31 -0800

It looks like 駄目 (unnecessary move) to me.  As I said, I can see how a pool
of DHCPv6 servers could use something like this to avoid having to
synchronize as much configuration state, but that doesn't strike me as a
pressing concern.  I don't see any other reason to put this stone on the
board.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Feb 2015 13:44:13 -0800

On Tue, Feb 10, 2015 at 11:41 PM, Mark ZZZ Smith <[email-masked]>
wrote:

> Any attacker of any reasonable capability is going to have root on their
> host, ignore the DHCPv6 server and use a static address, from a prefix
> supplied either via RA PIOs, or determined by sniffing DAD, MLD or ND NS
> messages. They won't appear in the DHCPv6 server address binding database.
> They'll probably disable DAD too for their static address because they've
> got 2^64 choices and a low likelihood of collision if they pick a good
> static IID.
>
> The one thing they can't really disable is responding to ND NS messages
> (unless their attack traffic is unidirectional). So if you want to have a
> far better method of logging address use on a link, logging ND NAs are the
> far superior method than using a DHCPv6 server (and I'd argue if
> unidirectional attack traffic is still an unacceptable risk, then you
> really need to authenticate uses before they can even send any inter-host
> traffic on the network using e.g., 802.1x.)
>
>
> I generally think a false sense of security is worse than no security at
> all, because at least when you have no security you know you don't have
> any. DHCPv6 addressing (as does DHCPv4 addressing) gives people a false
> sense of security about their ability to know what addresses are actually
> in use when.
>

Agree 100%. In fact, I'd be happy to work together on a document to clarify
that misconception.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Feb 2015 13:46:10 -0800

> Yes: addresses are stable per network.

So what? That's already a feature of DHCP. It's called the server lease
database.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Feb 2015 10:47:15 +1300

> message...do you mean you disagree with what I said?

Let me try to be precise. I think that rather than making a firm
recommendation, we should present it as a valid option for DHCPv6
deployments, with a short statement that it doesn't protect privacy
any better than any other DHCPv6 IID, but it does improve resistance
to scanning attacks (which site operators really do care about).

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Feb 2015 14:00:24 -0800

> just trojanize the host, and game over.

You're missing the point. Yes, these are the enterprise admins, and yes,
they have root. What I'm saying is that there *will* be admins that will
decide to use the same key on all hosts, and maybe even on the server.

> you can just include the MAC addres.

My point is that the client is free to use the DUID value as the Net_iface
value. There is an incentive to do so, so that it only needs to keep track
of one value.

> a client could use incremental values as "Network_ID".

My text should have said "IAID" instead of "DUID". Given the wording of RFC
7217, the policy is whatever the implementer feels like as long as the
Network_ID is unique per-network. Because the client chooses both the IAID
and the Network_ID, it can simply choose the same value for both.

> the MAC address. But it can't.

My point is that an implementation is free to use the same value for
Net_iface and DUID, and the same value for IAID and Network_ID, and in that
case you'll collide 100% of the time.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 12 Feb 2015 17:34:38 -0500

I believe that the SAVI working group products describe the problems, 
and suggest a way of addressing the problems.  (The DHCP document is the 
last one in the pipeline I believe.)

Yours,
Joel

On 2/12/15 4:44 PM, Lorenzo Colitti wrote:
> On Tue, Feb 10, 2015 at 11:41 PM, Mark ZZZ Smith
>     Any attacker of any reasonable capability is going to have root on
>     their host, ignore the DHCPv6 server and use a static address, from
>     a prefix supplied either via RA PIOs, or determined by sniffing DAD,
>     MLD or ND NS messages. They won't appear in the DHCPv6 server
>     address binding database. They'll probably disable DAD too for their
>     static address because they've got 2^64 choices and a low likelihood
>     of collision if they pick a good static IID.
>
>     The one thing they can't really disable is responding to ND NS
>     messages (unless their attack traffic is unidirectional). So if you
>     want to have a far better method of logging address use on a link,
>     logging ND NAs are the far superior method than using a DHCPv6
>     server (and I'd argue if unidirectional attack traffic is still an
>     unacceptable risk, then you really need to authenticate uses before
>     they can even send any inter-host traffic on the network using e.g.,
>     802.1x.)
>
>
>     I generally think a false sense of security is worse than no
>     security at all, because at least when you have no security you know
>     you don't have any. DHCPv6 addressing (as does DHCPv4 addressing)
>     gives people a false sense of security about their ability to know
>     what addresses are actually in use when.
>
>
> Agree 100%. In fact, I'd be happy to work together on a document to
> clarify that misconception.
>
>

---

From: 神明達哉 <[email-masked]>
Date: Fri, 13 Feb 2015 09:40:35 -0800

At Fri, 13 Feb 2015 10:47:15 +1300,

> to scanning attacks (which site operators really do care about).

Ah, so in the context of the original question of this thread, you
don't think we have to make dhc-stable-privacy-addresses the default
method (but it's worth mentioning its (possible) pros)?  Then I think
we're basically on the same page.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 13 Feb 2015 09:45:48 -0800

At Thu, 12 Feb 2015 11:47:31 -0800,

> pressing concern.  I don't see any other reason to put this stone on the

I guess we are (almost) on the same page.  Like you, ", but that
doesn't strike me as a pressing concern."  So I agreed that it's worth
discussing (adopting) at the dhc wg.  And, like you, "I don't see any
other reason to put this stone on the board."  So I thought making it
the default is too much.

Maybe the difference is that you also think it doesn't even make sense
to discuss/adopt it at the dhc-wg because of the latter.  I'm not
necessarily opposed to that - while I agreed (and still do agree) the
adoption, I was not really an enthusiastic supporter of it.  If the
wider consensus is rather to drop the idea altogether, I have no
problem with it.

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Feb 2015 10:08:34 -0800

I'm thinking of an operational document that would provide guidance to
network operators and designers. From the conversations I've been having
around DHCPv6, most operators appear to be of the firm belief that DHCPv6
is "required for legal tracking reasons".

On Thu, Feb 12, 2015 at 2:34 PM, Joel M. Halpern <[email-masked]>
wrote:

> I believe that the SAVI working group products describe the problems, and
> suggest a way of addressing the problems.  (The DHCP document is the last
> one in the pipeline I believe.)
>
> Yours,
> Joel
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Feb 2015 04:02:05 -0300

On 02/12/2015 07:00 PM, Lorenzo Colitti wrote:
> On Tue, Feb 10, 2015 at 11:43 PM, Fernando Gont <[email-masked]

If an admin configures a value named "SECRET key" in every single node
in the network, then... he gets what he deserves... what can I say?

But, as noted below, your example seems to be incorrect.

> My point is that the client is free to use the DUID value as the
> Net_iface value. There is an incentive to do so, so that it only needs
> to keep track of one value.

There is no incentive to use a parameter specified for DHCPv6 (the DUID)
in SLAAC. I disagree. For instance, the DUID identifies the node not the
interface. and the Net_Iface value in RFC7217 is meant to identify the
interface. That's like "mixing peas with bananas", as we say here...

> Net_iface and DUID, and the same value for IAID and Network_ID, and in
> that case you'll collide 100% of the time.

These are the two expressions:

F(Prefix1, Net_Iface, Network_ID, DAD_Counter, secret_key1)

RID = F(Prefix2 | Client_DUID | IAID | Counter | secret_key2)

Assuming:
 * Prefix1 == Prefix2
 * Net_Iface== IAID
 * DAD_Counter== Counter
 * secret_key1== secret_key2

... what's the strange reasonng with which Network_ID ends up with the
same value as the DUID?

FWIW, I fixed the equivalences from your proposal, since DUID identifies
the node, not the interface (even when it can be constructed from the
underlying MAC address). The obvious example that proves your example
(using to be wrong is that a node with two network inteerfaces wuld
(according to you) use the same DUID (unique per client) for two
different interfaces... which clearly shows that the DUID cannot
identify an interface.

All the above said, if you're really serious about this, I can swap the
order of, say, Counter and secret_key in the function specified in
draft-ietf-dhc-stable-privacy-addresses, and problem solved.

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Feb 2015 13:00:06 +1300

> we're basically on the same page.

Yes.

  Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Feb 2015 16:55:19 -0800

> in the network, then... he gets what he deserves... what can I say?

Same as if you configure the same SSL certificate and private key on every
server in your organization so you can serve the cert?

> ... what's the strange reasonng with which Network_ID ends up with the

The point is that the client can choose these values as it sees fit. A
client that was hardcoded to ever only support one interface (e.g., in an
embedded device) could well make this choice. In that case you'll get a
collision.

> draft-ietf-dhc-stable-privacy-addresses, and problem solved.

What I am serious about is that the draft needs to say something about the
fact that it uses an algorithm that is very similar to RFC 7217, and
explore the probability of collision both in the general case and in the
worst case.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Feb 2015 22:26:00 -0300

Lorenzo,

On 02/13/2015 09:55 PM, Lorenzo Colitti wrote:
> client that was hardcoded to ever only support one interface (e.g., in
> an embedded device) could well make this choice.

If the client uses a "client ID" as an "interface ID" it is not
following the specification. We meant what we said. "Interface ID" ==
something that identifies the interface != something that identifies the
client.

> What I am serious about is that the draft needs to say something about
> the fact that it uses an algorithm that is very similar to RFC 7217, and

So why don't we swap the two parameters in
draft-ietf-dhc-stable-privacy-addresses as I suggested, and then the
answer is simply a case of the birthday paradox?

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Feb 2015 17:34:18 -0800

> something that identifies the interface != something that identifies the

If a client is hardwired to support only one interface, it could use the
same value for both and it would be entirely compliant.

> answer is simply a case of the birthday paradox?

Can you prove that answer? It seems to me that the more similar the
algorithm's parameters are, the less entropy there is to use.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Feb 2015 23:28:24 -0300

Lorenzo,

On 02/13/2015 10:34 PM, Lorenzo Colitti wrote:
> On Fri, Feb 13, 2015 at 5:26 PM, Fernando Gont <[email-masked]

It's not compliant if we require an Interface ID, and it uses a client
ID. If I ask your given name and you respond with your surname ("because
there's only one 'Colitti' in the whole world"), you're answer might
"work" (for practical reasons), but it's still wrong -- because I asked
your name, not your surname.

> algorithm's parameters are, the less entropy there is to use.

The function F() is required to be cryptographically secure. If you
change the order in which you concatenate the parameters, the result is
totally different. Otherwise the function is not complying with the
stated requirement.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 16 Feb 2015 00:13:02 -0800

On Fri, Feb 13, 2015 at 6:28 PM, Fernando Gont <[email-masked]>
wrote:

> ID.

A device that has only one Ethernet interface and nothing else could decide
to choose a constant value for Network_ID because it "only supports one
network". I agree that would be a bad choice, but I don't think it's
clearly incorrect.