[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 3 May 2018 at 22:21, Michael Richardson <[email protected]> wrote:
> Martin Thomson <[email protected]> wrote:
>     > On Wed, May 2, 2018 at 10:06 PM Michael Richardson <[email protected]>
>     > wrote:
>     >> Have we considered TCP RST already? (I don't think it's better than ICMP,
>     >> but
>     >> I don't remember it being discussed yet)
>     > We can now if you like.  But not all protocols use TCP.
> Yes, that's true, but essentially all of the "am I behind a captive portal"
> probes do, and in the most restrictive places, that's all that works anyway.
> We don't need every protocol to detect the captive portal, so long as *some*
> method does.

We really need to consider not just the likely traffic mix "on first
attach" as it stands today but also (a) changes in traffic mix in the
future and (b) signaling on "steady-state" traffic when a captive
portal re-asserts itself after session expiry (or on reboot / loss of
state at the enforcement point).

In the latter case especially, what becomes clear is that the UE needs
to be able to receive an unsolicited packet.  ICMP is a canonical
example of receiving and processing an unsolicited packet.  But it
could also be something like a UDP socket listening on a well known
port that receives a 1-byte datagram, which causes the UE to enqueue
(for rate-limiting purposes) a captive API query.

Naively, my expectation for a simple Android implementation was
something along the lines of:

    [1] on network attach, create an ICMP socket (or 2, one each for
v4 and v6) and attach a filter to only get messages of the right type
or code or whatever we decide.

    [2] when a matching packet arrives, lob a message over to
NetworkMonitor (which houses the captive portal checking logic).

    [3] NetworkMonitor already rate limits requests from applications
to revalidate the network, and these would likely be no different (or
pretty much the same).

Since the UE expected action, I'm assuming, would be to reconnect to
the API I'm not sure I see the benefit of any interaction more complex
than this.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature