Subject: [dhcwg] Stephen Farrell's No Objection on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 01 Feb 2017 17:33:47 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-dhc-dhcpv6-failover-protocol-04: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I support Ben's discuss about "secure mode" - a few
more details are needed, in particular how a pair
decide to use/not-use TLS - are there different ports
or a STARTTLS equivalent - I can't see that defined
here. (Is it inherited from RFC7653? If so, maybe you
need to say?)

- For the DNS update stuff - is there no need to use
TSIG secrets? If there is, how is that sync'd between
the pair of DHCP servers?  If it is sync'd then don't
you need to say that TLS is a MUST for such
connections? If there is no support for TSIG, is that
likely to work?

---

From: kkinnear <[email-masked]>
Date: Thu, 2 Feb 2017 10:28:13 -0500

Stephen,

Thanks for your review!

I've responded to your comments, indented, below...

> On Feb 1, 2017, at 8:33 PM, Stephen Farrell <[email-masked]> wrote:
> 

	Yes, Section 9.1 of RFC 7653 discusses exactly this issue (in
	part due to your review comments from July 2015, as it
	happens).  I believe the discussion there is sufficient.

	I substantially enhanced the Security Considerations section
	as a result of Ben Campbell's comments.  One paragraph that I
	added discussed secure and insecure mode.  I will expand that
	paragraph to point in more detail towards RFC 7653 as follows:

  "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.  Failover
  servers MUST use the approach documented in Section 9.1 of [RFC7653]
  to decide to use or not to use TLS."

> connections? If there is no support for TSIG, is that

	Surely, TSIG is important.  Each DHCP server in a failover
	pair has its own relationship with the relevant DNS servers,
	and needs to be configured with the correct TSIG secrets to
	update those DNS servers.  The configuration of a DHCP server
	to communicate with a DNS server is a configuration issue, and
	outside of the scope of the failover protocol.  

	In the (now blessedly distant) past, we spent years working on
	the DHCPv4 failover protocol trying to shoehorn configuration
	information into the protocol, and it never worked.  DHCP
	servers need *lots* of configuration, and we have most
	consciously decided that synchronizing that configuration
	between failover partners is not the purpose of the DHCPv6
	failover protocol.

Thanks again for your review!

Kim

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Feb 2017 15:30:59 +0000

Hi Kim,

> 	between failover partners is not the purpose of the DHCPv6

Thanks - that'd have helped me as a reader but if implementers
would know it for sure, then I guess it's fine as-is.

Thanks,
S.

---

From: kkinnear <[email-masked]>
Date: Thu, 2 Feb 2017 13:58:25 -0500

I have submitted a new version of the DHCPv6 Failover Protocol:

  draft-ietf-dhc-dhcpv6-failover-protocol-05

https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ <https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/>

which reflects changes resulting from the IESG and directorate reviews
to date.  All of these changes are to explain things more clearly or
explicitly.  None of them alter the intended operation of the
protocol.

  * Added a sentence at the end of the Security Considerations
    section saying that if authentication of failover partners is
    desired, that TLS SHOULD be employed. [Kathleen Moriarty]

  * Significantly expanded the Security Considerations section to
    discuss some of the threats and when you might use secure and
    insecure mode.  [Ben Campbell]

  * Added clarification as to the use of the OPTION_F_PROTOCOL_VERSION
    option in the CONNECT and CONNECTREPLY message. [Ben Campbell]

  * Added information at the beginning of the Introduction
    describing the failover protocol and pointing to the DHCPv6
    Failover Requirements, RFC 7031. [Christer Holmberg]

  * Included a reference to RFC 3315 when the DHCPv6 server is first
    mentioned.  [Christer Holmberg]

  * Removed the term "DHCP service" from the Introduction as well
    as one other section of the draft, replacing it with "a service to
    DHCP clients". [Christer Holmberg]

  * Added text to the beginning of Section 4 Failover Concepts and
    Mechanisms, that clarifies that these concept and mechanisms are
    not present in RFC 3315, are required for failover, and are
    supported by the failover protocol. [Christer Holmberg]

  * Changed all instances of "this protocol" to be "the failover
    protocol".  [Christer Holmberg]

  * Added a pointer in the Security Considerations section to Section
    9.1 of RFC7653 which describes how two DHCPv6 servers can decide
    to use or not use TLS when connecting. [Stephen Farrell]

  * Added a paragraph in Section 6, Connection Management giving
    an overview of how connections are created and used by the
    failover protocol.  [Mirja Kuhlewind]

Regards -- Kim

---

From: kkinnear <[email-masked]>
Date: Mon, 27 Feb 2017 16:50:38 -0500

draft-ietf-dhc-dhcpv6-failover-protocol-06

which reflects the final changes resulting from the IESG and
directorate reviews to date.  All of these changes are to explain
things more clearly or explicitly.  None of them alter the intended
operation of the protocol.

The first two changes resulted from a COMMENT by Mirja Kuhlewind.

* Expanded the first occurrence of the use of MAX_UNACKED_BNDUPD
  in Section 6.1.1 "Sending a CONNECT message", from the current:

>   o  OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of BNDUPD
>      messages that this server is prepared to accept over the failover
>      connection without causing the connection to block.

  to the following:

  o  OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of BNDUPD
     messages that this server is prepared to accept over the failover
     connection without causing the connection to block.  This is to
     implement application level flow control over the connection, so
     that a flood of BNDUPD messages does not cause the connection to block
     and thereby prevent other messages from being transmitted 
     over the connection and received by the failover partner.

* Changed the second place where OPTION_F_MAX_UNACKED_BNDUPD
  is transmitted in Section 6.1.2 "Receiving a CONNECT message", where
  it discusses creating a CONNECTREPLY message, to say the same thing
  as above (as it currently has the same "current" text).

* Fixed several typographical errors observed while making the above
  changes (OPTION_F_MAX_UNACKED_BNDUPD was referenced as
  OPTION_F_UNACKED_BNDUPD).

* Added a missing "a" in recently added paragraph in Security
  Considerations section.

Regards -- Kim