On Tue, Sep 1, 2015 at 2:22 PM, Black, David <david.black@xxxxxxx> wrote: > The -16 version looks good, Thanks, --David > Thank you, and apologies again for missing them the first time. W >> -----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 -- 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