[dhcwg] Gen-ART and OPS-Dir review of draft-wkumari-dhc-capport-15

"Black, David" <david.black@emc.com> Fri, 28 August 2015 22:06 UTC

Return-Path: <david.black@emc.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7454B1B3490; Fri, 28 Aug 2015 15:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id exXwZe5-ycHk; Fri, 28 Aug 2015 15:06:42 -0700 (PDT)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ECCD1B3480; Fri, 28 Aug 2015 15:06:41 -0700 (PDT)
Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com []) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t7SM6AaW017312 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Aug 2015 18:06:14 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t7SM6AaW017312
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1440799574; bh=+zlNPW3YQKPC6yPT73bUUiF6YZo=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=VNx1Nzru5VK3mqQtTfgVr4auTFG5M60eCTJw998fgF/B9onsOhb3FIHxTzD87DDBR CQMdAQamdAj4eZChYrnFwgByMHF+ynGyZQR6U/u7TBb/ecV/XXFV71fnfkVqf9lAH0 cOmtXRl33r+ePrzgXj37qkT69N/buHxo+ht/23yo=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t7SM6AaW017312
Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com []) by maildlpprd01.lss.emc.com (RSA Interceptor); Fri, 28 Aug 2015 18:05:20 -0400
Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com []) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t7SM5S73001512 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Aug 2015 18:05:28 -0400
Received: from MXHUB105.corp.emc.com ( by mxhub18.corp.emc.com ( with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 28 Aug 2015 18:05:28 -0400
Received: from MX104CL02.corp.emc.com ([]) by MXHUB105.corp.emc.com ([]) with mapi id 14.03.0224.002; Fri, 28 Aug 2015 18:05:27 -0400
From: "Black, David" <david.black@emc.com>
To: Warren Kumari <warren@kumari.net>, "olafur@cloudflare.com" <olafur@cloudflare.com>, "ebersman-ietf@dragon.net" <ebersman-ietf@dragon.net>, "steve.sheng@icann.org" <steve.sheng@icann.org>, "General Area Review Team (gen-art@ietf.org)" <gen-art@ietf.org>, "ops-dir@ietf.org" <ops-dir@ietf.org>
Thread-Topic: Gen-ART and OPS-Dir review of draft-wkumari-dhc-capport-15
Thread-Index: AdDh3aUMKZyuQxPoTs6OQPcV693y0Q==
Date: Fri, 28 Aug 2015 22:05:27 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949361407B7BB@MX104CL02.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com
X-RSA-Classifications: public, Resumes
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/IDciuITxcMsTCjZJi1oiCxHLP7k>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "Black, David" <david.black@emc.com>, "ietf@ietf.org" <ietf@ietf.org>
Subject: [dhcwg] Gen-ART and OPS-Dir review of draft-wkumari-dhc-capport-15
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 28 Aug 2015 22:06:44 -0000

The Gen-ART and OPS-Dir review of the -13 version of this draft does not
appear to have been directly addressed in the -15 version.

Of the 5 minor issues, other changes have addressed issue [4] and the
first part of issue [5] (first chunk of quoted text).  In addition, it's
ok to treat issue [1] as editorial.

That leaves minor issues [2], [3] and the second part of [5] (second chunk
of quoted text) as topics that still merit attention, and I would like the
authors to consider adding the suggested additional security consideration.


> -----Original Message-----
> From: Black, David
> Sent: Sunday, July 05, 2015 10:37 AM
> To: Warren Kumari; olafur@cloudflare.com; ebersman-ietf@dragon.net;
> steve.sheng@icann.org; General Area Review Team (gen-art@ietf.org); ops-
> dir@ietf.org
> Cc: ietf@ietf.org; dhcwg@ietf.org; Black, David
> Subject: Gen-ART and OPS-Dir review of draft-wkumari-dhc-capport-13
> This is a combined Gen-ART and OPS-Dir review.  Boilerplate for both follows
> ...
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at:
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> Please resolve these comments along with any other Last Call comments
> you may receive.
> I have reviewed this document as part of the Operational directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments
> were written primarily for the benefit of the operational area directors.
> Document editors and WG chairs should treat these comments just like any other
> last call comments.
> Document: draft-wkumari-dhc-capport-13
> Reviewer: David Black
> Review Date: July 5, 2015
> IETF LC End Date: July 7, 2015
> Summary:  This draft is on the right track, but has open issues
>  		described in the review.
> This draft specifies DHCP (v4 and v6) and IPv6 RA options to provide the
> contact URI of a captive portal (e.g., for a WiFi hotspot).  It's a
> short draft that gets the job done - I found a few minor issues, and
> have an additional security consideration to suggest.
> Major issues: None
> Minor issues:
> [1] Section 2:
>    captive portals will still need to implement the
>    interception techniques to serve legacy clients, and clients will
>    need to perform probing to detect captive portals.
> Please explain what "the interception techniques" and "probing" are.
> I think this material was in -12 and removed for -13 - it does not need
> to be restored in its entirety, but those two terms deserve some
> explanation.  This should also explain "DNS interception" in the last
> paragraph in the section.
> [2] Section 2.1 - DHCPv4 has the shortest URI length limit, 255 bytes.
> That should be noted either here or in Section 2 in discussion of serving
> multiple classes of clients.  This should not be a problem in practice.
> [3] Sections 2.1, 2.2, 3: The term "URI of the authentication page" should
> be changed to something like "contact URI for the captive portal" because
> authentication is not always required by a captive portal.
> [4] Section 4: The IANA Considerations section is incomplete - see IANA's
> review.
> [5] Section 5:
>    Fake
>    DHCP servers / fake RAs are currently a security concern - this
>    doesn't make them any better or worse.
> Please cite a reference for this, preferably with operational recommendations
> on limiting these problems (e.g., ensure that DHCP and RA traffic cannot be
> injected from outside/beyond the network that is relevant to the portal).
>    Redirection to a portal where TLS can be used
>    without hijacking can ameliorate some of the implications of
>    connecting to a potentially malicious captive portal.
> Please explain who or what does the redirection and what is redirected
> (browser, VPN client?).  Is this a suggestion to use http:// URLs? (if
> so, that should be said explicitly).
> Nits/editorial comments:
> p.3, first sentence:
>    This document describe a DHCP ([RFC2131]) option (Captive Portal) and
> s/describe/describes
> I would add a sentence to section 2 to say that URI strings are not
> null-terminated.
> Section 3 - this should be renumbered to 2.3, as the overview text in
> Section 2 applies to the RA option.
> Possible additional security consideration:
> Captive portals are increasingly hijacking TLS connections to force
> browsers to talk to the portal.  Providing the portal's URI via a DHCP
> or RA option is a cleaner technique, and reduces user expectations of
> being hijacked - this may improve security by making users more reluctant
> to accept TLS hijacking, which can be performed from beyond the network
> associated with the captive portal.
> --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---
> Most of these questions reduce to the corresponding questions for DHCP
> or IPv6 RAs.  Once the portal is contacted, there are significant
> operational considerations that are well outside the scope of this
> draft.
> A.1.3  Has the migration path been discussed?
> 	Yes, briefly.  Minor issue [1] requests more information on
> 	existing techniques, with which coexistence is anticipated.
> A.3.  Documentation
> 	An operational considerations or manageability section isn't
> 	called for.  I do not expect the options in this draft to
> 	have significant operational impact.
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------