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

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

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?


On 2018-04-13 6:14 AM, Martin Thomson wrote:
Thanks to Lorenzo for kicking off the discussion about the desirable
properties of a signal from the network.

( Thread starts:

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

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.

Captive-portals mailing list
[email protected]