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

["Ben Campbell" <[e-mail]>]

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!