Thank you David. On 7/5/15 7:36 AM, Black, David wrote: > 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@xxxxxxx Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > >
Attachment:
signature.asc
Description: OpenPGP digital signature