Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with DISCUSS and COMMENT)
"Ben Campbell" <ben@nostrum.com> Thu, 02 February 2017 02:27 UTC
Return-Path: <ben@nostrum.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 74EC1129620; Wed, 1 Feb 2017 18:27:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level:
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
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 pd2vC1R9B9bg; Wed, 1 Feb 2017 18:27:11 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 F255F12948F; Wed, 1 Feb 2017 18:27:07 -0800 (PST)
Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v122R3Ex010520 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 1 Feb 2017 20:27:04 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39]
From: Ben Campbell <ben@nostrum.com>
To: kkinnear <kkinnear@cisco.com>
Date: Wed, 01 Feb 2017 20:27:03 -0600
Message-ID: <3F50B6FB-FE8B-4308-9220-B88F9D79B6B1@nostrum.com>
In-Reply-To: <DB565EB8-D133-4858-9990-39890BA55D4F@cisco.com>
References: <148590541849.5999.8358163403846302600.idtracker@ietfa.amsl.com> <DB565EB8-D133-4858-9990-39890BA55D4F@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.6r5319)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/JlXYIhweoDI2zAmL6XkkYm2GPO4>
Cc: dhc-chairs@ietf.org, dhcwg@ietf.org, Bernie Volz <volz@cisco.com>, draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [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
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: Thu, 02 Feb 2017 02:27:12 -0000
Hi, thanks for the response. Please see inline: Thanks! Ben. On 1 Feb 2017, at 10:28, kkinnear wrote: [...] >> >> ---------------------------------------------------------------------- >> 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. > > While I could try to answer your questions directly, it seemed like > offering an augmented Security Considerations section might be more > useful. This takes into account both your comments and Kathleen > Moriarty's comments as well: > > > DHCPv6 failover is an extension of a standard DHCPv6 protocol, so > all security considerations from [RFC3315], Section 23 and > [RFC3633], Section 15 related to the server apply. > > The use of TCP introduces some additional concerns. Attacks that > attempt to exhaust the DHCP server's available TCP connection > resources can compromise the ability of legitimate partners to > receive service. Malicious requestors who succeed in establishing > connections but who then send invalid messages, partial messages, > or no messages at all can also exhaust a server's pool of available > connections. > > DHCPv6 failover can operate in secure or insecure mode. Secure > mode (using TLS) would be indicated when the TCP connection between > failover partners is open to external monitoring or interception. > Insecure mode should only be used when the TCP connection between > failover partners remains within set of protected systems. Details > of such protections are beyond the scope of this document. > > The threats created by using failover directly mirror those from > using DHCPv6 itself: information leakage through monitoring, and > disruption of address assignment and configuration. Monitoring the > failover TCP connection provides no additional data beyond that > available from monitoring the interactions between DHCPv6 clients > and the DHCPv6 server. Likewise, manipulating the data flow > between failover servers provides no additional opportunities to > disrupt address assignment and configuration beyond that provided > by acting as a counterfeit DHCP server. Protection from both > threats is easier than with basic DHCPv6, as only a single TCP > connection needs to be protected. Either use secure mode to > protect that TCP connection or ensure that it can only exist with a > set of protected systems. > > When operating in secure mode, TLS [RFC5246] is used to secure the > connection. The recommendations in [RFC7525] SHOULD be followed > when negotiating a TLS connection. > > Servers SHOULD offer configuration parameters to limit the sources > of incoming connections through validation and use of the digital > certificates presented to create a TLS connection. They SHOULD > also limit the number of accepted connections and limit the period > of time during which an idle connection will be left open. > > Authentication for DHCPv6 messages [RFC3315] MUST NOT be used to > attempt to secure transmission of the messages described in this > document. If authentication is desired, secure mode using TLS > SHOULD be employed as described in Sections 8.2 and 9.1 of > [RFC7653] Thanks, that's exactly the sort of thing I was looking for. I will clear my discussion with the assumption that text will go into the draft. > > >> >> >> ---------------------------------------------------------------------- >> 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? >> >> > > The intent here is that each server tells the other server what > protocol version that it will be sending, and also has the > opportunity to accept or reject the version that that other server > is sending. As noted in Section 5.5.14, there is a major/minor > component to the protocol version. Each server is expected to have > a range of acceptable major (and, possibly, minor) versions on > reception. So, each server gets to see what the other server will > be sending and accept or reject the connection based on that > information. The secondary accepts or rejects that primary's > version, and the primary gets to do the same with the secondary. > > So, yes, they might send different versions to each other. Future > revisions of this document will define interoperability requirements > when new versions are created, the details can't be known at this > point. We just want to create a way to at least communicate the > information from the outset. > > I will add this Section 6.1.1 (for the primary sending CONNECT): > > o OPTION_F_PROTOCOL_VERSION containing the protocol version > that the primary server will use when sending failover messages. > > and this to Section 6.1.2 (for the secondary sending CONNECTREPLY): > > o OPTION_F_PROTOCOL_VERSION containing the protocol version being > used by the secondary server when sending failover messages. > > and this to Section 6.1.3 (primary receiving the CONNECTREPLY): > > o OPTION_F_PROTOCOL_VERSION - The primary server decides if the > protocol version in use by the secondary server is supported by > the primary server. If it is not, send a DISCONNECT message and > drop the connection. If it is supported, continue processing. > It is possible that the primary and secondary server will each > be sending different version of the protocol to the other > server. The extent to which this is supported will be in part > defined by as yet unknown differences in the protocols that the > versions represent, and in part by the capabilities of the two > implementations involved in the failover relationship. > That helps, thanks!