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

From: David Bird <[email-masked]>
Date: Wed, 2 Aug 2017 10:36:06 -0700

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-CaptivePortalSolution_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."*

---

From: Erik Kline <[email-masked]>
Date: Tue, 15 Aug 2017 17:19:12 -0700

Randomly selecting Tommy and Eric so this bubbles up in their inbox.

On 2 August 2017 at 10:36, David Bird <[email-masked]> wrote:
> multi-realm RADIUS setup in their Cisco NAS:
> "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
> portal. The controller prevents this pseudo-browser from popping up."
>
>
>
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 16 Aug 2017 17:40:27 +0900

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 <[email-masked]> wrote:

> > http://cloudessa.com/wp-content/uploads/2013/07/
> solutions_hotspots-co-working-cloudessa_2p1.png
> >
> > http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-
> 3/config-guide/b_cg83/b_cg83_chapter_0100111.html

---

From: David Bird <[email-masked]>
Date: Wed, 16 Aug 2017 05:58:17 -0700

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 <[email-masked]> wrote:

>> > http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3
>> /config-guide/b_cg83/b_cg83_chapter_0100111.html

---

From: David Bird <[email-masked]>
Date: Wed, 16 Aug 2017 06:51:58 -0700

My question about where the PvD API resides was somewhat rhetorical. In
reality, I'm sure you will find all of the above - In the NAS (e.g. Cisco),
at the hotspot services provider, and something hosted next to the venues
website. It depends mostly on how this URL is configured, and by whom. (One
could imagine people doing all sorts of things).

My question more specifically for the authors is, how would Cisco implement
PvD for Guest/Public access and would it actively stop avoiding Apple
captive portal detection? Or, would turning on PvD just make that 'feature'
easier to implement?

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 16 Aug 2017 09:20:14 -0700

Hi David,

You mention in one of your emails that you'd expect there to be many "broken PvD" deployments, which would either necessitate ignoring PvD and using legacy mechanisms, or else having the user face a broken portal. My impression is that if client-side deployments fail closed—that is, if there is a PvD advertised, but it does not work well, then we treat the network as broken. If this client behavior is consistent from the start of deployment, then I would think that deployments would notice very quickly if they are broken. The fundamental part of the PvD being advertised is in the RAs—if our DHCP or RAs are broken on a network, we generally are going to be broken anyhow.

As far as where the API resides, I appreciate your explanation of the various complexities. My initial take is this:

- Where a PvD is being served is up to the deployment, and determined by the entity that is providing the RAs. To that end, the server that hosts the API for extended PvD information may be very different for enterprise/carrier scenarios than in captive portals for coffee shops.
- For the initial take for Captive Portals, I would co-locate the "PvD API" server with the "Captive API" and "Captive Web Server". Presumably, the device that was previously doing the HTTP redirects would be able to do the similar coordination of making sure the PvD ID that is given out to clients matches the PvD API server (which is the same as the "Captive Web Server").

For the captive use-case, I see the integration of PvDs as an incremental step:

1. Today, we join a network, always do a probe, which may get redirected to a captive web server
2. With RFC 7710, we would join a network and do the same as (1), unless the captive URL is given in the DHCP/RA and we just make a connection directly.
3. With the Captive API draft, we can interact with the portal other than just showing a webpage; but this may still be bootstrapped by 7710 if not using another mechanism
4. With PvDs, the mechanism in 7710 is generalized to support APIs other than just captive, and can indicate that no captive portal or other extended info is present; and the PvD API in this form is just a more generic version of the captive API that allows us to use the same mechanism for other network properties that aren't specifically captive (like enterprise network extended info, or walled gardens)

Getting into the arms race of people avoiding the captive probes: if someone doesn't want to interact with the client OS's captive portal system, they can and likely will not change anything and just keep redirecting pages. Hopefully if a better solution becomes prevalent enough in the future, client OS's will be able to just ignore and reject any network that redirects traffic, and the only supported captive portals would be ones that interact in specified ways and advertise themselves as captive networks. In order to get to this point, there certainly needs to be a carrot to incentivize adoption. My goal with the more flexible interaction supported by PvD is that we will allow the networks to provide a better user experience to people joining their networks, and integrate with client OS's to streamline the joining process (notification of the network being available, who owns it, how to accept and how to pay), the maintenance process (being able to integrate time left or bytes left on the network into the system UI), and what is allowed or not on the network.

Thanks,
Tommy

> On Aug 16, 2017, at 6:51 AM, David Bird <[email-masked]> wrote:
> 
> My question about where the PvD API resides was somewhat rhetorical. In reality, I'm sure you will find all of the above - In the NAS (e.g. Cisco), at the hotspot services provider, and something hosted next to the venues website. It depends mostly on how this URL is configured, and by whom. (One could imagine people doing all sorts of things). 
> 
> My question more specifically for the authors is, how would Cisco implement PvD for Guest/Public access and would it actively stop avoiding Apple captive portal detection? Or, would turning on PvD just make that 'feature' easier to implement?
> 
> On Tue, Aug 15, 2017 at 5:19 PM, Erik Kline <[email-masked] <mailto:[email-masked]>> wrote:
> On 2 August 2017 at 10:36, David Bird <[email-masked] <mailto:[email-masked]>> wrote:
> > http://cloudessa.com/wp-content/uploads/2013/08/shema-CaptivePortalSolution_beta2b.png <http://cloudessa.com/wp-content/uploads/2013/08/shema-CaptivePortalSolution_beta2b.png>
> >
> > http://cloudessa.com/wp-content/uploads/2013/07/solutions_hotspots-co-working-cloudessa_2p1.png <http://cloudessa.com/wp-content/uploads/2013/07/solutions_hotspots-co-working-cloudessa_2p1.png>
> >
> > http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide/b_cg83/b_cg83_chapter_0100111.html <http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide/b_cg83/b_cg83_chapter_0100111.html>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>
> >
>

---

From: David Bird <[email-masked]>
Date: Fri, 18 Aug 2017 17:52:17 -0700

Thanks Tommy,

I don't dispute that PvD provides an elegant set of solutions --
particularly in enterprise and other 'private' networks. I question,
however, the value in public(/guest) access -- where everyone wants you to
access their network over others, for 'retail analytic' or
branding/attribution(/exploit) purposes.

Another way to see the PvD integration/deployment:

1. Today, we join a network, always do a probe, which redirects to captive
portal
2. A PvD URL is provide, so a captive portal notification is generated to
the user (is that what 'we just make a connection directly' means?)
3. We may have also gotten RFC7710 URL, there are potentially two APIs in
play at the same time, which is extra confusing (?)
4. The first NAS vendor release products with support, venues deploy and
start 'fiddling' with the new feature and URL to PvD end-points
5. The first UE vendor releases products with support, start using it at
said venues... complain to vendor about problems unique to this new device
6. In some networks, users complain that *only* their new PvD device is
seeing a captive portal, while all their other devices do not. Staff at the
coffee shop don't believe me; all their devices work too.

I think there are fundamental issues in splitting what should be 'network
notification' into web APIs....

1. Tomorrow, we join a network, always do a probe, which redirects to
captive portal

It wasn't clear in your e-mail if RFC7710 can be used *without* providing a
URL, or is there a PvD specific DHCP option?

Thanks,
David

On Wed, Aug 16, 2017 at 9:20 AM, Tommy Pauly <[email-masked]> wrote:

> Hi David,
>
> You mention in one of your emails that you'd expect there to be many
> "broken PvD" deployments, which would either necessitate ignoring PvD and
> using legacy mechanisms, or else having the user face a broken portal. My
> impression is that if client-side deployments fail closed—that is, if there
> is a PvD advertised, but it does not work well, then we treat the network
> as broken. If this client behavior is consistent from the start of
> deployment, then I would think that deployments would notice very quickly
> if they are broken. The fundamental part of the PvD being advertised is in
> the RAs—if our DHCP or RAs are broken on a network, we generally are going
> to be broken anyhow.
>
> As far as where the API resides, I appreciate your explanation of the
> various complexities. My initial take is this:
>
> - Where a PvD is being served is up to the deployment, and determined by
> the entity that is providing the RAs. To that end, the server that hosts
> the API for extended PvD information may be very different for
> enterprise/carrier scenarios than in captive portals for coffee shops.
> - For the initial take for Captive Portals, I would co-locate the "PvD
> API" server with the "Captive API" and "Captive Web Server". Presumably,
> the device that was previously doing the HTTP redirects would be able to do
> the similar coordination of making sure the PvD ID that is given out to
> clients matches the PvD API server (which is the same as the "Captive Web
> Server").
>
> 2. With RFC 7710, we would join a network and do the same as (1), unless
> the captive URL is given in the DHCP/RA and we just make a connection
> directly.
> 3. With the Captive API draft, we can interact with the portal other than
> just showing a webpage; but this may still be bootstrapped by 7710 if not
> using another mechanism
> 4. With PvDs, the mechanism in 7710 is generalized to support APIs other
> than just captive, and can indicate that no captive portal or other
> extended info is present; and the PvD API in this form is just a more
> generic version of the captive API that allows us to use the same mechanism
> for other network properties that aren't specifically captive (like
> enterprise network extended info, or walled gardens)
>
> Getting into the arms race of people avoiding the captive probes: if
> someone doesn't want to interact with the client OS's captive portal
> system, they can and likely will not change anything and just keep
> redirecting pages. Hopefully if a better solution becomes prevalent enough
> in the future, client OS's will be able to just ignore and reject any
> network that redirects traffic, and the only supported captive portals
> would be ones that interact in specified ways and advertise themselves as
> captive networks. In order to get to this point, there certainly needs to
> be a carrot to incentivize adoption. My goal with the more flexible
> interaction supported by PvD is that we will allow the networks to provide
> a better user experience to people joining their networks, and integrate
> with client OS's to streamline the joining process (notification of the
> network being available, who owns it, how to accept and how to pay), the
> maintenance process (being able to integrate time left or bytes left on the
> network into the system UI), and what is allowed or not on the network.
>
> Thanks,
> Tommy
>
>
> My question more specifically for the authors is, how would Cisco
> implement PvD for Guest/Public access and would it actively stop avoiding
> Apple captive portal detection? Or, would turning on PvD just make that
> 'feature' easier to implement?
>

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 18 Aug 2017 19:23:04 -0700

Hi David,

My thoughts with regards to RFC 7710 is that it is not deployed as far as I know, and no client stack respects the value sent in 7710. Without some API extensions, it isn't directly better than what we currently have. Ideally, this would not be an API that would get deployed if we were also using PvDs. My concern is that if PvDs are used for enterprise and private networks, we'll have a very similar but less complete path based on RFC 7710. We could end up deprecating or replacing that RFC, which was mentioned in our last meeting. I don't think RFC 7710 can be used without a URL, which is why I think we need a solution that does a better job of indicating the lack of captive or other extended network info.

I would hope that since both iOS and Android stack developers are working on the UE side, we would actually see UE deployment of PvDs before any captive vendors adopt PvDs, and we'd be standardizing around Cisco/etc enterprise deployments. By the time there were NAS vendors deploying, they would test with both iOS and Android devices to validate support.

Basing our standards on the idea that devices (either networks or UE's) may implement the RFCs incorrectly seems to be a difficult starting point.

I like the point you bring up of splitting network notifications from web APIs. There is a need to be judicious about what properties fall into each category. I think you're saying that the fact that there is a captive network can be signaled via ICMP, etc, as a network-level property. While ICMP is a fine solution for giving the UE hints when something has expired, I am concerned that (possibly unsolicited) network signaling is not the correct mechanism for the content details of the network, whether that is the enterprise network properties, or the captive network Terms & Conditions, tokens, expiration timers, and URLs for various kinds of user interaction. An JSON API is one form of grabbing information—I don't think we should necessarily interpret that as something that is a high-level Web interaction. We could create some custom protocol over UDP like DNS records to get the information (that would be a lot of new protocol work here that people may not be willing to get into), but the key is that it needs to be the choice of a UE device that understands how to request and parse content that initiates a lookup, and can fetch information from the network infrastructure.

With regards to your assertion that we'll always revert to doing a probe, I still would like to believe that if we have a network that advertises a PvD with no extended information, or extended information that doesn't include a captive portal, we can avoid the probe altogether. Will we still have networks that redirect HTTP requests? Yes. But that's no different from the scenario today in which a network whitelists our captive detection probes. We can still get to a captive portal once the user goes into the browser. We can stop doing probes whenever the RA on the network indicates that it supports explicit signaling about network properties. If a network operator wants to invoke the system-level captive interaction, then they will follow the RFCs we come up in the CAPPORT group as long as UEs end up deploying support first. If they want to avoid it, or they have a broken network, things will be like networks that whitelist our probes today. Not great, but still possible for the user to get through. My main goal in these standards is to make it possible for a network to give the user a good experience; not to make it impossible for the user to have a sub-par experience (since I don't think that goal is achievable).

Best,
Tommy 

> On Aug 18, 2017, at 5:52 PM, David Bird <[email-masked]> wrote:
> 
> Thanks Tommy,
> 
> I don't dispute that PvD provides an elegant set of solutions -- particularly in enterprise and other 'private' networks. I question, however, the value in public(/guest) access -- where everyone wants you to access their network over others, for 'retail analytic' or branding/attribution(/exploit) purposes. 
> 
> 1. Today, we join a network, always do a probe, which redirects to captive portal
> 2. A PvD URL is provide, so a captive portal notification is generated to the user (is that what 'we just make a connection directly' means?)
> 3. We may have also gotten RFC7710 URL, there are potentially two APIs in play at the same time, which is extra confusing (?)
> 4. The first NAS vendor release products with support, venues deploy and start 'fiddling' with the new feature and URL to PvD end-points
> 5. The first UE vendor releases products with support, start using it at said venues... complain to vendor about problems unique to this new device
> 6. In some networks, users complain that *only* their new PvD device is seeing a captive portal, while all their other devices do not. Staff at the coffee shop don't believe me; all their devices work too.
> 
> I think there are fundamental issues in splitting what should be 'network notification' into web APIs....
> 
> 1. Tomorrow, we join a network, always do a probe, which redirects to captive portal
> 
> It wasn't clear in your e-mail if RFC7710 can be used *without* providing a URL, or is there a PvD specific DHCP option?
> 
> Thanks,
> David
> 
> 
> On Wed, Aug 16, 2017 at 9:20 AM, Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
> Hi David,
> 
>> On Aug 16, 2017, at 6:51 AM, David Bird <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: David Bird <[email-masked]>
Date: Sat, 19 Aug 2017 07:12:24 -0700

HI Tommy,

Agreed that RFC7710 is lacking notification of captive portal existence, it
only provides configuration information. ICMP would provide the
notification, as it does today for other forms of destination unreachable,
port unreachable, etc. In your first reply, I thought you were suggesting
that RFC7710 was at play along side PvD DHCP/RA (and I wasn't clear what
you meant by DHCP/RA).

I think we both also agree that taking about both a Capport API *and* PvD
is adding to the confusion and we ultimately will not want two "APIs".

ICMP today delivers more than hints... it provides signaling that can
directly influence traffic. Yes, there are security concerns around ICMP,
which is why it is common for it to be filtered out of networks (which is a
good think for Capport ICMP, it is only for the edge network).

Regarding ICMP and the "content details of the network" ... I think that
statement conflates policy and enforcement. ICMP provides (as today)
notification of enforcement, and RFC7710 provides where to find out about
the policy (ToS, etc).

The JSON API becomes a "web service" when it has a http(s):// in front of
it :) .. but, indeed, my concern is in the transport protocol. It being a
URL signals that this is meant to be deployed alongside the portal, or
otherwise 'remotely'... Vendors will likely have a "PvD URL: "
configuration dialog ... and there will be many hotspot services companies
updating their "Howto" instructions with their PvD URL info... it is a web
service.

I welcome suggestions that put that JSON API into a lower layer network
protocol. We could stuff JSON into ICMP :)

Maybe there is a way to merge ICMP and PvD -- to where ICMP provides the
notification (with tokens) and PvD provides the policy (based on these
tokens) (?)

With regard to vendor (NAS/UE) cooperation, perhaps PvD could be a new
start, but thus far (as my quote of Cisco documentation suggests), it is
more about what users/venues want. Cisco already today actively avoids iOS
captive portal detection because the "pseudo-browser" (as they call it)
does work with their portal. That is a problem that could be solve today by
Apple/Cisco, couldn't it? Just by not using the pseudo browser...
introducing PvD doesn't resolve the core problem there, but does make it
easier to avoid that pseudo browser.

You also said "We can still get to a captive portal once the user goes into
the browser." ... However, this is increasingly untrue as the work moves to
https... So, doing this avoidance of detection will still be a problem.

Cheers,
David

On Fri, Aug 18, 2017 at 7:23 PM, Tommy Pauly <[email-masked]> wrote:

