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