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!