Last Call Review of draft-wkumari-dhc-capport-13
review-wkumari-dhc-capport-13-genart-lc-black-2015-07-07-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-wkumari-dhc-capport-13-genart-lc-black-2015-07-07

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