Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

[Tommy Pauly]

To chime in on the problem of misconfigured networks, I can picture three 
variations of issues:

1. If the PvD captivity information is unavailable due to misconfiguration, I 
would argue that an implementation MUST fall back to any legacy mechanisms like 
today’s HTTP probes. This means that on misconfigured networks that advertised 
a PvD server, we would have a delay after failing to fetch the information.
2. If the PvD information is wrong and lies saying that there is no captivity, 
when in fact there is, that could be detected by clients by the redirects that 
happen with future connections. This is essentially the situation we’re in 
today in which a captive network whitelists hosts such as captive.apple.com 
, and the user is forced to manually browse to a 
site and get redirected. This case is unfortunate, and exists today (and likely 
with any solution).
3. If the PvD information is wrong and lies that that there is captivity when 
there isn’t any, I would assume that the portal site would fail to connect or 
load, and would be ignored or dismissed by the system. The system could also 
run explicit probes in this case.

Between all three of these, there shouldn’t be any fundamental reason a device 
that is PvD-aware would fail to join a network that a legacy device was able to 
join. These cases may still involve probing, or waiting for connections to 
fail, but if we can hope that misconfiguration is not the norm (which must 
always be our hope), then we’re still benefiting most cases.

As for cases in which you join a network and then captivity starts partway 
through after expiration, I think the PvD solution is very elegant: we would 
still do explicit PvD discovery, and be altered that there is an expiration 
time on the access from the moment the network is joined.

Also, the configuration that’s accessed for the PvD captivity doesn’t need to 
be public—the information can be specific to a local network, and only needs to 
tell as much information as the network is willing to share for the device’s 
benefit.

Thanks,
Tommy

> On Jul 10, 2017, at 8:54 AM, Dave Dolson  wrote:
> 
> David,
> Is it fair to say your concerns are mainly about misconfigured networks?
> And this is the reason that devices will always be incented to probe 
> regardless of any method of provisioning?
>  
> -Dave
>  
>  
> From: David Bird [mailto:db...@google.com ] 
> Sent: Monday, July 10, 2017 9:39 AM
> To: Tommy Pauly
> Cc: Dave Dolson; Eric Vyncke (evyncke); captive-portals@ietf.org 
> 
> Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
>  
> On Sat, Jul 8, 2017 at 6:14 PM, Tommy Pauly  > wrote:
> [snip] 
> The idea with explicit PvD discovery is that it would, as a step, replace a 
> separate captive portal detection strategy.
>  
> My overall concern with discovery mechanisms that are specific to only 
> captive portals is that this is an extra step that is performed potentially 
> on every network association, that may have limited extensibility for 
> non-captive use cases. Since the explicit PvD design promises a way to 
> discover many properties beyond captivity, and is bootstrapped very early on 
> in the network association, it should hopefully allow clients to avoid the 
> extra probe.
> 
> 
>  
> I have concerns with the PvD approach, as described.
>  
> If a network was misconfigured to advertise a PvD that does have a (Internet 
> based) HTTPS server with a JSON file on it describing a captive portal 
> network, then devices utilizing the PvD information will *never* get on this 
> network while devices not using the PvD information do. That could be very 
> confusing to users and network administrators alike. 
>  
> If you have seen walled garden configurations for large networks, you will 
> notice a lot about the network operator's marketing partners. Indeed, many 
> walled gardens are much larger than the network really wants... sometimes 
> they just need to make things work in the garden. My point here is that 
> operators may not *want* to list out their walled garden configuration on a 
> public JSON file...
>  
> At the end of the day, I'd argue that the client *will always probe* -- 
> wether it means to or not... A networking using PvD could just advertise all 
> networks routes are available so that the device connects only to get caught 
> up in a captive portal redirect anyway... back to step 1 and captive portal 
> detection..
>  
> I'm also unclear how PvD would deal with scenarios where you might start out 
> with internet connectivity (e.g. "MAC Authentication") then to have a captive 
> portal return after a session timeout has occurred...
>  
>  
>  
>  
>  
> Note: the same “captivePortal” key is also defined in section 5.3 as a 
> Boolean. Should I consider this to be a defect in the draft, or am I missing 
> something?
>  
> The updated version of

Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

[Tommy Pauly]

Hi Dave,

