Subject: [dhcwg] draft-ietf-dhc-stable-privacy-addresses: Question on address ranges

From: Fernando Gont <[email-masked]>
Date: Wed, 18 Feb 2015 08:02:46 -0300

Folks,

The current version of the I-D (-01, posted today), tries to implement
support for address ranges (as opposed to just prefixes) as follows:

       RID = F(IPV6_ADDR_HI | IPV6_ADDR_LOW | Client_DUID | IAID |
       Counter | secret_key)

       Where:

       RID:
          Random (but stable) Identifier

       IPV6_ADDR_HI:
          An IPv6 address specifying the upper boundary of the IPv6
          address pool from which the DHCPv6 server leases IPv6
          addresses.  It MUST be represented as a 128-bit unsigned
          integer in network byte order.

       IPV6_ADDR_LOW:
          An IPv6 address specifying the lower boundary of the IPv6
          address pool from which the DHCPv6 server leases IPv6
          addresses.  It MUST be represented as a 128-bit unsigned
          integer in network byte order.  If multiple servers operate on
          the same network to provide increased availability, all such
          DHCPv6 servers MUST be configured with the address range
          (i.e., the same IPV6_ADDR_HI and IPV6_ADDR_LOW parameters).
          It is the administrator's responsibility that the
          aforementioned requirement is met.
[....]

and then doing:

       IPV6_ADDRESS = IPV6_ADDR_LOW + RID % (IPV6_ADDR_HI -
       IPV6_ADDR_LOW + 1)

(where addresses are processed as 128-bit unsigned integers)

The potential "problem" with this approach is that in order to implement
this you need to do math with rather large numbers.

Maybe a simpler approach would be do do something along the lines of:

IPV6_ADDRESS[n]= IPV6_ADDR_LOW[n] + RID[n] % (IPV6_ADDR_H[n]-
                              IPV6_ADDR_LOW[n] +1)

Where we process IPv6 addresses as an array of 16-bit integers -- and
hence should apply this expression for n= 4..7.

While this doesn't look so nice, as the expression in the current
version of the I-D, the advantage is that we don't need to d math with
"large" numbers, and also that the algorithm can support address ranges
for this sort: 2001:db8::0-ffff:1:2:10-50  (where we have specified
"ranges" for two 16-bit words, and hence the address pool will result in
a noncontiguous set of addresses).

(If you like this latter approach, there are a few other nits to be
discussed... but let's settle on the high-order bit first :-) )

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: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 18 Feb 2015 14:47:37 +0000

Hi:

There are servers that use full prefixes (i.e., can assign any addresses in /64) - and I guess you'd say to use ADDR_HI of x:x:x:x:FFFF:FFFF:FFFF:FFFF and ADDR_LOW of x:x:x:x:0:0:0:0? In these cases, the extra math is not required. (The above works for other prefix lengths too - just take the "lower order" 128-length bits of the result).

And, for servers that have specific range (low to high), they will always have to do some "math". Also, I think it would be safe for most implementations to assume that doing this math with 64-bits is more than sufficient. Probably 32-bits is OK too, but that may not be as future proof :).

An interesting question then is whether to change from Prefix to IPV6_ADDR_HI and IPV6_ADDR_LOW in the first place? Why not just stick to using the prefix that is in the RA (I would expect servers to know that since the configuration is probably a prefix with range(s)). Then the "range" is only applied at the end.

Note also that:
- Ranges may not be contiguous. What if there are multiple ranges (i.e., 10 to 1000, 2000 to 3000)? This is why I think dropping the idea of start/end range makes the most sense - just use the prefix.
- Ranges like this also have the interesting property that it breaks the idea of "stable" addresses whenever a change to the range occurs - increasing or decreasing the range will break stability.

Also, shouldn't the IA option type be part of the expression? While today we have IA_NA and IA_TA and you probably don't want to do this for IA_TA, might not hurt to include this in case there are other types developed in the future? It probably isn't a big deal if we don't since that is less likely to be the case.

An interesting question that might be asked is whether this work even needs to be standardized. Also, what might happen with a DHCPv6 failover implementation (in this case, it could be that the resulting address that is generated by this is not available to that server (assigned to partner) and so counter would have to be incremented and regenerate an address ... which could happen multiple times).