> Hi David,
>
> My thoughts with regards to RFC 7710 is that it is not deployed as far as
> I know, and no client stack respects the value sent in 7710. Without some
> API extensions, it isn't directly better than what we currently have.
> Ideally, this would not be an API that would get deployed if we were also
> using PvDs. My concern is that if PvDs are used for enterprise and private
> networks, we'll have a very similar but less complete path based on RFC
> 7710. We could end up deprecating or replacing that RFC, which was
> mentioned in our last meeting. I don't think RFC 7710 can be used without a
> URL, which is why I think we need a solution that does a better job of
> indicating the lack of captive or other extended network info.
>
> I would hope that since both iOS and Android stack developers are working
> on the UE side, we would actually see UE deployment of PvDs before any
> captive vendors adopt PvDs, and we'd be standardizing around Cisco/etc
> enterprise deployments. By the time there were NAS vendors deploying, they
> would test with both iOS and Android devices to validate support.
>
> Basing our standards on the idea that devices (either networks or UE's)
> may implement the RFCs incorrectly seems to be a difficult starting point.
>
> I like the point you bring up of splitting network notifications from web
> APIs. There is a need to be judicious about what properties fall into each
> category. I think you're saying that the fact that there is a captive
> network can be signaled via ICMP, etc, as a network-level property. While
> ICMP is a fine solution for giving the UE hints when something has expired,
> I am concerned that (possibly unsolicited) network signaling is not the
> correct mechanism for the content details of the network, whether that is
> the enterprise network properties, or the captive network Terms &
> Conditions, tokens, expiration timers, and URLs for various kinds of user
> interaction. An JSON API is one form of grabbing information—I don't think
> we should necessarily interpret that as something that is a high-level Web
> interaction. We could create some custom protocol over UDP like DNS records
> to get the information (that would be a lot of new protocol work here that
> people may not be willing to get into), but the key is that it needs to be
> the choice of a UE device that understands how to request and parse content
> that initiates a lookup, and can fetch information from the network
> infrastructure.
>
> With regards to your assertion that we'll always revert to doing a probe,
> I still would like to believe that if we have a network that advertises a
> PvD with no extended information, or extended information that doesn't
> include a captive portal, we can avoid the probe altogether. Will we still
> have networks that redirect HTTP requests? Yes. But that's no different
> from the scenario today in which a network whitelists our captive detection
> probes. We can still get to a captive portal once the user goes into the
> browser. We can stop doing probes whenever the RA on the network indicates
> that it supports explicit signaling about network properties. If a network
> operator wants to invoke the system-level captive interaction, then they
> will follow the RFCs we come up in the CAPPORT group as long as UEs end up
> deploying support first. If they want to avoid it, or they have a broken
> network, things will be like networks that whitelist our probes today. Not
> great, but still possible for the user to get through. My main goal in
> these standards is to make it possible for a network to give the user a
> good experience; not to make it impossible for the user to have a sub-par
> experience (since I don't think that goal is achievable).
>
> Best,
> Tommy
>
>
> It wasn't clear in your e-mail if RFC7710 can be used *without* providing
> a URL, or is there a PvD specific DHCP option?
>
> Thanks,
> David
>
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Aug 2017 11:34:54 +1000

Hi David,

Can you explain more about why you believe that a lower-layer protocol
needs to be used?

I remember a similar discussion about this about 10 years ago with
GEOPRIV.  Then it was asserted that DHCP was the only protocol that
could deliver location information to user equipment.  That discussion
took a long time, but ultimately ended with an HTTP-based protocol.  I
have no desire to repeat that experience.

It seems like this is - at least in part - based in how this might be
configured.  That is, you believe that a lower-layer protocol offers
no option for misconfiguration.  Is that correct?  Have I missed
something?

On 20 August 2017 at 00:12, David Bird <[email-masked]> wrote:
> that RFC7710 was at play along side PvD DHCP/RA (and I wasn't clear what you
> meant by DHCP/RA).
>
> I think we both also agree that taking about both a Capport API *and* PvD is
> adding to the confusion and we ultimately will not want two "APIs".
>
> The JSON API becomes a "web service" when it has a http(s):// in front of it
> :) .. but, indeed, my concern is in the transport protocol. It being a URL
> signals that this is meant to be deployed alongside the portal, or otherwise
> 'remotely'... Vendors will likely have a "PvD URL: " configuration dialog
> ... and there will be many hotspot services companies updating their "Howto"
> instructions with their PvD URL info... it is a web service.
>
> captive portal detection because the "pseudo-browser" (as they call it) does
> work with their portal. That is a problem that could be solve today by
>> 7710. We could end up deprecating or replacing that RFC, which was mentioned
>> in our last meeting. I don't think RFC 7710 can be used without a URL, which
>> is why I think we need a solution that does a better job of indicating the
>> lack of captive or other extended network info.
>>
>> have networks that redirect HTTP requests? Yes. But that's no different from
>> the scenario today in which a network whitelists our captive detection
>> great, but still possible for the user to get through. My main goal in these
>> standards is to make it possible for a network to give the user a good
>> experience; not to make it impossible for the user to have a sub-par
>>> is a PvD advertised, but it does not work well, then we treat the network as
>>> broken. If this client behavior is consistent from the start of deployment,
>>> then I would think that deployments would notice very quickly if they are
>>> broken. The fundamental part of the PvD being advertised is in the RAs—if
>>> our DHCP or RAs are broken on a network, we generally are going to be broken
>>> anyhow.
>>>
>>> the entity that is providing the RAs. To that end, the server that hosts the
>>> API for extended PvD information may be very different for
>>> API" server with the "Captive API" and "Captive Web Server". Presumably, the
>>> device that was previously doing the HTTP redirects would be able to do the
>>> similar coordination of making sure the PvD ID that is given out to clients
>>> matches the PvD API server (which is the same as the "Captive Web Server").
>>>
>>> than just captive, and can indicate that no captive portal or other extended
>>> info is present; and the PvD API in this form is just a more generic version
>>> of the captive API that allows us to use the same mechanism for other
>>> network properties that aren't specifically captive (like enterprise network
>>> extended info, or walled gardens)
>>>
>>> someone doesn't want to interact with the client OS's captive portal system,
>>> they can and likely will not change anything and just keep redirecting
>>> pages. Hopefully if a better solution becomes prevalent enough in the
>>> future, client OS's will be able to just ignore and reject any network that
>>> redirects traffic, and the only supported captive portals would be ones that
>>> interact in specified ways and advertise themselves as captive networks. In
>>> order to get to this point, there certainly needs to be a carrot to
>>> incentivize adoption. My goal with the more flexible interaction supported
>>> by PvD is that we will allow the networks to provide a better user
>>> experience to people joining their networks, and integrate with client OS's
>>> to streamline the joining process (notification of the network being
>>> available, who owns it, how to accept and how to pay), the maintenance
>>> process (being able to integrate time left or bytes left on the network into
>>> the system UI), and what is allowed or not on the network.
>>>
>>> Thanks,
>>> Tommy
>>>
>>>

---

From: David Bird <[email-masked]>
Date: Tue, 22 Aug 2017 13:09:12 -0700

I don't think that is a fair comparison...

Geolocation isn't anything enforced by the network... and clearly not
designed for public/guest access networks (as they exists today).

You might re-read some of the Security Consideration in the docs
surrounding GEOPRIV.

HTTP-Enabled Location Delivery (HELD)
https://datatracker.ietf.org/doc/html/rfc5985#page-22

   HELD is a location acquisition protocol whereby the client requests
   its location from a LIS.  Specific requirements and security
   considerations for location acquisition protocols are provided in
   [RFC5687].  An in-depth discussion of the security considerations
   applicable to the use of Location URIs and by-reference provision of
   LI is included in [RFC5808].

   By using the HELD protocol, the client and the LIS expose themselves
   to two types of risk:

   Accuracy:  The client receives incorrect location information.

   Privacy:  An unauthorized entity receives location information.

   The provision of an accurate and privacy- and confidentiality-
   protected location to the requestor depends on the success of five
   steps:

   1.  The client must determine the proper LIS.

   2.  The client must connect to the proper LIS.

   3.  The LIS must be able to identify the Device by its identifier (IP
       address).

   4.  The LIS must be able to return the desired location.

   5.  HELD messages must be transmitted unmodified between the LIS and
       the client.

   Of these, only steps 2, 3, and 5 are within the scope of this
   document.  Step 1 is based on either manual configuration or on the
   LIS discovery defined in [RFC5986], in which appropriate security
   considerations are already discussed.  Step 4 is dependent on the
   specific positioning capabilities of the LIS and is thus outside the
   scope of this document.

