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

Warren Kumari <warren@kumari.net> Tue, 11 April 2017 22:17 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE2C1276AF for <dhcwg@ietfa.amsl.com>; Tue, 11 Apr 2017 15:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCCwItStlvAg for <dhcwg@ietfa.amsl.com>; Tue, 11 Apr 2017 15:17:27 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8E6124D6C for <dhcwg@ietf.org>; Tue, 11 Apr 2017 15:17:26 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id c45so9488580qtb.1 for <dhcwg@ietf.org>; Tue, 11 Apr 2017 15:17:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hJ9Q4GvKr7mBpVGGi0n8e4gELgk8ZMTzKGZdtxhRzvg=; b=a7kdo6CKWEqPYne/Rigml56ZH9TKZBfdyCErJyyo7SwNCnKClxbU8sODkodJr3nGv1 p9upy/H5KFUR4iLbl9uEWfHXek0oulVwBgZDI5IjL72kcZEBSK8quCe47MGAkSvk5eTh cw2cZUIGCmwefOeyoLZb3CK8qtDp7o8OE3BWzNpcWA8tQ/uQaxyMlHbfsyyURbREM9Lt SrNpCwPm6iF0x34PM1Re8DLaY2XnMRMFzSNgZJheyZCyUQaOIgiLod7j0K9iM4bnn78H pXdPh89faAYIE4+hqZBGoTaa3tgkTNOUGMswl56et6tAKG8udzhpEkfwqK+ioFRvCyQ1 HbPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hJ9Q4GvKr7mBpVGGi0n8e4gELgk8ZMTzKGZdtxhRzvg=; b=GF52wDuBcsB6laJ4lgQJZyz7McYAewJcpLHIgcC1onkRgbSKSeLQHqY6sCnyWtcdPm OxpbOwkoVW/tUpmx0BzQIg3kxPaycdvjIaEshHrU147PG0NhqikKqZ7kWEwcPmeAjxa6 eef0JDPZr3VULDig+PNqhLm/yKOTpaluVSAJFQS/3lFiKK665/8uusnVeUK+qIoYNHM+ UUFaHmXfvGyOVANq+VLc0RgYlViMeSE93c5fK8xFnT+2Izzy3pVcIKYcNWqStjxcCuoO 4jDggMR646y1wnB1BW+e0Ue5O53Zk8N/MFDsnjef4GxMJo9xa0mdAoX1BPZ2/JXTyUOn RPIw==
X-Gm-Message-State: AN3rC/4vpKwUw8qeN9mjwi/WBnIXEykaQ3mg0dA4iAFfAR5Cu8l8BALIAgHhE7VBUBn9FaX4ALA7wpsrwJcQlD0h
X-Received: by 10.200.55.13 with SMTP id o13mr14345347qtb.57.1491949045766; Tue, 11 Apr 2017 15:17:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.183.136 with HTTP; Tue, 11 Apr 2017 15:16:45 -0700 (PDT)
In-Reply-To: <5320BC41-545C-4510-89AC-9C62460E80CA@cisco.com>
References: <5320BC41-545C-4510-89AC-9C62460E80CA@cisco.com>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 11 Apr 2017 18:16:45 -0400
Message-ID: <CAHw9_i+DZD30Z=9h6KmeK9zQXn_-wkrBvM+u69rsHGWFjqCp_A@mail.gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Cc: The IESG <iesg@ietf.org>, Tomek Mrugalski <tomasz.mrugalski@gmail.com>, "dhc-chairs@ietf.org" <dhc-chairs@ietf.org>, "draft-ietf-dhc-relay-server-security@ietf.org" <draft-ietf-dhc-relay-server-security@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/8ZiOjQiPXAYFvZzX5FmJjcIlDuo>
Subject: Re: [dhcwg] Discusses on draft-ietf-dhc-relay-server-security-04
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Apr 2017 22:17:29 -0000

On Tue, Apr 11, 2017 at 4:46 PM, Bernie Volz (volz) <volz@cisco.com> 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.
>
> 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.

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.

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

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

>
> - Bernie Volz
>



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