Subject: default-iids & DHCPv6 (Take #2)

From: Fernando Gont <[email-masked]>
Date: Sat, 14 Feb 2015 07:00:58 -0300

Folks,

Based on the comments received on the thread
"draft-ietf-6man-default-iids & DHCPv6", it would seem that there is not
consensus to recommend draft-ietf-dhc-stable-privacy-addresses as the
default algorithm for generating DHCPv6 IIDs. However, there seems to be
interest in recommending that the leased DHCPv6 addresses should not be
predictable.

How about adding something along the lines of:

"By default, DHCPv6 server implementations SHOULD NOT generate
predictable IPv6 addresses (such as IPv6 addresses where the IIDs are
consecutive small numbers). [draft-ietf-dhc-stable-privacy-addresses]
specifies one possible algorithm that could be employed to comply with
this requirement"
?

(where [draft-ietf-dhc-stable-privacy-addresses] would be an
Informational reference, I guess)

Thoughts?

If you'd like to propose changes to the above text, or think that I've
misread the opinion from the wg, please let us know/speak up.

Thanks!

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 15 Feb 2015 08:11:14 +1300

> Informational reference, I guess)

Seems reasonable to me.

   Brian

---

From: Peter Dordal <[email-masked]>
Date: Sat, 14 Feb 2015 21:20:08 -0600

On 02/14/2015 04:00 AM, Fernando Gont wrote:
> default algorithm for generating DHCPv6 IIDs. 
There is lack of consensus on whether the RFC 7217 formula

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

is sufficiently different from the DHCPv6 draft formula:

    F(Prefix2, Client_DUID, IAID, DAD_Counter, secret_key2)

I think this issue is fixable.

> However, there seems to be
> predictable IPv6 addresses 
This is not nearly strong enough; it is arguably consistent with generating
addresses within a small range (eg /112 versus /64). The /112 range means
there are 2^16 possible addresses, small enough to permit probing.

What one wants is more like the following:

   By default, DHCPv6 server implementations should generate addresses
   that appear to outsiders be uniformly randomly distributed across
   the entire /64 range. (outsiders = those without the secret_key)

But it's better to propose a specific algorithm.

While some site administrators may intentionally choose not to use randomly
distributed addresses, if this is not the default then scanning attacks
will be much harder to prevent. Lots of smaller sites have very little
control over their DHCP implementation, especially if it comes with the
hardware.

Peter Dordal
Loyola University Chicago CS Dept

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 15 Feb 2015 22:16:14 -0800

> specifies one possible algorithm that could be employed to comply with

The first part of this text is fine, but I don't think we should cite
draft-ietf-dhc-stable-privacy-addresses unless we also state that another
possible solution is to make the IID completely random.

---

From: Antonio Querubin <[email-masked]>
Date: Sun, 15 Feb 2015 23:55:21 -1000 (HST)

> I think this issue is fixable.

How about just updating RFC 7217 to generalize the algorithm allowing for 
different parameters depending on whether we're talking SLAAC or DHCPv6? 
I don't see a need for specifying yet another standards document which 
provides similar functionality when the algorithms potentially could be 
identical but using different inputs.

> But it's better to propose a specific algorithm.

And one standards document instead of two.

Antonio Querubin
e-mail:  [email-masked]
xmpp:  [email-masked]

---

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

> possible solution is to make the IID completely random.

I hate to be picky*, but "completely random" is a meaningless phrase.
You have to cite something, such as RFC 4086 (BCP 106), or else use
a meaningful phrase like "a pseudo-random value chosen from a discrete
uniform distribution".

   Brian

* Well, sometimes it's fun to be picky.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Feb 2015 10:21:35 +0900

> a meaningful phrase like "a pseudo-random value chosen from a discrete

Either text is fine by me. There are also reserved IID values that need to
be excluded, right?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Feb 2015 16:53:25 +1300

> Either text is fine by me. There are also reserved IID values that need to

Right, also see http://tools.ietf.org/html/rfc7136#section-7

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Feb 2015 22:52:27 -0300

On 02/16/2015 03:16 AM, Lorenzo Colitti wrote:
> On Sat, Feb 14, 2015 at 2:00 AM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> draft-ietf-dhc-stable-privacy-addresses unless we also state that
> another possible solution is to make the IID completely random.

The proposed text says "one possible solution" --- not "the only
solution or the like". If one mentions the "random" approach, then one
should probably also note that special addresses need to be avoided. --
That said, strictly speaking draft-ietf-dhc-stable-privacy-addresses
randomizes the IID.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Feb 2015 22:49:00 -0300

Peter,

>     F(Prefix2, Client_DUID, IAID, DAD_Counter, secret_key2)

It doesn't need to be different. F() is required to be a
cryptographically-secure function. And, as noted, each function takes
different parameters, so the output is different.

That say, I'll swap DAD_Counter and secret_key, just so that everyone is
happy. -- But such change is not really necessary.

>    the entire /64 range. (outsiders = those without the secret_key)

We shouldn't mention an address range, since DHCPv6 is employed in
non-64 subnets, too. If anything, we could mention range (see Brian's
suggestion) without mentioning any subnet size.

> But it's better to propose a specific algorithm.

That was the intent, but it seems there wasn't consensus to do that.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Feb 2015 22:56:23 -0300

On 02/16/2015 06:55 AM, Antonio Querubin wrote:
> How about just updating RFC 7217 to generalize the algorithm allowing
> for different parameters depending on whether we're talking SLAAC or
> DHCPv6? I don't see a need for specifying yet another standards document
> which provides similar functionality when the algorithms potentially
> could be identical but using different inputs.

While the expression is the same, the context is different. In SLAAC the
IIDs are generated by the host, wheres in DHCPv6 they are generated by
the server. In DHCPv6 you need to take care of DECLINE messages, whereas
in SLAAC you obviously don't. And, at the end of the day, making a
document that is generic to accommodate both SLAAC and DHCPv6 would mean
that the document is harder to read for folks willing to implement one
algorithm or another (they need to start with the generic document, and
then map that to their specific case9).

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 18 Feb 2015 11:01:32 +0900

On Wed, Feb 18, 2015 at 10:52 AM, Fernando Gont > The first part of this
text is fine, but I don't think we should cite
> solution or the like".

I object to citing only one possible solution, when "assign randomly,
except for reserved IIDs" is another possible solution.

> If one mentions the "random" approach, then one should probably also note
> that special addresses need to be avoided.

Agreed.