[dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with DISCUSS and COMMENT)

"Ben Campbell" <ben@nostrum.com> Tue, 31 January 2017 23:30 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B36C12964F; Tue, 31 Jan 2017 15:30:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ben Campbell" <ben@nostrum.com>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.41.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148590541849.5999.8358163403846302600.idtracker@ietfa.amsl.com>
Date: Tue, 31 Jan 2017 15:30:18 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/hokJbxrFJ--5t9LYTG2Uw_C1fY8>
Cc: dhc-chairs@ietf.org, volz@cisco.com, draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, dhcwg@ietf.org
Subject: [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with DISCUSS and COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
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, 31 Jan 2017 23:30:18 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-dhc-dhcpv6-failover-protocol-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I think the security considerations need some elaboration. The draft says
"When operating in secure mode...", but it doesn't discuss when one might
want to run in secure more vs non-secure mode. It would be helpful to
discuss actual threats. You mention TCP DoS attacks, but, for example,
can an eavesdropper learn sensitive or private information? Is there a
risk of someone impersonating a partner? Tampering with messages on the

There's a mention of using TLS certs for authentication/authorization,
but I think there's more to be said there. Is there any authentication or
authorization if you aren't using secure mode? How do you match a TLS
certificate to the partner name?

The section opens saying that the security considerations from 3315 and
3633 apply, but I doubt either of those contemplated that you would be
sending DHCP messages over TCP connections between partner servers.


- 6.1.3: I'm confused by the procedure for checking
already checked that it supported the version in the CONNECT message; why
does the primary need to check it again? Is it expected that the
secondary might choose to send a different version in the CONNECTREPLY
than it received in CONNECT? Is it possible that the partners use
different protocol versions at the same time?