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

[Eric Rescorla <[e-mail]>]

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

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

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