Re: [Captive-portals] Review of draft-wkumari-capport-icmp-unreach-01

[David Bird <[e-mail]>]

I've updated the draft to -02 - sorry for not doing so sooner.

Contributors (and co-authors) welcome!


On Sat, Apr 1, 2017 at 1:40 PM, Martin Thomson <[e-mail]>
wrote:

> (As a contributor only.)
>
> David, Warren,
>
> Looking at this draft, I think that there are a few fairly major
> changes that this could benefit from.
>
> # Extension payload
>
> The presence of the extension is sufficient signaling for this channel.
>
> If we accept that there will be a protocol for asking the portal for
> basic information about connectivity, the UE/device/etc can query that
> interface for expiration time.
>
> The warning bit seems dangerous in this context given that it
> establishes a non-backwards-compatible behaviour.  To an entity that
> doesn't understand this extension, ICMP Unreachable means that the
> packet was not forwarded.  I don't think that an extension can safely
> change this.
>
> The one obvious caveat for this comment is if we determine that RFC
> 7710 is insufficient for advertisement of the captive portal URL.  In
> that case, we might consider adding the URL to the ICMP message.  I
> don't see any evidence that this is necessary yet, and that would
> compound the next issue, but it's something to consider.
>
> # Security considerations
>
> There is a fairly direct path between this message and a user visiting
> the site identified.  Now, it is well-accepted that it is easy to
> cause a user to visit any site, but nonetheless this needs to be
> discussed.  We can also offer some suggestions for reducing the use of
> this message by arbitrary endpoints.  For example, a device that
> receives this message might not act immediately, but instead trigger
> portal detection routines before opening a browser.  Those routines
> might involve sending more packets and looking for more ICMP
> unreachable packets.
>
> For this reason, I think that we should mandate the use of RFC 4884
> and a minimum size for the echo of the dropped packet.
>