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

["Bernie Volz (volz)" <[e-mail]>]

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