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

Eric Rescorla <ekr@rtfm.com> Tue, 11 April 2017 21:17 UTC

Return-Path: <ekr@rtfm.com>
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 7A0701201F8 for <dhcwg@ietfa.amsl.com>; Tue, 11 Apr 2017 14:17:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 qEvelWAgHr_M for <dhcwg@ietfa.amsl.com>; Tue, 11 Apr 2017 14:17:02 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 73FF1126D73 for <dhcwg@ietf.org>; Tue, 11 Apr 2017 14:17:00 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id l189so4362743ywb.0 for <dhcwg@ietf.org>; Tue, 11 Apr 2017 14:17:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tr4E5WgFssxuU3vYBBJACRzfVlfKjLzJy4JrOlyOw8w=; b=ipGSROXTOj7cA+bhFrHVnZChxd3H0SFtW7zSPi0gvWEfGmBjxVyFeOZOXSJ4YgCPT5 ukz/Gw5N/FodhZAJW0VN/nMgl9C7VS0rlg41wSkgMjNfgPqdtfk1y/kTDgtV+G6QMZFJ QSTyzPT6hCbZsgjdR4IfFio6tsWC9ERdSuzFSwrDTcnOZzfhUJIlB6kLwlvel/zCjnd6 N7sfT7H7xJzpCJ5zkQi2MHvFa7S4w7C9zg9dVzVhkWHk+cdn8bvhBgNFcptFWx2UpwkD Fg3dC1FsFfmnrFtz74vasuFoDer4NhJayokX1OWPQuZWGQOrlBgA8fiOsLFNIasxe1mJ pE9Q==
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; bh=tr4E5WgFssxuU3vYBBJACRzfVlfKjLzJy4JrOlyOw8w=; b=eHAOGBon7edsjqRnTzceXU7JXyDrZOX4bZqM28BZg93ow+RcS6nrvuwZoQLk9+qF/d K40oUYHFEqIzFWlszVZJhVbhI21POAFPsry6kJc8cTDMRv1WMSXJTgNIGaOx94YDotUd KrODKC/Gk7i4uNKuEE5/gs575IQWo7tXXHOPjr8wu7ZEPc5KCyCioS5zHmuKGBaA7kWa z+SeocdLHMeBgoKOMzWnQak+So2M2GcKEQC4EKTwYpsFAU7OXdjRibxgZdwwhxeB9FG3 2dVPYtasgKFEHCaq56H05s3CS7d90Z0G3LO0N2Rz8XqJY2quODJdf2YT8wGMlTL15woa aLWA==
X-Gm-Message-State: AFeK/H0Bp9sJxEb0S15PqEi6mK2SHGpldCMr7aY/rYSgDfotuBdjHxBtxgUDrVIPpEYJHZnnKEUjpGwLemn2XQ==
X-Received: by 10.129.125.5 with SMTP id y5mr40368899ywc.120.1491945419617; Tue, 11 Apr 2017 14:16:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.113.7 with HTTP; Tue, 11 Apr 2017 14:16:19 -0700 (PDT)
In-Reply-To: <5320BC41-545C-4510-89AC-9C62460E80CA@cisco.com>
References: <5320BC41-545C-4510-89AC-9C62460E80CA@cisco.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 11 Apr 2017 14:16:19 -0700
Message-ID: <CABcZeBOXxitLAk_jNXbqU0oaNP5RO2RfYbfG0ft-bYf-XXR20A@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: multipart/alternative; boundary=001a11493644c35b9c054cea9c5a
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/c9VXBaHhr0Sunc5WtP_uxFLVLhk>
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 21:17:04 -0000

On Tue, Apr 11, 2017 at 1: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.
>

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