Re: [Captive-portals] Opsdir last call review of draft-ietf-capport-rfc7710bis-04

[Erik Kline <[e-mail]>]

Tim,

Thanks for taking the time to read and comment.  Replies inline below
and changes made at https://github.com/capport-wg/7710bis .

On Thu, May 14, 2020 at 7:30 AM Tim Chown via Datatracker
<[e-mail]> wrote:
>
> Reviewer: Tim Chown
> Review result: Has 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.

As part of feedback from a security review we've added text and
references to RA Guard and DHCP Shield.

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

The PVD doc is in the editors' queue.

> Nits:
>
> Abstract:
>
> * Clarify that the document describes and DHCPv4 and DHCPv6 option.

done

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

done

> * 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.“

sounds good; done

> * 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.”

also good; done

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

changed to 2131 for DHCPv4 and 8415 for DHCPv6 (3315 was obsoleted by 8415).

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

done

> Section 2:
>
> “Implement the interception” -> “implement interception”

done

> Section 3:
>
> Second paragraph, is that a “should be logged” or “SHOULD be logged”?

No strong feelings either way, since it's a device behaviour that no
user will probably ever see.  Went with SHOULD.