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

[Lorenzo Colitti <[e-mail]>]

On Wed, Apr 8, 2015 at 9:28 PM, Fernando Gont <[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.

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


> > 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.


> > 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?


> > 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,
> but the address lease would be recorded in the lease database. After
> that, things would work as for any other DHCPv6 address generation
> scheme. If the server is replaced (same IP address, same server DUID),
> renew/rebind itself would "fail" but then but then the same address
> would be leased again (when the algorithm is applied ot generate a "new"
> IPv6 address). For failover to a different server this doesn't really
> matter, as a renew is sent to the same server, nt just ot "any server".
>
>
> For a 100% stateless operation, then the server should check whether the
> address t be renewed is the result of applying the expression in the
> I-D. If it is, that'd be the same as having an entry in the lease
> database. Otherwise, it's a "no binding" scenario. For the case where
> one wants to cope with possible address clollisions, one might (MAY) the
> server to try to expression (incrementing Counter) up to "MaxRetries"
> (which should be the same value that the server should use when trying
> to come up with a unique address but collissions are found).
>
> 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.