Last Call Review of draft-ietf-capport-rfc7710bis-04
review-ietf-capport-rfc7710bis-04-opsdir-lc-chown-2020-05-14-00

Hi,

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 with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document describes IPv4 DHCP, IPv6 DHCP and IPv6 RA options to indicate to
hosts that they are behind some form of captive portal, and to convey the
associated API endpoint with which they can communicate to establish wider
network access. It updates RFC7110, which turned out to be using a DHCP
codepoint that was already in use).

The draft is part of the capport WG’s initiative to provide a more consistent
and robust mechanism for hosts, such as those in WiFi hotspots, to determine
when a captive portal is in place, and how they might negotiate / authenticate
with that portal.

The text is well-written and describes the IPv4 DHCP, IPv6 DHCP and RA option
formats clearly.  I would say that the draft is Ready with Nits.

General comments:

The security considerations (Section 5) talk of potential spoofed DHCP or RA
captive portal option messages; equally an attacker could use a rogue RA or
DHCP message to convey (for example) a bad DNS server option, which could
direct a client to a bad captive portal endpoint.  So the document should
probably state that there is an assumption of RFC 6105 (RA Guard) or equivalent
measures being in place; whether such a capability is realistic in a coffee
shop scenario is another question.

I also wonder how commonly multiple provisioning domain scenarios will arise
for school network access, where a client may see multiple captive portals. I
note that draft-ietf-intarea-provisioning-domains-04 seems to have expired, so
I’m not clear whether that initiative has been dropped; it seemed to have good
potential.

Nits:

Abstract:

* Clarify that the document describes and DHCPv4 and DHCPv6 option.

* Remove the parantheses from the RA option text; these are “equal” options.

* Perhaps rewrite “it is designed to be used in larger solutions“ to “it is
designed to be one component of a standardised approach for hosts to interact
with such portals.“

* And perhaps rewrite “The method of authenticating to, and interacting with
the captive portal is out of scope of this document.” to “While this document
defines how the network operator may convey the captive portal API endpoint to
hosts, the specific methods of authenticating to, and interacting with the
captive portal are out of scope of this document.”

Section 1:

* This cites RFC 2131 for DHCP; I’d suggest citing RFC 3315 and RFC 8415 and
emphasising that there are options for DHCP for IPv4 and DHCPv6.

* It also says “how to contact an API”; probably better to say “the API
endpoint that the host can contact” as the “how” is out of scope for this
document.

Section 2:

“Implement the interception” -> “implement interception”

Section 3:

Second paragraph, is that a “should be logged” or “SHOULD be logged”?

--
Tim