Re: [Captive-portals] Requirements for "captive portal closed" notifications

Likewise, I'm not saying the API can't play a role either (especially in
verifying / confirming ICMP) ...

My biggest concern with the API providing this kind of notification,
instead of the NAS/network, is that the API can so very easily be wrong or
misinformed - especially when you consider how some hotspots may have
multiple RADIUS servers because of roaming partners and the like. Sure, it
requires "more work" to get the ICMP feature plumbed through a hotspot
architecture (e.g. RADIUS client updates, development required, etc). But,
that is *good* that all that must take place before the feature can be
used... opposed to creating an API with these features and worrying about
the network integration later (with a broken network in the meantime). By
"broken" ... I mean a network that works fine with older devices, just
generating a lot of complaints from UE users with the new Capport enabled
UE devices...

On Tue, Mar 20, 2018 at 10:29 AM Pierre Pfister <pierre.pfister@darou.fr>
wrote:

>
>
> Le 20 mars 2018 à 17:06, David Bird <dbird@google.com> a écrit :
>
>
>
> On Tue, Mar 20, 2018, 9:56 AM Pierre Pfister <pierre.pfister@darou.fr>
> wrote:
>
>> Turning the requirements around I would add that sending ICMP messages
>> based on a session being ‘almost done’ might be challenging from a
>> router/hardware perspective. Routers might have to rate-limit such
>> messages, and sometimes fail to send them.
>>
>
> My feeling is just the opposite.. the NAS knows perfectly when it will or
> will not hold a session captive. If that NAS is being told what to do (e.g.
> it isn't working on it's own counters, but relying on a radius server),
> then the radius CoA could just come early with extra parameters (e.g.
> 'grace period' or even how many and how often to send icmp warnings…)
>
>
> Which would rely on the CoA to tell the NAS to let the client know in an
> unauthenticated way (and if it ever sees traffic, and if it doesn’t get
> rate-limited) that it should maybe contact the API…
> On the other hand we can leverage the direct and secure protocol between
> the API and the client.
>
> I am not saying the ICMP message is useless. It might even be necessary.
> But it should be used as a backup to the API<->client interactions.
>
> - Pierre
>
>
>
>> So I would add that the ICMP message should only be relied upon as a
>> backup mechanism to detect that something is wrong while the API mechanism
>> already failed to detect that the session is almost over.
>> In other words, I think the detection of a session being almost over is
>> first and foremost a problem to be solved by the API mechanism, and as a
>> backup (i.e. in case of inconsistency between the API and the Enforcement
>> point), with the ICMP mechanism.
>>
>> - Pierre
>>
>> Le 20 mars 2018 à 15:29, Lorenzo Colitti <lorenzo@google.com> a écrit :
>>
>> Per discussion at the mike today on what we should do with the ICMP
>> unreachable draft - here are some properties I think are necessary in a
>> hint to the UE that the captive portal is closed.
>>
>> 1. The notification should not be easy to spoof. This is easiest to do by
>> making it a hint to the UE that it should talk to the API.
>>
>>    - An ICMP message by itself is not secure. For example, it's trivial
>>    for an off-path attacker to generate ICMP messages for sessions from
>>    legitimate UEs to <popularwebsite>:443. Getting a UE to trust such a
>>    message only requires getting the ephemeral port right, and many OSes have
>>    a quite limited range of ephemeral ports.
>>    - Tero points out that if we do want to secure such a message, then
>>    we should not roll our own security but should use an existing, secure
>>    protocol such as IPsec.
>>
>>
>> 2. It should be possible to send the notification *before* the captive
>> portal closes, to facilitate seamless connectivity. Ideally the user should
>> be able to re-up the captive portal without having to wait until the
>> network is dead or the device has switched to another network.
>>
>> 3. The notification should not be on a per-destination basis. A hint that
>> conveys the information "you can reach facebook, but to reach CNN you need
>> to upgrade to another service plan" is not technically infeasible but is
>> unlikely ever to reach WG and IETF consensus and therefore I think we
>> should not spend our time talking about it.
>>
>> 4. I'm not sure whether it's possible for the hint to be anything more
>> than a binary "you are or will very soon be captive". Saying things like
>> "an upgrade opportunity is available" may be hard to encode.
>>
>> Cheers,
>> Lorenzo
>> _______________________________________________
>> 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
>>
>
>