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

[kkinnear <[e-mail]>]

Ben,

Thanks for the review.  My comments are indented below.

> On Jan 31, 2017, at 6:30 PM, Ben Campbell <[e-mail]> wrote:
> 
> 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.

  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]


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

Again, thanks for the review.

Kim