Re: [dhcwg] Next step(s) for draft-ietf-dhc-stable-privacy-addresses -> abandon work? / IA_NA applicability

[Fernando Gont <[e-mail]>]

Hi, Lorenzo,

On 04/08/2015 09:45 AM, Lorenzo Colitti wrote:
> On Wed, Apr 8, 2015 at 9:28 PM, Fernando Gont <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     > That just changes the question to "what happens if the server uses both
>     > this type of address and other types of address".
> 
>     The intent is that if you're going to use this scheme, for leasing
>     addreses, you use this scheme for all prefixes: at the end of the day,
>     if *one* of your addresses is predictable, that's enough for the
>     attacker to track you or scan you.
> 
> 
> No, it's not enough. The attacker can only track or scan you if you use
> a stupid algorithm to generate the IIDs. Yours is not stupid, but
> neither are many others such as "random". You can perfectly well use
> random assignment on some subnets and your algorithm on other subnets.

The intent is that, for a given subnet, all IIDs have the same property.

But, in any case, as far as I recall this I-D does not say "you must
employ this algorithm for all of the prefixes from which you lease
addresses", anyway.

If you have any suggested text that would address your concern, please
do let us know.


> Regardless - if that's the intent, then the draft should say so.

mm.. how about changing this:

---- cut here ----
   DHCPv6 server implementations conforming to this specification MUST
   generate non-temporary IPv6 addresses using the algorithm specified
   in this section.

   Implementations conforming to this specification SHOULD provide the
   means for a system administrator to enable or disable the use of this
   algorithm for generating IPv6 addresses.

   All of the parameters included in the expression below MUST be
   included when generating an IPv6 address.

   A DHCPv6 server implementing this specification must select the IPv6
   addresses to be leased with the following algorithm:
---- cut here ----

to to this:

---- cut here ----
   A DHCPv6 server implementation employing this specification MUST
   generate non-temporary IPv6 addresses for the corresponding prefix
   by means of the algorithm specified in this section.

   Implementations conforming to this specification SHOULD provide the
   means for a system administrator to enable or disable the use of this
   algorithm for generating IPv6 addresses.

   Unless otherwise noted, all of the parameters included in the
   expression below MUST be included when generating an IPv6 address.

   A DHCPv6 server employing this specification must select the IPv6
   addresses to be leased from the corresponding prefix with the
   following algorithm:
---- cut here ----

?




>     > then you'll need to make it clear
>     > what is required for it to coexist with other ways of generating IPv6
>     > IIDs. If not, then you'll need to make it clear that it cannot coexist
>     > with other ways of generating addresses.
> 
>     Other ways of generating IIDs for the same prefix, or for other
>     prefixes?
> 
>     For other prefixes, the idea is that if you use a weak scheme for other
>     prefixes, you're toast. For the same prefix, if you employ multple
>     schemes you won't achieve address stability.
> 
>     Is this what you were referring to?
> 
> 
> I was referring to the lack of any such statement in the draft, yes.

Ok, how about adding something along these lines:

---- cut here ----
In order to achieve the goals described in Section 3 of this document,
all of the DHCPv6 servers leasing addresses from a given IPv6 address
range must employ this algorithm. If different DHCPv6 servers leasing
addresses from the same IPv6 address range employ different algorithms,
address stability will not be achieved.

DHCPv6 servers leasing addresses from different IPv6 address ranges may
employ other algorithms for selecting the IPv6 addresses to be leased.
We note, however, that security-unwise algorithm is employed for
selecting addresses from a different IPv6 address range on the same
subnet, the benefits of the algorithm specified in this document may be
reduced. For example, if a DHCPv6 server employs this algorithm for
selecting addresses from a given address range, and another server on
the same subnet selects address incrementally for a different address
range on the same subnet, a node that is leased addresses from both
address ranges will still be vulnerable to address scans attacks.
---- cut here ----

?


>     > Another issue I see is that the document says that the addresses are
>     > stable and stateless, but they're not, because the value of counter for
>     > every lease needs to be shared between the servers. For example, if the
>     > client sends a DECLINE because it fails DAD, what do you do? The address
>     > is no longer stable.
> 
>     IMO, I see the counter as mostly an "optional" parameter, which allows
>     to recover from address collisions (rather than a mandatory field). If
>     you do employ the Counter, but do not store it, then whether the
>     addresses are stable or not depends on the order in which systems are
>     bootstrapped.
> 
> 
> Then the draft needs to say what the server needs to do if it doesn't
> use the counter and the client sends a decline. Does the client get no
> address?

If you don't use the counter at all, yes. However, I'd expect
implementations not to include the counter, but not to record it's
contents (if they don't record the address lease) -- (yes, sorry, my
previous response was confusing).

I'll craft text about this and send it to the list for review.



>     > Another issue: if the addresses are stable and stateless, then that
>     > means you can replace a server and have the client keep the same
>     > address. What modifications are needed on the server side for that to
>     > work? If the client sends a renew unicast to the new server, will this
>     > just work?
> 
>     This deserves a clarification, indeed.
> 
>     Of th top of my head:
> 
>     * Address stability can be achieved 100% stateless-ly, but need not.
>     e.g., you can generate addresses as specified in this document, but
>     still keep an address lease database. In that case, the server would
>     employ this algorithm for generating the addresses in the first place,
[....[
> 
>     Does (some version of) this sound reasonable?
> 
> Perhaps. But you have to document this, and if you document this and it
> turns out that you need server-side behaviour changes, then you need to
> update RFC 3315.
> 
> Again, I don't think it's worth it.

For the time being, I think we should not consider the 100% stateless
version of this. After all, the man goal of this document is an address
selection scheme for DHCPv6, rather than an improvement in terms of "now
DHCPv6 can be fully stateless".

Thanks!

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