Re: [dhcwg] Kathleen Moriarty's No Objection on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with COMMENT)

[kkinnear <[e-mail]>]

Kathleen,

See my response below, inline...

> On Feb 2, 2017, at 3:07 PM, Kathleen Moriarty <[e-mail]> wrote:
> 
> Hi Kim,
> 
> Thanks for your response, inline.
> 
> On Tue, Jan 31, 2017 at 4:46 PM, kkinnear <[e-mail]> wrote:
>> Kathleen,
>> 
>> Thanks for your comments.  My responses are indented below.
>> 
>>> On Jan 31, 2017, at 2:14 PM, Kathleen Moriarty <[e-mail]> wrote:
>>> 
>>> Kathleen Moriarty 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 have 2 questions that I would like to chat about and should be easy
>>> enough to resolve.
>>> 
>>> 1. I know we've discussed in the past why there is no MUST for TLS and it
>>> having to do with DHCPv6 use on private networks or isolated.  Is there
>>> text in one of the more recent RFCs that covers this explanation that can
>>> be cited?  I'd like to make sure that's enough too.
>> 
>>        To the best of my knowledge the justifications for both a secure
>>        and an insecure mode have been kept out of the RFC's themselves,
>>        and are scattered over a variety of issues raised for different
>>        drafts.  A pretty succinct summary came from you for the DHCPv4
>>        Active Leasequery draft (the bottom of this page):
>> 
>>        https://datatracker.ietf.org/doc/rfc7724/ballot/ <https://datatracker.ietf.org/doc/rfc7724/ballot/>
>> 
>>        I can go back to the email surrounding the DHCPv6 Active Leasequery
>>        draft and try to pull that together into something longer, but
>>        essentially it is going to say pretty much what you have summarized
>>        at the above URL.
> 
> Hmm, it's too bad nothing has been documented on this, can we fix that
> for future draft references?
> 

	Subsequent to our discussion, I have added the following to
	the Security Considerations section at the behest of Ben
	Campbell:

   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 [a] 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] <https://tools.ietf.org/html/rfc7653#section-9.1>
   to decide to use or not to use TLS when connecting with the failover
   partner.

   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.

	I hope that helps.

	Here is the entire Security Considerations section in the
	-05 version of the draft (which is maybe 90 minutes old):

https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-protocol-05#page-88 <https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-protocol-05#page-88>

	I also just noticed a typo in the first new paragraph which I
	will fix at the next opportunity.

	Thanks -- Kim