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

kkinnear <kkinnear@cisco.com> Tue, 31 January 2017 21:46 UTC

Return-Path: <kkinnear@cisco.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 1F25D129545; Tue, 31 Jan 2017 13:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.721
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 pSsyCU6hCpzz; Tue, 31 Jan 2017 13:46:17 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435891294A5; Tue, 31 Jan 2017 13:46:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3223; q=dns/txt; s=iport; t=1485899177; x=1487108777; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=g5SvjZ9CZObCMA9r5oXf0O6Tn68g960Op78cdgl2jro=; b=PMUSoGPkfHzihBJs1ThwtzQrEGYd5aZE5lceh9TFz3B8eJw014t7YzUA XU0sDM38U+vEH2mRNaejpulGSPYrIErxynvXP2KwJ9ymO/JPyQTJZbaFg TeX62JbQ+EDlxTrFYcJ0KrYgZq4duehjuTfYO5Z6G5xSo+R/Dwh2cN/Mz w=;
X-IronPort-AV: E=Sophos;i="5.33,316,1477958400"; d="scan'208";a="378989705"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2017 21:46:16 +0000
Received: from [161.44.67.129] ([161.44.67.129]) (authenticated bits=0) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v0VLkFWG002569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jan 2017 21:46:16 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: kkinnear <kkinnear@cisco.com>
In-Reply-To: <148589004659.5913.10170408064364078877.idtracker@ietfa.amsl.com>
Date: Tue, 31 Jan 2017 16:46:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <FB4D79AA-4297-4BD2-B7B1-A3FC5D3DED48@cisco.com>
References: <148589004659.5913.10170408064364078877.idtracker@ietfa.amsl.com>
To: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
X-Mailer: Apple Mail (2.3124)
X-Authenticated-User: kkinnear@cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/6yQKQzLHq-HpIxffpNzS8QAHVl4>
Cc: Bernie Volz <volz@cisco.com>, dhc-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, dhcwg@ietf.org, Kim Kinnear <kkinnear@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: Tue, 31 Jan 2017 21:46:19 -0000

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.
> 
> 2. The Security Considerations section says not to use Authentication
> from RFC3316.  SHould authentication instead be done within TLS or how
> will the session be authenticated.  Did I miss something?  I'm not
> finding the term authentication elsewhere in the draft and can infer
> things, but wanted to make sure since nothing is stated explicitly.
> 

	Interesting point.  Yes, if you care about authentication you
	should use TLS.  And the discussion on authentication in TLS
	is in Section 9.1 of the DHCPv6 Active Leasequery draft, RFC
	7653.  That section is not otherwise referenced here in the
	failover draft.  I will add the following to the end of the
	Security Considerations section, immediately after:

>>    Authentication for DHCPv6 messages [RFC3315 <https://tools.ietf.org/html/rfc3315>] MUST NOT be used to
>>    attempt to secure transmission of the messages described in this
>>    document.

	
	"If authentication is desired, TLS SHOULD be employed
	as described in Sections 8.2 and 9.1 of [RFC7653] <https://tools.ietf.org/html/rfc7653#section-8.2>."

	Thanks for catching this!

	Regards -- Kim