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 <noreply@xxxxxxxx> 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
