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

From: 神明達哉 <[email-masked]>
Date: Sun, 26 Mar 2017 07:32:07 -0700

While reviewing ietf-dhc-sedhcpv6-21, I've realized one thing that
probably requires a discussion: whether/how to use sedhcpv6 for
Confirm.  To avoid distraction I'm raising it separately from the full
review I'm planning to submit later.

When a client might want to send a Confirm, it should be reasonably
possible that the client has moved and would be talking to a different
server.  In that case it doesn't make sense to encrypt the Confirm
message and encapsulate it in an Encryption-query message; the actual
server would silently discard it, and the client can't tell whether
it's because it has moved or the message is simply lost.  So I think
we need some special case handling here.  A couple of choices I can
think of are:
- say sedhcpv6 can't support Confirm (I don't like this option)
- have the client perform a separate information-request/reply
  exchange to see if the currently recognized server and its public
  key are still usable (if not, the client should basically not send
  the Confirm, following the sense of RFC7844).

(There may be other options.)

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 26 Mar 2017 14:44:49 +0000

Hi:

Good point ... I was thinking that encrypted Confirm (or Rebind) would be fine - if still on same link (or at least server) it would work just fine. Otherwise, client times out and is left to use other mechanisms (RS/RA)?

But using Information-Request is interesting. Wonder if doing both or falling back to Information-Request after short period (note that if client determined it needed new leases, it would do Information-Request anyway).

We can add to discussion at Thursday DHC WG meeting as we hoped to get some issues regarding draft that could use discussion.

- Bernie (from iPhone)

> On Mar 26, 2017, at 9:32 AM, 神明達哉 <[email-masked]> wrote:
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: 神明達哉 <[email-masked]>
Date: Mon, 27 Mar 2017 21:16:30 -0700

At Sun, 26 Mar 2017 14:44:49 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> Good point ... I was thinking that encrypted Confirm (or Rebind)
> would be fine - if still on same link (or at least server) it would
> work just fine. Otherwise, client times out and is left to use other
> mechanisms (RS/RA)?

I think that's find in the case of Rebind: if the current server dies
but there are other available servers, and if the admin chooses to
deploy sedhcpv6 in that network, other servers hopefully share the
same server key pair and can decrypt the encrypted Rebind.  (But even
if so, it may be a good idea to discuss this point explicitly).

But, in the case of Confirm and when the client has actually moved,
this approach will involve some longer time until the client falls
back to other mechanisms including a restart of DHCPv6.  This is worse
than the current Confirm without sedhcpv6, and I think it's generally
better to eliminate such regression.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Mar 2017 10:28:34 -0500

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.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 28 Mar 2017 15:44:35 +0000

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" <[email-masked]> wrote:

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Mar 2017 14:48:40 -0400

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)" <[email-masked]> 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”.
>
> 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.
>
>     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.
>
>
>
>