[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: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 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 network? 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 6.1.3: I'm confused by the procedure for checking OPTION_F_PROTOCOL_VERSION in the CONNECTREPLY message. The secondary 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?