Discovering the Local Location Information Server (LIS)
https://datatracker.ietf.org/doc/html/rfc5986#page-11

   The address of a *LIS is usually well-known within an access network*;
   therefore, interception of messages does not introduce any specific
   concerns.

   The primary attack against the methods described in this document is
   one that would lead to impersonation of a LIS.  The LIS is
   responsible for providing location information, and this information
   is critical to a number of network services; furthermore, a Device
   does not necessarily have a prior relationship with a LIS.  Several
   methods are described here that can limit the probability of, or
   provide some protection against, such an attack.  These methods MUST
   be applied unless similar protections are in place, or in cases --
   such as an emergency -- where location information of dubious origin
   is arguably better than none at all.

   An attacker could attempt to compromise LIS discovery at any of three
   stages:

*   1.  providing a falsified domain name to be used as input to U-NAPTR
 2.  altering the DNS records used in U-NAPTR resolution   3.
 impersonating the LIS*

   The domain name that used to authenticate the LIS is the domain name
   input to the U-NAPTR process, not the output of that process
   [RFC3958], [RFC4848].  As a result, the results of DNS queries do not
   need integrity protection.

   An HTTPS URI is authenticated using the method described in Section
   3.1 of [RFC2818].  HTTP client implementations frequently do not
   provide a means to authenticate based on a domain name other than the
   one indicated in the request URI, namely the U-NAPTR output.  To
   avoid having to authenticate the LIS with a domain name that is
   different from the one used to identify it, a client MAY choose to
   reject URIs that contain a domain name that is different to the
   U-NAPTR input.  To support endpoints that enforce the above
   restriction on URIs, network administrators SHOULD ensure that the
   domain name in the DHCP option is the same as the one contained in
   the resulting URI.

*Authentication of a LIS relies on the integrity of the domain name
 acquired from DHCP.  An attacker that is able to falsify a domain   name
circumvents the protections provided. * To ensure that the access
   network domain name DHCP option can be relied upon, preventing DHCP
   messages from being modified or spoofed by attackers is necessary.

*Physical- or link-layer security are commonly used to reduce the
 possibility of such an attack within an access network. * DHCP
   authentication [RFC3118] might also provide a degree of protection
   against modification or spoofing.

   A LIS that is identified by an HTTP URI cannot be authenticated.  Use
   of unsecured HTTP also does not meet requirements in HELD for
   confidentiality and integrity.  If an HTTP URI is the product of LIS
   discovery, this leaves Devices vulnerable to several attacks.

*Lower-   layer protections, such as Layer 2 traffic separation might be
used   to provide some guarantees.*

Requirements for a Location-by-Reference Mechanism
https://datatracker.ietf.org/doc/html/rfc5808#page-12

   The method of constructing the location URI to include randomized
   components helps to prevent adversaries from obtaining location
   information without ever retrieving a location URI.  In the
   possession model, a location URI, regardless of its construction, if
   made publicly available, implies no safeguard against anyone being
   able to dereference and get the location.  Care has to be paid when
   distributing such a location URI to the *trusted location recipients*.
   When this aspect is of concern, the authorization model has to be
   chosen.

*Even in this model, care has to be taken on how to construct   the
authorization policies to ensure that only those parties have   access to
location information that are considered trustworthy enough   to enforce
the basic rule set that is attached to location   information in a PIDF-LO
document.*

   Any location URI, by necessity, indicates the server (name) that
   hosts the location information.  Knowledge of the server in some
   specific domain could therefore reveal something about the location
   of the Target.  This kind of threat may be mitigated somewhat by
   introducing another layer of indirection: namely the use of a
   (remote) presence server.

   A covert channel for protocol message exchange is an important
   consideration, given an example scenario where user A subscribes to
   location information for user B, then every time A gets a location
   update, an (external) observer of the subscription notification may
   know that B has moved.  One mitigation of this is to have periodic
   notification, so that user B may appear to have moved even when
   static.

On Sun, Aug 20, 2017 at 6:34 PM, Martin Thomson <[email-masked]>
wrote:

> you
> does
> mentioned
> from
> these
> >>> For the captive use-case, I see the integration of PvDs as an
> incremental
> >>> step:
> >>>
> >>> 1. Today, we join a network, always do a probe, which may get
> redirected
> >>> to a captive web server
> extended
> system,
> >>>> > Could an author of PvD help me understand the following questions
> for
> >>>> > each

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Aug 2017 09:38:42 +1000

I wrote all of that text.  I'm not sure that I get your point though.
There's a discovery mechanism that is vulnerable to interception,
etc..., but that (mostly) happens using network-local mechanisms (DHCP
primarily).  That's the only weak link.  The identity is well known
and authenticated once later interactions happen (the text on
unsecured HTTP is a relic of a bygone era, no one actually implements
that).

In short, the design is to discover the identity of a service using
those lower-layer primitives and then use that to bootstrap into
something else.  If your assertion is that PvD - as a discovery
mechanism - is vulnerable, then the weakness is in the layer 3 parts,
not in the bits that use HTTP.  Those can (and should) be
authenticated.

Did I miss something?

On 23 August 2017 at 06:09, David Bird <[email-masked]> wrote:
> You might re-read some of the Security Consideration in the docs surrounding
> GEOPRIV.
>
>    The address of a LIS is usually well-known within an access network;
>    1.  providing a falsified domain name to be used as input to U-NAPTR
>
>    2.  altering the DNS records used in U-NAPTR resolution
>
>    3.  impersonating the LIS
>
>    Authentication of a LIS relies on the integrity of the domain name
>    acquired from DHCP.  An attacker that is able to falsify a domain
>    name circumvents the protections provided.  To ensure that the access
>    Physical- or link-layer security are commonly used to reduce the
>    possibility of such an attack within an access network.  DHCP
>    discovery, this leaves Devices vulnerable to several attacks.  Lower-
>    layer protections, such as Layer 2 traffic separation might be used
>    to provide some guarantees.
>
>    distributing such a location URI to the trusted location recipients.
>    chosen.  Even in this model, care has to be taken on how to construct
>    the authorization policies to ensure that only those parties have
>    access to location information that are considered trustworthy enough
>    to enforce the basic rule set that is attached to location
>    information in a PIDF-LO document.
>

---

From: David Bird <[email-masked]>
Date: Thu, 24 Aug 2017 06:40:48 -0700

No, that is more or less my point exactly...

One problem people seem to have with ICMP and think PvD is the solution is
around security. You brought up GEOPRIV as an example of that. However, as
you said, "Those can (and should) be authenticated". In public access
(where you can't punt security to "Lower-layer protections, such as Layer 2
traffic separation might be used to provide some guarantees."), maybe that
statement would be upgraded to "Those MUST be authenticated". In RFC 5687
is says " The client MUST authenticate the discovered LIS." ... however,
I'm not clear what "authenticate" means here. My assumption is that is
means more than just a valid SSL cert of an unfamiliar hostname (like you
would expect in public/guest access PvD).

And, yes, I absolutely believe we will have a higher rate of
misconfiguration using the L7/Application layer... To quote myself from
earlier in the thread:  Vendors will likely have a "PvD URL: "
configuration dialog ... and there will be many hotspot services companies
updating their "Howto" instructions with their PvD URL info... pretty darn
easy to misconfigure. Can you give an example of how ICMP could be
misconfigured?

On Tue, Aug 22, 2017 at 4:38 PM, Martin Thomson <[email-masked]>
wrote:

> surrounding
> >> > Agreed that RFC7710 is lacking notification of captive portal
> existence,
> >> > it
> >> > the browser." ... However, this is increasingly untrue as the work
> moves
> >> > to
> >> >> My thoughts with regards to RFC 7710 is that it is not deployed as
> far
> >> >> as
> >> >> in our last meeting. I don't think RFC 7710 can be used without a
> URL,
> >> >> which
> >> >> is why I think we need a solution that does a better job of
> indicating
> >> >> the
> >> >> correct mechanism for the content details of the network, whether
> that
> >> >> is
> >> >> we should necessarily interpret that as something that is a
> high-level
> >> >> Web
> >> >> people may not be willing to get into), but the key is that it needs
> to
> >> >> be
> >> >> I still would like to believe that if we have a network that
> advertises
> >> >> a
> >> >> will follow the RFCs we come up in the CAPPORT group as long as UEs
> end
> >> >> up
> >> >> network, things will be like networks that whitelist our probes
> today.
> >> >> Not
> >> >> however, the value in public(/guest) access -- where everyone wants
> you
> >> >> to
> >> >> 2. A PvD URL is provide, so a captive portal notification is
> generated
> >> >> to
> >> >> 3. We may have also gotten RFC7710 URL, there are potentially two
> APIs
> >> >> in
> >> >> seeing a captive portal, while all their other devices do not. Staff
> at
> >> >> the
> >> >>> "broken PvD" deployments, which would either necessitate ignoring
> PvD
> >> >>> and
> >> >>> using legacy mechanisms, or else having the user face a broken
> portal.
> >> >>> My
> >> >>> impression is that if client-side deployments fail closed—that is,
> if
> >> >>> there
> >> >>> then I would think that deployments would notice very quickly if
> they
> >> >>> are
> >> >>> our DHCP or RAs are broken on a network, we generally are going to
> be
> >> >>> broken
> >> >>> anyhow.
> >> >>>
> >> >>> - Where a PvD is being served is up to the deployment, and
> determined
> >> >>> by
> >> >>> just showing a webpage; but this may still be bootstrapped by 7710
> if
> >> >>> not
> >> >>> using another mechanism
> >> >>> future, client OS's will be able to just ignore and reject any
> network
> >> >>> that
> >> >>> experience to people joining their networks, and integrate with
> client
> >> >>> OS's
> >> >>> website. It depends mostly on how this URL is configured, and by
> whom.
> >> >>> (One
> >> >>>> > - How does the API keep in-sync with the NAS? Who's responsible
> for
> >> >>>> > that
> >> >>>> > 3) Now consider the above, but the venue has more roaming
> partners
> >> >>>> > and
> >> >>>> > Also note this interesting article:  the section Information
> About
> >> >>>> > Captive
> >> >>>> > detection!!! "If no response is received, then the Internet
> access
> >> >>>> > is
> >> >>>> > Assistant (CNA) auto-launches the pseudo-browser to request
> portal
> >> >>>> > login in

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Aug 2017 23:01:41 +0900

