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

[Dave Dolson]

I agree about viewing ICMP as a hint for the user equipment to visit the 
API. The UE should trust nothing in the ICMP message itself.


And querying the API should be harmless (GET having no side-effects), 
aside from the load imposed on it. So we should say that the UE must 
rate-limit ICMP-triggered API visits.  Example wording: "The UE MUST 
rate-limit ICMP-triggered API requests to once every 5s."


We could get fancy with back-off retries, or allowing the API to specify 
the rate limit, but my main point is that the ICMP message does not 
require any sort of authentication if we make a spoofed message harmless.


-Dave


On 2018-03-20 11:29 AM, Lorenzo Colitti wrote:
Per discussion at the mike today on what we should do with the ICMP 
unreachable draft - here are some properties I think are necessary in 
a hint to the UE that the captive portal is closed.


1. The notification should not be easy to spoof. This is easiest to do 
by making it a hint to the UE that it should talk to the API.


  * An ICMP message by itself is not secure. For example, it's trivial
for an off-path attacker to generate ICMP messages for sessions
from legitimate UEs to :443. Getting a UE to trust
such a message only requires getting the ephemeral port right, and
many OSes have a quite limited range of ephemeral ports.
  * Tero points out that if we do want to secure such a message, then
we should not roll our own security but should use an existing,
secure protocol such as IPsec.


2. It should be possible to send the notification *before* the captive 
portal closes, to facilitate seamless connectivity. Ideally the user 
should be able to re-up the captive portal without having to wait 
until the network is dead or the device has switched to another network.


3. The notification should not be on a per-destination basis. A hint 
that conveys the information "you can reach facebook, but to reach CNN 
you need to upgrade to another service plan" is not technically 
infeasible but is unlikely ever to reach WG and IETF consensus and 
therefore I think we should not spend our time talking about it.


4. I'm not sure whether it's possible for the hint to be anything more 
than a binary "you are or will very soon be captive". Saying things 
like "an upgrade opportunity is available" may be hard to encode.


Cheers,
Lorenzo


___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals


___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] I-D Action: draft-ietf-capport-architecture-00.txt

[Dave Dolson]

Tommy,
Thanks for the careful review.
Please see inline [DD] comments.
Changes I've made can be seen on github.
https://github.com/capport-wg/architecture/commit/7aadf5a140b4876b074e09b6387382d77430c301


As for the unresolved issues below, after some list discussion we should raise 
issues in github. See "*issue*" below.

-Dave


-Original Message-
From: tpa...@apple.com [mailto:tpa...@apple.com] 
Sent: Thursday, November 2, 2017 7:59 PM
To: captive-portals@ietf.org; draft-ietf-capport-architect...@ietf.org
Subject: Re: [Captive-portals] I-D Action: 
draft-ietf-capport-architecture-00.txt

Hi Kyle, Dave,

Thanks for updating the architecture document! It's nicely written, and serves 
as a very good summary of the state of our collective thoughts in the WG.

I've just done a pass of a review of the document, and wanted to share my 
notes/thoughts with you and the rest of the group for discussion. Details below!

Best,
Tommy


Section 1:

The principles in general are great!

I’m not sure about this one:

“Solutions SHOULD allow a device to be alerted that it is in a
  captive network when attempting to use any application on the
  network.  (Versus requiring a user to visit a clear-text HTTP site
  in order to receive a notification.)”

I would possible modify the requirement to be:

“Solutions SHOULD allow a device to be alerted that it is in a
captive network before and in response to any attempt by 
an application to use the network.”

It’s very similar, but we’re likely fine if we know before the attempt (as part 
of attachment) or as a notification in response to a failed connection.
[DD] I think we could do this as two principles: (a) notification when using 
any protocol and (b) querying before using data. So would it be acceptable to 
add a NEW bullet:
[DD] "Solutions SHOULD allow a device to learn that it is in a captive network 
before any application attempts to use the network."
[DD] I will make that change on github, presuming it is OK.