If DHCPv6 is supposed to provide stable addresses, why not just have the server remember the addresses that it assigned to a specific client (or Client & IA)? Servers have to have state, so this is not that challenging. Sure, you have to limit the time (otherwise you could build up a large amount of state), but would you really want to have the same address after many months?

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: Wednesday, February 18, 2015 6:03 AM
To: [email-masked]
Subject: [dhcwg] draft-ietf-dhc-stable-privacy-addresses: Question on address ranges

Folks,

       Where:

       RID:

       IPV6_ADDR_HI:

       IPV6_ADDR_LOW:

and then doing:

Thoughts?

Thanks!

Best regards,

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Fernando Gont <[email-masked]>
Date: Wed, 18 Feb 2015 13:09:58 -0300

Hi, Bernie,

Thanks so much for your prompt response! Please find my comments in-line....

On 02/18/2015 11:47 AM, Bernie Volz (volz) wrote:
> 
> There are servers that use full prefixes (i.e., can assign any
> addresses in /64) - and I guess you'd say to use ADDR_HI of
> x:x:x:x:FFFF:FFFF:FFFF:FFFF and ADDR_LOW of x:x:x:x:0:0:0:0?

Exactly. Actually, they could use the prefix notation in the
configuration file, and it would be the DHCPv6 server software
converting from prefix notation to low/hi.

> In these
> cases, the extra math is not required. 

You mean the low/hi thing?

> And, for servers that have specific range (low to high), they will
> always have to do some "math". Also, I think it would be safe for
> most implementations to assume that doing this math with 64-bits is
> more than sufficient. 

You mean to assume that the upper 64 bits (the prefix) is the same for
low ad hi?

> An interesting question then is whether to change from Prefix to
> IPV6_ADDR_HI and IPV6_ADDR_LOW in the first place? Why not just stick
> to using the prefix that is in the RA (I would expect servers to know
> that since the configuration is probably a prefix with range(s)).
> Then the "range" is only applied at the end.

Because if what you specify is really a range, I'm not sure that the
prefix is meaningful anymore?

> Note also that: - Ranges may not be contiguous. What if there are
> multiple ranges (i.e., 10 to 1000, 2000 to 3000)? This is why I think
> dropping the idea of start/end range makes the most sense - just use
> the prefix. - Ranges like this also have the interesting property
> that it breaks the idea of "stable" addresses whenever a change to
> the range occurs - increasing or decreasing the range will break
> stability.

This later point is very interesting indeed, and makes strong case for
using the Prefix in the hash, rather than the range. How about employing
the Prefix in the hash function (as in the previous versions of the
I-D), and then "adjusting" the selected address to the hi/lo range as
follows:

if(IID < IID_low){
	IID=IID_low + iid % (IID_hi - IID_low + 1);
}
else if(IID > IID_hi){
	IID= IID_low + IID_hi  % (IID_hi - IID_low + 1);
}

?

> Also, shouldn't the IA option type be part of the expression? While
> today we have IA_NA and IA_TA and you probably don't want to do this
> for IA_TA, might not hurt to include this in case there are other
> types developed in the future? It probably isn't a big deal if we
> don't since that is less likely to be the case.

In this case it would be kind of redundant, since the spec itself says
that it's the IA_NA that we include (i.e., the type is implicit).
However, I agree that this wouldn't hurt.

Please let me know if you think it would be great to apply the suggested
change, and we'll do it (meanwhile maybe others can weigh in?).

> An interesting question that might be asked is whether this work even
> needs to be standardized. 

Well, you do need a spec if you need to achive the goals set forth in
this document. Note that e.g., we've specified port-number randomization
in RFC6056....

> Also, what might happen with a DHCPv6
> failover implementation (in this case, it could be that the resulting
> address that is generated by this is not available to that server
> (assigned to partner) and so counter would have to be incremented and
> regenerate an address ... which could happen multiple times).

Well, since the address space is supposed to be large, collissions
should be pretty low.

But... maybe we should add a note regarding the address range? i.e.
"don't make it too small ore collisions might happen".

> If DHCPv6 is supposed to provide stable addresses, why not just have
> the server remember the addresses that it assigned to a specific
> client (or Client & IA)? Servers have to have state, so this is not
> that challenging. Sure, you have to limit the time (otherwise you
> could build up a large amount of state), but would you really want to
> have the same address after many months?

Yes. Why would you want to change it? -- think ACLs, logging, etc.

Thanks,

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 21 Feb 2015 04:07:10 +0000

Some comments below (BV>).

Sorry for the delay.