On Thu, Aug 24, 2017 at 10:40 PM, David Bird <[email-masked]> wrote:

> Can you give an example of how ICMP could be misconfigured?
>

It doesn't matter how hard it is to misconfigure, because it is trivial to
forge.

---

From: David Bird <[email-masked]>
Date: Thu, 24 Aug 2017 07:29:27 -0700

Just like the rampant problem we see in ICMP Dest-Unreachable forgery
attacks?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Aug 2017 23:40:43 +0900

A forged destination unreachable can't cause someone else's device to think
that wifi is a portal and switch to possibly expensive cellular data.

On Thu, Aug 24, 2017 at 11:29 PM, David Bird <[email-masked]> wrote:

>> It doesn't matter how hard it is to misconfigure, because it is trivial
>> to forge.
>>
>
>

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 24 Aug 2017 08:14:36 -0700

Right, I think the difference between an unreachable destination, and a captive portal or walled garden, is that we expect the captive portal style interaction to be an Operating System-level action, and one that will have consequences on everything the device does while associated to a given network. You can certain use spoofed ICMP to disrupt connections, but (a) the user would notice and (b) you're not causing the Operating System to change behavior. When the OS thinks it is on a captive network or not, it will change what network it considers primary/usable, which may potentially be invisible to the user other than an icon change. I would be able to go onto a captive network, start sending out ICMP messages, and potentially bump other people's connection off the network. 

Having the UE fetch some resource in order to determine captive state, especially if that resource can be somehow signed, makes it much harder for an attacker to cause the OS to take silent behavior.

Tommy

> On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti <[email-masked]> wrote:
> 
> A forged destination unreachable can't cause someone else's device to think that wifi is a portal and switch to possibly expensive cellular data.
> 
> On Thu, Aug 24, 2017 at 11:29 PM, David Bird <[email-masked] <mailto:[email-masked]>> wrote:
> Just like the rampant problem we see in ICMP Dest-Unreachable forgery attacks? 
> 
> On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti <[email-masked] <mailto:[email-masked]>> wrote:
> On Thu, Aug 24, 2017 at 10:40 PM, David Bird <[email-masked] <mailto:[email-masked]>> wrote:
> It doesn't matter how hard it is to misconfigure, because it is trivial to forge.
> 
>

---

From: David Bird <[email-masked]>
Date: Thu, 24 Aug 2017 08:21:51 -0700

You are both describing decisions the UE makes... perhaps the UE waits for
several flows (with same session-id) to indicate capport warning/errors
before acting on it... especially when already connected. There were also
proposals to link the ICMP messages to the DHCP message somehow so that
ICMP is 'authenticated' against the original DHCP. Theses are solvable
concerns, not road blocks.

On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly <[email-masked]> wrote:

> Right, I think the difference between an unreachable destination, and a
> captive portal or walled garden, is that we expect the captive portal style
> interaction to be an Operating System-level action, and one that will have
> consequences on everything the device does while associated to a given
> network. You can certain use spoofed ICMP to disrupt connections, but (a)
> the user would notice and (b) you're not causing the Operating System to
> change behavior. When the OS thinks it is on a captive network or not, it
> will change what network it considers primary/usable, which may potentially
> be invisible to the user other than an icon change. I would be able to go
> onto a captive network, start sending out ICMP messages, and potentially
> bump other people's connection off the network.
>
> Having the UE fetch some resource in order to determine captive state,
> especially if that resource can be somehow signed, makes it much harder for
> an attacker to cause the OS to take silent behavior.
>
> Tommy
>
> A forged destination unreachable can't cause someone else's device to
> think that wifi is a portal and switch to possibly expensive cellular data.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 25 Aug 2017 00:33:48 +0900

It seems to me that any solution involving coordination between two
protocols is little different, in terms of your criticism that it will lead
to "a higher rate of misconfiguration", from the PVD solution. (Personally
I don't think that's a valid argument - saying that if you misconfigure the
network it won't work well is pretty much a tautology - but you were the
one that cited that argument in support of the ICMP solution.)

As for several flows, I don't see what would stop an attacker from trying
to spoof several flows.

---

From: David Bird <[email-masked]>
Date: Thu, 24 Aug 2017 08:55:14 -0700

Indeed, one could just as easily misconfigure the "Captive Portal URL: "
field in the NAS. A key difference is that this configuration is enforced
the same way (with slight variation for capport) for all devices... It is
not just a misconfiguration only visible to "First Vendor to Release PvD
Client" products.

I'm trying to figure out the value the attacker is gaining (e.g. the
motivation) for putting others off the network using Capport ICMP. If they
are off-network, chances are their attacks will not work because of
firewalls. If they are on-network, particularly if this is Open SSID public
access network, I'd say they are wasting their time... Sending 802.11
Disassoc would be easier.

On Thu, Aug 24, 2017 at 8:33 AM, Lorenzo Colitti <[email-masked]> wrote:

>> You are both describing decisions the UE makes... perhaps the UE waits
>> for several flows (with same session-id) to indicate capport warning/errors

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 24 Aug 2017 09:03:41 -0700

If the client OS needs to add in heuristics to reach a certain volume of ICMP messages before trusting them, I think the design is flawed. Beyond that, the information we'd like to get isn't just as simple as a boolean value that can be aggregated (like unreachable would be). Among the problems we're trying to solve for CAPPORT is "how much time do I have left", and "when to re-join the portal". Having a source we can query about those properties seems to dramatically simplify the flow and trust model. However we do things, it seems like this information should be pull-able (even if it allows the client to open a connection on which changes are pushed or notified) rather than unsolicited pushes of ICMP by the network.

