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

kkinnear <> Thu, 02 February 2017 20:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 949F812954A; Thu, 2 Feb 2017 12:22:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.721
X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YXIYCTKdwmrh; Thu, 2 Feb 2017 12:22:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6B1E1294FB; Thu, 2 Feb 2017 12:22:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4739; q=dns/txt; s=iport; t=1486066942; x=1487276542; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=iUYhU0CSSoBb2hKfuhZml33sgyErwnPE0CZJ9KyH+u4=; b=GSejmRBDJw3okGhDLwC3Lg79DKUONFUvJtjEtWfpDr8Rd7GRssnkVyNu t4aN7Ug3rbi6FBp0JK0OhSWWxiKYLw148RCp4Wk0dWEGri4rA3xnMAatP OYjINqsthve1EzMpfST0l4Fxr4ldH33q8KxGovabrYtbOjxKEZT9IF/6E k=;
X-IronPort-AV: E=Sophos;i="5.33,326,1477958400"; d="scan'208";a="379170464"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2017 20:22:22 +0000
Received: from [] ([]) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id v12KMLnh031703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2017 20:22:21 GMT
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: kkinnear <>
In-Reply-To: <>
Date: Thu, 2 Feb 2017 15:22:21 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Kathleen Moriarty <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: Bernie Volz <>, "<>" <>, The IESG <>,, "<>" <>, Kim Kinnear <>
Subject: Re: [dhcwg] Kathleen Moriarty's No Objection on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Feb 2017 20:22:24 -0000


See my response below, inline...

> On Feb 2, 2017, at 3:07 PM, Kathleen Moriarty <> wrote:
> Hi Kim,
> Thanks for your response, inline.
> On Tue, Jan 31, 2017 at 4:46 PM, kkinnear <> wrote:
>> Kathleen,
>> Thanks for your comments.  My responses are indented below.
>>> On Jan 31, 2017, at 2:14 PM, Kathleen Moriarty <> 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
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> The document, along with other ballot positions, can be found here:
>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> 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):
>> <>
>>        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

   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] <>
   to decide to use or not to use TLS when connecting with the failover

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

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

	Thanks -- Kim