> On Jul 10, 2017, at 8:54 AM, Dave Dolson  wrote:
> 
> At the last meeting, I think we heard, “PvDs can help solve this problem.”
> (This seems to me to be true.)
> Are the PvD authors backing away from this assertion?

No, we’re definitely still saying that PvDs can help solve the Captive Portal 
problem. The details of the JSON aren’t in latest revision of the main PvD 
document just to focus the scope of the draft, but the idea would be that the 
PvD provisioning information would be how you bootstrap captive portal 
discovery.

>  
> I think there are two aspects:
> 1.   The PvD data structures on the end-user device, which track 
> captivity state per PvD. (RFC 7556 discusses connectivity tests per PvD.)
> 2.   Whether the PvD protocol explicitly conveys the captive-portal 
> concept.
>  
> If I understand correctly, (1) could be achieved even if capport information 
> is conveyed in DHCP or RAs (vs. in the PvD protocol).
> However, that points to yet another API to query.

You’re correct. A client device can keep track of PvD information and already 
should associate captivity when discovered with the implicit PvD. Part (2) is 
saying that if we are doing external PvD discovery anyway, it should include 
captivity information. This is how we avoid the extra API to call.
>  
> I think that draft-bruneau-intarea-provisioning-domains has addressed a 
> problem more generic than the CAPPORT API problem.
> And therefore I’m feeling it is still worth pursuing.

Right, the draft is more generic than the captive portal right now. I could 
imagine that we make sure that the CAPPORT solution references and works well 
with PvDs.

Thanks,
Tommy
>  
>  
> I think Tommy makes a great point that there is value in explicitly 
> indicating, “this is not a captive portal”. This ought to speed up network 
> association.
>  
>  
> -Dave
>  
>  
>  
> From: tpa...@apple.com  [mailto:tpa...@apple.com 
> ] 
> Sent: Saturday, July 8, 2017 9:15 PM
> To: Dave Dolson
> Cc: Eric Vyncke (evyncke); captive-portals@ietf.org 
> ; David Bird
> Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
>  
>  
> 
> 
> On Jun 27, 2017, at 12:46 PM, Dave Dolson  > wrote:
>  
> Eric,
> Do I understand correctly from 
> https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-00#section-5.5
>  
> 
> that the intention is for the JSON key “captivePortal” to indicate that the 
> specified URL is to be visited by the browser to navigate the requirements 
> for exiting captivity?
>  
> If so, would you say this URL should be used in place of performing a capport 
> detection strategy (e.g., canary HTTP request)?
>  
> The idea with explicit PvD discovery is that it would, as a step, replace a 
> separate captive portal detection strategy.
>  
> My overall concern with discovery mechanisms that are specific to only 
> captive portals is that this is an extra step that is performed potentially 
> on every network association, that may have limited extensibility for 
> non-captive use cases. Since the explicit PvD design promises a way to 
> discover many properties beyond captivity, and is bootstrapped very early on 
> in the network association, it should hopefully allow clients to avoid the 
> extra probe.
> 
> 
>  
>  
>  
> Note: the same “captivePortal” key is also defined in section 5.3 as a 
> Boolean. Should I consider this to be a defect in the draft, or am I missing 
> something?
>  
> The updated version of the draft 
> (https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-01 
> ) 
> leaves out the specific keys for captive portals, and discusses it more 
> abstractly. That would be a good thing to nail down at the Prague meeting. If 
> PvD detection is done generically on network association, then a boolean or 
> some way to indicate that this is *not* a captive portal will allow the 
> device to not perform extra probing. If there is a captive network, we should 
> be able to get the page or instructions on how to get beyond captivity.
>  
> Thanks,
> Tommy
> 
> 
>  
> -Dave
>  
>  
>  
> From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com 
> ] 
> Sent: Sunday, June 25, 2017 8:27 PM
> To: Dave Dolson; captive-portals@ietf.org 
> Cc: David Bird
> Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
>  
> At least Erik Kline and myself are following the captive-portal list :-)
>  
> And the more we think about it, PvD could really be useful and we, the PvD 
> I-D authors, would be pleased to present at your WG
>  
> -éric
>  
> From: Captive-portals  > on behalf of Dave Dolson 
> m

Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

[Dave Dolson]

