Hi Erik, All sounds good, apologies I missed the 05 posted the same day. Best wishes, Tim > On 14 May 2020, at 23:06, Erik Kline <ek.ietf@xxxxxxxxx> wrote: > > 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
