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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 02 February 2017 21:41 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B7B1294B6; Thu, 2 Feb 2017 13:41:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuMQKb1kAXev; Thu, 2 Feb 2017 13:41:38 -0800 (PST)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A14E129431; Thu, 2 Feb 2017 13:41:38 -0800 (PST)
Received: by mail-qt0-x231.google.com with SMTP id k15so1647620qtg.3; Thu, 02 Feb 2017 13:41:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qu9kX7QNQIjyhQ18SdWYAqeIeK93EjSTWEWVm5OrT0E=; b=mkPUsvABUDr3wLXuV/EvSWM4IeR0TT9b4JpqmVnY1boz6Lr397L9N6ZvPykCIX7/+h vboDhpFE5yOuXn65/931mRY6erOzXIUoQAJsIn7BNtMiDSqv2/oB3V8KQcNMDa4NZ/hY ltH+60bxH07eGXvls6oV09D16afcSP8+nZZkAcWjqwVWsFdIyW3XNCv6umTqHr98iI3p N1+oY9paTdcAyxvTYLgjmo4d5kmMlm4CuJ6jftqXBvNJJLtY/QLauPh7Bjk+5QTQIzBh fr/rEzrHoaFDBBWiBqi/w7Gs0/KHaTXz6LtSbJ9YKlqfPqoKkJh3RR2b7JxfUXCh/hz4 +VrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qu9kX7QNQIjyhQ18SdWYAqeIeK93EjSTWEWVm5OrT0E=; b=g4rDk+WdWKdi5jJdEfIqJEhmQnsZPUf1uzgMYUPZTbof0ioA1h+gvhFgZbc4OnJmqU Bju0725Hvwl4h0tj9dXKmBZ2Aax8OkBPc9mOwDHFlNLaVyfllYFGYpMBh/3EtRqInzti kLrH7rWUVK260DhHIczHIWJz38LLCLa6TlN9tXqsrNJfpBLyg0jlQj0RkCtqM6NpYLUQ fGXyTS/O7treF4x0Gm+dG0cU3RO6kuTvADMECoJJWZRFhSE1OQwLNdzMdyEkyCz6zKaE EbYuRJfNbjn1rCr/kcGeL+2KmzqT+oe+PSgDxBtES3IRQ45rWC6hR6nOUqp7P8vnM7F/ IEcw==
X-Gm-Message-State: AIkVDXL7OzGMmMpkLS5+9Tnmteuz33+xEM8723g78uycZ4017ncV/K3NfU8kI9ZLLnxBiQ/3tPupyDu+r13YbQ==
X-Received: by 10.237.41.36 with SMTP id s33mr9812196qtd.139.1486071697404; Thu, 02 Feb 2017 13:41:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.170.30 with HTTP; Thu, 2 Feb 2017 13:41:37 -0800 (PST)
In-Reply-To: <BCCE05CC-E36A-42EB-BDEF-90619B7E03B4@cisco.com>
References: <148589004659.5913.10170408064364078877.idtracker@ietfa.amsl.com> <FB4D79AA-4297-4BD2-B7B1-A3FC5D3DED48@cisco.com> <CAHbuEH6Mkw3a2u8OW9Ry4VnL6fKJptrMDngvLv5yku2X_fkJ2A@mail.gmail.com> <BCCE05CC-E36A-42EB-BDEF-90619B7E03B4@cisco.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Thu, 2 Feb 2017 16:41:37 -0500
Message-ID: <CAHbuEH4Gu=mYwuPwuvzXOHs_T90TmybA2k3pwLupKyi_FW_2bw@mail.gmail.com>
To: kkinnear <kkinnear@cisco.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/VaO8IUv0dDDcO1v8WxUBxjVRaG0>
Cc: "<dhc-chairs@ietf.org>" <dhc-chairs@ietf.org>, "<dhcwg@ietf.org>" <dhcwg@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, Bernie Volz <volz@cisco.com>
Subject: Re: [dhcwg] Kathleen Moriarty's No Objection on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Feb 2017 21:41:40 -0000

On Thu, Feb 2, 2017 at 3:22 PM, kkinnear <kkinnear@cisco.com>; wrote:
> Kathleen,
>
> See my response below, inline...
>
>> On Feb 2, 2017, at 3:07 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; wrote:
>>
>> Hi Kim,
>>
>> Thanks for your response, inline.
>>
>> On Tue, Jan 31, 2017 at 4:46 PM, kkinnear <kkinnear@cisco.com>; wrote:
>>> Kathleen,
>>>
>>> Thanks for your comments.  My responses are indented below.
>>>
>>>> On Jan 31, 2017, at 2:14 PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>; 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