David,
Is it fair to say your concerns are mainly about misconfigured networks?
And this is the reason that devices will always be incented to probe regardless 
of any method of provisioning?

-Dave


From: David Bird [mailto:db...@google.com]
Sent: Monday, July 10, 2017 9:39 AM
To: Tommy Pauly
Cc: Dave Dolson; Eric Vyncke (evyncke); captive-portals@ietf.org
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

On Sat, Jul 8, 2017 at 6:14 PM, Tommy Pauly 
mailto:tpa...@apple.com>> wrote:
[snip]
The idea with explicit PvD discovery is that it would, as a step, replace a 
separate captive portal detection strategy.

My overall concern with discovery mechanisms that are specific to only captive 
portals is that this is an extra step that is performed potentially on every 
network association, that may have limited extensibility for non-captive use 
cases. Since the explicit PvD design promises a way to discover many properties 
beyond captivity, and is bootstrapped very early on in the network association, 
it should hopefully allow clients to avoid the extra probe.



I have concerns with the PvD approach, as described.

If a network was misconfigured to advertise a PvD that does have a (Internet 
based) HTTPS server with a JSON file on it describing a captive portal network, 
then devices utilizing the PvD information will *never* get on this network 
while devices not using the PvD information do. That could be very confusing to 
users and network administrators alike.

If you have seen walled garden configurations for large networks, you will 
notice a lot about the network operator's marketing partners. Indeed, many 
walled gardens are much larger than the network really wants... sometimes they 
just need to make things work in the garden. My point here is that operators 
may not *want* to list out their walled garden configuration on a public JSON 
file...

At the end of the day, I'd argue that the client *will always probe* -- wether 
it means to or not... A networking using PvD could just advertise all networks 
routes are available so that the device connects only to get caught up in a 
captive portal redirect anyway... back to step 1 and captive portal detection..

I'm also unclear how PvD would deal with scenarios where you might start out 
with internet connectivity (e.g. "MAC Authentication") then to have a captive 
portal return after a session timeout has occurred...





Note: the same “captivePortal” key is also defined in section 5.3 as a Boolean. 
Should I consider this to be a defect in the draft, or am I missing something?

The updated version of the draft 
(https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-01) 
leaves out the specific keys for captive portals, and discusses it more 
abstractly. That would be a good thing to nail down at the Prague meeting. If 
PvD detection is done generically on network association, then a boolean or 
some way to indicate that this is *not* a captive portal will allow the device 
to not perform extra probing. If there is a captive network, we should be able 
to get the page or instructions on how to get beyond captivity.

Thanks,
Tommy




-Dave



From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com]
Sent: Sunday, June 25, 2017 8:27 PM
To: Dave Dolson; captive-portals@ietf.org
Cc: David Bird
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

At least Erik Kline and myself are following the captive-portal list :-)

And the more we think about it, PvD could really be useful and we, the PvD I-D 
authors, would be pleased to present at your WG

-éric

From: Captive-portals 
mailto:captive-portals-boun...@ietf.org>> on 
behalf of Dave Dolson mailto:ddol...@sandvine.com>>
Date: Friday 23 June 2017 at 11:57
To: "captive-portals@ietf.org" 
mailto:captive-portals@ietf.org>>
Cc: David Bird mailto:db...@google.com>>
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

[resend with fewer recipients to avoid mailing list problems]

To echo David’s request,
> If the authors of the PvD concept (re-)present their I-D to the mailing list, 
> and stick around for discussion, that would be helpful.


From: David Bird [mailto:db...@google.com]
Sent: Wednesday, June 14, 2017 9:36 AM
To: Erik Kline
Cc: Gunther Nitzsche; Mark Townsley; Heiko Folkerts; Martin Thomson; 
captive-portals@ietf.org; Livingood, Jason; 
Herzig, Willi; Warren Kumari; Dave Dolson
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

On Sun, Jun 11, 2017 at 11:17 PM, Erik Kline 
mailto:e...@google.com>> wrote:
I'm not sure we have enough input on whether 511 is useful or not.  There 
seemed to be some suggestion it would help, and some that it wouldn't.  Perhaps 
one question we could ask is whether it's harmful?  And if we agree it's not 
harmful, is it worth developing some recommendations for its use?

Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

[Dave Dolson]

At the last meeting, I think we heard, “PvDs can help solve this problem.”
(This seems to me to be true.)
Are the PvD authors backing away from this assertion?

