The -16 version looks good, Thanks, --David > -----Original Message----- > From: Warren Kumari [mailto:warren@xxxxxxxxxx] > Sent: Monday, August 31, 2015 12:07 PM > To: Black, David > Cc: olafur@xxxxxxxxxxxxxx; ebersman-ietf@xxxxxxxxxx; steve.sheng@xxxxxxxxx; > General Area Review Team (gen-art@xxxxxxxx); ops-dir@xxxxxxxx; ietf@xxxxxxxx; > dhcwg@xxxxxxxx > Subject: Re: Gen-ART and OPS-Dir review of draft-wkumari-dhc-capport-15 > > On Fri, Aug 28, 2015 at 6:05 PM, Black, David <david.black@xxxxxxx> wrote: > > 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. > > > > Apologies, David, no sure how we missed those. I think I got > sidetracked while trying to address the first part of [5] and never > came back to [2], [3]. > > [2]: I added (new text in '***' : > The captive portal operator should ensure that the URIs handed out are > equivalent to reduce the chance of operational problems. ***The > maximum length of the URI that can be carried in IPv4 DHCP is 255 > byte, and so URIs longer than 255 bytes should not be used in IPv6 > DHCP or IPv6 RA.*** > > I'm not in love with this text, but not sure how to make it better. > Implementers don't *have* to use the same URI in all protocols, and so > I guess they could decide to use longer than 255 octets in DHCPv6 if > they were sufficiently pathological. > > [3]: Done. Thanks for providing text. > > > [5]: > > "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." > This was a cut and paste from an email. > I'm rewording it to: > "By handing out a URI using which is protected with TLS, the captive > portal operator can attempt to reassure the user that the captive > portal is not malicious." > > > The original text was provided by Joel -- I'm assuming that the > rewording capture what he was attempting to say. David, does this > address your comment? And Joel, does it (still) convey what you were > saying? > > > > > Additional: > > Thank you for the text - I added (to security considerations): > 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. > > Nits: > s/describe/describes/ - done (in earlier rev). > > Mentioned that the URI is not null terminated. > > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Black, David > >> Sent: Sunday, July 05, 2015 10:37 AM > >> To: Warren Kumari; olafur@xxxxxxxxxxxxxx; ebersman-ietf@xxxxxxxxxx; > >> steve.sheng@xxxxxxxxx; General Area Review Team (gen-art@xxxxxxxx); ops- > >> dir@xxxxxxxx > >> Cc: ietf@xxxxxxxx; dhcwg@xxxxxxxx; 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@xxxxxxx Mobile: +1 (978) 394-7754 > >> ---------------------------------------------------- > > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf