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

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



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 protected]> wrote:
> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/captive-portals
>
>
> _______________________________________________
> Captive-portals mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/captive-portals

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