I think there are two aspects:

1.   The PvD data structures on the end-user device, which track captivity 
state per PvD. (RFC 7556 discusses connectivity tests per PvD.)

2.   Whether the PvD protocol explicitly conveys the captive-portal concept.

If I understand correctly, (1) could be achieved even if capport information is 
conveyed in DHCP or RAs (vs. in the PvD protocol).
However, that points to yet another API to query.

I think that draft-bruneau-intarea-provisioning-domains has addressed a problem 
more generic than the CAPPORT API problem.
And therefore I’m feeling it is still worth pursuing.


I think Tommy makes a great point that there is value in explicitly indicating, 
“this is not a captive portal”. This ought to speed up network association.


-Dave



From: tpa...@apple.com [mailto:tpa...@apple.com]
Sent: Saturday, July 8, 2017 9:15 PM
To: Dave Dolson
Cc: Eric Vyncke (evyncke); captive-portals@ietf.org; David Bird
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"




On Jun 27, 2017, at 12:46 PM, Dave Dolson 
mailto:ddol...@sandvine.com>> wrote:

Eric,
Do I understand correctly from 
https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-00#section-5.5
that the intention is for the JSON key “captivePortal” to indicate that the 
specified URL is to be visited by the browser to navigate the requirements for 
exiting captivity?

If so, would you say this URL should be used in place of performing a capport 
detection strategy (e.g., canary HTTP request)?

The idea with explicit PvD discovery is that it would, as a step, replace a 
separate captive portal detection strategy.

My overall concern with discovery mechanisms that are specific to only captive 
portals is that this is an extra step that is performed potentially on every 
network association, that may have limited extensibility for non-captive use 
cases. Since the explicit PvD design promises a way to discover many properties 
beyond captivity, and is bootstrapped very early on in the network association, 
it should hopefully allow clients to avoid the extra probe.





Note: the same “captivePortal” key is also defined in section 5.3 as a Boolean. 
Should I consider this to be a defect in the draft, or am I missing something?

The updated version of the draft 
(https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-01) 
leaves out the specific keys for captive portals, and discusses it more 
abstractly. That would be a good thing to nail down at the Prague meeting. If 
PvD detection is done generically on network association, then a boolean or 
some way to indicate that this is *not* a captive portal will allow the device 
to not perform extra probing. If there is a captive network, we should be able 
to get the page or instructions on how to get beyond captivity.

Thanks,
Tommy



-Dave



From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com]
Sent: Sunday, June 25, 2017 8:27 PM
To: Dave Dolson; captive-portals@ietf.org
Cc: David Bird
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

At least Erik Kline and myself are following the captive-portal list :-)

And the more we think about it, PvD could really be useful and we, the PvD I-D 
authors, would be pleased to present at your WG

-éric

From: Captive-portals 
mailto:captive-portals-boun...@ietf.org>> on 
behalf of Dave Dolson mailto:ddol...@sandvine.com>>
Date: Friday 23 June 2017 at 11:57
To: "captive-portals@ietf.org" 
mailto:captive-portals@ietf.org>>
Cc: David Bird mailto:db...@google.com>>
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

[resend with fewer recipients to avoid mailing list problems]

To echo David’s request,
> If the authors of the PvD concept (re-)present their I-D to the mailing list, 
> and stick around for discussion, that would be helpful.


From: David Bird [mailto:db...@google.com]
Sent: Wednesday, June 14, 2017 9:36 AM
To: Erik Kline
Cc: Gunther Nitzsche; Mark Townsley; Heiko Folkerts; Martin Thomson; 
captive-portals@ietf.org; Livingood, Jason; 
Herzig, Willi; Warren Kumari; Dave Dolson
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

On Sun, Jun 11, 2017 at 11:17 PM, Erik Kline 
mailto:e...@google.com>> wrote:
I'm not sure we have enough input on whether 511 is useful or not.  There 
seemed to be some suggestion it would help, and some that it wouldn't.  Perhaps 
one question we could ask is whether it's harmful?  And if we agree it's not 
harmful, is it worth developing some recommendations for its use?


In of itself, I don't believe it is harmful. However, if vendors use it as a 
reason to continue to terminate TLS connection in order to deliver the 511, 
th