Re: [Captive-portals] Questions about PvD/API

[David Bird <[e-mail]>]

I have no doubt that PvD _could_ be setup and configured to work well. My
concern is that if it is difficult to implement/setup correctly, plenty of
locations will have a broken PvD. At that point, I wonder what the UE
vendors will do... Keep using the PvD (and get user complaints) or start
ignoring the PvD and doing 'legacy' portal detection anyway.

In 3GPP terms, PvD is like asking the UE to connect directly to the PCRF
(or systems like a captive portal that talks to PCRF) and not the PCEF. The
PCEF is analogous to the "NAS" and connects to PCRF using Diameter for AAA
(in WiFi the NAS typically uses RADIUS for AAA). The PCEF might be talking
to multiple PCRFs... It would make more sense if the UE only interacted
with the PCEF and never directly with the PCRF(s). PvD _could_ live in the
PCEF (or NAS), but would that be the common way to deploy PvD? Perhaps in
3GPP is would make sense to put PvD in the PCEF (assuming PCEF is
centralized, more or less, in their network). However, in WiFi, the "NAS"
can often be in the AP itself (so there are many of them) and often are not
physically owned by the same party running the AAA/Portal (a hotspot
services company). I don't think a hotspot services company wants to put
their SSL cert on other peoples devices...



On Wed, Aug 16, 2017 at 1:40 AM, Lorenzo Colitti <[e-mail]> wrote:

> Per my understanding, the part of the system that returns the PVD
> information needs to be in sync with the network elements that are
> responsible for dropping unauthenticated users' packets and redirecting
> plaintext HTTP requests to the portal login page. If the two are not in
> sync then it is a configuration error.
>
> To the untrained eye, this does not seem different from saying that the
> part of the system that handles billing and authentication needs to be in
> sync with the network elements. For example, it would be bad if the user
> paid for service and then couldn't use the network.
>
> On Wed, Aug 16, 2017 at 9:19 AM, Erik Kline <[e-mail]> wrote:
>
>> Randomly selecting Tommy and Eric so this bubbles up in their inbox.
>>
>> On 2 August 2017 at 10:36, David Bird <[e-mail]> wrote:
>> > Could an author of PvD help me understand the following questions for
>> each
>> > of the diagrams below I found on the Internet -- which represent some
>> > typical hotspot configurations out there...
>> >
>> > - Where would the API reside?
>> >
>> > - Who 'owns' the API?
>> >
>> > - How does the API keep in-sync with the NAS? Who's responsible for that
>> > (possibly multi-vendor, multi-AAA) integration?
>> >
>> > 1) Typical Hotspot service company outsourcing:
>> > http://cloudessa.com/wp-content/uploads/2013/08/shema-Captiv
>> ePortalSolution_beta2b.png
>> >
>> > 2) Same as above, except venue owns portal:
>> > http://cloudessa.com/wp-content/uploads/2013/07/solutions_
>> hotspots-co-working-cloudessa_2p1.png
>> >
>> > 3) Now consider the above, but the venue has more roaming partners and
>> > multi-realm RADIUS setup in their Cisco NAS:
>> > http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3
>> /config-guide/b_cg83/b_cg83_chapter_0100111.html
>> > describes many options -- including separate MAC authentication sources,
>> > optional portals for 802.1x (RADIUS) authenticated users, and so much
>> > more...
>> >
>> > "Cisco ISE supports internal and external identity sources. Both
>> sources can
>> > be used as an authentication source for sponsor-user and guest-user
>> > authentication."
>> >
>> > Also note this interesting article:  the section Information About
>> Captive
>> > Bypassing and how it describes how to avoid Apple captive portal
>> > detection!!! "If no response is received, then the Internet access is
>> > assumed to be blocked by the captive portal and Apple’s Captive Network
>> > Assistant (CNA) auto-launches the pseudo-browser to request portal
>> login in
>> > a controlled window. The CNA may break when redirecting to an ISE
>> captive
>> > portal. The controller prevents this pseudo-browser from popping up."
>> >
>> >
>> >
>> > _______________________________________________
>> > Captive-portals mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/captive-portals
>> >
>>
>> _______________________________________________
>> Captive-portals mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/captive-portals
>>
>>
>