Section 1: I would remove the parentheses around the statement “(However, this 
document does not yet…”
[DD] OK, done.

Section 1: I don’t see a large different between the mechanism “End-user 
devices are notified of captivity with ICMP/ICMP6” and “Receipt of the 
ICMP/ICMP6 messages informs an end-user device”. Is this just trying to split 
the network behavior from the device behavior?
[DD] Yes, I think these 3 bullets identify the things that happen. In the 2nd 
bullet "devices are notified". In the 3rd bullet, "device SHOULD query the 
provisioned API". 
[DD] Personally, I think it is important that the 3rd bullet is independent. 
There might be reasons for not implementing that behavior.

Section 2.1: I would upgrade distinguishing Captive Portal API per-interface to 
a SHOULD from a MAY. While mPvD is a way to view it, any UE that has multiple 
interfaces (PvDs) really should not be treating all as captive, if only one is 
captive. Captive servers are prime examples of resources that are likely local 
to your attachment.
[DD] I agree that was our intent. I will update it.

Section 2.2.2: The summary of the PvD approach is good. We should update the 
references to [draft-ietf-intarea-provisioning-domains].
[DD] Reference updated.

Later on, in Section 6, you mention how PvDs are trying to tie the authenticity 
of the JSON API server to the RA/DHCP provisioning; that may be a useful point 
to bring up to the initial discussion in 2.2.2.
[DD] Would it be appropriate to say, "The PvD security model provides secure 
binding between the information provided by the trusted Router Advertisement, 
and the HTTPS server." ?
[DD] Tentatively added to the document. 

Areas I’d like to discuss with the group around PvDs, or the currently 
specified DHCP option:
• Clearly, the DHCP option needs more specification to point to an API 
(protocol, etc) beyond the current RFC, as discussed in 2.2.1. I’d love to see 
this update as opportunity for 2.2.1 and 2.2.2 to converge, however that makes 
most sense.
[DD] Yes, it seems we should update or deprecate RFC7710. [*issue*]

• A difference of the PvD option is that it allows for finer 
granularity, i.e. that you can have multiple PvDs/access routes on a single 
layer 2 interface (two uplinks on one Wi-Fi). One may be captive, the other 
not. Of course, we can specify that the DHCP/RA option for CAPPORT API URL will 
be associated with the PvD that shares the RA packet, so that’s solvable.
[DD] Why wouldn't RFC7710 apply per route as well? (If clarified.)

• We need to have a story around authentication that the CAPPORT API is 
actually provisioned by the same entity that provides the DHCP/RA. That can 
either be an auth option separately, or by using authentication of the PvD if 
we tie the captive option to a PvD.
[DD] I think everyone would agree it is the same business entity. Otherwise, 
I'm not sure I appreciate what you are saying.

• One 

Re: [Captive-portals] client identifying info between API and enforcement

[Dave Dolson]

> Not to mention, there is (currently) no guarantee that the IP address
> the device uses for interacting with the portal is necessarily the
> same as the newly created address that needs to be used

So having the client explicitly mention the IP addresses in the message is a 
good idea, vs.
using addresses implied from the API client.


-Dave


-Original Message-
From: Erik Kline [mailto:e...@google.com] 
Sent: Friday, October 20, 2017 9:39 AM
To: Dave Dolson
Cc: Kyle Larose; captive-portals@ietf.org; David Bird
Subject: Re: client identifying info between API and enforcement

With temporary addresses being created on the fly whenever desired,
the user could be perpetually bombarded with non-stop portal
interactions.

Not to mention, there is (currently) no guarantee that the IP address
the device uses for interacting with the portal is necessarily the
same as the newly created address that needs to be used (speaking of
IPv6 only; in IPv4 I think we all accept devices really only get one
and only one address).

Clearly if the enforcement box is on the same link as the shared
prefix it's a solvable problem, right?  (just record {l2, l3} pairs)

The issue is then one of what to do about architectures where the
enforcement point is not on the same link as a shared prefix?  In a
deeply multi-tiered architecture this could get really difficult...
hmm...

On 20 October 2017 at 21:19, Dave Dolson <ddol...@sandvine.com> wrote:
> There also needs to be a basis for enforcement, i.e., the firewall 
> block/allow rules. This must be something carried in every packet.
> I think the user IP address is the best candidate.
>
> In some types of access, users are granted /64 IPv6 prefixes, from which 
> devices can choose the address. In such cases, the enforcement can be based 
> on the prefixes.
>
> ‎If multiple users are sharing a prefix, I see no alternative to having the 
> user device register each address to be used.
>
> The initial capport conversation could have the server produce a token for 
> later use. The client would generally be motivated to use the token in 
> subsequent updates vs starting a new session.
>
>
> David Dolson
> Sandvine
>   Original Message
> From: Erik Kline
> Sent: Friday, October 20, 2017 7:39 AM
> To: Kyle Larose
> Cc: Dave Dolson; captive-portals@ietf.org; David Bird
> Subject: Re: client identifying info between API and enforcement
>
>
> 
>
> In the abstract we could define the requirements for what could
> replace MAC address.  The MAC address is really just a "token" that
> the enforcement point adds to the URL and then gets it back from the
> API-serving element (AIUI).
>
> It could just as well be HMAC("my c00l secr3t", )
> which, when passed back to the enforcement point is looked up in some
> hash that can expire old entries to find the mapping that identifies
> the client.
>
> But that still leaves the issue of how does that "token" get into the
> API URL in the first place.  Currently, I have seen what looks like
> the enforcement point rewriting URLs to insert this stuff.  I just
> think we should be explicit in calling out what we think needs calling
> out in this area.  (if for no other reason than it might become
> "operational guidance" if someone wants to write such a doc in the
> future)
>
> The issue of link-layer token to IP address policy is a somewhat
> separate discussion, I feel.  We definitely shouldn't give IPv6 SLAAC
> addresses any grief though.  And to me, that points toward the token
> being fairly well tied to the link-layer, though of course it can be
> made an opaque token (opaque to everything bug the enforcement
> device(s)).
>
> On 20 October 2017 at 00:10, Kyle Larose <klar...@sandvine.com> wrote:
>> Is another way of looking at this problem to consider defining the identity 
>> of the user equipment?
>>
>> From the perspective of the enforcement device, it's probably the source MAC 
>> address or source IP (or both) of the packets being sent through it. It's 
>> hard to spoof that without wrecking the network, right?
>>
>> But, if we intend on having the API server potentially live elsewhere in the 
>> network, those identifying characteristics may not be available in the 
>> requests being sent to that server, or if they are, they may be different 
>> due to intermediate devices such as NAT, routers, etc.
>>
>> If the user equipment understands its identity, then it can always put that 
>> into requests. As long as everyone agrees on what constitutes the identify, 
>> we're good. That sort of aligns with my earlier email about potentially 
>> negotiating what identifies a user equipment.
>>
>> However, what 

Re: [Captive-portals] client identifying info between API and enforcement

[Dave Dolson]

Erik,
Good questions.

Some options:

(a) enforcement should be done at the access layer.
In that case we'd have to support multiple types of access-specific identities 
(MAC address, IMSI/IMEI, ...)

(b) Is it reasonable to require DHCPv6 (either stateful or using prefix 
delegation) at captive portals, excluding SLAAC?


I think it's interesting to consider the tethered and virtual-machine 
use-cases. 
I'm on the fence about whether these devices should be considered independent 
agents or fall under the session of the parent device.


-Dave



-Original Message-
From: Erik Kline [mailto:e...@google.com] 
Sent: Friday, October 20, 2017 9:39 AM
To: Dave Dolson
Cc: Kyle Larose; captive-portals@ietf.org; David Bird
Subject: Re: client identifying info between API and enforcement

With temporary addresses being created on the fly whenever desired,
the user could be perpetually bombarded with non-stop portal
interactions.

Not to mention, there is (currently) no guarantee that the IP address
the device uses for interacting with the portal is necessarily the
same as the newly created address that needs to be used (speaking of
IPv6 only; in IPv4 I think we all accept devices really only get one
and only one address).

Clearly if the enforcement box is on the same link as the shared
prefix it's a solvable problem, right?  (just record {l2, l3} pairs)

The issue is then one of what to do about architectures where the
enforcement point is not on the same link as a shared prefix?  In a
deeply multi-tiered architecture this could get really difficult...
hmm...

On 20 October 2017 at 21:19, Dave Dolson <ddol...@sandvine.com> wrote:
> There also needs to be a basis for enforcement, i.e., the firewall 
> block/allow rules. This must be something carried in every packet.
> I think the user IP address is the best candidate.
>
> In some types of access, users are granted /64 IPv6 prefixes, from which 
> devices can choose the address. In such cases, the enforcement can be based 
> on the prefixes.
>
> ‎If multiple users are sharing a prefix, I see no alternative to having the 
> user device register each address to be used.
>
> The initial capport conversation could have the server produce a token for 
> later use. The client would generally be motivated to use the token in 
> subsequent updates vs starting a new session.
>
>
> David Dolson
> Sandvine
>   Original Message
> From: Erik Kline
> Sent: Friday, October 20, 2017 7:39 AM
> To: Kyle Larose
> Cc: Dave Dolson; captive-portals@ietf.org; David Bird
> Subject: Re: client identifying info between API and enforcement
>
>
> 
>
> In the abstract we could define the requirements for what could
> replace MAC address.  The MAC address is really just a "token" that
> the enforcement point adds to the URL and then gets it back from the
> API-serving element (AIUI).
>
> It could just as well be HMAC("my c00l secr3t", )
> which, when passed back to the enforcement point is looked up in some
> hash that can expire old entries to find the mapping that identifies
> the client.
>
> But that still leaves the issue of how does that "token" get into the
> API URL in the first place.  Currently, I have seen what looks like
> the enforcement point rewriting URLs to insert this stuff.  I just
> think we should be explicit in calling out what we think needs calling
> out in this area.  (if for no other reason than it might become
> "operational guidance" if someone wants to write such a doc in the
> future)
>
> The issue of link-layer token to IP address policy is a somewhat
> separate discussion, I feel.  We definitely shouldn't give IPv6 SLAAC
> addresses any grief though.  And to me, that points toward the token
> being fairly well tied to the link-layer, though of course it can be
> made an opaque token (opaque to everything bug the enforcement
> device(s)).
>
> On 20 October 2017 at 00:10, Kyle Larose <klar...@sandvine.com> wrote:
>> Is another way of looking at this problem to consider defining the identity 
>> of the user equipment?
>>
>> From the perspective of the enforcement device, it's probably the source MAC 
>> address or source IP (or both) of the packets being sent through it. It's 
>> hard to spoof that without wrecking the network, right?
>>
>> But, if we intend on having the API server potentially live elsewhere in the 
>> network, those identifying characteristics may not be available in the 
>> requests being sent to that server, or if they are, they may be different 
>> due to intermediate devices such as NAT, routers, etc.
>>
>> If the user equipment understands its identity, then it can always put that 
>> into requests. As long as everyone agrees on what cons

Re: [Captive-portals] client identifying info between API and enforcement

[Dave Dolson]

Or change MAC addresses at will?
Each change could be handled as a new capport session.


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Monday, October 16, 2017 11:01 AM
To: Dave Dolson
Cc: Erik Kline; Kyle Larose; captive-portals@ietf.org; David Bird
Subject: Re: [Captive-portals] client identifying info between API and 
enforcement

On Mon, Oct 16, 2017 at 11:23 PM, Dave Dolson 
<ddol...@sandvine.com<mailto:ddol...@sandvine.com>> wrote:
I infer you mean the MAC address is required so that the portal can open/close 
the firewall using it as a filter.
I'd prefer to see this done at the Internet layer (AKA layer3), with IPv4/6 
addresses, to avoid limiting usefulness to a particular access technology.

How do you do that when devices can create new IPv6 addresses at will?
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] [adoption call] draft-donnelly-capport-detection

