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

[Tim Chown <[e-mail]>]

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 <[e-mail]> 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
> <[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.
>