Re: [Gen-art] Gen-ART and OPS-Dir review of draft-wkumari-dhc-capport-13

[joel jaeggli <[e-mail]>]

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
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 
>