[Dave Dolson]

I support adopting the API document, expecting some changes to the details of 
the API itself, which I believe the authors also said they expected.

David Dolson
Sandvine
  Original Message
From: Erik Kline
Sent: Wednesday, August 30, 2017 7:04 AM
To: captive-portals@ietf.org
Cc: martin.thom...@gmail.com
Subject: [Captive-portals] [adoption call] draft-donnelly-capport-detection


All,

As indicated in the minutes from Prague
[https://datatracker.ietf.org/doc/minutes-99-capport/], there was a
general hum in favor of the API document:

"""
4. API document: do we need a milestone? Humming: in favor.
5. Is this document a good basis. Humming in favor.


This email is to initiate a two week call for adoption for:

https://datatracker.ietf.org/doc/draft-donnelly-capport-detection/

Feedback requested, even if only to restate an opinion expressed in Prague.

Thanks,
-Erik

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] [adoption call] draft-larose-capport-architecture

[Dave Dolson]

As one of the authors, I support adoption.

David Dolson
Sandvine
  Original Message
From: Erik Kline
Sent: Wednesday, August 30, 2017 7:04 AM
To: captive-portals@ietf.org
Cc: martin.thom...@gmail.com
Subject: [Captive-portals] [adoption call] draft-larose-capport-architecture


All,

As indicated in the minutes from Prague
[https://datatracker.ietf.org/doc/minutes-99-capport/], there was a
general hum in favor of the architecture document:

"""
1. for arch doc, do we want a milestone for architecture. Humming: in favor.
2. is the document a good basis for the milestone? Humming: in favor.
"""

This email is to initiate a two week adoption call for:

https://datatracker.ietf.org/doc/draft-larose-capport-architecture/

Feedback requested, even if only to restate an opinion expressed in Prague.

Thanks,
-Erik

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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 
<tpa...@apple.com<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<mailto: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 
<captive-portals-boun...@ietf.org<mailto:captive-portals-boun...@ietf.org>> on 
behalf of Dave Dolson <ddol...@sandvine.com<mailto:ddol...@sandvine.com>>
Date: Friday 23 June 2017 at 11:57
To: "captive-portals@ietf.org<mailto:captive-portals@ietf.org>" 
<captive-portals@ietf.org<mailto:captive-portals@ietf.org>>
Cc: David Bird <db...@google.com<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<mailto: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 
<e...@google.com<mailto:e...@google.com>> wrote:
I'm

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 
<ddol...@sandvine.com<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<mailto: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 
<captive-portals-boun...@ietf.org<mailto:captive-portals-boun...@ietf.org>> on 
behalf of Dave Dolson <ddol...@sandvine.com<mailto:ddol...@sandvine.com>>
Date: Friday 23 June 2017 at 11:57
To: "captive-portals@ietf.org<mailto:captive-portals@ietf.org>" 
<captive-portals@ietf.org<mailto:captive-portals@ietf.org>>
Cc: David Bird <db...@google.com<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<mailto: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 
<e...@google.com<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

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

[Dave Dolson]

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)?



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?

-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 <captive-portals-boun...@ietf.org> on behalf of Dave 
Dolson <ddol...@sandvine.com>
Date: Friday 23 June 2017 at 11:57
To: "captive-portals@ietf.org" <captive-portals@ietf.org>
Cc: David Bird <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 
<e...@google.com<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, 
then perhaps it is a bit harmful - or at least misleading. As the world moves 
to TLS (and QUIC), I think the time for the 511 code has already passed, to 
some degree. That, combined with the fact you may still have browsers not 
handling that return code properly, I don't see the value for any vendor or 
venue to implement this.


As for the ICMP unreachable option, I certainly don't think it would be harmful 
(with the extra URL bits removed for now).  Is that something we wish to 
progress?


I will work on a new draft that is only the basics. The additional fields could 
always be add in their own draft as extensions.


Given that we're probably looking at a portal detection method based on 
entirely new work, it seems to me we're free to look at new things like 
utilizing the PVD detection scheme (DNS queries for "provisioning domain 
names", followed by other interaction still TBD).  Have the portal implementors 
reviewed this and given consideration as to whether its useful?  (I think of 
the discovery of the portal and subsequent interaction with it as 2 separate 
processes conducted, obviously, in serial.)


I believe there are several talking points here, as the PvD method seems to 
have several possible implementations.

I think requiring Ipv6 to configure Ipv4 is weird (I believe that was one 
proposed method to convey configuration)

Several points I made in the thread "Arguments against any Capport API" 
regarding a web service - detached from the NAS - controlling the UE/station I 
think are relevant.

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.


Thoughts?

___
Captive-portals mailing list
Captive-portals@ietf.org<mailto:Captive-portals@ietf.org>
https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] practicality of 511 HTTP status code

[Dave Dolson]

Regardless of how 511 is handled, I think it is orthogonal to the work at hand. 
It only helps with the clear-text http, which I think operators would be 
resistant to change.



David Dolson
Sandvine
  Original Message
From: Julian Reschke
Sent: Tuesday, June 27, 2017 11:55 AM
To: Dave Dolson; Mark Nottingham
Cc: captive-portals@ietf.org
Subject: Re: [Captive-portals] practicality of 511 HTTP status code


On 2017-06-27 16:56, Dave Dolson wrote:
> Mark, thanks for the info about 511.
>
> But to the working group, I think this discussion about HTTP status codes is 
> a distraction.
>
> I think the ICMP approach is a superior solution that doesn't require 
> modification of transport-layer data.
>
> Redirection of clear-text HTTP is an existing practice. It will continue for 
> some time;

Yes.

> but there is no need to tweak it, since tweaks would not be recognized by 
> existing software anyhow...

Existing software == browsers? They should be totally OK with 511. Do
you have evidence to the contrary?

> ...

Best regards, Julian

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] practicality of 511 HTTP status code

[Dave Dolson]

Mark, thanks for the info about 511.

But to the working group, I think this discussion about HTTP status codes is a 
distraction.

I think the ICMP approach is a superior solution that doesn't require 
modification of transport-layer data.

Redirection of clear-text HTTP is an existing practice. It will continue for 
some time;
but there is no need to tweak it, since tweaks would not be recognized by 
existing software anyhow...

Redirection of encrypted HTTP should be discouraged.
The ICMP notification allows HTTPS traffic (and all other IPv4/6 traffic) to be 
notified of the captive network.




-Dave




-Original Message-
From: Mark Nottingham [mailto:m...@mnot.net] 
Sent: Friday, June 23, 2017 9:32 PM
To: Dave Dolson
Cc: Julian F. Reschke; Vincent van Dam; David Bird; Erik Kline; 
captive-portals@ietf.org
Subject: Re: [Captive-portals] practicality of 511 HTTP status code

The idea behind 511 was that it's an explicit signal that the response is NOT 
from the origin.

The payload will be displayed by browsers that don't understand its semantics, 
and you can use JS or http-equiv redirects if you want to send that user 
somewhere else.

The real value only comes when a) browsers understand its semantics, and b) a 
payload format is designed to do something interesting with them.

Cheers,



> On 24 Jun 2017, at 4:53 am, Dave Dolson <ddol...@sandvine.com> wrote:
> 
> Probably all of those codes are used, as well as 200 (with content).
> We could debate which is best, but that's a distraction, since we want 
> portals to stop pretending to be the real end-point.
> (FWIW, I think 301 is a bad idea, since later requests should try the real 
> URI again.)
> 
> My hypothesis is that 511 is an acceptable thing to send an old (pre-RFC6585) 
> device, when there is no expectation of causing user interaction.
> 
> -Dave
> 
> -Original Message-
> From: Julian Reschke [mailto:julian.resc...@gmx.de] 
> Sent: Friday, June 23, 2017 2:34 PM
> To: Dave Dolson; Vincent van Dam; David Bird; Erik Kline
> Cc: captive-portals@ietf.org
> Subject: Re: [Captive-portals] practicality of 511 HTTP status code
> 
> On 2017-06-23 20:11, Dave Dolson wrote:
>> It seems 511 is probably better than 30x for non-browser 
>> requests-clearly an error instead of redirecting to something unexpected.
>> 
>> Is 511 likely to be OK for old IoT devices? Probably a better outcome 
>> than 307.
>> ...
> 
> FWIW, why is *307* desirable in the first place? Wouldn't it be better to use 
> 301/302 or even 303?
> 
> Best regards, Julian
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

--
Mark Nottingham   https://www.mnot.net/

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Requests for capport survey items

[Dave Dolson]

Mariko,
I think the survey of detection strategies is useful.
Are you going to publish an I-D (or other document) describing what you have 
collected?

(I would like to be able to reference the information in 
draft-larose-capport-architecture)

-Dave


From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
mariko kobayashi
Sent: Wednesday, May 3, 2017 9:24 AM
To: captive-portals@ietf.org
Subject: [Captive-portals] Requests for capport survey items

Hi,

As I talked in IETF98 "Japanese Survey",
I will conduct a further survey by implementing tool(app?).
I plan to develop the survey tool on Android app or Linux(Raspberry Pi), but
if there are some volunteers, we can work on this survey on several 
platforms(iOS/Android).

I would like to look for survey items from capport WG members, so
please let me know what you want to see and any ideas for survey method.
I also welcome survey items which should be surveyed for preparing ICMP, API or 
some future solutions.

I just have started to edit store information for the survey here(will continue 
to edit).
https://hackmd.io/BwJgbALARgxlwFo4HYCcCIEZWKgEwGYQFkBWKAMwr2AIAYKwKg==?both
(URL is opened for everyone in HACKMD)

I appreciate if **all OS vendors** open about what checks they use for Captive 
Portal Detection,
so please let me know or feel free to edit the information.

Best,
Mariko


--

⭐︎



　Mariko Kobayashi(a...@sfc.wide.ad.jp)

　Keio Univ. SFC M1

  Jun Murai Lab./WIDE Project/ao(あお)

　

---⭐︎
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

[Dave Dolson]

[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 
<e...@google.com<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, 
then perhaps it is a bit harmful - or at least misleading. As the world moves 
to TLS (and QUIC), I think the time for the 511 code has already passed, to 
some degree. That, combined with the fact you may still have browsers not 
handling that return code properly, I don't see the value for any vendor or 
venue to implement this.


As for the ICMP unreachable option, I certainly don't think it would be harmful 
(with the extra URL bits removed for now).  Is that something we wish to 
progress?


I will work on a new draft that is only the basics. The additional fields could 
always be add in their own draft as extensions.


Given that we're probably looking at a portal detection method based on 
entirely new work, it seems to me we're free to look at new things like 
utilizing the PVD detection scheme (DNS queries for "provisioning domain 
names", followed by other interaction still TBD).  Have the portal implementors 
reviewed this and given consideration as to whether its useful?  (I think of 
the discovery of the portal and subsequent interaction with it as 2 separate 
processes conducted, obviously, in serial.)


I believe there are several talking points here, as the PvD method seems to 
have several possible implementations.

I think requiring Ipv6 to configure Ipv4 is weird (I believe that was one 
proposed method to convey configuration)

Several points I made in the thread "Arguments against any Capport API" 
regarding a web service - detached from the NAS - controlling the UE/station I 
think are relevant.

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.


Thoughts?

___
Captive-portals mailing list
Captive-portals@ietf.org<mailto:Captive-portals@ietf.org>
https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] practicality of 511 HTTP status code

[Dave Dolson]

Probably all of those codes are used, as well as 200 (with content).
We could debate which is best, but that's a distraction, since we want portals 
to stop pretending to be the real end-point.
(FWIW, I think 301 is a bad idea, since later requests should try the real URI 
again.)

My hypothesis is that 511 is an acceptable thing to send an old (pre-RFC6585) 
device, when there is no expectation of causing user interaction.

-Dave

-Original Message-
From: Julian Reschke [mailto:julian.resc...@gmx.de] 
Sent: Friday, June 23, 2017 2:34 PM
To: Dave Dolson; Vincent van Dam; David Bird; Erik Kline
Cc: captive-portals@ietf.org
Subject: Re: [Captive-portals] practicality of 511 HTTP status code

On 2017-06-23 20:11, Dave Dolson wrote:
> It seems 511 is probably better than 30x for non-browser 
> requests-clearly an error instead of redirecting to something unexpected.
> 
> Is 511 likely to be OK for old IoT devices? Probably a better outcome 
> than 307.
> ...

FWIW, why is *307* desirable in the first place? Wouldn't it be better to use 
301/302 or even 303?

Best regards, Julian

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

[Dave Dolson]

Gunther,
My view is that new mechanisms we propose will be used in addition to existing 
capture/redirect of port 80.
E.g., applied to email, ftp, bittorrent, etc.
When devices support it, and access networks provide it, the user experience 
will be better. That would be the motivation for deployment.

It does seem like it could take a long time to deploy, but if it is completely 
backwards compatible and fairly cheap to implement, it might happen.

-Dave


-Original Message-
From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
Gunther Nitzsche
Sent: Thursday, May 18, 2017 8:14 AM
To: David Bird
Cc: Heiko Folkerts; captive-portals@ietf.org; Herzig, Willi
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

Hello,

thanks for your reply. Let me argue against ..:)

On 17.05.2017 17:11, David Bird wrote:
>
>
> We need to stop the 443 redirecting!
>
> Thus far, I don't see any reason why ICMP wouldn't work. In fact, if
> *no* ICMP worked, some basic networking stops working (general dest
> unreach, MTU discovery, etc).
>  

In a theoretical point of view I absolutely second your opinion. In real
world scenarios I don't see how this
could work out.

>That is by design, in some respects. The "capport compliant" device
will not ignore these messages (by definition). "Legacy" devices would
ignore them, and they will still depend on the >HTTP redirect.


I guess that is the crux. There are no "capport compliant devices"
outside wifi and there won't be any
for long long time.(as I said: outside the mobile world))  (I may be
wrong here?)
I do not see how to tell Microsoft, Apple, sun/oracle or the linux
community to insert a capport detection inside their
OS. And even if a Windows 11 and a linux kernel 5 would support that,
there will be a
wide majority of devices which would not be updated and will not meet
the criteria and still has to be
handled in a different way.

When the major browsers would support that (like the Chromium Project
for ChromeBooks in
https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection#TOC-Interpretation-of-Portal-State
)
we might get a step further. But I doubt that the majority of users will
accept permanent "test-traffic" in
normal circumstances.

> The separation of "configuration" and "notification" is by design.
>

That might be a design error.  Notification is done by the provider, but
configuration (how to react
on e.g. icmp unreachable) is up to the enduser. The provider cannot (and
will not) configure
any customer's client device. Maybe the CPE can be (pre-)configured
(cable-modem/dsl-router) but
not the home-PC. How do I tell the home-PC to open up a specific URL
when capport
detection gets activated (if it would exist)?
 
>
> => If the customers wants to communicate via a browser, then we should
> answer via the browser. All other separate communication forms may
> work but are
> unreliable and are dependent on the customer setup.
>
>
>
> Increasingly, it is the operating system's captive portal detection
> that is detecting the need for portal interaction. I agree that it is
> convenient to have an in-line HTTP response with the redirect or 511
> status code, but plain old HTTP is becoming obsolete. Hijacking HTTPS
> to return a 511 response is a bad idea. The ICMP approach gives
> 'notification' without requiring (in-line protocol dependent)
> man-in-the-middle responses and is protocol agnostic.
>

Now let's see how that would look like. If an ICMP unreachable is sent
out to the customer, he will see
an error in the browser. A different one like the ssl-breaking/stopping
error, but still an error.
But what comes next? Now we have lost the only channel to the customer -
the http(s) session
has ended. And we have lost the opportunity to tell the customer's
browser what to show instead.

If we sent out a status code instead we have at least the chance to show
>something< in the
browser which might help the customer to get on the right way. Maybe the
return code
just triggers a warning of the kind "the webserver is unreachable due to
providers action and
asks you to go to  instead" and does not do a redirection by
itself. Everything is better
(for the customers experience, not for the pure theoretical doctrine)
than just showing a
site unreachable.

>
>
> It isn't clear to me how subscriber UEs get assigned their IP
> addresses in your network; they don't use DHCP?

Some do, some don't. cable users do DHCP, DSL customers do radius (via
ppp). Pretty standard stuff. Actually that
doesn't matter a lot, since the connection termination is done by the
CPE, not by the customer's client device (PC).
Even if the cable-modem realizes that something strange is going on, the
home-PC will not be affected by that.

>
> The UE browser will be 'informed' of the captive portal URL by the
> captive portal detection mechanism (OS/vendor dependent like today).

That might be true in the mobile world; 

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

[Dave Dolson]

I consider this in scope. It is an excellent example of why captive portals 
should be handled at the IP layer (layer3) with IP protocols, and are not only 
a WiFi (layer 2) problem.


-Original Message-
From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
Heiko Folkerts
Sent: Wednesday, May 3, 2017 8:43 AM
To: captive-portals@ietf.org
Cc: Herzig, Willi; Gunther Nitzsche
Subject: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

Hi everybody,

I visited the capport WG the first time in Chicago. Thank you very much for the 
presentations! Afterwards I had a very brief chat with Martin about a use case, 
I name “carrier grade captive portals”. As a result I want to present this use 
case to you on this mailing list:

*Background and use case:*
In Germany the Federal Office for Information Security informs the ISPs with 
IPs, timestamp and other information of users that are part of a botnet. The 
ISPs are informing the users about the infection. We can not inform the users 
without the help of the ISP as they are the only ones knowing who is behind the 
dynamic IP address users get normally in Germany.
There are different ways to inform users by the ISPs: e-mail, snail mail or a 
carrier grade captive portal (aka walled garden, forced portal),

The most efficient way to inform and get systems cleaned has been proven is the 
carrier grade captive portal.
One of the  internet service providers, NetCologne, uses a, as they call it, 
Forced Portal. The current solution is legal in germany, if the ISPs terms of 
service are appropriate.

*Technically it roughly works like this:*
- When the abuse management system detects that a user is infected, the CPE 
customers router connection (PPOE connection) is disconnected and immediately a 
new PPOE connection is started.
- With the new PPOE connection, the CPE customers router gets a new DNSServer, 
IP, gateway (policy routing) and is connected to a carrier grade captive portal.
- Within the new network connection all traffic is routed through a HTTP/HTTPS 
proxy. This proxy allows the user to access selected sites like informational 
sites about infections, AV and OS vendors and will otherwise present an 
information page to the user. This information page tells the user about the 
situation, including information about the infection(s) and instructs him how 
to clean the system.

*Problem (almost the same as you know it):* As with captive portals in local 
networks this worked pretty well using HTTP. 
Also on Browsers, which first tries a HTTP connection, the information page  is 
displayed. Problem occurs now with HTTPS. Especially Google Chrome does no 
longer connect first using HTTP when the user enters a domain name of a web 
page if using HSTS and HSTS preload.
Connecting with HTTPS, the browser detects a MITM attack (which of course makes 
sense, because it is MITM) and does not display the information page. 
Instead an error page is displayed, which generates a whole lot of calls to the 
costumer support. An addional problem we encounter is that the well known 
detection strategies used by iOS/macOS, Windows and Android for captive portals 
do *never* work in our case.
Reason is that these detection strategies will only test for captive portals, 
when the network connection of the actual device (for example using WiFi) is 
started new. In our case the customers CPE router gets a new PPPOE connection, 
but the client  does not detect that the network connection to the internet was 
dropped by the router.

Do you think that „carrier grade captive portals“ are in scope of the capport 
WG charta? Would the work already done at capport help to cope with this 
problem?
My understanding of the current work in capport is, that it will not solve this 
problem entirely, but I think, it may already be half-way towards a solution. 
Because pushing a customer to a walled garden does not do a status change on 
the client system, but the CPE might work as some kind of “captive portal 
relais”, using at least parts of the current architecture of capport on the 
internal LAN.

Do you think it is usful that the capport WG considers our use case in its 
work? Any help is appreciated.

Best regards,

Heiko.

--
Heiko Folkerts
---
Referat CK 15
Federal Office for Information Security (BSI)

Godesberger Allee 185 -189
53175 Bonn
Germany
Telefon:+49 228 99 9582-5955
Fax:+49 228 99 10 9582-5955
E-Mail: heiko.folke...@bsi.bund.de
Internet:   www.bsi.bund.de
www.bsi-fuer-buerger.de

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] thoughts on two documents

[Dave Dolson]

Regarding the sacrificial q‎ueries, I would hope these are considered temporary 
measures to detect existing portals, not the preferred approach.

David Dolson
Sandvine
From: Erik Kline
Sent: Sunday, April 23, 2017 10:41 AM
To: David Bird; Kyle Larose
Cc: captive-portals@ietf.org
Subject: [Captive-portals] thoughts on two documents


All,

I have the vague feeling that there might be some general agreement around the 
idea of having an ICMP unreachable code for captive portals (like an HTTP 511 
code [https://tools.ietf.org/html/rfc6585#section-6] for ICMP :-), and it seems 
like there's no objection from captive portal implementers with respect to the 
basic functional elements captured in draft-larose-capport-architecture.

Where I think some rough spots might lie for both of these is in their 
integration with as-yet-undecided new behaviour.

To that point, I would like to take my co-chair hat off and ask the authors and 
the group for opinions of the following.

[ draft-wkumari-capport-icmp-unreach ]

There was some unresolved discussion about the contents of any included 
extension. I wonder if the extra payload parts might be removed (Dave Dolson's 
comment, I think?) and thereby simplify this version of the document.  Given 
that Destination Unreachable is a TCP soft error (vis. RFC 5461) I'm not sure 
how much the proposed extra validation semantics are really adding.

If the document simply said that receiving and authenticating an ICMP message 
with the capport code generically "MAY/SHOULD trigger the receiving node's 
captive portal handling subsystem", would that be something that folks might 
agree on?

We'll need to run this whole thing by intarea and 6man as well, of course.

And nothing stops us from proposing a mulit-part extension to be optionally 
included in a future document, once the captive portal interaction 
recommendations are more fully understood.

[ draft-larose-capport-architecture ]

I felt it was promising to hear some agreement about the functional elements of 
a captive portal system as documented.

Given that the captive portal interaction process is still on-going work, would 
the document authors think it worth trying to advance the document with either 
(a) section 3 removed or (b) section 3 rewritten to describe broadly how most 
clients behave today?  Even given the variety of clients I think it could be 
roughly captured (e.g. make a few sacrificial queries to trigger DNS/HTTP 
rewrites, keep trying until a sacrificial query produces an expected result 
while launching an HTTP-capable application, and so on).

-Erik
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] A view from a WiFi provider on captive portal requirements, challenges and improvements

[Dave Dolson]

Regarding the AP/client identification, this is the reason I suggested in an 
earlier email,
https://mailarchive.ietf.org/arch/msg/captive-portals/RPwEIuLlW6ZSLmEyaqfxgDrF88Q

"
Posting to the create_href:
POST http:///capport/sessions (Accept: application/json)
{ "identity": ""}

…

The USERNAME could be DHCP option-12 value or MAC address or ?
"

I didn’t know exactly what this identity should be. Maybe multiple identity 
options are useful.

-Dave


From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
David Bird
Sent: Tuesday, April 18, 2017 1:09 PM
To: James Wood
Cc: captive-portals@ietf.org
Subject: Re: [Captive-portals] A view from a WiFi provider on captive portal 
requirements, challenges and improvements

Welcome and thanks for the input James!

Comments in-line.


On Tue, Apr 18, 2017 at 8:21 AM, James Wood 
> wrote:
[snip]
1. Security. Nobody prefers to join an open network, but most end up doing
because that's the way it is. The hype around Hotspot 2.0 came and went as
that was never really deisgned to help captive portals but rather for
seamless, non-interaction from the user. As a portal provider, we don't want
that, we want to show a portal even if it's just a 'welcome back, you're now
online' message.

No doubt, Wi-Fi security is important in public access, but I'd argue outside 
the scope of the WG. While captive portals are often used on Open Wi-Fi, they 
are not limited to public access (there are LTE use-cases, for example). Also, 
security in public access transcends L1 security -- do you trust any wired LAN 
you plug into while in public places? HS2.0 (more or less) solves the public 
Wi-Fi security problem in that users trust their providers (albeit to varying 
degrees) and their providers have a relationship with the HS2.0 network 
provider. Even if deployed, this doesn't address situations where users have no 
trust relationship with the network provider and still want Wi-Fi (as most 
people, they assume Apps are increasingly using TLS and provide end-to-end 
security).


2. More devices/browers/web servers are defaulting to checking/redirecting
to a HTTPs URL. As you know, when in a captive portal/walled garden state,
this will cause a problem because you can't intercept a HTTPs request
(rightly so!) to a captive portal page without a browser/certificate
warning. This breaks everything from the end user perspective.

Yes, we need to fix this! It is disturbing that vendors commonly hijack https 
even with the security errors.


3. Built-in OS captive popups provide limited browser
functionality/cookies/etc. When trying to offer login options like Facebook,
it can really affect the user experience when cookies are not permitted or
other features disabled. The behaviour is also different per device. In
Android 5.0+, the captive portal window immediately dissappears when the
user is authenticated. This is a pain for us as we want to display a "you
are now online" page, or redirect the user to a landing page with
information etc.

Very common problems.

4. Walled garden. It's a nightmare having to manage lists of domains/IP's
across all the different vendors kit out there. For example to offer a
social login through Facebook we need to allow certain domains like
facebook.com, akamaihd.net and 
connect.facebook.net etc. This is all static
lists inside an AP/controller, and would be a nightmare to update should
Facebook change the URLs they send authentication requests throught etc. How
about some way to dynamicly pass back a list of domains as part of the DHCP
option or some other way to allow the operator to set the required domains
at time of connection? Or, how about, as part of the capport API, we are
able to send a list of domains back to the AP, so if someone chooses
Facebook, we open the Facebook domains for that MAC for a few minutes to
allow them to login.

Managing the walled garden configuration is probably also outside the code of 
the WG. I don't think we should have any API inform the client directly of the 
walled garden as that information could be misleading, or wrong. I do agree 
that the real issue is having the walled garden configuration synchronized with 
the NAS/AP ... however, vendors do their own proprietary ways of doing this 
already.


Other thoughts...

I had a look at "draft-wkumari-capport-icmp-unreach-02". I note that it
describes the example URL that could be returned as part of the captive
portal URL: https://wifi.domain.com/portal?icmp_session=10_class=100.
However, what about the other traditional parameters that a captive portal
redirect injects? As a minimum, we need the ap_mac, client_mac and login_url
to which we post the login request back to (traditional captive portal login
request). Without such parameters, we cannot identify the venue/ap/client
and provide the relevant portal splash page 

Re: [Captive-portals] time-based walled gardens

[Dave Dolson]

Thinking about the plenary session and discussion of tussle, I think we should 
consider how to improve standardization in such a way that is fair to both 
parties. Doing nothing leaves the portal doing all the bad behaviors you 
documented so concisely in the problem statement.

Any access point has full control of client access to the Internet. I think we 
can improve the means this is signaled and presented to the user, while also 
removing any need for application-layer modifications of http or DNS.


David Dolson
‎
  Original Message
From: Mark Nottingham
Sent: Monday, April 10, 2017 8:28 PM
To: David Bird
Cc: Erik Kline; captive-portals@ietf.org; Martin Thomson; Mikael Abrahamsson
Subject: Re: [Captive-portals] time-based walled gardens


Hi David,

I'm not arguing against helping improve the user experience of captive portals 
as they're commonly understood and currently deployed; I'm against expanding 
the definition of "captive portal" to give the network more control over 
communication *after the captive portal phase is done.*

Of course, networks already have significant power over what a user can and 
cannot do over them. Codifying this by standardising a way for networks to 
interpose themselves in subsequent communication, or pop up "helpful" 
information on the fly, or selectively refuse communication and offer 
replacement content -- all of which seem to be under discussion here -- is a 
pretty substantial expansion of that power, in practical terms.

It may be that that's the right thing to do, but it'd need to be informed by a 
wider discussion. This was *not* the scope of work that I understood when this 
WG was chartered.

WRT your question about "who is the IETF to define what is an appropriate 
business model access" -- this is a question that is being taken seriously in 
the IETF, as evidenced by tech plenary session in Chicago. It's clear that we 
don't solely determine the balance of these things on the Internet, but it's 
just as clear that we do have some role to play; I think it'd be pretty poor if 
we just abdicated any responsibility to end users and said "let the market sort 
it out, we just write specs." At the very least, I'd expect a discussion of the 
effect these changes might have upon the Internet and people's access to it.

Regards,


> On 11 Apr 2017, at 10:15 am, David Bird  wrote:
>
> On Mon, Apr 10, 2017 at 4:46 PM, Mark Nottingham  wrote:
>
> > On 11 Apr 2017, at 1:57 am, Mikael Abrahamsson  wrote:
> >
> > CAPPORT doesn't have to just solve its own problems, perhaps it'd be good 
> > to try to come up with a slightly more generic solution and send it for 
> > review in INT-AREA for instance?
>
> If I follow the discussion here and on the issues list correctly, I'm 
> concerned.
>
> My understanding when this WG was chartered was that we didn't really *like* 
> captive portals, but people thought there was some benefit to at least making 
> their operation smoother; we had lots of examples of interop problems and bad 
> user outcomes in the discussion leading up to it. In that manner, the goal 
> here AIUI is to codify current practice and incrementally improve it.
>
>
> Indeed, there is a distinct bias against captive portals, of all forms. We 
> all hate them, but we all still use them. (don't you?)  I also hate paying 
> taxes.
>
> Often, venues don't want to use them either, but they need to for a variety 
> of reasons, some legal (as in they are legally required to display 
> something), but who are we to judge? Ideally, we get rid of http hijacking. 
> But, there will always be legacy devices - for the foreseeable future, and 
> you just can't say they aren't supported in public access (or not subject to 
> restrictions), nor can a network trust a device to always do what it is told.
>
>
> As I said in the BoF, even mitigating those problems might not lead to a 
> great outcome, as it will encourage the deployment of more captive portals 
> (as many networks are rolling them back, at least in my experience).
>
> There is one use case defined in our charter:
>
> """
> Some networks require interaction from users prior to authorizing
> network access. Before that authorization is granted, network access
> might be limited in some fashion. Frequently, this authorization process
> requires human interaction to arrange for payment or to accept some
> legal terms.
> """
>
> Expanding the scope of this work to allow networks to further control their 
> users' experience after authorisation to use the network (even if that is 
> just giving a better user experience of that control) is not a small change. 
> Allowing networks to interpose themselves in communication after 
> authorisation is not a small change.
>
>
> But, alas, networks are already doing this and people are using these 
> networks (willfully, they can always pick another network). They just can't 
> do it in very elegant ways and still implement 

Re: [Captive-portals] Arguments against (any) Capport "API"

[Dave Dolson]

There is a risk in specifying the client check RFC7710 URL and also the Legacy 
HTTP query.
The risk is that portal operators will get creative in requiring work-flows 
involving both—must visit 7710 URL and also the redirected page.

I like the idea of specifying what the client should do.
But I also think we should label the client fall-back behavior as deprecated, 
to inform portal operators they should not rely on it in the future.



From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
David Bird
Sent: Wednesday, April 5, 2017 10:42 AM
To: Erik Kline
Cc: captive-portals@ietf.org
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"

In your example, you are doing (what I'm calling) Capport and Legacy at the 
same time. What would you do if Capport indicates YES (you have a portal), but 
Legacy says, NO (no portal)? Or wise versa? By adding Capport did we make 
anything easier?

After you had a success, do you ever check again (for when time expired, etc)?

Is it possible to 'suggest' that a user go to the captive portal without 
actually requiring it? (There are a number of use-cases here, my favorite being 
the offering of free low-tier rate-limited (but no captive portal) access to 
the Internet, but with the option of upgrading with paid access. Or, the 
indicating that time or data is about to run out.)

I think we tend to conflate two related, but different, issues... 1) The lack 
of signaling the existence of a captive portal for non-HTTP port 80 clients, 
and 2) issues around why OS captive portal detection fails (or is thwarted). 
The second issue should be addressed separately, and if that issue didn't 
exist, then current (OS/browser) detection methods would already be working 
just fine...

I think the client should, ideally do:

-  Use the network for all connections (why ask permission when forgiveness is 
cheap).
-  In Background, detect Capport ICMP, kick off portal notification (in real 
browser if https), possibly pin that (blocked) flow to an existing (LTE) network
-  In Background, Kick off Legacy HTTP query and generate a few random packets 
(to get Capport ICMP SessionID) - if we had rfc7710, we don't really need the 
Legacy HTTP result if we already see Capport ICMP, but we might compare it to 
the rfc7710 URL if we do get it). If Legacy is detected, but no Capport ICMP, 
then you have no choice but to pin all connection to LTE like you do today.
- When the Capport ICMP SessionId has changed (e.g. a Change of Authorization 
has occurred), go back to step 1.
- When (connection non-terminal) Capport ICMP warnings come in for flows, the 
user gets a 'suggestion' to go to the portal.

(A participant at the meeting indicated he was interested in pre-paid LTE 
use-cases, I believe those use-cases - with rfc7710 RA, at least -  are covered 
here as well.)

I realize this is a big ask... :)

Wanted to repeat one rational for this from a previous e-mail:

I think there are many use-cases for wanting to move beyond the boolean "all or 
nothing" view of a captive portal networks. From Chicago O'Hare airport 
offering free access to airline sites, to many developing-world examples (I 
like to think operating system update sites should be freely available), even 
'human rights' examples in terms of access to government resource (for FREE, in 
walled garden), I think UEs should be allowing users to take advantage of these 
free resources...


On Wed, Apr 5, 2017 at 6:45 AM, Erik Kline 
> wrote:
I think we can't get away from nodes doing both new style (7710 + 
yet-to-be-published stuff) and legacy detection.  In an increasingly 
HTTPS-ified world I would expect we'll end up with devices doing something like:

[1]
if (7710 available) {
do 7710 + yet-to-be-published interaction;
if (successful HTTPS Internet query) return;
}

[2]# possibly in parallel with [1]
do sacrificial cleartext HTTP request
if (rewriting detected) {
do legacy interaction;
if (success HTTPS Internet query) return;
}

[3]
last ditch effort here

I think it's what the majority of client OS vendors do with (first) [3] and 
(then) [2] that will determine, in a sort of game theoretic sense, how 
successful [1] will be.

If a majority of client OSes implement [3] as "never make this network the 
default, but some apps can use it via a multiple Provisioning Domain API (to 
support connecting to printer hotspots, and the like), or new TAPS API, while 
leaving (if available) mobile up", then captive portal vendors will at least be 
incentivized to stop faking out the queries that constitute [2].

If there proves to be some industry support for [1], and ongoing measurements 
show some meaningful adoption trends, then OS vendors can look at taking action 
with respect to networks that still only support [2].  This could include 
things like de-prioritization in ESSID auto-join 

[Captive-portals] Comments on draft-donnelly-capport-detection-01

[Dave Dolson]

Mark and Margaret,
Thanks for putting this together. I have some questions and comments.

I suspect there are a number of nits in the syntax, but first I'd like to 
discuss some high-level questions.


1.   Regarding $toplevel, is this intended to be used as the body for both 
request and response? I suspect no, this is the body of the response and the 
body of the POST has not been defined. For example, how is the MD5 sum of the 
t to be presented?

2.   I see a role for performing GET, once the session has been established.

3.   Do you see any opposition to including various hrefs for satisfying 
requirements in the browser?

I think working through some examples would be useful. This differs from your 
proposal, but I was thinking:

---
GET from the DHCP-provided URL:
GET http:///capport (Accept: application/json)
200 OK
{
   "create_href": "http:///capport/sessions",
   "browse_href": "http://portal.example.com/;
}


Posting to the create_href:
POST http:///capport/sessions (Accept: application/json)
{ "identity": ""}
200 OK
{ " id": { "uuid": "",
   "href": "http:///capport/sessions/" },
  "identity": "",
  "state": { "permitted": false },
  "requirements": [
{"view_page": 
"http://portal.example.com/welcome/terms_and_conditions.html?session="},
{"provide_credentials": 
"http:///capport/sessions//credentials"}]
}

---
The session now exists, and GET works:
GET http:///capport/sessions/ (Accept: application/json)
200 OK
{ " id": { "uuid": "",
   "href": "http:///capport/sessions/" },
  "identity": "",
  "state": { "permitted": false },
  "requirements": [
{"view_page": 
"http://portal.example.com/welcome/terms_and_conditions.html?session="},
{"provide_credentials": 
"http:///capport/sessions//credentials"}]
}

--
Or GET for browser:
GET http:///capport/sessions/ (Accept: text/html)
200 OK
 Human readable page of above information 

--
After visiting the view_page URL and clicking OK, the internet works, and the 
info is available for query:
GET http:///capport/sessions/ (Accept: application/json)
200 OK
{ " id": { "uuid": "",
   "href": "http:///capport/sessions/" },
  "identity": "",
  "token": "",
  "state": { "permitted": true, "expires": "2017-02-25T19:00:00-06:00", 
"bytes_remaining": 1000 },
  "requirements": []
}


When the session expires, ICMP alert occurs, the client GETs again (note 
different value for view_page):
GET http:///capport/sessions/ (Accept: application/json)
200 OK
{ " id": { "uuid": "",
   "href": "http:///capport/sessions/" },
  "identity": "",
  "state": { "permitted": false, "expires": "2017-02-25T19:00:00-06:00", 
"bytes_remaining": 0 },
  "requirements": [
{"view_page": 
"http://portal.example.com/welcome/renew.html?session="},
{"provide_credentials": 
"http:///capport/sessions//credentials"}]
}

The client can fulfil requirements again.


When the client wants to explicitly leave the network, delete the href for the 
session:
DELETE http:///capport/sessions/
200 OK


The USERNAME could be DHCP option-12 value or MAC address or ?  I don't think 
it is too important for security, but useful for diagnostics.
I did not delve into how the TOKEN would be used with provide_credentials. But 
the idea is that it could be shared (e.g., with devices lacking displays.)

Does this make sense?

-Dave

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Thinking of something related to captive portals for the ietf98 hackathon

[Dave Dolson]

Erik,
I don’t think it is onerous.
But, the device causing captive portal is not always on the local subnet of the 
end-user device.

I think it is better to have a security scheme that doesn’t depend on TTL.

-Dave

From: Erik Kline [mailto:e...@google.com]
Sent: Wednesday, February 22, 2017 9:52 PM
To: David Bird
Cc: Dave Dolson; captive-portals@ietf.org; Kyle Larose; war...@kumari.net; 
Lorenzo Colitti
Subject: Re: [Captive-portals] Thinking of something related to captive portals 
for the ietf98 hackathon

How onerous would it be to require that an ICMPv[46] message with a captive 
portal code also have a hoplimit of 255 (i.e. be link-local / from an on-link 
source)?

I could imagine writing a user-space daemon that listens for ICMP message of 
one specific type, and validates the hoplimit with traditional cmsg tricks.  
Furthermore, only having to do so on networks advertising a 7710 option would 
be good.

On 23 February 2017 at 02:10, David Bird 
<db...@google.com<mailto:db...@google.com>> wrote:
Further, we could tie this to RFC 7710, so that you can disregard this ICMP 
from networks not expected to be captive portal and networks who do implement 
captive portal can easily (as in iptables rules) filter out external ICMP of 
this nature.

On Wed, Feb 22, 2017 at 9:07 AM, Dave Dolson 
<ddol...@sandvine.com<mailto:ddol...@sandvine.com>> wrote:
Agreed. Hence the discussion about using a difficult-to-guess token in the 
message.

From: Lorenzo Colitti [lore...@google.com<mailto:lore...@google.com>]
Sent: Wednesday, February 22, 2017 12:05 PM

To: Dave Dolson
Cc: David Bird; war...@kumari.net<mailto:war...@kumari.net>; Kyle Larose; 
captive-portals@ietf.org<mailto:captive-portals@ietf.org>
Subject: Re: [Captive-portals] Thinking of something related to captive portals 
for the ietf98 hackathon

The ability for any host in the Internet to trigger an instant response sounds 
it could turn into a DOS vector, though.

On Thu, Feb 23, 2017 at 2:04 AM, Dave Dolson 
<ddol...@sandvine.com<mailto:ddol...@sandvine.com>> wrote:
As I understand it, to "think something is wrong" requires an application-layer 
timeout. Some people think this is about 5s, but I don't believe TCP specifies 
an upper bound.

An ICMP message can give an "instant" response.

It's worth considering that the ICMP message may trigger the "sacrificial" HTTP 
request by the operating system.



From: Lorenzo Colitti [lore...@google.com<mailto:lore...@google.com>]
Sent: Wednesday, February 22, 2017 10:24 AM
To: Dave Dolson
Cc: David Bird; war...@kumari.net<mailto:war...@kumari.net>; Kyle Larose; 
captive-portals@ietf.org<mailto:captive-portals@ietf.org>

Subject: Re: [Captive-portals] Thinking of something related to captive portals 
for the ietf98 hackathon

Ok, but the implementations that are the most likely to implement this sort of 
feature already send sacrificial plaintext HTTP requests on connect, and are 
quite capable of generating HTTP requests on demand when they think something 
is wrong.

On Wed, Feb 22, 2017 at 11:53 PM, Dave Dolson 
<ddol...@sandvine.com<mailto:ddol...@sandvine.com>> wrote:
Lorenzo,
My interest in ICMP is that it could work with any protocol, not just HTTP, and 
doesn't require any MITM for HTTPS.
I recall a discussion about adding a difficult-to-guess token to the ICMP 
message, making it hard to spoof.

-Dave



From: Captive-portals 
[captive-portals-boun...@ietf.org<mailto:captive-portals-boun...@ietf.org>] on 
behalf of Lorenzo Colitti [lore...@google.com<mailto:lore...@google.com>]
Sent: Wednesday, February 22, 2017 9:42 AM
To: David Bird
Cc: war...@kumari.net<mailto:war...@kumari.net>; Kyle Larose; 
captive-portals@ietf.org<mailto:captive-portals@ietf.org>
Subject: Re: [Captive-portals] Thinking of something related to captive portals 
for the ietf98 hackathon
I'm not a fan of the ICMP method. I think the security implications need more 
thought.

As is, it looks like pretty much anyone on the Internet can send you one of 
these packets, and you have no way of knowing if it's legitimate. Relying on 
such an easy-to-spoof signal to decide that a network no longer provides 
Internet access could be quite harmful, particularly if the receiving device 
decided to switch to cellular data and incur the associated traffic costs. Even 
if the signal is only taken as a hint to revalidate the network, that still has 
battery implications.

It would seem to be much more useful to use:

  *   A header in the initial redirect that captive portals almost always 
generate.
  *   A well-known URL where the state of the captive portal can be 
revalidated, either periodically or when some other indication of loss of 
connectivity is observed.
At the last IETF we talked about possibly having

Re: [Captive-portals] capport lunch or Bar BoF in IETF97

[Dave Dolson]

I would be available either day, but prefer Wednesday.


From: mariko kobayashi [mailto:a...@sfc.wide.ad.jp]
Sent: Saturday, November 12, 2016 11:51 AM
To: emile.step...@orange.com
Cc: captive-portals@ietf.org; Dave Dolson
Subject: Re: [Captive-portals] capport lunch or Bar BoF in IETF97

Sounds nice!
I would like to chat about issues on the user interaction of Captive Portals,
 and how industrial survey is needed for our WG.
I will be available for Monday and Wednesday lunch time.

Best,
Mariko

On 2016/11/12 10:28, emile.step...@orange.com<mailto:emile.step...@orange.com> 
wrote:
Hi

What about Monday lunch ?

I would like to have a chat about a comparison of Capport use cases and mobile 
use cases we made in the GSMA Web WG.

Regards
Emile

From: STEPHAN Emile IMT/OLN
Sent: mardi 8 novembre 2016 09:57
To: 'Dave Dolson'; mariko kobayashi; 
captive-portals@ietf.org<mailto:captive-portals@ietf.org>
Subject: RE: [Captive-portals] capport lunch or Bar BoF in IETF97

+1

From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
Dave Dolson
Sent: dimanche 6 novembre 2016 15:14
To: mariko kobayashi; captive-portals@ietf.org<mailto:captive-portals@ietf.org>
Subject: Re: [Captive-portals] capport lunch or Bar BoF in IETF97

I would like to.

From: mariko kobayashi
Sent: Sunday, November 6, 2016 7:07 AM
To: captive-portals@ietf.org<mailto:captive-portals@ietf.org>
Subject: [Captive-portals] capport lunch or Bar BoF in IETF97



Hi, all.
We do not have a WG meeting in IETF97,
, but how about having a capport lunch or Bar BoF,
and discussion issues we gonna work on?

Best,
Mariko



--

⭐︎



　Mariko Kobayashi(a...@sfc.wide.ad.jp<mailto:a...@sfc.wide.ad.jp>)

　Keio Univ. SFC

  Jun Murai Lab./WIDE Project/ao(あお)

　

---⭐︎

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.




___

Captive-portals mailing list

Captive-portals@ietf.org<mailto:Captive-portals@ietf.org>

https://www.ietf.org/mailman/listinfo/captive-portals




--

⭐︎



　Mariko Kobayashi(a...@sfc.wide.ad.jp<mailto:a...@sfc.wide.ad.jp>)

　Keio Univ. SFC B4

  Jun Murai Lab./WIDE1854/ao(あお)

　

---⭐︎
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] capport lunch or Bar BoF in IETF97

[Dave Dolson]

I would like to.

From: mariko kobayashi
Sent: Sunday, November 6, 2016 7:07 AM
To: captive-portals@ietf.org
Subject: [Captive-portals] capport lunch or Bar BoF in IETF97



Hi, all.

We do not have a WG meeting in IETF97,
, but how about having a capport lunch or Bar BoF,
and discussion issues we gonna work on?

Best,
Mariko


--
⭐︎

　Mariko Kobayashi(a...@sfc.wide.ad.jp)
　Keio Univ. SFC
  Jun Murai Lab./WIDE Project/ao(あお)
　
---⭐︎
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals