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, 02 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
- [dhcwg] Kathleen Moriarty's No Objection on draft… Kathleen Moriarty
- Re: [dhcwg] Kathleen Moriarty's No Objection on d… kkinnear
- Re: [dhcwg] Kathleen Moriarty's No Objection on d… Kathleen Moriarty
- Re: [dhcwg] Kathleen Moriarty's No Objection on d… kkinnear
- Re: [dhcwg] Kathleen Moriarty's No Objection on d… Kathleen Moriarty