> On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti <[email-masked]> wrote:
> 
> It seems to me that any solution involving coordination between two protocols is little different, in terms of your criticism that it will lead to "a higher rate of misconfiguration", from the PVD solution. (Personally I don't think that's a valid argument - saying that if you misconfigure the network it won't work well is pretty much a tautology - but you were the one that cited that argument in support of the ICMP solution.)
> 
> As for several flows, I don't see what would stop an attacker from trying to spoof several flows.
> 
> On Fri, Aug 25, 2017 at 12:21 AM, David Bird <[email-masked] <mailto:[email-masked]>> wrote:
> You are both describing decisions the UE makes... perhaps the UE waits for several flows (with same session-id) to indicate capport warning/errors before acting on it... especially when already connected. There were also proposals to link the ICMP messages to the DHCP message somehow so that ICMP is 'authenticated' against the original DHCP. Theses are solvable concerns, not road blocks. 
> 
> 
> 
> On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
>> On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: David Bird <[email-masked]>
Date: Thu, 24 Aug 2017 12:34:39 -0700

There are no unsolicited pushes of ICMP by the network; they all have a
flow context and in response to traffic (in the latest draft). There isn't
any need for an idle device to require notification (and should be left to
go idle... stop session, lose lease, etc). The ICMP proposal does
allow for "when
to re-join the portal" warning notifications... and, when time does expire,
the notification is immediate (assuming there is traffic).

I'm not convinced this really improves the 'trust model' as the weakest
link, as discussed, was in discovery. Having a source to query about
information is a good idea, and some networks even already do such things
[1]...

However, the assumptions behind a PvD web service 'working' are huge.. It
will *require* RADIUS Accounting integration such that this API knows when
sessions start/stop. It will *require* knowing RADIUS Authorization logic
to know, before hand, when the RADIUS server might be sending a CoA to stop
the session (to provide the warnings) -- it would also need to be
integrated with provisioning logic (be it in RADIUS, or a portal, or both)
for situations where a CoA is sent for reasons other than Stop (to change
walled garden, session parameters, etc).

Should "First Vendor to Release PvD Client" products start getting
complaints about their devices having problems at Hotspots, unseen by other
devices, what will they do?

I was only proposing the client heuristics as something the client _could_
do, should that _threat_ actually materialize... (which I doubt)

[1]
https://sourceforge.net/p/hotcakes/wiki/Coova%20Chilli%20JSON%20Interface/

On Thu, Aug 24, 2017 at 9:03 AM, Tommy Pauly <[email-masked]> wrote:

> If the client OS needs to add in heuristics to reach a certain volume of
> ICMP messages before trusting them, I think the design is flawed. Beyond
> that, the information we'd like to get isn't just as simple as a boolean
> value that can be aggregated (like unreachable would be). Among the
> problems we're trying to solve for CAPPORT is "how much time do I have
> left", and "when to re-join the portal". Having a source we can query about
> those properties seems to dramatically simplify the flow and trust model.
> However we do things, it seems like this information should be pull-able
> (even if it allows the client to open a connection on which changes are
> pushed or notified) rather than unsolicited pushes of ICMP by the network.
>

---

From: Vincent van Dam <[email-masked]>
Date: Thu, 24 Aug 2017 20:58:06 +0000

I agree that the information you describe should be pulled from somewhere, however, I am more concerned _when_ they should be pulled.

In this working group we acknowledged (welcomed) use cases that go beyond connecting to a network; the latest example: https://www.ietf.org/mail-archive/web/captive-portals/current/msg00455.html

If these use cases are indeed in scope; signalling, or a solution that allows detection that the walled garden is (re)activated after joining the network, need to be in place. The alternative to a signal would be polling, or doing some mitm on protocols that allow it. I think both mitm, and polling regularly to see if the connection state is walled are bad.

Just focussing on signalling (without the semantics/api); I think that leaves us with three directions:

* descope any solution that would improve the scenario where walled gardens are (re-)activated

* accept icmp is a valid direction, and think of a way on how we can use this securely in our use-case

* invent a new signal? something the nas is allowed to send to the ue, but not icmp?

Gr., Vincent

________________________________
Van: Captive-portals [[email-masked]] namens Tommy Pauly [[email-masked]]
Verzonden: donderdag 24 augustus 2017 18:03
Aan: Lorenzo Colitti
CC: Erik Kline; Eric Vyncke (evyncke); Martin Thomson; [email-masked]; David Bird
Onderwerp: Re: [Captive-portals] Questions about PvD/API

On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Aug 25, 2017 at 12:21 AM, David Bird <[email-masked]<mailto:[email-masked]>> wrote:
You are both describing decisions the UE makes... perhaps the UE waits for several flows (with same session-id) to indicate capport warning/errors before acting on it... especially when already connected. There were also proposals to link the ICMP messages to the DHCP message somehow so that ICMP is 'authenticated' against the original DHCP. Theses are solvable concerns, not road blocks.

On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly <[email-masked]<mailto:[email-masked]>> wrote:
Right, I think the difference between an unreachable destination, and a captive portal or walled garden, is that we expect the captive portal style interaction to be an Operating System-level action, and one that will have consequences on everything the device does while associated to a given network. You can certain use spoofed ICMP to disrupt connections, but (a) the user would notice and (b) you're not causing the Operating System to change behavior. When the OS thinks it is on a captive network or not, it will change what network it considers primary/usable, which may potentially be invisible to the user other than an icon change. I would be able to go onto a captive network, start sending out ICMP messages, and potentially bump other people's connection off the network.

Tommy

On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Aug 24, 2017 at 11:29 PM, David Bird <[email-masked]<mailto:[email-masked]>> wrote:
Just like the rampant problem we see in ICMP Dest-Unreachable forgery attacks?

On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Aug 24, 2017 at 10:40 PM, David Bird <[email-masked]<mailto:[email-masked]>> wrote:
Can you give an example of how ICMP could be misconfigured?

_______________________________________________
Captive-portals mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/captive-portals

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Aug 2017 09:55:40 +1000

What is interesting about Heiko's example here is that this transition
is not necessarily visible to endpoints. Nor can they be forewarned
(assuming they are ignorant of the botnet using their link).
Endpoints were previously on a network without a captive portal, but
one is suddenly interjected.

I see several problems, different for each of the various solutions:

* With 7710 or PvD, the original network would have to be provisioned
with a captive portal, or the switch would happen and the endpoint
won't have a URI to talk to.  That seems relatively tractable,
providing that this didn't lead to a false assumption of captivity
(this is a problem with 7710, I think, because the existence of the
option seems to imply captivity, though this is quite unclear from the
RFC).

* With ICMP, the signal comes from more than one hop away.  An
unmodified router in the home would receive the ICMP message, reduce
the TTL and then it looks like a random Internet host was trying to
deny service.

So running through all the combinations:

7710/PvD + ICMP - you know where to go to get status information and
the network can signal

7710/PvD - ICMP - you know where to go to get status information, but
how would you decide to ask?  Is there some other trigger you would
use?  (This is, I think Vincent's question.)

ICMP - 7710/PvD - you get a signal, but is it legit?  How do you validate it?

Neither - that's the situation we have today.

It seems that there are at least a few people who think that this use
case is in scope.  It doesn't seem materially different from the case
where you run out of bytes (for networks that do accounting that way).
Maybe this use case can inform the design a little better.  Or maybe
someone would like to argue that we don't need to worry about this.

On 25 August 2017 at 06:58, Vincent van Dam <[email-masked]> wrote:
> I agree that the information you describe should be pulled from somewhere,
> however, I am more concerned _when_ they should be pulled.
>
>
> In this working group we acknowledged (welcomed) use cases that go beyond
> connecting to a network; the latest example:
> https://www.ietf.org/mail-archive/web/captive-portals/current/msg00455.html
>
>
> If these use cases are indeed in scope; signalling, or a solution that
> allows detection that the walled garden is (re)activated after joining the
> network, need to be in place. The alternative to a signal would be polling,
> or doing some mitm on protocols that allow it. I think both mitm, and
> polling regularly to see if the connection state is walled are bad.
>
>
> value that can be aggregated (like unreachable would be). Among the problems
> we're trying to solve for CAPPORT is "how much time do I have left", and
> "when to re-join the portal". Having a source we can query about those
> properties seems to dramatically simplify the flow and trust model. However
> we do things, it seems like this information should be pull-able (even if it
> allows the client to open a connection on which changes are pushed or
> notified) rather than unsolicited pushes of ICMP by the network.
>
> to "a higher rate of misconfiguration", from the PVD solution. (Personally I
> don't think that's a valid argument - saying that if you misconfigure the
> network it won't work well is pretty much a tautology - but you were the one
> that cited that argument in support of the ICMP solution.)
>
>> proposals to link the ICMP messages to the DHCP message somehow so that ICMP
>> is 'authenticated' against the original DHCP. Theses are solvable concerns,
>> not road blocks.
>>
>>
>>

---

From: David Bird <[email-masked]>
Date: Thu, 24 Aug 2017 18:49:01 -0700

I don't see RFC7710 grouped with PvD and vs ICMP. In fact, RFC7710 is
required in the ICMP draft.

So, it should be 7710 & ICMP vs PvD. Nobody is arguing 7710 should stand
alone, or is useful by itself.

There are unique considerations when the captive portal "client" is a
router and not the UE... In this example, no clients get 'released' from
captivity - so, it doesn't really have to trace clients by IP address. The
CPE firmware needs updating to have RFC7710 configurable via their
management system -- this might be a good opportunity to have a minimal
Capport ICMP based captive portal implemented completely in CPE firmware,
perhaps Linux iptables w/Capport ICMP support. Assuming they don't do that
(but do get RFC 7710 supported), the CPE can be configuring clients for
Capport and ICMP coming multiple hops away.. validated by (yet to be
defined) material in the original DHCP/RA, is just fine... (better, maybe
the CPE reconfigures into a bridge and has a L2 capport in the NOC, which
can maybe help users identity exactly which machine has the virus....)

There is no harm, btw, in having RFC7710 *always* configured in networks
that support features like this... it could be a multi-purpose portal. RFC
7710 should always be ignored until (yet to be defined) notification is
received.

On Thu, Aug 24, 2017 at 4:55 PM, Martin Thomson <[email-masked]>
wrote:

> > * descope any solution that would improve the scenario where walled
> gardens
> > are (re-)activated
> >
> > * invent a new signal? something the nas is allowed to send to the ue,
> but
> > not icmp?
> >
> >
> > Gr., Vincent
> >
> >
> > Van: Captive-portals [[email-masked]] namens Tommy
> Pauly
> > [[email-masked]]
> problems
> one
> > As for several flows, I don't see what would stop an attacker from
> trying to
> > spoof several flows.
> >
> ICMP

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Aug 2017 12:09:10 +1000

Hmm, maybe we understand this very differently then.  I see PvD as
providing configuration in exactly the same way as 7710 does.

That is,

* 7710 says "here is the URL you go to for ???"  where "???" is one or
both of "web browsing" and "API" (see the API doc).  It doesn't really
say whether the endpoint is currently captive or not (and nor can it
do so).

* PvD, as I understand it, would say the same, though it might provide
separate "web browsing" and "API" URLs, if we accept that an API is
valuable (see below).  It *could* also act in the "API" role, and I
think that Tommy in particular finds that idea appealing, but my
understanding was that we would consider that to be a logically
distinct function.

If, as we seem to have agreed in Prague, consider API to be basically
reduced to "am I captive? y/n" and maybe "for how long? <time>" for
now.

You seem to be most concerned about the potential for an API that
could make claims about whether a given host is captive or not.  Is
that the source of your concerns here?

If we agree - as seem to, based on your comments here - that the
configuration of a URL has no effect until the host discovers that it
is captive (somehow), is this a concern more about the API than the
existence of a mechanism like PvD?

(NOC == NIC?)

On 25 August 2017 at 11:49, David Bird <[email-masked]> wrote:
> There are unique considerations when the captive portal "client" is a router
> and not the UE... In this example, no clients get 'released' from captivity
> - so, it doesn't really have to trace clients by IP address. The CPE
> firmware needs updating to have RFC7710 configurable via their management
> system -- this might be a good opportunity to have a minimal Capport ICMP
> based captive portal implemented completely in CPE firmware, perhaps Linux
> iptables w/Capport ICMP support. Assuming they don't do that (but do get RFC
> 7710 supported), the CPE can be configuring clients for Capport and ICMP
> coming multiple hops away.. validated by (yet to be defined) material in the
> original DHCP/RA, is just fine... (better, maybe the CPE reconfigures into a
> bridge and has a L2 capport in the NOC, which can maybe help users identity
> exactly which machine has the virus....)
>

---

From: David Bird <[email-masked]>
Date: Fri, 25 Aug 2017 06:11:41 -0700

Sorry, NOC == Network Operations Center (Data Center).

My concern isn't that an API *can* make claims about your captive state, it
is more:
- The implementation of the API/PvD web services will be highly varied --
in compliance to the RFC, integration with the infrastructure (RADIUS,
portal, etc), and easy to misconfigure.
- It separates enforcement for Capport devices from enforcement of
non-Capport devices, which has consequences... (*)
- It may very well make "Hotspots" more complicated, error prone, and
"broken"

(*) This question isn't rhetorical :-)  ... What will "First vendor with
PvD client" do when a new phone, and only that new phone, has problems at
(just for arguments sake) Chicago O'Hare?

- Complain to venue? (even though their friend isn't having problems)
- Tell the user to turn off PvD?
- Tell the user to use their old phone?
- UE vendor will start contacting venues?
- Start doing legacy probes on top of PvD?

My concern is that after all this work... UEs will still be doing legacy
probing...

On Thu, Aug 24, 2017 at 7:09 PM, Martin Thomson <[email-masked]>
wrote:

> router
> >> ICMP - 7710/PvD - you get a signal, but is it legit?  How do you
> validate
> >> it?
> >>
> >> > * accept icmp is a valid direction, and think of a way on how we can
> use
> >> > this securely in our use-case
> >> >
> >> >>> Right, I think the difference between an unreachable destination,
> and
> >> >>> a
> >> >>> captive portal or walled garden, is that we expect the captive
> portal
> >> >>> style
> >> >>> interaction to be an Operating System-level action, and one that
> will
> >> >>> have
> >> >>> network. You can certain use spoofed ICMP to disrupt connections,
> but
> >> >>> (a)
> >> >>> the user would notice and (b) you're not causing the Operating
> System
> >> >>> to
> >> >>> change behavior. When the OS thinks it is on a captive network or
> not,
> >> >>> it
> >> >>> be invisible to the user other than an icon change. I would be able
> to
> >> >>> go
> >> >>> think that wifi is a portal and switch to possibly expensive
> cellular
> >> >>> data.
> >> >>>
> >> >>>> On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti <
> [email-masked]>
> >> >>>> wrote:
> >> >>>>>

---

From: David Bird <[email-masked]>
Date: Thu, 31 Aug 2017 05:54:27 -0700

Sending to list...
---------- Forwarded message ----------
From: "Martin Thomson" <[email-masked]>
Date: Aug 30, 2017 3:52 PM
Subject: Re: [Captive-portals] Questions about PvD/API
To: "David Bird" <[email-masked]>
Cc:

sending that to the list would be helpful

On 30 August 2017 at 23:11, David Bird <[email-masked]> wrote:
> Part of the reason for confusion is that the "API" and "PvD" have a high
> potential to overlap, and I generally feel that they will be merged
somehow.
> I got the impression from PvD authors in Prague that PvD could certainly
> swallow the feature set of the API. So, without knowing exactly how the
API
> vs PvD will shake out, I generally lump them together.
>
> Re-looking at the drafts...
>
> PvD:
> - The core material of interest to Capport is now largely in Appendix B.
The
> main part actually seems find... though, not very useful. If someone
> *already* selected a WiFi network, do they really care about the name of
the
> network or the bandwidth? That data seems more important to know before
> association (during network selection), not after. Anyways,
> - Appendix B is where it gets more interesting -- and where I'm sure the
> authors plan to baby-step in more features. This is where it starts
> overstepping into 'enforcement' (and, frankly, should be triggering all
the
> same concern you have with ICMP; why doesn't it?):
>
>    [
>      {
>        "domains": ["example.com"]
>      },
>      {
>        "prefixes4": ["78.40.123.182/32","78.40.123.183/32"]
>      },
>      {
>        "beginDate": "2016-07-16T00:00:00Z",
>        "endDate": "2016-07-17T23:59:59Z",
>      },
>      {
>        "beginDate": "2016-06-20T00:00:00Z",
>        "endDate": "2016-07-19T23:59:59Z",
>        "trafficRemaining": 12000000
>      },
>      {
>        "throughputMax": 100000
>      }
>    ]
>
>    If the host tries to download data from example.com, the conditions
>    of the first elementary billing are fulfilled, so the host takes this
>    elementary billing, finds no cost indication in it and so deduces
>    that it is totally free.  If the host tries to exchange data with
>    foobar.com and the date is 2016-07-14T19:00:00Z, the conditions of
>    the first, second and third elementary billing are not fulfilled.
>
> API:
> - Hm.. that doc seems stripped down a bit too. It has a network object
which
> has a 'state', 'conditions', etc, and a value for 'bytes_remaining' ..
> (already overlaps?)
>
>
>
> On Sun, Aug 27, 2017 at 5:58 PM, Martin Thomson <[email-masked]>
> wrote:
>>
>> Hi David, I'm just trying to work out if the concern is with PvD or
>> the API to start with.  Baby steps because I want to make sure there
>> is no miscommunication.  Can you address that question please?  I
>> can't tell from your response here.
>>
>> On 25 August 2017 at 23:11, David Bird <[email-masked]> wrote:
>> > My concern isn't that an API *can* make claims about your captive
state,
>> > it
>> > is more:
>> > - The implementation of the API/PvD web services will be highly varied
>> > -- in
>> > compliance to the RFC, integration with the infrastructure (RADIUS,
>> > portal,
>> > client" do when a new phone, and only that new phone, has problems at
>> > (just
>> >> > iptables w/Capport ICMP support. Assuming they don't do that (but do
>> >> > get
>> >> > RFC
>> >> > coming multiple hops away.. validated by (yet to be defined)
material
>> >> > in
>> >> > the
>> >> > original DHCP/RA, is just fine... (better, maybe the CPE
reconfigures
>> >> > into a
>> >> > that support features like this... it could be a multi-purpose
>> >> > portal.
>> >> > RFC
>> >> >> > In this working group we acknowledged (welcomed) use cases that
go
>> >> >> > beyond
>> >> >> > allows detection that the walled garden is (re)activated after
>> >> >> > joining
>> >> >> > the
>> >> >> > network, need to be in place. The alternative to a signal would
be
>> >> >> > polling,
>> >> >> > Just focussing on signalling (without the semantics/api); I think
>> >> >> > that
>> >> >> > leaves us with three directions:
>> >> >> >
>> >> >> >
>> >> >> > * invent a new signal? something the nas is allowed to send to
the
>> >> >> > ue,
>> >> >> > If the client OS needs to add in heuristics to reach a certain
>> >> >> > volume
>> >> >> > of
>> >> >> > we're trying to solve for CAPPORT is "how much time do I have
>> >> >> > left",
>> >> >> > and
>> >> >> > properties seems to dramatically simplify the flow and trust
>> >> >> > model.
>> >> >> > However
>> >> >> > we do things, it seems like this information should be pull-able
>> >> >> > (even
>> >> >> > if it
>> >> >> > allows the client to open a connection on which changes are
pushed
>> >> >> > or
>> >> >> > protocols is little different, in terms of your criticism that it
>> >> >> > will
>> >> >> > lead
>> >> >> > don't think that's a valid argument - saying that if you
>> >> >> > misconfigure
>> >> >> > the
>> >> >> > network it won't work well is pretty much a tautology - but you
>> >> >> > were
>> >> >> > the
>> >> >> > one
>> >> >> >> before acting on it... especially when already connected. There
>> >> >> >> were
>> >> >> >> also
>> >> >> >> proposals to link the ICMP messages to the DHCP message somehow
>> >> >> >> so
>> >> >> >> that
>> >> >> >> ICMP
>> >> >> >> is 'authenticated' against the original DHCP. Theses are
solvable
>> >> >> >>> consequences on everything the device does while associated to
a
>> >> >> >>> given
>> >> >> >>> especially if that resource can be somehow signed, makes it
much
>> >> >> >>> harder for
>> >> >> >>> On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti
>> >> >> >>> <[email-masked]>
>> >> >> >>> wrote:
>> >> >> >>>
>> >> >> >>> A forged destination unreachable can't cause someone else's
>> >> >> >>> device
>> >> >> >>> to
>> >> >> >>>> On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti
>> >> >> >>>> <[email-masked]>
>> >> >> >>>> wrote:
>> >> >> >>>>>
>> >> >> >>>>> On Thu, Aug 24, 2017 at 10:40 PM, David Bird
>> >> >> >>>>> <[email-masked]>
>> >> >> >>>>> wrote:
>> >> >> >>>>>>
>> >> >> >>>>> It doesn't matter how hard it is to misconfigure, because it
>> >> >> >>>>> is
>> >> >> >>>>> trivial
>> >> >> >>>>> to forge.
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>

---

From: David Bird <[email-masked]>
Date: Thu, 31 Aug 2017 06:04:19 -0700

I will add Vincent's (valid) concern about API/PvD: It requires either
polling or push (over TCP, which does require keepalive for NAT traversal),
which means stations likely do not go idle on the network, and, in cases
where a captive portal is possible, but not probable, UEs still have to
maintain this API/PvD association if they want to ever get notified.

On Thu, Aug 31, 2017 at 5:54 AM, David Bird <[email-masked]> wrote:

> >> >> > system -- this might be a good opportunity to have a minimal
> Capport
> >> >> > ICMP
> >> >> > based captive portal implemented completely in CPE firmware,
> perhaps
> >> >> > Linux
> >> >> > 7710 should always be ignored until (yet to be defined)
> notification
> >> >> > is
> >> >> > received.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >> On 25 August 2017 at 06:58, Vincent van Dam <[email-masked]
> >
> >> >> >> wrote:
> >> >> >> > If these use cases are indeed in scope; signalling, or a
> solution
> >> >> >> > that
> >> >> >> > or doing some mitm on protocols that allow it. I think both
> mitm,
> >> >> >> > and
> >> >> >> > ICMP messages before trusting them, I think the design is
> flawed.
> >> >> >> > Beyond
> >> >> >> > On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti <
> [email-masked]>
> >> >> >> > wrote:
> >> >> >> >
> >> >> >> >> You are both describing decisions the UE makes... perhaps the
> UE
> >> >> >> >> waits
> >> >> >> >> for
> >> >> >> >> On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly <[email-masked]
> >
> >> >> >> >> wrote:
> >> >> >> >>>
> >> >> >> >>> consequences on everything the device does while associated
> to a
> >> >> >> >>> given
> >> >> >> >>> will change what network it considers primary/usable, which
> may
> >> >> >> >>> potentially
> >> >> >> >>> Having the UE fetch some resource in order to determine
> captive
> >> >> >> >>> state,
> >> >> >> >>> On Thu, Aug 24, 2017 at 11:29 PM, David Bird <
> [email-masked]>
> >> >> >> >>> wrote:
> >> >> >> >>>>

---

From: David Bird <[email-masked]>
Date: Thu, 31 Aug 2017 06:47:17 -0700

My remaining questions:

- What will "First vendor with PvD client" do when a new phone, and only
that new phone, has problems at (just for arguments sake) Chicago O'Hare?

- Can an API/PvD (in terms of captivity notification) be a solution for
https://www.ietf.org/mail-archive/web/captive-portals/current/msg00455.html
? (If not, does that show it's limitations?)

- And, a new question. I must be missing something... but, how does the API
or PvD identify UE/stations?
The API doc says:

5.1.1.  Associating User Equipment with its URL

   The CAPPORT API Server SHOULD associate an incoming request with a
   particular User Equipment consistently.  [TODO: specify how this
   would happen.]

This becomes a pretty important point because it can't be that each DHCP or
RA is custom formatted for each station with a UE specific URL. It also
needs to be a MUST if the API is returning information about
'bytes_remaining' and such. Or, does the UE self report it's MAC to the
API/PvD? The service needs some way of associating that API/PvD session
with the RADIUS accounting stream.

On Thu, Aug 31, 2017 at 6:04 AM, David Bird <[email-masked]> wrote:

>> > - The core material of interest to Capport is now largely in Appendix
>> B. The
>> > *already* selected a WiFi network, do they really care about the name
>> of the
>> >> >> > 7710 supported), the CPE can be configuring clients for Capport
>> and
>> >> >> > ICMP
>> >> >> >> option seems to imply captivity, though this is quite unclear
>> from
>> >> >> >> the
>> >> >> >> RFC).
>> >> >> >>
>> >> >> >> On 25 August 2017 at 06:58, Vincent van Dam <
>> [email-masked]>
>> >> >> >> wrote:
>> >> >> >> > In this working group we acknowledged (welcomed) use cases
>> that go
>> >> >> >> > beyond
>> >> >> >> > network, need to be in place. The alternative to a signal
>> would be
>> >> >> >> > polling,
>> >> >> >> > * accept icmp is a valid direction, and think of a way on how
>> we
>> >> >> >> > can
>> >> >> >> > use
>> >> >> >> > that, the information we'd like to get isn't just as simple as
>> a
>> >> >> >> > boolean
>> >> >> >> > "when to re-join the portal". Having a source we can query
>> about
>> >> >> >> > those
>> >> >> >> > On Fri, Aug 25, 2017 at 12:21 AM, David Bird <[email-masked]
>> >
>> >> >> >> > wrote:
>> >> >> >> >>
>> >> >> >> >> On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly <
>> [email-masked]>
>> >> >> >> >> wrote:
>> >> >> >> >>>
>> >> >> >> >>> change behavior. When the OS thinks it is on a captive
>> network
>> >> >> >> >>> or
>> >> >> >> >>> not,
>> >> >> >> >>> it
>> >> >> >> >>> be invisible to the user other than an icon change. I would
>> be
>> >> >> >> >>> able
>> >> >> >> >>> to
>> >> >> >> >>> go
>> >> >> >> >>>> Just like the rampant problem we see in ICMP
>> Dest-Unreachable
>> >> >> >> >>>> forgery
>> >> >> >> >>>> attacks?
>> >> >> >> >>>>