Subject: [Captive-portals] Signals from the network and ICMP

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Apr 2018 20:14:50 +1000

Thanks to Lorenzo for kicking off the discussion about the desirable
properties of a signal from the network.

( Thread starts:
https://mailarchive.ietf.org/arch/msg/captive-portals/pYYQqxAzJp8ZVLtfu1QLqJdMiiM/?qid=7c89d24eec00ff0608ee5398c9bb9d33
)

The chairs have discussed this and would like to confirm the following
conclusions:

1. We don't have any current proposal for a signal that the group
deems suitable.  For now, we will remove pieces from the API and
architecture documents that specifically mention ICMP.

2. We will add a description of the properties we believe that a
signal should have to the architecture document, but note that no such
signal is defined.  That is, the signal will be sent by the network
when it believes that a UE should check with the API for updated
information.  The UE will treat that signal as a hint and may talk to
the API as a result.  Rate-limiting will likely be needed.

3. We will consider a proposal to define a signal in future.  That
would be a stand-alone proposal if it appeared.  To my reading, it is
within our charter to take on work like that, but we would probably
need to have a discussion with our AD at that point because we're
already past our milestones.

Does anyone disagree with these conclusions?  I don't think that this
completely rules out the use of ICMP, though Destination Unreachable
might not be an ideal fit as was discussed in London.

---

From: David Bird <[email-masked]>
Date: Sun, 15 Apr 2018 14:22:27 +0000

I, for one, disagree --

I believe the *risks* are that we: make network signaling optional, keep
going down the road of trying to solve network enforcement at an
Application layer, and ultimately just adding another way for Hotspots to
be "broken".

Just wanted to highlight a few comments made recently to the list
concerning ICMP:

"So using ICMP as hint and doing rate limited operatins based on that is
*acceptable*.
<https://www.ietf.org/mail-archive/web/captive-portals/current/msg00688.html>
"

"if authenticating ICMP messages would be easy there would already be
authentication in them :-)
<https://www.ietf.org/mail-archive/web/captive-portals/current/msg00679.html>
"

"I *agree* about viewing ICMP as a hint for the user equipment to visit the
API.
<https://www.ietf.org/mail-archive/web/captive-portals/current/msg00672.html>
"

David

On Fri, Apr 13, 2018 at 3:15 AM Martin Thomson <[email-masked]>
wrote:

> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Dave Dolson <[email-masked]>
Date: Sun, 15 Apr 2018 16:30:00 -0400

Having just re-read the thread, I disagree with this conclusion.

There was a discussion about ICMP security and the conclusion that 
treating it as a hint to consult the API (rate limited) renders spoofed 
ICMP messages harmless.

There was a discussion about whether alerts might be generated before 
the portal closes, which I think is feature creep.

There was also a discussion about net neutrality (which parts of the 
internet might be reachable), which seems orthogonal to mechanism.

So I would like to know on what basis the chairs find ICMP unsuitable?

-Dave

---

From: Erik Kline <[email-masked]>
Date: Tue, 1 May 2018 12:55:53 +0900

I was unable to make it to London, but I was able to watch the session
on Youtube.  The ICMP discussion begins here:

    https://www.youtube.com/watch?v=tavhoXNVcP8&t=1h12m5s

and carries on until Darshak's presentation starts at t=1h45m35s (a
good 30+ minutes).

My reading of that portion of the session was not that ICMP was
"unsuitable", but rather that there wasn't consensus in the room to
move forward with anything in particular at that time--other than a
discussion about requirements (i.e. the thread to which Martin
linked).

I would say the aim here was to "unhook" the ICMP discussion from the
other work (architecture-cum-API), so both could proceed at their
relative paces.

<chair_hat="off">

There seemed to be much mic discussion about host behavior (possibly
caching destination unreachables, the applicability of admin
prohibiteds).  I wonder if we are in need of some kind of broader
input on / more discussion of current popular OS behavior.

On 16 April 2018 at 05:30, Dave Dolson <[email-masked]> wrote:
> There was a discussion about ICMP security and the conclusion that treating
> it as a hint to consult the API (rate limited) renders spoofed ICMP messages
> harmless.
>
> There was a discussion about whether alerts might be generated before the
> portal closes, which I think is feature creep.
>