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 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: 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. _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