- Bernie

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Wednesday, February 18, 2015 11:10 AM
To: Bernie Volz (volz); [email-masked]
Subject: Re: [dhcwg] draft-ietf-dhc-stable-privacy-addresses: Question on address ranges

Hi, Bernie,

> x:x:x:x:FFFF:FFFF:FFFF:FFFF and ADDR_LOW of x:x:x:x:0:0:0:0?

Exactly. Actually, they could use the prefix notation in the configuration file, and it would be the DHCPv6 server software converting from prefix notation to low/hi.

BV> Yes, if a full /x prefix is used, one can just take the lower-order 128-x bits from the result. (There may be some cases where certain addresses may not be assignable, in which case one might have to do another calculating by increasing the counter.)

> always have to do some "math". Also, I think it would be safe for most 
> implementations to assume that doing this math with 64-bits is more 
> than sufficient.

You mean to assume that the upper 64 bits (the prefix) is the same for low ad hi?

BV> Yes, I meant a server that was configured to use ::1:20 to ::1:8f (0x6f addresses). Not a server that configured to use an entire /x prefix.

> Then the "range" is only applied at the end.

Because if what you specify is really a range, I'm not sure that the prefix is meaningful anymore?

BV> Well, I guess you could argue but would someone really have 3 links with such "ranges" for v6. I thought we assumed there would be plenty of address space in v6 and one wouldn't have to do that? Also, if some ways does it really matter that much in this case? If Client A moves from Link 1 (range 1) to Link 2 (range 2), the algorithm will give it a new address any way you slice it since the ranges are different. 

BV> Also, if you have a small address space, you can't really have stable addresses unless you have a very small client population. There are too many conflicts otherwise (think of a Wifi hotspot that only had 100 addresses - when you visit the hotspot tomorrow, your address has a very likely chance of being in use by someone else so a different one has to be given anyway).

BV> Sure, a /64 allows for many large ranges. But so does splitting the /64 into /68s or /72s. And if you do that, you are likely much better off.

> the prefix. - Ranges like this also have the interesting property that 
> it breaks the idea of "stable" addresses whenever a change to the 
> range occurs - increasing or decreasing the range will break 
> stability.

This later point is very interesting indeed, and makes strong case for using the Prefix in the hash, rather than the range. How about employing the Prefix in the hash function (as in the previous versions of the I-D), and then "adjusting" the selected address to the hi/lo range as
follows:

if(IID < IID_low){
	IID=IID_low + iid % (IID_hi - IID_low + 1); } else if(IID > IID_hi){
	IID= IID_low + IID_hi  % (IID_hi - IID_low + 1); }

BV> Yes, I think the prefix should just be used in the hash. Once you get the hash value, you can use this kind of algorithm to determine which entry in the "range" to assign to the client (if available).

?

> don't since that is less likely to be the case.

In this case it would be kind of redundant, since the spec itself says that it's the IA_NA that we include (i.e., the type is implicit).
However, I agree that this wouldn't hurt.

Please let me know if you think it would be great to apply the suggested change, and we'll do it (meanwhile maybe others can weigh in?).

BV> Yes, would be interesting to hear other input on this. I see little harm in adding two more bytes to the hash. But, yeah, we may never end up needing it. But if we did, it would avoid defining yet another hash.

> needs to be standardized.

Well, you do need a spec if you need to achive the goals set forth in this document. Note that e.g., we've specified port-number randomization in RFC6056....

BV> Sure, there are some goals that are not achieved by having the server(s) remember (such as if the server's data is lost or the server is replaced by a completely different one). But how often is that going to happen? And collisions are going to occur (especially with smaller ranges), so I don't see that this gives you any guarantee that things will be that much better.

> regenerate an address ... which could happen multiple times).

Well, since the address space is supposed to be large, collissions should be pretty low.

BV> Yes. I think the statement should be the smaller you make the pool the more likely collisions are and the less value this has. A pool of 2^64 addresses has much lower probability of collisions than a pool of 2^32 (probably 1/2^32 less, but someone might prove that wrong). But of course, if you only have 1 unique client connecting to your network, a pool of 1 is just fine. So, this has to be taken in the context of the intended client population and the intended stability of addresses. The more unique clients and the longer the chance of stability desired, the larger the pool must be. And finally there is always bad luck - You may have no stability with just two clients.

BV> If you are going to create ACLs and assuming logging information is valid over long times, RESERVE addresses for a client. I doubt any administrator would be willing to risk critical resources / logging based on "stable privacy addresses". They will reserve the addresses for the client. (Yes, this isn't perfect either as if you know the client DUID you can "steal" the address; but "stable privacy addresses" has that same issue as well so it doesn't buy you anything better).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 22 Feb 2015 09:35:34 -0300

