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

[Kathleen Moriarty <[e-mail]>]

On Thu, Feb 2, 2017 at 3:22 PM, kkinnear <[e-mail]> wrote:
> 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.

Yes, thank you.  This is very helpful and can be referenced in future drafts.

Best regards,
Kathleen

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



-- 

Best regards,
Kathleen