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

Re: [Captive-portals] Fwd: [IAB] user notification from the network/captive portals

Are we going down the path of defining a generic solution to signalling at the network layer with implications to upper layers of the stack? We have ICMP for signalling, yes, but it sounds like we want to define some properties for this signalling protocol which go beyond the wire-protocol details of an ICMP type/code?

Perhaps such a solution would be useful to the internet at large? From Yari's email, WIreless network operators want it. We've heard that fixed network operators want it. And clearly wireless access point operators want it. 

Are we doing the signalling solution a disservice by considering it only from the perspective of a standard coffee shop/hotel/airport captive portal? Should we instead be thinking about a larger picture? That is, do we need to define a more generic protocol, one of whose uses is signalling a closed/pending closure captive portal?

If we need to define a generic protocol like this, is capport the proper working group?

On Wed, May 30, 2018 at 5:01 PM David Bird <dbird=[email protected]> wrote:
Some important questions asked... 

FWIW, using ICMP for notification would work for LTE just like WiFi. The PCEF enforcing the walled garden (e.g. Dropping packets) is in a good position to respond with the appropriate ICMP (which it may or may not already be doing; responding with regular Dest-Unreach/Filtered). Configuring the Portal URL, on the other hand, needs defining in the absence of DHCP -- for which we could require the IPv6/RA approach. 

I hope we don't go down the road of thinking UEs should be connecting directly to PCRF like policy engines... 

On Wed, May 30, 2018 at 1:34 PM Martin Thomson <[email protected]> wrote:
Hi Folks,

Jari has been pretty heavily involved in the 5G effort, and provided
the IAB this summary of the captive portal situation in 5G (and
predecessors).  I thought that it might be useful input to the work
here.  And maybe another reminder that it's not just WiFi we have to
think about.

---------- Forwarded message ---------
From: Jari Arkko <[email protected]>
Date: Thu, May 31, 2018 at 5:20 AM
Subject: Re: [IAB] user notification from the network/captive portals
To: Martin Thomson <[email protected]>
Cc: Internet Architecture Board <[email protected]>

Slightly edited. Feel free to forward.


At the IAB retreat we talked about various challenges around the
Internet protocol stack and architecture, including, for instance,
path signals from end points to devices on the path, and notifications
from the network to users. Network notifications often show up to end
users as annoying captive web portal actions, although had they been
designed better, such notifications might offer benefits in terms of
advising users about what connections work well or cost least. I was
asked to discuss the state of user notifications in mobile networks.
The question was whether we see changes in the mobile network space
that would either demand or enable the creation of versatile
notifications from the network, beyond the WLAN-style captive web

Here’s the situation as I see it.

While captive portals are occasionally used in mobile networks, they
are less common and used in different ways than in wireless LANs. In
wireless LANs captive portals are used as an authentication scheme or
as acceptable usage policy/agreement mechanism. These are not commonly
needed in mobile networks. Given mobile network authentication
mechanisms, there is no need for repeated use of a captive portal
every time the user arrives in the network.

In mobile networks, network notifications typically focus on either
initial account configuration, depletion of prepaid usage, warnings
related to usage limits, or cost and roaming related notifications.
Much of this is handled as SMSes, some of it is handled in special
applications, but there are cases (particularly with depleted prepaid
SIM cards) that lead to turning a captive portal on.

A large fraction of the mobile network usage is provisioned as
subscriptions rather than pre-paid usage, which reduces the need for
configuration and top-up acftions. In addition, over time, both
subscription-based and prepaid SIM cards have become more readily
usable without any user action, reducing the need for initial
configuration step.

While the issues with captive portals are not as severe in wireless
LANs, there certainly are issues. SMS-based mechanisms are often
unreliable in roaming situations, and some devices (such as Apple
iPads) are incapable of handling them. SMS is also only usable for
notification, not for rectification of any issues. Just like in
wireless LANs, captive portal solutions are often imperfectly
implemented and have issues on different types of equipment and
browsers. Applications other than browsers generally cannot recognise
what to do with captive portals. Although in recent years operating
systems have become better in recognising when network connectivity is
actually available, so while applications may not be too confused
about the situation, they will still be unable to get any
connectivity. Similarly, devices other than those managed by a human
(or a human paying attention) will be unable to deal with these
conditions at all. Imagine a sensor device trying to reload more money
to an account or accepting the new GDPR privacy rules presented in a
web page.

Part of the problem stems from architecture of access network stacks
across several types of networks. There’s rarely a concept for
powerful communication between the parties, beyond setting up the
technical details of a connection. And where such communication
mechanisms have been designed, they have not been present from day one
in those networks, so it is difficult to rely on their existence.

Does 5G change something with respects to mobile networks and captive
portals or user notifications? While 5G is a re-design of many aspects
of mobile networks, the changes to the user equipment - network
signalling interface are relatively conservative, and have more to do
with changes to the radio interfaces than fundamental redesign of the
capabilities. Other parts of the 5G system have been redesigned in
more significant manner. For instance, the Diameter-based 4G core
network signalling has been replaced by web-based APIs in 5G core. The
goal of this change is to enable a more service-based, flexible design
that employs technologies used broadly in the IT world.

With 3GPP nearing the completion of the first specification release
for the entire 5G system, in my opinion significant further changes in
the user equipment - network interface or new user notification
functionality are unlikely. However, the same motivations that drove
the redesign of the 5G core signalling mechanisms could also drive
flexible/service-based interfaces elsewhere in the system. It is
possible that future generations will introduce flexibility in the
user equipment - network or user - network interface, and as a part of
that, additional user notification functionality is one possible
development area.


Captive-portals mailing list
[email protected]
Captive-portals mailing list
[email protected]