Hi, Bernie,

Thanks so much for your feedback! -- Please find my comments in-line....

On 02/21/2015 01:07 AM, Bernie Volz (volz) wrote:
> BV> Also, if you have a small address space, you can't really have
> stable addresses unless you have a very small client population.
> There are too many conflicts otherwise (think of a Wifi hotspot that
> only had 100 addresses - when you visit the hotspot tomorrow, your
> address has a very likely chance of being in use by someone else so a
> different one has to be given anyway).

Fully agreed.

>> multiple ranges (i.e., 10 to 1000, 2000 to 3000)? This is why I
>> think dropping the idea of start/end range makes the most sense -
>> just use the prefix. - Ranges like this also have the interesting
>> property that it breaks the idea of "stable" addresses whenever a
>> change to the range occurs - increasing or decreasing the range
>> will break stability.
> 
> This later point is very interesting indeed, and makes strong case
> for using the Prefix in the hash, rather than the range. How about
> employing the Prefix in the hash function (as in the previous
> versions of the I-D), and then "adjusting" the selected address to
> the hi/lo range as follows:
> 
> 
> if(IID < IID_low){ IID=IID_low + iid % (IID_hi - IID_low + 1); } else
> if(IID > IID_hi){ IID= IID_low + IID_hi  % (IID_hi - IID_low + 1); }
> 
> BV> Yes, I think the prefix should just be used in the hash. Once you
> get the hash value, you can use this kind of algorithm to determine
> which entry in the "range" to assign to the client (if available).
> 
> ?

Agreed. I will update the I-D as discussed.

>>  today we have IA_NA and IA_TA and you probably don't want to do
>> this for IA_TA, might not hurt to include this in case there are
>> other types developed in the future? It probably isn't a big deal
>> if we don't since that is less likely to be the case.
> 
> In this case it would be kind of redundant, since the spec itself
> says that it's the IA_NA that we include (i.e., the type is
> implicit). However, I agree that this wouldn't hurt.
> 
> Please let me know if you think it would be great to apply the
> suggested change, and we'll do it (meanwhile maybe others can weigh
> in?).
> 
> BV> Yes, would be interesting to hear other input on this. I see
> little harm in adding two more bytes to the hash. But, yeah, we may
> never end up needing it. But if we did, it would avoid defining yet
> another hash.

Unless there are arguments against this, I'll apply the proposed change.

>> An interesting question that might be asked is whether this work
>> even needs to be standardized.
> 
> this document. Note that e.g., we've specified port-number
> randomization in RFC6056....
> 
> BV> Sure, there are some goals that are not achieved by having the
> server(s) remember (such as if the server's data is lost or the
> server is replaced by a completely different one). But how often is
> that going to happen? And collisions are going to occur (especially
> with smaller ranges), so I don't see that this gives you any
> guarantee that things will be that much better.

This algorithm assumes that you'll employ most of the /64 for selecting
the addresses to be leased (otherwise, from a security standpoint,
randomizing the IID will not buy you much) -- maybe this should be noted
in the I-D?

That said, while I don't have stats regarding the aforementioned
failures in e.g. enterprise networks, I'm sure I'm not the only one who
has experienced his home server's HD die from "night to day".

And you can achieve the aforementioned benefit by simply replacing the
call you'd make to random() -- assuming you want to randomize addresses
-- with the expression specified in this document, and including a
"secret_key" parameter in the configuration file.

>> Also, what might happen with a DHCPv6 failover implementation (in
>> this case, it could be that the resulting address that is generated
>> by this is not available to that server (assigned to partner) and
>> so counter would have to be incremented and regenerate an address
>> ... which could happen multiple times).
> 
> BV> Yes. I think the statement should be the smaller you make the
> pool the more likely collisions are and the less value this has. A
> pool of 2^64 addresses has much lower probability of collisions than
> a pool of 2^32 (probably 1/2^32 less, but someone might prove that
> wrong). But of course, if you only have 1 unique client connecting to
> your network, a pool of 1 is just fine. So, this has to be taken in
> the context of the intended client population and the intended
> stability of addresses. The more unique clients and the longer the
> chance of stability desired, the larger the pool must be. And finally
> there is always bad luck - You may have no stability with just two
> clients.

Agreed.

Thanks!

Best regards,