Re: [dhcwg] whether/how to support Confirm with sedhcpv6

[Ted Lemon <[e-mail]>]

I think these are easy problems to solve and do not add significant
complexity.   Encryption of the confirm I think addresses the privacy
problem.

On Mar 28, 2017 10:44 AM, "Bernie Volz (volz)" <[e-mail]> wrote:

> Interesting idea …
>
> But, wouldn’t just sending the initial Information-Request per seDHCPv6
> which “solicits” server’s certificates with the Encrypted-Message Option
> which contained the Confirm (and an Encryption Key Tag Option) be best? Not
> exactly sure what the reference to “wrap relay messages”.
>
> We might also consider whether this could be useful for the Rebind (prefix
> delegation version of Confirm).
>
> And, then there’s the question of what the server’s response is … for the
> server that can decrypt, it would send a Reply for the Confirm(/Rebind) and
> not answer the Information-Request?
>
> BTW: RFC 7844 (DHCP Anonymity Profiles) section 4.2 says not to send
> Confirms. Perhaps for seDHCPv6, starting with the seDHCPv6
> Information-Request is thus OK and if client determines same server exists
> (based on certificate) it could then issue Confirm (or just Renew/Rebind).
> RFC7844 4.2 also suggests that if other information about the link is
> available (such as SSID), the Confirm might be sent directly.
>
> The main question is how much special mechanism to add? Be nice to not
> make it too complex.
>
> - Bernie
>
> On 3/28/17, 11:28 AM, "Ted Lemon" <[e-mail]> wrote:
>
>     Probably the most expedient way to handle this would be to create a
> confirm, sign and encrypt it, and then wrap it the same way we wrap relay
> messages, including it in an information-request as in the regular
> IR/Solicit/Confirm process for secure DHCP.
>
>     The server on the local wire either supports the wrapping and can
> decrypt, supports it but cannot decrypt, or doesn't support it and hence
> ignores it.   This allows the client to send a single packet that will
> always elicit a response, either an answer to the question asked in the
> Information request, or else a confirmation that it's okay to continue
> using the address.
>
>     The hard question is, what do you do if you get an answer to the
> information request, rather than to the Confirm?   But I think that's
> straightforward: you wait a (short) while to see if you get an answer to
> the confirm; if you do, you take that; otherwise you take the answer from
> the Information-Request.
>
>
>
>