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.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Sunday, July 05, 2015 10:37 AM
> To: Warren Kumari; olafur at cloudflare.com; ebersman-ietf at dragon.net;
> steve.sheng at icann.org; General Area Review Team (gen-art at ietf.org); ops-
> dir at ietf.org
> Cc: ietf at ietf.org; dhcwg at 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 at emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------