Subject: Re: [dhcwg] Discusses on draft-ietf-dhc-relay-server-security-04

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 11 Apr 2017 20:46:20 +0000

Hi:

Regarding the discusses:

1. Eric Rescorla Discuss (2017-04-07)
What's not clear to me from reading this document is whether anyone
actually does IPsec for DHCP relaying. If so, what configurations do
they run it in? If not, will they do so as the result of this
document?
 
Answer: I do not know if anyone actually uses IPsec. The RFC3315 mechanism was optional and did not provide encryption so it may not have ever been used. Therefore, I do not know what anyone actually does today (if anything). Those using DHCP that I am aware of with relays do not.

The hope is that more would use this more robust version, and those operators that find it important to do so will require it of their relay and server vendors by purchasing implementations that support this to-be-RFC.

2. Warren Kumari Discuss (2017-04-08)
This document says that it "replaces the text in RFC3315 Section 21.1.", but it does not have an Updates tag. It is also contains a large blob of RFC3315, with clear explanation of what exactly changed.

ANSWER: If we said Updates, that would mean it would likely become a new required standard for those implementing RFC 3315. For many DHCP items, we only use the Updates tag when there is a “required” change in earlier documents. This is not “required” – it is an optional feature that vendors can chose to implement and operators can choose to use/require of their vendors to implement. Regarding the text, much of it is similar to what was in RFC 3315 because it is specifying the full IPsec specification. The main things that changed are that it is required (if you want to claim conformance to this to-be-RFC, whereas if you say you comply with 3315 there is no requirement to implement IPsec) and the use of encryption.

The writeup says "Even though this I-D introduces changes to RFC3315, the WG doesn't want to enforce IPsec encryption on every DHCPv6 server. Therefore, it does not update RFC3315." -- so, if I'm writing a new DHCPv6 implementation, do I need to support this? The document reads like it tries to update 3315, but the writeup says otherwise -- once published, no-one will read the shepherd writeup. I think that the document itself needs to be clearer that this is an optional extension (so if I want to buy an implementation which does this, I ask for RFC3315 and RFCxxxx).

ANSWER: Whether you implement this IPsec requirement in the to-be-RFC is an implementation choice. There is no requirement to implement this to-be-RFC. And operators that wish to use IPsec must require their vendors to implement this to-be-RFC. So there would be implementation that comply with RFC 3315 and this-to-be-RFC. This will make it clear to anyone desiring relays or servers whether they can use IPsec based on whether they implement this-to-be-RFC. This is not much different than other DHCP extensions – such as Bulk or Active Leaseuquery – these are not part of the base specification but OPTIONAL features documented in other RFCs.

I also do not understand the relationship between this document (which talks about text RFC3315), and draft-ietf-dhc-rfc3315bis (which is currently in WGLC) -- if rfc3315bis is almost done, should this reference that instead? Or should rfc3315bis simply incorporate this?

ANSWER: 3315bis has this exact same text EXCEPT it is optional. When working on 3315bis we did not feel that it was worth documenting the old IPsec “rules” from 3315 as they were weak and not very useful. But again, we did not want to make IPsec required as part of 3315bis. Also, we wanted this to-be-RFC to be available sooner than 3315bis might be. We could certainly discuss REMOVING IPsec text from 3315bis and just referring to this to-be-RFC. That in the end may be cleaner.

Comment (2017-04-08)
I found the document confusing -- it says that it REQUIRES IPsec for DHCPv4 and DHCPv6, but it reads like it is requiring that operators enable this, not that implementations have to support this; what exactly is is trying to do? 
I think that it would be much clearer if it said that implementations of this document must support IPsec and that operators are recommended to enable it (assuming that it what it means).

ANSWER: Is it both – for vendors to implement and for operators to use. It requires both because of key management. If you prefer we can certainly add a sentence or reword some existing text to says “implementations of this document must support IPsec and that operators are recommended to enable it”. Perhaps replace:

   For DHCPv6 [RFC3315], this specification REQUIRES IPsec encryption of
   relay to relay and relay to server communication and replaces the
   text in RFC3315 Section 21.1.

   For DHCPv4 [RFC2131], this specification REQUIRES IPsec encryption of
   relay to server communication.

With something like:

   For DHCPv6 [RFC3315], this specification REQUIRES relay and server
   implementations to support IPsec encryption of relay to relay and
   relay to server communication as documented below (this replaces
   the text in RFC3315 Section 21.1).

   For DHCPv4 [RFC2131], this specification REQUIRES relay and server
   implementations to support IPsec encryption of relay to server
   communication as documented below.

   This specification RECOMMENDS that operators enable IPsec for this 
   communication.

- Bernie Volz

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Apr 2017 14:16:19 -0700

On Tue, Apr 11, 2017 at 1:46 PM, Bernie Volz (volz) <[email-masked]> wrote:

> Answer: I do not know if anyone actually uses IPsec. The RFC3315 mechanism
> was optional and did not provide encryption so it may not have ever been
> used. Therefore, I do not know what anyone actually does today (if
> anything). Those using DHCP that I am aware of with relays do not.
>

This seems like a fairly strong argument against mandating it.

-Ekr

>
> The hope is that more would use this more robust version, and those
> operators that find it important to do so will require it of their relay
> and server vendors by purchasing implementations that support this
> to-be-RFC.
>
> This document says that it "replaces the text in RFC3315 Section 21.1.",
> but it does not have an Updates tag. It is also contains a large blob of
> RFC3315, with clear explanation of what exactly changed.
>
> ANSWER: If we said Updates, that would mean it would likely become a new
> required standard for those implementing RFC 3315. For many DHCP items, we
> only use the Updates tag when there is a “required” change in earlier
> documents. This is not “required” – it is an optional feature that vendors
> can chose to implement and operators can choose to use/require of their
> vendors to implement. Regarding the text, much of it is similar to what was
> in RFC 3315 because it is specifying the full IPsec specification. The main
> things that changed are that it is required (if you want to claim
> conformance to this to-be-RFC, whereas if you say you comply with 3315
> there is no requirement to implement IPsec) and the use of encryption.
>
>
> The writeup says "Even though this I-D introduces changes to RFC3315, the
> WG doesn't want to enforce IPsec encryption on every DHCPv6 server.
> Therefore, it does not update RFC3315." -- so, if I'm writing a new DHCPv6
> implementation, do I need to support this? The document reads like it tries
> to update 3315, but the writeup says otherwise -- once published, no-one
> will read the shepherd writeup. I think that the document itself needs to
> be clearer that this is an optional extension (so if I want to buy an
> implementation which does this, I ask for RFC3315 and RFCxxxx).
>
> ANSWER: Whether you implement this IPsec requirement in the to-be-RFC is
> an implementation choice. There is no requirement to implement this
> to-be-RFC. And operators that wish to use IPsec must require their vendors
> to implement this to-be-RFC. So there would be implementation that comply
> with RFC 3315 and this-to-be-RFC. This will make it clear to anyone
> desiring relays or servers whether they can use IPsec based on whether they
> implement this-to-be-RFC. This is not much different than other DHCP
> extensions – such as Bulk or Active Leaseuquery – these are not part of the
> base specification but OPTIONAL features documented in other RFCs.
>
>
> I also do not understand the relationship between this document (which
> talks about text RFC3315), and draft-ietf-dhc-rfc3315bis (which is
> currently in WGLC) -- if rfc3315bis is almost done, should this reference
> that instead? Or should rfc3315bis simply incorporate this?
>
> ANSWER: 3315bis has this exact same text EXCEPT it is optional. When
> working on 3315bis we did not feel that it was worth documenting the old
> IPsec “rules” from 3315 as they were weak and not very useful. But again,
> we did not want to make IPsec required as part of 3315bis. Also, we wanted
> this to-be-RFC to be available sooner than 3315bis might be. We could
> certainly discuss REMOVING IPsec text from 3315bis and just referring to
> this to-be-RFC. That in the end may be cleaner.
>
>
> Comment (2017-04-08)
> I found the document confusing -- it says that it REQUIRES IPsec for
> DHCPv4 and DHCPv6, but it reads like it is requiring that operators enable
> this, not that implementations have to support this; what exactly is is
> trying to do?
> I think that it would be much clearer if it said that implementations of
> this document must support IPsec and that operators are recommended to
> enable it (assuming that it what it means).
>
> ANSWER: Is it both – for vendors to implement and for operators to use. It
> requires both because of key management. If you prefer we can certainly add
> a sentence or reword some existing text to says “implementations of this
> document must support IPsec and that operators are recommended to enable
> it”. Perhaps replace:
>

---

From: Warren Kumari <[email-masked]>
Date: Tue, 11 Apr 2017 18:16:45 -0400

> ANSWER: Whether you implement this IPsec requirement in the to-be-RFC is an implementation choice. There is no requirement to implement this to-be-RFC. And operators that wish to use IPsec must req…

That really was not clear from my reading of the document -- it very
much sounds like it is (trying) to add additional requirements to
*all* DHCP implementations, not that this is an optional extension.
Until I read the shepherd writeup and the WG discussions I thought
that this was adding new requirements to the base spec (as, I think,
did other ADs), and that it also tried to tell me how to run my
servers. I really think that the document should clarify that this is
an optional feature / extension -- unfortunately I don't have text to
suggest.
I happen to think that this is a USEFUL feature / extension, but
please clarify that it is optional.

>    This specification RECOMMENDS that operators enable IPsec for this

I think that this would be useful.
Much of my comment stems from the earlier "what exactly is "this
specification"? Is it DHCP, or DHCP with this optional extension?

Again, I think that this is a useful document, happy to clear my
DISCUSS once it is clear that this is an option, not a new requirement
on all implementations.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf