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

[Martin Thomson <martin.thomson@gmail.com>]

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