Re: [Captive-portals] Signals from the network and ICMP

[Dave Dolson]

Having just re-read the thread, I disagree with this conclusion.

There was a discussion about ICMP security and the conclusion that 
treating it as a hint to consult the API (rate limited) renders spoofed 
ICMP messages harmless.


There was a discussion about whether alerts might be generated before 
the portal closes, which I think is feature creep.


There was also a discussion about net neutrality (which parts of the 
internet might be reachable), which seems orthogonal to mechanism.


So I would like to know on what basis the chairs find ICMP unsuitable?


-Dave


On 2018-04-13 6:14 AM, Martin Thomson wrote:

Thanks to Lorenzo for kicking off the discussion about the desirable
properties of a signal from the network.

( Thread starts:
https://mailarchive.ietf.org/arch/msg/captive-portals/pYYQqxAzJp8ZVLtfu1QLqJdMiiM/?qid=7c89d24eec00ff0608ee5398c9bb9d33
)

The chairs have discussed this and would like to confirm the following
conclusions:

1. We don't have any current proposal for a signal that the group
deems suitable.  For now, we will remove pieces from the API and
architecture documents that specifically mention ICMP.

2. We will add a description of the properties we believe that a
signal should have to the architecture document, but note that no such
signal is defined.  That is, the signal will be sent by the network
when it believes that a UE should check with the API for updated
information.  The UE will treat that signal as a hint and may talk to
the API as a result.  Rate-limiting will likely be needed.

3. We will consider a proposal to define a signal in future.  That
would be a stand-alone proposal if it appeared.  To my reading, it is
within our charter to take on work like that, but we would probably
need to have a discussion with our AD at that point because we're
already past our milestones.


Does anyone disagree with these conclusions?  I don't think that this
completely rules out the use of ICMP, though Destination Unreachable
might not be an ideal fit as was discussed in London.

___
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] 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] IETF 100: ICMP Discussion Summary

[Dave Dolson]

Regarding multiple IPv6 addresses, consider these two alternatives:
1. Associate the new address with an existing capport "session", for 
uninterrupted experience.
2. Treat a new address as a new session, for increased anonymity to the captive 
portal.

(I don't see how one can have the anonymity without the pain of signing in 
again.)

Since the level of anonymity with the portal is dubious anyhow (it sees the MAC 
address, and possibly other credentials), and repeatedly signing into a portal 
is annoying, I think it is important to try to provide a standard for (1).
Even if (1) is provided, the device of a privacy-seeking user could nonetheless 
choose to trigger the workflow of a new device, case (2).

I propose that the capport API permits new IP addresses to be assigned to an 
existing session, by providing an appropriate token. 

-Dave


-Original Message-
From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
Erik Kline
Sent: Sunday, December 3, 2017 10:48 PM
To: Michael Richardson
Cc: Kyle Larose; captive-portals@ietf.org
Subject: Re: [Captive-portals] IETF 100: ICMP Discussion Summary

On 4 December 2017 at 09:25, Michael Richardson  wrote:
>
> {did not make it in person, and had a conflict and I haven't watched 
> the session on youtube yet}
>
> Kyle Larose  wrote:
> > - Question was raised about whether we should restrict the number of v6
> > addresses (one address, one prefix, etc).
>
> Was there any consensus?
>
> I don't see a way to restrict the number of v6 addresses per UE except 
> via stateful DHCPv6, and few use that.

No consensus yet, IIRC.



My opinion is that we cannot restrict IPv6 addresses (violation of 7934).  And 
any captive portal that identifies clients solely by IPv6 address is going to 
give some UEs a royally painful experience.  When the downstream network 
architecture can include whole /64s given to single devices (e.g. 64-per-host) 
the experience will get really bad.

This is just a reality of dealing with IPv6 (and I think it's a good thing).  
We just need to adapt, and I think it actually points to some constraints we 
can use to narrow down the solution space.

As I see it at the moment, the only future-proof options come down do:

- building into the portal/enforcement point knowledge of the network 
architecture
- identifying clients by things that identify the device on-link (e.g. MAC 
address)
- identifying clients by things that identify the link itself (DSL line ID, 
/64, ...)


___
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 disc

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  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  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 concerns me with this approach is secu

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

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

[Dave Dolson]

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  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 concerns me with this approach is security: how can we trust 
> that the client of the API server isn't spoofing its identity? So, the 
> question becomes: what verifiable identify can a user equipment have that an 
> API server can validate, and if necessary, translate into an identity 
> understood by the enforcement device?
>
>
> -----Original Message-
> From: Erik Kline [mailto:e...@google.com]
> Sent: Monday, October 16, 2017 8:20 AM
> To: Kyle Larose; Dave Dolson
> Cc: captive-portals@ietf.org; David Bird
> Subject: client identifying info between API and enforcement
>
> 
>
> Kyle, Dave, (David, all,)
>
> When a client is trying to talk to an [architecture-2.3] API server,
> using the URL is learned in [architecture-2.2], will it need to
> present some token that the API server can ultimately use when
> communicating back to the enforcement box?
>
> I'm effectively wondering about how we get (something like) the MAC
> address of a client into this URL, /especially/ when the URL might not
> be custom crafted for each client (i.e. in the case of the URL in an
> ICMPv6 RA or learned via PvD mechanics).
>
> What's required here and how do we think it should work?

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

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 
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] client identifying info between API and enforcement

[Dave Dolson]

Erik,

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.

So then, 
(a) one of the user's IP addresses would be used to make the request, but we 
might expect to include multiple addresses in the body of the request itself.
E.g., to provision IPv4 and (multiple) IPv6 at the same time.

Or, (b) we could say that provisioning must be repeated from each IP address to 
be used. Then the address could be implicit in the connection used for 
communication--which also serves as proof of ownership.

Just some thoughts.
-Dave


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



Kyle, Dave, (David, all,)

When a client is trying to talk to an [architecture-2.3] API server,
using the URL is learned in [architecture-2.2], will it need to
present some token that the API server can ultimately use when
communicating back to the enforcement box?

I'm effectively wondering about how we get (something like) the MAC
address of a client into this URL, /especially/ when the URL might not
be custom crafted for each client (i.e. in the case of the URL in an
ICMPv6 RA or learned via PvD mechanics).

What's required here and how do we think it should work?
___
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 
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 
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>" 
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<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 
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.  Perhap

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<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 
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>" 
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<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 
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&#x

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  on behalf of Dave 
Dolson 
Date: Friday 23 June 2017 at 11:57
To: "captive-portals@ietf.org" 
Cc: David Bird 
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, 
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  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 
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] practicality of 511 HTTP status code

[Dave Dolson]

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.

Do we expect the enforcement device should be checking user-agent to decide on 
511 vs. 30x code?

For captive portals to want to use 511 (vs. 307), the browsers would have to 
behave in a better way from the network operator's perspective.
I would expect the browsers to show the information that the operator wants to 
be displayed.


Having said all of that, this solution is specific to HTTP, vs. the ICMP 
approach that works for any protocol.

-Dave


From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
Vincent van Dam
Sent: Sunday, May 7, 2017 3:09 PM
To: David Bird; Erik Kline
Cc: captive-portals@ietf.org
Subject: Re: [Captive-portals] practicality of 511 HTTP status code

- A legacy 30X response will still be needed for some user-agents

Is that because you don't expect all user-agents (webbrowsers specifically) to 
support it?

- The response contains HTML that should contain the login URL (or a meta 
refresh, etc), which isn't a very well structured way to get the URL

I agree, it makes more sense that the url would be in a response header instead 
(like the 30x status).


   It is not intended to

   encourage deployment of captive portals -- only to limit the damage

   caused by them.



Damage? Hm...



In terms of non-browsers accessing apis, they should be using TLS! And perhaps 
not follow redirects or otherwise add some integrity to their api.



I agree, apis should use tls. Not every developer might agree though (a rest 
api containing weather predictions?).

But also, I don't think we can fix the world, fix every api/client that is ever 
made. We can only at least identify mitm 30x scenarios are implemented, and try 
to regulate that scenario a bit more, which has been done by introducing the 
511.



Van: Captive-portals [captive-portals-boun...@ietf.org] namens David Bird 
[db...@google.com]
Verzonden: zondag 7 mei 2017 20:36
Aan: Erik Kline
CC: captive-portals@ietf.org
Onderwerp: Re: [Captive-portals] practicality of 511 HTTP status code
I personally do not find it very useful in public access networks, because:
- A legacy 30X response will still be needed for some user-agents
- Returning 511 is still a man-in-the-middle response (nothing changed there)
- The response contains HTML that should contain the login URL (or a meta 
refresh, etc), which isn't a very well structured way to get the URL
- differences in how browsers handle the 'error' and the associated user 
experience

There are a couple other oddities:


   Note that the 511 response SHOULD NOT contain a challenge or the

   login interface itself, because browsers would show the login

   interface as being associated with the originally requested URL,

   which may cause confusion.



Why shouldn't it contain a challenge? (the reason given only relates to the 
'login interface itself').



   It is not intended to

   encourage deployment of captive portals -- only to limit the damage

   caused by them.



Damage? Hm...



In terms of non-browsers accessing apis, they should be using TLS! And perhaps 
not follow redirects or otherwise add some integrity to their api.

On Sun, May 7, 2017 at 1:05 AM, Erik Kline 
mailto:e...@google.com>> wrote:
I wanted to poll the group's thoughts on the usefulness of the 
rfc6585#section-6 511 HTTP status code.

Has anybody tried to serve 511s to clients, and if so what were the results?

Might it be useful to serve an API endpoint (rather than the full-blown HTML 
UI)?

I'm trying to get a sense of whether this will be a useful tool to use in 
assembling a recommended portal interaction.  If we determine it's not really 
going to be a workable component, then that's useful to know too.

___
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] 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; Fo

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 
mailto:james.w...@purplewifi.com>> 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&policy_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 and user specific opt

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

[Dave Dolson]

In this context, one advantage is that the user device knows this is a special 
URL. It knows exactly why it is being presented. We may recommend the user be 
made clearly aware.

I think it is clearer than some random http or DNS that might be redirected 
(methods currently available)

David Dolson
‎
  Original Message
From: Martin Thomson
Sent: Monday, April 17, 2017 8:50 PM
To: David Bird
Cc: Michael Richardson; Martin J. Dürst; captive-portals@ietf.org
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"


On 7 April 2017 at 22:08, David Bird  wrote:
> To be clear, Gmail hyperlinked boingo.com for me... but, the point is that
> the UE/capport detection parsed and validated (checked the cert and cert
> status) of the FQDN. It is not some URL with questionable formatting...

I think that you missed my point.

The foundation for HTTPS is that there is an expectation of server
identity when navigation is initiated.  The same cannot be said in
this context.

___
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] 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 their business model. Who is 
> IETF to define what is

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

[Dave Dolson]

This is OK if you only need to serve devices with browsers and attentive humans.
The API offers possibilities for automation in the device by making a formal 
data model (vs. HTML).


From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
Christian Saunders
Sent: Wednesday, April 5, 2017 12:38 PM
To: David Bird
Cc: captive-portals@ietf.org
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"

The currently proposed solution has 3 components:

1. The ICMP component is used to detect a captive network.

2. The DHCP component is used to discover the address of the Captive Portal.

3. The API is an information service with a standardized interface that allows 
discovery and potentially remediation of the requirements for network access.

The ICMP and DHCP components are sufficient to resolve the redirection and 
HTTPS issue.

I would consider the API as an optional component - it might create some user 
experience benefits if the device developers and network operators choose to 
use it.

The difficulty with the API is having a way of codifying all of the possible 
network access requirements.  I'm not sure this is reasonably possible.

Assuming that such a definition is possible, then there is some benefit to the 
common definition.

(It also strikes me that this definition would make a nice back end design for 
the Captive Portal itself.)

Cheers!

Christian


On 17-04-05 10:25 AM, David Bird wrote:
Edits in-line :)

On Wed, Apr 5, 2017 at 9:06 AM, David Bird 
mailto:db...@google.com>> wrote:
A few more key benefits of the ICMP approach :

- Capport detection is made easier for the client, even when RFC 7710 (or any 
API) is NOT implemented (as long as the NAS is Capport compliant).

- "Signaling" can be done by different components (NAS, iptables, rate-limiter, 
PCEF, etc), without (necessarily) needing to coordinate with a central service.

- In defining the RFC in how a NAS should handle blocking traffic for Capport 
compliant devices, we are also defining how the NAS should handle Legacy 
devices - which is, there is no difference - they both get ICMP Dest Unreach 
w/Capport extension) - which is helpful.



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

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

[Dave Dolson]

I’d like to hear from browser vendors as to why the browser gets sandboxed when 
interacting with a captive portal.

If one could trust the URL came from the local network (via DHCP), could 
restrictions be lifted?
If the URL were HTTPS, and certificates were valid (e.g., valid cert of Chicago 
OHare Airport), could restrictions be lifted?

Because as we’ve heard, portals try to defeat captive portal detection to get 
the “real” browser: cookies, video player, etc.

-Dave


From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
David Bird
Sent: Tuesday, April 4, 2017 5:35 PM
To: Christian Saunders
Cc: captive-portals@ietf.org
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"

Thanks Christian,

I wanted to high-light something you said:

On Tue, Apr 4, 2017 at 1:13 PM, Christian Saunders 
mailto:christian.saund...@sjrb.ca>> wrote:
I agree that determining the operators intention for the portal isn't really 
worthwhile.

On the other hand, it is worth providing the operators with tools to enable as 
seamless an experience as possible.

This is exactly right... the (consistent) and seamless an experience as 
possible.

However, today this sometimes means tricking UE captive portal detection into 
not giving you the 'other' browser (sandboxed, incognito, or otherwise not the 
browser the user is already logged into sites with). For people who build fancy 
websites for Hotspots, you can imagine that is frustrating (to require users to 
login, every time, even when your site uses HTTPS and cookies are "safe").


Beyond this the operators will sink or swim on their own merits.

Cheers!

Christian
Shaw Communications Inc.

On 17-04-04 02:05 PM, David Bird wrote:
Attribution / advertising is a big motivator, at least in the US.

On Tue, Apr 4, 2017 at 1:00 PM, Kyle Larose 
mailto:klar...@sandvine.com>> wrote:
I was sitting in a coffee shop on Saturday in Chicago, and decided to log in to 
their wifi. It was a captive portal that basically said something like “Hey, 
we’re giving you this service for free, because we’re [the coffee shop] 
awesome!”. To log in I just needed to click a button to continue.

The point here, I think, is that the coffee shop is providing this as a service 
to you, and wants you to know that. I’m not sure how much that is worth to 
them, but it’s an example of something that isn’t just ToS, and wasn’t terribly 
intrusive.

From: Captive-portals 
[mailto:captive-portals-boun...@ietf.org]
 On Behalf Of David Bird
Sent: Tuesday, April 04, 2017 3:52 PM
To: Mikael Abrahamsson
Cc: captive-portals@ietf.org
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"

My opinion is that guessing why venues put up a portal isn't always that 
useful. The point is, they have a reason. In some countries, there are legal 
requirements to display ToS. While we could try to implement ways around ToS 
type portals, are we helping the venue be more compliant? In all jurisdictions? 
(Some laws *require* the ToS is displayed *every time*).

For some locations, they may simply WANT to annoy you! (While also collecting 
per session fees from Boingo or iPass for the privileged of skipping that 
annoying portal.) More than likely, however, sites like the one you mentioned 
are just themselves concerned about liability and want that minimal amount of 
disclaimer...

As a user, you should either be willing to view the portal, pay for ease of 
use, or find another network...

David


On Tue, Apr 4, 2017 at 12:43 PM, Mikael Abrahamsson 
mailto:swm...@swm.pp.se>> wrote:
On Tue, 4 Apr 2017, David Bird wrote:
The one area I do see value in solving is how to get headless IoT devices 
on-line on capport networks.. But, in some ways, all we need their is a WISPr 
client in the device and an out-of-band way of configuring credentials into it. 
That can be solved with existing protocols and technologies.

I only have experience with captive portals as a user. When I travel the world, 
I have frequently seen captive portal pages that as far as I can see, offer 
nothing apart from a login page. It might have the hotel name in there, but 
that's it. So then I have to manually do something like find the piece of paper 
where my username/password is, and enter that. It seems to be only about 
authenticating me as actually being a resident of the hotel or whatever venue 
it is. Sometimes it seems to be there because there are legal requirements for 
tracking (they will write down a log of my room number and username on the 
paper in a ledger).

It's extremely cumbersome and as far as I can tell, it adds nothing for the 
WISP (at least nothing I can tell) by means of marketing or alike, it's only 
for assuring that people in the street can't just use the wifi.

Do you know the motivation for doing this in the context of your email? Is 
there added cost for them to automate the behavior, as in IPR or other 
li

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 
mailto:e...@google.com>> 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 algorithms.

We'll obvio

Re: [Captive-portals] Review of draft-wkumari-capport-icmp-unreach-01

[Dave Dolson]

Regarding Delay, what would be the harm in answering every blocked flow with an 
ICMP unreachable?
If there is rate-limiting to the portal, that would be the client's 
responsibility.


David Dolson
Sandvine
From: David Bird
Sent: Sunday, April 2, 2017 5:04 PM
To: Dave Dolson
Cc: Martin Thomson; draft-wkumari-capport-icmp-unre...@ietf.org; 
captive-portals@ietf.org
Subject: Re: [Captive-portals] Review of draft-wkumari-capport-icmp-unreach-01


I don't disagree that ICMP should only be meant for signaling... each field 
needs to be considered separately.

Session-ID : this bit of information is actually helping a UE determine 
authenticity [Marin's suggestion of the UE 'sampling' a few packets to random 
IPs and ports (to build a bit of entropy) and expect capport ICMP responding 
with a consistent SessionID].

The Validity and Delay together help clarify a few things to the UE, like how 
often or when it should expect ICMP Dest Unreach (e.g. NAS sets Validity to 5s 
and does not repeated send ICMP back to the UE for the same tuple, while using 
Delay to indicate a soon to change SessionID).

The PolicyID (probably poorly named) is meant as a 'hint' -- to help the portal 
know *something* about the reason you were sent to the portal -- be http 
redirect, rate limiting reasons, etc. This value shouldn't have much value, can 
be site specific, and it just informational.



On Sun, Apr 2, 2017 at 12:04 PM, Dave Dolson 
mailto:ddol...@sandvine.com>> wrote:
David,
Thanks.
I see you have added more information to the ICMP packet. This of course makes 
validating the ICMP message more important, whereas if the ICMP packet were 
only a trigger to visit the API, it would be the API that implements the 
security.

‎My opinion has been that the ICMP message should only say "unreachable because 
captive portal", which makes the ICMP risk only a DoS concern -- no different 
than ICMP today -- which if a real concern should be addressed for the ICMP 
protocol in general.


David Dolson
Sandvine
From: David Bird
Sent: Saturday, April 1, 2017 8:18 PM
To: Martin Thomson
Cc: 
draft-wkumari-capport-icmp-unre...@ietf.org<mailto:draft-wkumari-capport-icmp-unre...@ietf.org>;
 captive-portals@ietf.org<mailto:captive-portals@ietf.org>
Subject: Re: [Captive-portals] Review of draft-wkumari-capport-icmp-unreach-01


I've updated the draft to -02 - sorry for not doing so sooner.

Contributors (and co-authors) welcome!


On Sat, Apr 1, 2017 at 1:40 PM, Martin Thomson 
mailto:martin.thom...@gmail.com>> wrote:
(As a contributor only.)

David, Warren,

Looking at this draft, I think that there are a few fairly major
changes that this could benefit from.

# Extension payload

The presence of the extension is sufficient signaling for this channel.

If we accept that there will be a protocol for asking the portal for
basic information about connectivity, the UE/device/etc can query that
interface for expiration time.

The warning bit seems dangerous in this context given that it
establishes a non-backwards-compatible behaviour.  To an entity that
doesn't understand this extension, ICMP Unreachable means that the
packet was not forwarded.  I don't think that an extension can safely
change this.

The one obvious caveat for this comment is if we determine that RFC
7710 is insufficient for advertisement of the captive portal URL.  In
that case, we might consider adding the URL to the ICMP message.  I
don't see any evidence that this is necessary yet, and that would
compound the next issue, but it's something to consider.

# Security considerations

There is a fairly direct path between this message and a user visiting
the site identified.  Now, it is well-accepted that it is easy to
cause a user to visit any site, but nonetheless this needs to be
discussed.  We can also offer some suggestions for reducing the use of
this message by arbitrary endpoints.  For example, a device that
receives this message might not act immediately, but instead trigger
portal detection routines before opening a browser.  Those routines
might involve sending more packets and looking for more ICMP
unreachable packets.

For this reason, I think that we should mandate the use of RFC 4884
and a minimum size for the echo of the dropped packet.


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

Re: [Captive-portals] Review of draft-wkumari-capport-icmp-unreach-01

[Dave Dolson]

David,
Thanks.
I see you have added more information to the ICMP packet. This of course makes 
validating the ICMP message more important, whereas if the ICMP packet were 
only a trigger to visit the API, it would be the API that implements the 
security.

‎My opinion has been that the ICMP message should only say "unreachable because 
captive portal", which makes the ICMP risk only a DoS concern -- no different 
than ICMP today -- which if a real concern should be addressed for the ICMP 
protocol in general.


David Dolson
Sandvine
From: David Bird
Sent: Saturday, April 1, 2017 8:18 PM
To: Martin Thomson
Cc: draft-wkumari-capport-icmp-unre...@ietf.org; captive-portals@ietf.org
Subject: Re: [Captive-portals] Review of draft-wkumari-capport-icmp-unreach-01


I've updated the draft to -02 - sorry for not doing so sooner.

Contributors (and co-authors) welcome!


On Sat, Apr 1, 2017 at 1:40 PM, Martin Thomson 
mailto:martin.thom...@gmail.com>> wrote:
(As a contributor only.)

David, Warren,

Looking at this draft, I think that there are a few fairly major
changes that this could benefit from.

# Extension payload

The presence of the extension is sufficient signaling for this channel.

If we accept that there will be a protocol for asking the portal for
basic information about connectivity, the UE/device/etc can query that
interface for expiration time.

The warning bit seems dangerous in this context given that it
establishes a non-backwards-compatible behaviour.  To an entity that
doesn't understand this extension, ICMP Unreachable means that the
packet was not forwarded.  I don't think that an extension can safely
change this.

The one obvious caveat for this comment is if we determine that RFC
7710 is insufficient for advertisement of the captive portal URL.  In
that case, we might consider adding the URL to the ICMP message.  I
don't see any evidence that this is necessary yet, and that would
compound the next issue, but it's something to consider.

# Security considerations

There is a fairly direct path between this message and a user visiting
the site identified.  Now, it is well-accepted that it is easy to
cause a user to visit any site, but nonetheless this needs to be
discussed.  We can also offer some suggestions for reducing the use of
this message by arbitrary endpoints.  For example, a device that
receives this message might not act immediately, but instead trigger
portal detection routines before opening a browser.  Those routines
might involve sending more packets and looking for more ICMP
unreachable packets.

For this reason, I think that we should mandate the use of RFC 4884
and a minimum size for the echo of the dropped packet.

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

[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&c 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] FW: New Version Notification for draft-larose-capport-architecture-00.txt

[Dave Dolson]

Martin,
We look forward to addressing all of these issues.

We have a story for (1), and we've waved our hands about (2) and (3).

‎I think a separate draft might be appropriate for the API.

To take an initial stab at it, we think a GET to the ‎URI provides a JSON 
document of information and menu choices, since we've heard of a lot of 
different ideas about how User Equipment might want to navigate the captive 
portal. Clearly this will need to be standardized.

Input and new wording is very welcome.


-Dave


  Original Message
From: Martin Thomson
Sent: Thursday, March 9, 2017 6:32 PM
To: Kyle Larose
Cc: captive-portals@ietf.org; Dave Dolson
Subject: Re: [Captive-portals] FW: New Version Notification for 
draft-larose-capport-architecture-00.txt


Thanks for putting this together Kyle.

After a brief skim (I will read this more thoroughly in the next week
or so), I have some high level comments that I think you should spend
some time thinking about:

1. How to manage trust in the ICMP messages.  I like that you are just
using these to nudge a client into the flow, but how do you avoid
spoofing?  We've a little bit of experience with this in QUIC and
there is some advice on how a client might handle unauthenticated ICMP
there that might be reused (key observation: v6 >> v4 because you get
much better assurances about the message coming from a path element).

2. How do you authenticate the interactions with the portal? How do
you decide what to give it?

3. How to interact with the DHCP-provided URI.  The big failing of RFC
7710 (in my view) is that it doesn't really say what to do with this
URI that falls into your lap.  I think that you either shove it in a
browser or poke at it with some sort of other type of request (you
seem to assume the latter here), but that's astonishingly vague.  This
seems like a great opportunity to point at other work.  Work I'm
hoping will start at the hackathon.



On 10 March 2017 at 09:26, Kyle Larose  wrote:
> Hello,
>
> Dave and I realized that the working group had discussed, at length, a 
> possible solution to the captive portal problem.
> Since we were planning on working on it during the hackathon, we figured it'd 
> be a good idea to capture the working group's ideas in an architecture.
>
> We've uploaded the below draft as a skeleton for the architecture in the 
> interest of having something to work from for the hackathon,
> and discuss at the meeting.
>
> Let us know what you think.
>
> Thanks!
>
> Kyle
>
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Thursday, March 09, 2017 5:22 PM
> To: Dave Dolson; Kyle Larose
> Subject: New Version Notification for draft-larose-capport-architecture-00.txt
>
>
> A new version of I-D, draft-larose-capport-architecture-00.txt
> has been successfully submitted by Kyle Larose and posted to the IETF 
> repository.
>
> Name:   draft-larose-capport-architecture
> Revision:   00
> Title:  CAPPORT Architecture
> Document date:  2017-03-09
> Group:  Individual Submission
> Pages:  10
> URL:
> https://www.ietf.org/internet-drafts/draft-larose-capport-architecture-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-larose-capport-architecture/
> Htmlized:   
> https://tools.ietf.org/html/draft-larose-capport-architecture-00
>
>
> Abstract:
>This document aims to document concensus on the CAPPORT architecture.
>DHCP, ICMP, and an HTTP API are used to provide the solution.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission 
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> ___
> 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] 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 
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 
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 
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 
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 a more structured way of 
communicating this and other bits of information from 

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

[Dave Dolson]

Agreed. Hence the discussion about using a difficult-to-guess token in the 
message.


From: Lorenzo Colitti [lore...@google.com]
Sent: Wednesday, February 22, 2017 12:05 PM
To: Dave Dolson
Cc: David Bird; war...@kumari.net; Kyle Larose; 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 
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 
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 a more structured way of 
communicating this and other bits of information from captive portal to host (a 
RESTful API, IIRC). That would also be useful, if we can all collectively 
resist the temptation to overengineer such a mechanism. :-)

On Wed, Feb 22, 2017 at 11:31 PM, David Bird 
mailto:db...@google.com>> wrote:
Hi Kyle,

I think that is a great idea!

I had started to implement here: 
https://github.com/coova/coova-chilli/tree/capport-icmp

What would be nice, in addition to the NAS changes, is to also demonstrate the 
client side ... either something like 
icmpd<https://github.com/snaewe/books-code/tree/master/unpv13e/icmpd> (to 
listen for the ICMP and provide applications a way of checking the status of 
their dest. unreach. connections), or the necessary Linux kernel changes. Also 
with kernel changes, the I-D could also be implemented using iptables, or other 
NAS software too.

Cheers,
David


On Wed, Feb 22, 2017 at 6:12 AM, Kyle Larose 
mailto:klar...@sandvine.com>> wrote:
Hey everyone,

I was thinking of doing something (anything) related to captive portals for the 
ietf 98 hackathon. In particular, 
https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01 caught my 
eye. I was wondering if anyone had thoughts on that, and whether there is 
anything else they'd like to see me champion.

Thanks,

Kyle

___
Captive-portals mailing list
Captive-portals@ietf.org<mailto:Captive-portals@ietf.org>
https://ww

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

[Dave Dolson]

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]
Sent: Wednesday, February 22, 2017 10:24 AM
To: Dave Dolson
Cc: David Bird; war...@kumari.net; Kyle Larose; 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 
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 a more structured way of 
communicating this and other bits of information from captive portal to host (a 
RESTful API, IIRC). That would also be useful, if we can all collectively 
resist the temptation to overengineer such a mechanism. :-)

On Wed, Feb 22, 2017 at 11:31 PM, David Bird 
mailto:db...@google.com>> wrote:
Hi Kyle,

I think that is a great idea!

I had started to implement here: 
https://github.com/coova/coova-chilli/tree/capport-icmp

What would be nice, in addition to the NAS changes, is to also demonstrate the 
client side ... either something like 
icmpd<https://github.com/snaewe/books-code/tree/master/unpv13e/icmpd> (to 
listen for the ICMP and provide applications a way of checking the status of 
their dest. unreach. connections), or the necessary Linux kernel changes. Also 
with kernel changes, the I-D could also be implemented using iptables, or other 
NAS software too.

Cheers,
David


On Wed, Feb 22, 2017 at 6:12 AM, Kyle Larose 
mailto:klar...@sandvine.com>> wrote:
Hey everyone,

I was thinking of doing something (anything) related to captive portals for the 
ietf 98 hackathon. In particular, 
https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01 caught my 
eye. I was wondering if anyone had thoughts on that, and whether there is 
anything else they'd like to see me champion.

Thanks,

Kyle

___
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<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] Thinking of something related to captive portals for the ietf98 hackathon

[Dave Dolson]

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] on behalf of Lorenzo 
Colitti [lore...@google.com]
Sent: Wednesday, February 22, 2017 9:42 AM
To: David Bird
Cc: war...@kumari.net; Kyle Larose; 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 a more structured way of 
communicating this and other bits of information from captive portal to host (a 
RESTful API, IIRC). That would also be useful, if we can all collectively 
resist the temptation to overengineer such a mechanism. :-)

On Wed, Feb 22, 2017 at 11:31 PM, David Bird 
mailto:db...@google.com>> wrote:
Hi Kyle,

I think that is a great idea!

I had started to implement here: 
https://github.com/coova/coova-chilli/tree/capport-icmp

What would be nice, in addition to the NAS changes, is to also demonstrate the 
client side ... either something like 
icmpd (to 
listen for the ICMP and provide applications a way of checking the status of 
their dest. unreach. connections), or the necessary Linux kernel changes. Also 
with kernel changes, the I-D could also be implemented using iptables, or other 
NAS software too.

Cheers,
David


On Wed, Feb 22, 2017 at 6:12 AM, Kyle Larose 
mailto:klar...@sandvine.com>> wrote:
Hey everyone,

I was thinking of doing something (anything) related to captive portals for the 
ietf 98 hackathon. In particular, 
https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01 caught my 
eye. I was wondering if anyone had thoughts on that, and whether there is 
anything else they'd like to see me champion.

Thanks,

Kyle

___
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


___
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 will see you near reception at noon.
-Dave


From: emile.step...@orange.com [mailto:emile.step...@orange.com]
Sent: Monday, November 14, 2016 1:04 AM
To: ao; Yoav Nir
Cc: captive-portals@ietf.org; Dave Dolson
Subject: RE: [Captive-portals] capport lunch or Bar BoF in IETF97

I will be there
Emile

From: ao [mailto:a...@sfc.wide.ad.jp]
Sent: dimanche 13 novembre 2016 11:29
To: Yoav Nir
Cc: captive-portals@ietf.org<mailto:captive-portals@ietf.org>; STEPHAN Emile 
IMT/OLN; Dave Dolson
Subject: Re: [Captive-portals] capport lunch or Bar BoF in IETF97

Cool!

Mariko

2016/11/13 19:26、Yoav Nir mailto:ynir.i...@gmail.com>> 
のメッセージ:
Sounds interesting.  I’ll try to make it.

Yoav

On 13 Nov 2016, at 16:52, mariko kobayashi 
mailto:a...@sfc.wide.ad.jp>> wrote:

Hi,
How about meeting up around 12:00 in front of the reception desk(5th floor)?

We're welcome more other guys will join us:)

Best,
Mariko

On 2016/11/13 2:21, Dave Dolson wrote:
Ok

From: mariko kobayashi
Sent: Sunday, November 13, 2016 1:03 AM
To: Dave Dolson; captive-portals@ietf.org<mailto:captive-portals@ietf.org>
Cc: emile.step...@orange.com<mailto:emile.step...@orange.com>
Subject: Re: [Captive-portals] capport lunch or Bar BoF in IETF97


Exactly!
How is Monday lunch, Dave?

Mariko

On 2016/11/12 13:05, emile.step...@orange.com<mailto:emile.step...@orange.com> 
wrote:
Hi
I prefer Monday because it lets us the week to organize deeper discussions on 
the interaction part.
Emile

From: Dave Dolson [mailto:ddol...@sandvine.com]
Sent: samedi 12 novembre 2016 04:15
To: mariko kobayashi; STEPHAN Emile IMT/OLN
Cc: captive-portals@ietf.org<mailto:captive-portals@ietf.org>
Subject: RE: [Captive-portals] capport lunch or Bar BoF in IETF97

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<mailto:emile.step...@orange.com>
Cc: captive-portals@ietf.org<mailto: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



--

⭐︎



　Mar

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

Re: [Captive-portals] API / ICMP for status and remaining time

[Dave Dolson]

I guess the link-local check is to mitigate the impact of attack?
But an attacker cannot force a particular URL, only a policy class.
And the receiver could easily rate-limit visits to the portal.

I think there are use-cases that might not come from the local access point, 
such as the emergency or weather warnings.

Also, some internet access comes over-the-top, such as VPN access in a tunnel. 
It seems reasonable to cause capport from the other end of a tunnel.

‎So IMHO, limiting to link-local origin is too limiting.

-Dave

From: David Bird
Sent: Friday, October 21, 2016 5:06 PM
To: Erik Kline
Cc: Dave Dolson; captive-portals@ietf.org; Alexander Roscoe
Subject: Re: [Captive-portals] API / ICMP for status and remaining time


What all stuff are you referring? I consider the "Policy Class" that piece of 
opaque data that is meaningful to the portal. Instead of using an arbitrary 
length string, this is just a unsigned 32 bit integer -- which should give 
enough flexibility in terms of portal feedback. Other fields are useful to the 
client (not the portal) in terms Validity, Delay, etc.

Indeed, we have define how to assemble the 7710 URL with the Policy Class(es) 
received...

I think Link-Local or ensuring the ICMP comes from the DHCP address is 
reasonable.. and would work in most captive implementations.

On Tue, Oct 18, 2016 at 7:45 AM, Erik Kline 
mailto:e...@google.com>> wrote:
Do you really need all this stuff to be present and well-formatted for the 
client?

Can you just collapse some (most) of this stuff into a single "opaque string" 
that the captive portal verifying service will append the 7710 URL?

I'm trying to figure out how we'd make this work in Android.  If the Linux 
kernel just generated CAPPORT_HORRIBLENESS netlink messages containing the 
interface ID on which it was received and the opaque string part, then 
userspace could listen for those and marry them up with the 7710 URL it 
recorded from DHCPv4/RAs.

What userspace does with the assembled URL I'm assuming would be defined at 
some point.  But it could just try to fetch it and if it got a 3xx response it 
could fire up a browser or show a notification.

I would feel a little safer if there were only an explicit message and it had 
to, say, come from the same IPv4 link-local address as the source of RA with 
the 7710 option.  It should essentially be a link-local message only (for v4 
you'd have this message come from either the default router or the DHCP server, 
which are probably going to be the same in these kinds of networks anyway).

On 7 September 2016 at 07:14, David Bird 
mailto:db...@google.com>> wrote:
The idea is that the Dest Unreach + Capport Extension is one notification for 
both legacy and capport devices. It is largely up to the NAS depending on what 
it wants legacy devices to understand.

On Tue, Sep 6, 2016 at 2:04 PM, Dave Dolson 
mailto:ddol...@sandvine.com>> wrote:
David,
I’m unclear on when a new message type (section 2.7) should be used vs. an 
extension (section 2.8)?

-Dave


From: David Bird [mailto:db...@google.com<mailto:db...@google.com>]
Sent: Tuesday, September 06, 2016 3:59 PM
To: Dave Dolson
Cc: captive-portals@ietf.org<mailto:captive-portals@ietf.org>; Alexander Roscoe
Subject: Re: [Captive-portals] API / ICMP for status and remaining time

I've updated the I-D here 
https://github.com/wlanmac/draft-wkumari-capport-icmp-unreach, comments 
appreciated.

The Policy Class 'hint' can be any value that both the NAS and CP understand. 
Not all implementations will use it; it is only really useful if your NAS might 
send users to the CP for one of several reasons. A very simple use-case could 
be that the NAS puts the destination port in the Policy Class so that the CP 
knows what services you were trying to access.

On Wed, Aug 31, 2016 at 2:00 PM, Dave Dolson 
mailto:ddol...@sandvine.com>> wrote:
David,
Yes, I would like to see that draft updated, thanks.

Would this new hint support different reasons? E.g., bad weather warning vs. 
payment required?

-Dave


From: David Bird [mailto:db...@google.com<mailto:db...@google.com>]
Sent: Wednesday, August 31, 2016 9:29 AM
To: Dave Dolson
Cc: captive-portals@ietf.org<mailto:captive-portals@ietf.org>; Alexander Roscoe

Subject: Re: [Captive-portals] API / ICMP for status and remaining time


I am working updating 
https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01. I plan to 
add a 'policy class' uint32 to the ICMP message that can be used as a site 
specific 'hint' to the captive portal. This uint32 is site specific and -can- 
be unique per visitor and should only be used by portal as a hint/reason 
(capport URL gotten from DHCP rfc 7710) .

On Aug 31, 2016 5:55 AM, "Dave Dolson" 
mailto:ddol...@sandvine.com>> wrote:
An ICMP extension could notify a sender that a 5-tuple connection is walled 
o

Re: [Captive-portals] API / ICMP for status and remaining time

[Dave Dolson]

Sending to mailing list.

From: Dave Dolson
Sent: Tuesday, September 06, 2016 5:29 PM
To: 'David Bird'
Subject: RE: [Captive-portals] API / ICMP for status and remaining time

Inline [DD]

From: David Bird [mailto:db...@google.com]
Sent: Tuesday, September 06, 2016 5:23 PM
To: Dave Dolson
Subject: Re: [Captive-portals] API / ICMP for status and remaining time

On Tue, Sep 6, 2016 at 1:56 PM, Dave Dolson 
mailto:ddol...@sandvine.com>> wrote:
If I understand correctly, the “Policy Class” can be considered as a “Reason”.
Then different users can be having different portal experiences from the same 
base URL.
Is that what you meant?

That would depend on the portal -- it can decide to redirect to a different 
portal, display different text, or do nothing -- so, potentially.


If so, I think this does address the issues of URL phishing by an off-net 
attacker.

It would be easy to prevent ICMP of this nature entering a network from the 
Internet (the NAS decide is in a good position to do this in many cases). We 
could make it clear that routers should drop capport ICMP unless specifically 
configured not to.
 [DD] I’m not a fan of recommending ICMP be dropped. My point was that there is 
little damage that an off-network attacker can do, except make you go to your 
own portal. But perhaps often; hence the receiver should rate-limit visits to 
the portal.

Any thoughts on whether rate-limiting of messages should be specified?


I think there needs to be a section on it. In the validity description I 
mention a NAS may start silently dropping packets, that could be stronger. Any 
suggestions from past experiences?
[DD] How about saying the receiver of the ICMP messages should rate-limit 
visits to the portal.





From: David Bird [mailto:db...@google.com<mailto:db...@google.com>]
Sent: Tuesday, September 06, 2016 4:03 PM
To: Michael Richardson
Cc: Dave Dolson; Alexander Roscoe; 
captive-portals@ietf.org<mailto:captive-portals@ietf.org>
Subject: Re: [Captive-portals] API / ICMP for status and remaining time

Ideally, the "Policy Class" hint could be used instead of putting the URL in 
the ICMP packet (which was our original thought). I think it helps to require 
RFC 7710 to get the base CP URL so that Capport ICMP is meaningless in networks 
not configured with Capport DHCP.

On Tue, Sep 6, 2016 at 12:46 PM, Michael Richardson 
mailto:mcr+i...@sandelman.ca>> wrote:

Dave Dolson mailto:ddol...@sandvine.com>> wrote:
> An ICMP extension could notify a sender that a 5-tuple connection is 
walled
> off‎. It works for all IP protocols (TCP, UDP, GRE, even ICMP-echo).
> ‎This will be more real-time than relying on the sender to periodically 
probe
> well-known servers on port 80.

Agreed, it's good.  Like all ICMPs, we must assume that they could be forged.

> Such a message should indicate a reason, which could be a URL to a 
JSON/REST
> interface.
> Or, it could simply be an event that means "go probe port 80 to get
> redirected"

While I think it's slight less attackable to get redirected; I also favour
putting the URL in the packet, even if we ultimately can not trust it.

--
Michael Richardson mailto:mcr%2bi...@sandelman.ca>>, 
Sandelman Software Works
 -= IPv6 IoT consulting =-


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

Re: [Captive-portals] API / ICMP for status and remaining time

[Dave Dolson]

David,
I’m unclear on when a new message type (section 2.7) should be used vs. an 
extension (section 2.8)?

-Dave


From: David Bird [mailto:db...@google.com]
Sent: Tuesday, September 06, 2016 3:59 PM
To: Dave Dolson
Cc: captive-portals@ietf.org; Alexander Roscoe
Subject: Re: [Captive-portals] API / ICMP for status and remaining time

I've updated the I-D here 
https://github.com/wlanmac/draft-wkumari-capport-icmp-unreach, comments 
appreciated.

The Policy Class 'hint' can be any value that both the NAS and CP understand. 
Not all implementations will use it; it is only really useful if your NAS might 
send users to the CP for one of several reasons. A very simple use-case could 
be that the NAS puts the destination port in the Policy Class so that the CP 
knows what services you were trying to access.

On Wed, Aug 31, 2016 at 2:00 PM, Dave Dolson 
mailto:ddol...@sandvine.com>> wrote:
David,
Yes, I would like to see that draft updated, thanks.

Would this new hint support different reasons? E.g., bad weather warning vs. 
payment required?

-Dave


From: David Bird [mailto:db...@google.com<mailto:db...@google.com>]
Sent: Wednesday, August 31, 2016 9:29 AM
To: Dave Dolson
Cc: captive-portals@ietf.org<mailto:captive-portals@ietf.org>; Alexander Roscoe

Subject: Re: [Captive-portals] API / ICMP for status and remaining time


I am working updating 
https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01. I plan to 
add a 'policy class' uint32 to the ICMP message that can be used as a site 
specific 'hint' to the captive portal. This uint32 is site specific and -can- 
be unique per visitor and should only be used by portal as a hint/reason 
(capport URL gotten from DHCP rfc 7710) .

On Aug 31, 2016 5:55 AM, "Dave Dolson" 
mailto:ddol...@sandvine.com>> wrote:
An ICMP extension could notify a sender that a 5-tuple connection is walled 
off‎. It works for all IP protocols (TCP, UDP, GRE, even ICMP-echo).
‎This will be more real-time than relying on the sender to periodically probe 
well-known servers on port 80.

Such a message should indicate a reason, which could be a URL to a JSON/REST 
interface.

Or, it could simply be an event that means "go probe port 80 to get redirected"



From: David Bird
Sent: Tuesday, August 30, 2016 9:07 PM
To: Alexander Roscoe
Cc: captive-portals@ietf.org<mailto:captive-portals@ietf.org>
Subject: Re: [Captive-portals] API / ICMP for status and remaining time


I believe ICMP is useful for realtime, 5-tuple flow specific (as well as 
general), notifications, but it should not be used to carry any session 
parameters or meaningful data. A REST API would be better for that.

On Tue, Aug 30, 2016 at 2:49 PM, Alexander Roscoe 
mailto:alexander.ros...@gmail.com>> wrote:
I am looking at the mechanisms to communicate captive portal states to
users. I think a RESTful API would be viable candidate for
communicating this information.  The same URL from RFC7710 or the URL
given by the 302 redirect could be used to as the endpoint for this
service as well.  Clients could reach out to this endpoint to get
status such as "Time Remaining" or "TX/RX transferred".  RESTful
interfaces can be easily setup and can be easily extended to add new
features.

Along side REST, I was looking at the ICMP as a conduit to transmit
this information as well.  Information could be pushed to the clients'
device and then digested rather than pulled like a RESTful protocol.
I think an implementation of this setup could work well on a
deployment where the AAA server resides on the same system as the
gateway because the information in the ICMP is easily accessible.
When the AAA server exists on another system it may pose a problem.
For example, many networks that use captive portals block external
ICMP messages and/or NAT devices to client, therefore the gateway
would need to proxy these packets.  This adds more complexity to the
network design. Also, ICMP message would be very rigid and not as
extendable as a RESTful service. Maybe rigid might be a good thing?

Thoughts?  Did I miss another type of conduit to transfer status...
excluding SOAP :)

--
Alexander Roscoe
484-716-9048

___
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] API / ICMP for status and remaining time

[Dave Dolson]

David,
I have a concern related to the Session ID.

This is specified re: Session-ID:
   Any change in this value between ICMP messages
   MUST be considered by the client to mean a change in access policy
   has occurred and previous notifications are no longer valid.


One problem with this is that different network elements may be competing with 
policy for the same end-point, thrashing each other’s policy.
E.g., one network element could be informing about quota and another could be 
informing about a weather warning.
(Or one of these might not be legitimate.)

A fix for this is to put the Session-ID in the context of the IP address of the 
host sending the ICMP message.
NEW:
   Any change in this value between ICMP messages from the same source IP 
address
   MUST be considered by the client to mean a change in access policy
   has occurred and previous notifications are no longer valid.




From: David Bird [mailto:db...@google.com]
Sent: Tuesday, September 06, 2016 3:59 PM
To: Dave Dolson
Cc: captive-portals@ietf.org; Alexander Roscoe
Subject: Re: [Captive-portals] API / ICMP for status and remaining time

I've updated the I-D here 
https://github.com/wlanmac/draft-wkumari-capport-icmp-unreach, comments 
appreciated.

The Policy Class 'hint' can be any value that both the NAS and CP understand. 
Not all implementations will use it; it is only really useful if your NAS might 
send users to the CP for one of several reasons. A very simple use-case could 
be that the NAS puts the destination port in the Policy Class so that the CP 
knows what services you were trying to access.

On Wed, Aug 31, 2016 at 2:00 PM, Dave Dolson 
mailto:ddol...@sandvine.com>> wrote:
David,
Yes, I would like to see that draft updated, thanks.

Would this new hint support different reasons? E.g., bad weather warning vs. 
payment required?

-Dave


From: David Bird [mailto:db...@google.com<mailto:db...@google.com>]
Sent: Wednesday, August 31, 2016 9:29 AM
To: Dave Dolson
Cc: captive-portals@ietf.org<mailto:captive-portals@ietf.org>; Alexander Roscoe

Subject: Re: [Captive-portals] API / ICMP for status and remaining time


I am working updating 
https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01. I plan to 
add a 'policy class' uint32 to the ICMP message that can be used as a site 
specific 'hint' to the captive portal. This uint32 is site specific and -can- 
be unique per visitor and should only be used by portal as a hint/reason 
(capport URL gotten from DHCP rfc 7710) .

On Aug 31, 2016 5:55 AM, "Dave Dolson" 
mailto:ddol...@sandvine.com>> wrote:
An ICMP extension could notify a sender that a 5-tuple connection is walled 
off‎. It works for all IP protocols (TCP, UDP, GRE, even ICMP-echo).
‎This will be more real-time than relying on the sender to periodically probe 
well-known servers on port 80.

Such a message should indicate a reason, which could be a URL to a JSON/REST 
interface.

Or, it could simply be an event that means "go probe port 80 to get redirected"



From: David Bird
Sent: Tuesday, August 30, 2016 9:07 PM
To: Alexander Roscoe
Cc: captive-portals@ietf.org<mailto:captive-portals@ietf.org>
Subject: Re: [Captive-portals] API / ICMP for status and remaining time


I believe ICMP is useful for realtime, 5-tuple flow specific (as well as 
general), notifications, but it should not be used to carry any session 
parameters or meaningful data. A REST API would be better for that.

On Tue, Aug 30, 2016 at 2:49 PM, Alexander Roscoe 
mailto:alexander.ros...@gmail.com>> wrote:
I am looking at the mechanisms to communicate captive portal states to
users. I think a RESTful API would be viable candidate for
communicating this information.  The same URL from RFC7710 or the URL
given by the 302 redirect could be used to as the endpoint for this
service as well.  Clients could reach out to this endpoint to get
status such as "Time Remaining" or "TX/RX transferred".  RESTful
interfaces can be easily setup and can be easily extended to add new
features.

Along side REST, I was looking at the ICMP as a conduit to transmit
this information as well.  Information could be pushed to the clients'
device and then digested rather than pulled like a RESTful protocol.
I think an implementation of this setup could work well on a
deployment where the AAA server resides on the same system as the
gateway because the information in the ICMP is easily accessible.
When the AAA server exists on another system it may pose a problem.
For example, many networks that use captive portals block external
ICMP messages and/or NAT devices to client, therefore the gateway
would need to proxy these packets.  This adds more complexity to the
network design. Also, ICMP message would be very rigid and not as
extendable as a RESTful service. Maybe rigid might be a good thing?

Tho

Re: [Captive-portals] API / ICMP for status and remaining time

[Dave Dolson]

If I understand correctly, the “Policy Class” can be considered as a “Reason”.
Then different users can be having different portal experiences from the same 
base URL.
Is that what you meant?

If so, I think this does address the issues of URL phishing by an off-net 
attacker.

Any thoughts on whether rate-limiting of messages should be specified?





From: David Bird [mailto:db...@google.com]
Sent: Tuesday, September 06, 2016 4:03 PM
To: Michael Richardson
Cc: Dave Dolson; Alexander Roscoe; captive-portals@ietf.org
Subject: Re: [Captive-portals] API / ICMP for status and remaining time

Ideally, the "Policy Class" hint could be used instead of putting the URL in 
the ICMP packet (which was our original thought). I think it helps to require 
RFC 7710 to get the base CP URL so that Capport ICMP is meaningless in networks 
not configured with Capport DHCP.

On Tue, Sep 6, 2016 at 12:46 PM, Michael Richardson 
mailto:mcr+i...@sandelman.ca>> wrote:

Dave Dolson mailto:ddol...@sandvine.com>> wrote:
> An ICMP extension could notify a sender that a 5-tuple connection is 
walled
> off‎. It works for all IP protocols (TCP, UDP, GRE, even ICMP-echo).
> ‎This will be more real-time than relying on the sender to periodically 
probe
> well-known servers on port 80.

Agreed, it's good.  Like all ICMPs, we must assume that they could be forged.

> Such a message should indicate a reason, which could be a URL to a 
JSON/REST
> interface.
> Or, it could simply be an event that means "go probe port 80 to get
> redirected"

While I think it's slight less attackable to get redirected; I also favour
putting the URL in the packet, even if we ultimately can not trust it.

--
Michael Richardson mailto:mcr%2bi...@sandelman.ca>>, 
Sandelman Software Works
 -= IPv6 IoT consulting =-



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

Re: [Captive-portals] API / ICMP for status and remaining time

[Dave Dolson]

David,
Yes, I would like to see that draft updated, thanks.

Would this new hint support different reasons? E.g., bad weather warning vs. 
payment required?

-Dave


From: David Bird [mailto:db...@google.com]
Sent: Wednesday, August 31, 2016 9:29 AM
To: Dave Dolson
Cc: captive-portals@ietf.org; Alexander Roscoe
Subject: Re: [Captive-portals] API / ICMP for status and remaining time


I am working updating 
https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01. I plan to 
add a 'policy class' uint32 to the ICMP message that can be used as a site 
specific 'hint' to the captive portal. This uint32 is site specific and -can- 
be unique per visitor and should only be used by portal as a hint/reason 
(capport URL gotten from DHCP rfc 7710) .

On Aug 31, 2016 5:55 AM, "Dave Dolson" 
mailto:ddol...@sandvine.com>> wrote:
An ICMP extension could notify a sender that a 5-tuple connection is walled 
off‎. It works for all IP protocols (TCP, UDP, GRE, even ICMP-echo).
‎This will be more real-time than relying on the sender to periodically probe 
well-known servers on port 80.

Such a message should indicate a reason, which could be a URL to a JSON/REST 
interface.

Or, it could simply be an event that means "go probe port 80 to get redirected"



From: David Bird
Sent: Tuesday, August 30, 2016 9:07 PM
To: Alexander Roscoe
Cc: captive-portals@ietf.org<mailto:captive-portals@ietf.org>
Subject: Re: [Captive-portals] API / ICMP for status and remaining time


I believe ICMP is useful for realtime, 5-tuple flow specific (as well as 
general), notifications, but it should not be used to carry any session 
parameters or meaningful data. A REST API would be better for that.

On Tue, Aug 30, 2016 at 2:49 PM, Alexander Roscoe 
mailto:alexander.ros...@gmail.com>> wrote:
I am looking at the mechanisms to communicate captive portal states to
users. I think a RESTful API would be viable candidate for
communicating this information.  The same URL from RFC7710 or the URL
given by the 302 redirect could be used to as the endpoint for this
service as well.  Clients could reach out to this endpoint to get
status such as "Time Remaining" or "TX/RX transferred".  RESTful
interfaces can be easily setup and can be easily extended to add new
features.

Along side REST, I was looking at the ICMP as a conduit to transmit
this information as well.  Information could be pushed to the clients'
device and then digested rather than pulled like a RESTful protocol.
I think an implementation of this setup could work well on a
deployment where the AAA server resides on the same system as the
gateway because the information in the ICMP is easily accessible.
When the AAA server exists on another system it may pose a problem.
For example, many networks that use captive portals block external
ICMP messages and/or NAT devices to client, therefore the gateway
would need to proxy these packets.  This adds more complexity to the
network design. Also, ICMP message would be very rigid and not as
extendable as a RESTful service. Maybe rigid might be a good thing?

Thoughts?  Did I miss another type of conduit to transfer status...
excluding SOAP :)

--
Alexander Roscoe
484-716-9048

___
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] API / ICMP for status and remaining time

[Dave Dolson]

An ICMP extension could notify a sender that a 5-tuple connection is walled 
off‎. It works for all IP protocols (TCP, UDP, GRE, even ICMP-echo).
‎This will be more real-time than relying on the sender to periodically probe 
well-known servers on port 80.

Such a message should indicate a reason, which could be a URL to a JSON/REST 
interface.

Or, it could simply be an event that means "go probe port 80 to get redirected"



From: David Bird
Sent: Tuesday, August 30, 2016 9:07 PM
To: Alexander Roscoe
Cc: captive-portals@ietf.org
Subject: Re: [Captive-portals] API / ICMP for status and remaining time


I believe ICMP is useful for realtime, 5-tuple flow specific (as well as 
general), notifications, but it should not be used to carry any session 
parameters or meaningful data. A REST API would be better for that.

On Tue, Aug 30, 2016 at 2:49 PM, Alexander Roscoe 
mailto:alexander.ros...@gmail.com>> wrote:
I am looking at the mechanisms to communicate captive portal states to
users. I think a RESTful API would be viable candidate for
communicating this information.  The same URL from RFC7710 or the URL
given by the 302 redirect could be used to as the endpoint for this
service as well.  Clients could reach out to this endpoint to get
status such as "Time Remaining" or "TX/RX transferred".  RESTful
interfaces can be easily setup and can be easily extended to add new
features.

Along side REST, I was looking at the ICMP as a conduit to transmit
this information as well.  Information could be pushed to the clients'
device and then digested rather than pulled like a RESTful protocol.
I think an implementation of this setup could work well on a
deployment where the AAA server resides on the same system as the
gateway because the information in the ICMP is easily accessible.
When the AAA server exists on another system it may pose a problem.
For example, many networks that use captive portals block external
ICMP messages and/or NAT devices to client, therefore the gateway
would need to proxy these packets.  This adds more complexity to the
network design. Also, ICMP message would be very rigid and not as
extendable as a RESTful service. Maybe rigid might be a good thing?

Thoughts?  Did I miss another type of conduit to transfer status...
excluding SOAP :)

--
Alexander Roscoe
484-716-9048

___
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] IPv6 RA URI option

[Dave Dolson]

Alexander,
Suppose instead of providing a URL for the landing page, the RA provided the 
URI for a standardized REST interface; the client could post its details (MAC 
address, device type?) to this interface, which would return the URL for the 
browser landing page, and possibly any number of other details and mechanisms, 
e.g., in a JSON response.

This adds a level of indirection that simplifies what needs to go in the RA.

I think there is also flexibility in letting the client know details about the 
capport situation in the API. E.g., how often will the page need to be visited?

RA-->client:  “This is the URI for getting capport info: 
http://capport.example.com/api”
Client-->capport/api: “My MAC address is 01:02:03:04:05:06 and my IP address is 
…”
Capport/api-->client: “Your landing page is 
https://capport.example.com/landing/mac=01:02:03:04:05:06 ; refresh every 60min”



-Dave


From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
Alexander Roscoe
Sent: Friday, August 26, 2016 11:15 AM
To: captive-portals@ietf.org
Subject: [Captive-portals] IPv6 RA URI option

I am looking over RFC 7710 concerning how 
the URI is communicated to the end user.  I really like the IPv4 DHCP solution, 
 I think this could easily be implemented in a DHCP server.  I think it could 
be easily implemented in the RA for IPv6 as well however I do see a challenge 
when each connected client needs a unique URI such as it containing the 
parameter for the client mac. For example, a url like 
https://captiveportal/?client-mac=11:22:33:44:55:66. The RA is sent to everyone 
and cannot be tailored to each client while DHCP is very client specific and 
can be changed on-the-fly.  Most captive portals rely on the client mac address 
during the authentication process. I am aware of networks using the IP address 
to associate the user at the AAA server but from my understanding this is a 
rare network setup.  I think a potential solution for the IPv6 RA would be to 
define an HTTP POST parameter in which the client can use like ‘client-mac’ and 
let the client post it the URI https://captiveporta/.   Thoughts? Ideas?


--
Alexander Roscoe
484-716-9048
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00

[Dave Dolson]

Regarding non-browser clients, even non-HTTP clients, and considering
this is the IETF, it seems reasonable to find an IP-layer solution vs. 
an HTTP-layer solution.

E.g., a new ICMP/ICMP6 error code to indicate the host is walled, with a pointer
to the method to authenticate in the payload.
This could be an extension to "Network Unreachable", or a new code.

ICMP messages are handled by the O/S, and could trigger an authentication 
work-flow
appropriate to the device, whether it be a human-interface device like a tablet
or a head-less IOT device.

E.g., suppose the a VoIP phone becomes walled during a call. Outgoing packets
are answered with an ICMP message; the O/S immediately performs the 
authentication
using previously-provided credentials, and the call continues shortly 
thereafter.
If the credentials fail, the user can be presented with a  window or browser.


The ICMP payload would be a standard format, and could have security features
to avoid spoofing.


I guess I'm jumping ahead of the problem statement, but I think the
"Non-Browser Clients" issue could be changed to "Non-HTTP Clients",
providing a huge win.



-Dave




-Original Message-
From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
Martin Thomson
Sent: Wednesday, March 02, 2016 7:25 PM
To: Livingood, Jason
Cc: Mark Nottingham; captive-portals@ietf.org
Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00

On 3 March 2016 at 11:16, Livingood, Jason  wrote:
> 3.0, Feel free to take a look at the text in Section 12 of RFC 6108 and
> use some of that text. You got the gist of it in the Non-Browser Clients
> sub-section though (https://tools.ietf.org/html/rfc6108#section-12)


This raises an interesting point about internet dot org by facebook.
I wonder if there are any lessons to be learned from that as well.

___
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] Feedback requested: Charter text.

[Dave Dolson]

Hyperbole aside, ‎the techniques in use today can be deployed in any network 
gear along the path, even theoretically in a core router, and also to present 
any kind of alert. Yet the internet has not degraded into chaos.

I know that some captive portal enforcement points reside at locations other 
than ‎WiFi access points. Sometimes the networks aren't even WiFi networks. So 
failing to provide for those would mean mobile devices would need to continue 
with proprietary methods and new methods as well.

So I think this group could try to solve the general problem, or just address 
the "WiFi at hotels and airports" problem.‎ The former is what I'd expect from 
IETF.

-Dave
‎
  Original Message
From: 🔓Dan Wing
Sent: Monday, June 29, 2015 10:33 PM
To: Dave Dolson
Cc: Warren Kumari; captive-portals@ietf.org
Subject: Re: [Captive-portals] Feedback requested: Charter text.


On 26-Jun-2015 11:11 am, Dave Dolson  wrote:
>
> A couple of discussion points, since you asked:
>
> 1.
> "Captive Portal" is a term that seems to be specifically about getting access 
> to the network.
> Could this technology embrace other forms of alerts, such as 
> tornado/tsunami/fire/toxic-spill ?
> In other words, the ability of the network to interrupt the user with,
> "I need your eyes on this information, right now"

Only if the device can handle such alerts (opt-in, somehow).  I mean, we don't 
want our own fire alarm system interrupted from its communication because of a 
tornado 10 miles away, and we don't want our Internet-connected door lock 
interrupted because of a fire (even a fire within the same building).  And we 
don't want to relive 1987 for our normal web usage, either; 
https://en.wikipedia.org/wiki/Max_Headroom_broadcast_signal_intrusion.  That 
is, such interruptions need to be authorized and authenticated.

tl;dr:  No.


> 2.
> On an unrelated note, should probably allow devices without operators or 
> screens (IoT devices) to fulfill CP requirements.
> Hence, not just about browsers rendering HTML to humans, but any kind of 
> client.
>
>
> 3.
> Although the proposed charter doesn't say it, some discussion seems to 
> indicate this should be a link-layer
> problem. I.e., a matter for DHCP and the first-hop router. I'd like to see 
> this posed as an internet-layer
> problem, hence applicable to all forms of internet access, and made 
> enforceable by any forwarding device
> along the path. As a simple example, a device behind a NAT may need to 
> receive a captive-portal alert from
> an enforcement point on the other side of the NAT.

I'm not sure how that would work.  Are you mentioning NAT because of address 
sharing (NAPT) which makes it difficult/impossible to distinguish separate 
devices on the public side of a NAPT?

I would not want any device along the path able to inject itself to become a 
captive portal; imagine the chaos if a core router did that.

-d


>
>
> I don't know if any of my points warrant changes to the proposed charter. But 
> if the above are to be
> specifically excluded, it's probably worth saying so.
>
>
>
> -Dave
>
>
>
>
>
>
>
> -Original Message-
> From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
> Warren Kumari
> Sent: Tuesday, June 23, 2015 2:26 PM
> To: captive-portals@ietf.org
> Subject: [Captive-portals] Feedback requested: Charter text.
>
> Hi all,
>
> We have a BoF scheduled for the IETF in Prague.
>
> We would like to get a discussion going on some *strawman* charter text.
>
>
> -
>
> Captive Portals are used to restrict access to a network until users
> have purchased access, or accepted Acceptable Use Polices (AUP).
> They accomplish this by intercepting connections from unauthenticated
> clients, redirecting them to an authentication server, and then
> granting access (if satisfied). By developing a standard set of
> Captive Portal interactions (including simple ways for clients to
> discover and interact with CPs), we will significantly improve the CP
> user experience, increase security, and simply the CP interceptions.
> This will increase the user completion rate, increase the CP
> interception reliability, and decrease the implementation complexity
> and cost.
>
> Many of the interception techniques are very similar to
> man-in-the-middle attacks, and, as clients become more secure, are
> increasingly ineffective, leading to a poor user experience. Many of
> the captive portals require a web browser to interact with the
> authentication system, and may require that the user disconnects any
> VPNs, browses to a non-HTTPs site, or similar. In addition, there is
> no standard way to discover the existence of the capti

Re: [Captive-portals] Feedback requested: Charter text.

[Dave Dolson]

A couple of discussion points, since you asked:

1.
"Captive Portal" is a term that seems to be specifically about getting access 
to the network.
Could this technology embrace other forms of alerts, such as 
tornado/tsunami/fire/toxic-spill ?
In other words, the ability of the network to interrupt the user with, 
"I need your eyes on this information, right now"


2.
On an unrelated note, should probably allow devices without operators or 
screens (IoT devices) to fulfill CP requirements.
Hence, not just about browsers rendering HTML to humans, but any kind of client.


3.
Although the proposed charter doesn't say it, some discussion seems to indicate 
this should be a link-layer 
problem. I.e., a matter for DHCP and the first-hop router. I'd like to see this 
posed as an internet-layer 
problem, hence applicable to all forms of internet access, and made enforceable 
by any forwarding device 
along the path. As a simple example, a device behind a NAT may need to receive 
a captive-portal alert from
an enforcement point on the other side of the NAT.



I don't know if any of my points warrant changes to the proposed charter. But 
if the above are to be
specifically excluded, it's probably worth saying so.



-Dave







-Original Message-
From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
Warren Kumari
Sent: Tuesday, June 23, 2015 2:26 PM
To: captive-portals@ietf.org
Subject: [Captive-portals] Feedback requested: Charter text.

Hi all,

We have a BoF scheduled for the IETF in Prague.

We would like to get a discussion going on some *strawman* charter text.


-

Captive Portals are used to restrict access to a network until users
have purchased access, or accepted Acceptable Use Polices (AUP).
They accomplish this by intercepting connections from unauthenticated
clients, redirecting them to an authentication server, and then
granting access (if satisfied). By developing a standard set of
Captive Portal interactions (including simple ways for clients to
discover and interact with CPs), we will significantly improve the CP
user experience, increase security, and simply the CP interceptions.
This will increase the user completion rate, increase the CP
interception reliability, and decrease the implementation complexity
and cost.

Many of the interception techniques are very similar to
man-in-the-middle attacks, and, as clients become more secure, are
increasingly ineffective, leading to a poor user experience. Many of
the captive portals require a web browser to interact with the
authentication system, and may require that the user disconnects any
VPNs, browses to a non-HTTPs site, or similar. In addition, there is
no standard way to discover the existence of the captive portal, when
the captive portal has been satisfied, and how much time remains
before the captive portal restricts access again.

The Captive Portal (CAPPORT) Working Group will address these (and
related issues) by defining a standard mechanism for clients to
interact with Captive Portals, including how to connect to the captive
portal and how to communicate with it to obtain status information
such as remaining access time, purchased bandwith class, etc.

This working group will seek participation and input from browser /
operating system vendors, captive portal developers and operators.
One of the known challenges is that some captive portal operators may
not want to use a standard interaction protocol, preferring to perform
more intrusive interception and interactions. We are hoping that the
benefits to CP standardization outlined here are sufficient to not
only encourage input from CP developers and operators, but also aid in
deployment.

Milestones:
TDB: Initial problem statement / use case document [0]
TBD: Initial terminology document [1]
TBD: Initial portal interaction document (perhaps based upon
http://coova.org/CoovaChilli/JSON ?)
TBD: Extended portal interaction document (for systems without browsers)

[ Each of these milestones is actually Initial draft -> WGLC -> IESG, etc ]


[0]: Primarily to ensure that we are understand what we are trying to
accomplish / working to the same goal. This may or may not become an
RFC...
[1]:  We have already discovered that we have issues here - what's the
webpage after the CP has granted access called? What's the "lease"
time called -- different vendors have different names for things.
Crappy first pass:
http://www.ietf.org/mail-archive/web/captive-portals/current/msg9.html




-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

___
Captive-portals 

Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach

[Dave Dolson]

‎I like the ICMP idea because it is immediate, and can be applied to any 
traffic (not just http).

I think it even allows use cases where some traffic is permitted and other 
traffic denied. ‎ E.g., allow http to certain web sites, but otherwise access 
portal to unlock full features.

However, I'm concerned application software won't be able to receive these ICMP 
messages on most operating systems. I'm unsure about this.

David Dolson
Senior Software Architect, Sandvine Inc.
From: David Bird
Sent: Friday, May 1, 2015 12:29 AM
To: Dave Dolson
Cc: Warren Kumari; Yaron Sheffer; captive-portals@ietf.org
Subject: Re: [Captive-portals] A new draft / idea - 
draft-wkumari-capport-icmp-unreach


I think there are two (probably more :) concepts at play here; assisting a 
client's captive portal discovery mechanism in identifying a CP network and the 
discovery of the login URL, and the notification ("hints") to the client about 
why connections failed (and to trigger a new CP detection loop), and when they 
may start failing. I tried to combine these with the optional URL/URI, but 
agree that's problematic. In the absence of CP info from DHCP (or RA), CP 
detection can do the current HTTP redirect check.

I think the ICMP notification mechanism is helpful, thoughts?

On Thu, Apr 30, 2015 at 7:49 PM, Dave Dolson 
mailto:ddol...@sandvine.com>> wrote:
I think it would be desirable to keep the captive portal mechanism independent 
of DHCP. The captive portal enforcement need not be on the same link as the 
user device. Furthermore, DHCP is not the only way to obtain an IP address.

David Dolson
Senior Software Architect, Sandvine Inc.
  Original Message
From: Warren Kumari
Sent: Thursday, April 30, 2015 8:02 PM
To: Yaron Sheffer
Cc: captive-portals@ietf.org<mailto:captive-portals@ietf.org>
Subject: Re: [Captive-portals] A new draft / idea - 
draft-wkumari-capport-icmp-unreach


On Thu, Apr 30, 2015 at 10:52 AM, Yaron Sheffer 
mailto:yaronf.i...@gmail.com>> wrote:
> Hi Warren.
>
> The security consideration (an attacker can send any arbitrary URL, and will
> redirect you at will) seems like a showstopper to me.

Yeah, we were a bit freaked about that too :-)

I have removed the URL / URI stuff - now this is simply annotates
Destination Unreachable to explain that the reason for the Dest
Unreachable is because of a captive portal.

>
> Also, once you have the DHCP mechanism, you can have client-initiated
> communication to a well-defined interface, and you don't need to deal with
> arbitrary connections being rejected. After all, the client needs to get an
> IP address from DHCP before it can initiate any such connection.


One reason that this is still useful is that eventually your captive
portal connection will expire and the CP will close. If you have
gotten CP information from DHCP, and then start getting these
Destination Unreachables you will know to connect to the captive
portal URL and pay again
So, basically, get CP information from DHCP and use it. After 4hours
(or whatever), you start getting these new unrechables and know to
connect and pay again...

I think that the security implications are now the same as for
"regular" (extended) Destination Unreachable.

Thoughts?

Thank you very much for your feedback,
W

>
> Thanks,
> Yaron
>
>
> On 04/29/2015 11:32 PM, Warren Kumari wrote:
>>
>> Hi y'all.
>>
>>
>> So, this short document discusses another way for Captive Portals to
>> inform users that they are behind a CP. Basically, it uses an extended
>> ICMP Destination Unreachable message to let the host know that the
>> reason it cannot reach a destination is because it is behind a CP and
>> also includes a URL to reach the CP.
>>
>> This idea is mainly David's, I'm largely the editor. We'd really like
>> some feedback on this idea and the implementation we've written up.
>> Obviously the document would need a bunch more work, but we'd like to
>> get some idea if folk think this is worth pursuing.
>>
>> URL:
>>
>> https://www.ietf.org/internet-drafts/draft-wkumari-capport-icmp-unreach-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-wkumari-capport-icmp-unreach/
>> Htmlized:
>> https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-00
>>
>> It is somewhat similar to the wkumari-dhc-capport document, but solves
>> a different issue, in a different way - I think that they are
>> complementary documents.
>>
>>
>> Any feedback gratefully accepted.
>> W
>>
>



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having ch

Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach

[Dave Dolson]

Any middlebox between user and server can block traffic and redirect http.
An IETF protocol should not mix layering or be limited to specific access 
technology.

IPv6 has ‎autoconfiguration for obtaining IP addresses.

3GPP has specific GTP-based mechanisms for obtaining IP addresses.

So DHCP isn't even always used to access the internet.

David Dolson
Senior Software Architect, Sandvine Inc.
  Original Message
From: Yaron Sheffer
Sent: Friday, May 1, 2015 7:43 AM
To: Dave Dolson; Warren Kumari
Cc: captive-portals@ietf.org
Subject: Re: [Captive-portals] A new draft / idea - 
draft-wkumari-capport-icmp-unreach


As a user, I have never seen a case where the captive portal is not on
the same link as the client device, and never seen a case where an IP is
obtained using a non-DHCP mechanism when in a CP setting. Can you give
some concrete examples?

Thanks,
Yaron

On 05/01/2015 05:49 AM, Dave Dolson wrote:
> I think it would be desirable to keep the captive portal mechanism 
> independent of DHCP. The captive portal enforcement need not be on the same 
> link as the user device. Furthermore, DHCP is not the only way to obtain an 
> IP address.
>
> David Dolson
> Senior Software Architect, Sandvine Inc.
>Original Message
> From: Warren Kumari
> Sent: Thursday, April 30, 2015 8:02 PM
> To: Yaron Sheffer
> Cc: captive-portals@ietf.org
> Subject: Re: [Captive-portals] A new draft / idea - 
> draft-wkumari-capport-icmp-unreach
>
>
> On Thu, Apr 30, 2015 at 10:52 AM, Yaron Sheffer  wrote:
>> Hi Warren.
>>
>> The security consideration (an attacker can send any arbitrary URL, and will
>> redirect you at will) seems like a showstopper to me.
>
> Yeah, we were a bit freaked about that too :-)
>
> I have removed the URL / URI stuff - now this is simply annotates
> Destination Unreachable to explain that the reason for the Dest
> Unreachable is because of a captive portal.
>
>>
>> Also, once you have the DHCP mechanism, you can have client-initiated
>> communication to a well-defined interface, and you don't need to deal with
>> arbitrary connections being rejected. After all, the client needs to get an
>> IP address from DHCP before it can initiate any such connection.
>
>
> One reason that this is still useful is that eventually your captive
> portal connection will expire and the CP will close. If you have
> gotten CP information from DHCP, and then start getting these
> Destination Unreachables you will know to connect to the captive
> portal URL and pay again
> So, basically, get CP information from DHCP and use it. After 4hours
> (or whatever), you start getting these new unrechables and know to
> connect and pay again...
>
> I think that the security implications are now the same as for
> "regular" (extended) Destination Unreachable.
>
> Thoughts?
>
> Thank you very much for your feedback,
> W
>
>>
>> Thanks,
>>  Yaron
>>
>>
>> On 04/29/2015 11:32 PM, Warren Kumari wrote:
>>>
>>> Hi y'all.
>>>
>>>
>>> So, this short document discusses another way for Captive Portals to
>>> inform users that they are behind a CP. Basically, it uses an extended
>>> ICMP Destination Unreachable message to let the host know that the
>>> reason it cannot reach a destination is because it is behind a CP and
>>> also includes a URL to reach the CP.
>>>
>>> This idea is mainly David's, I'm largely the editor. We'd really like
>>> some feedback on this idea and the implementation we've written up.
>>> Obviously the document would need a bunch more work, but we'd like to
>>> get some idea if folk think this is worth pursuing.
>>>
>>> URL:
>>>
>>> https://www.ietf.org/internet-drafts/draft-wkumari-capport-icmp-unreach-00.txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-wkumari-capport-icmp-unreach/
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-00
>>>
>>> It is somewhat similar to the wkumari-dhc-capport document, but solves
>>> a different issue, in a different way - I think that they are
>>> complementary documents.
>>>
>>>
>>> Any feedback gratefully accepted.
>>> W
>>>
>>
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
> ---maf
>
> ___
> 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] A new draft / idea - draft-wkumari-capport-icmp-unreach

[Dave Dolson]

I think it would be desirable to keep the captive portal mechanism independent 
of DHCP. The captive portal enforcement need not be on the same link as the 
user device. Furthermore, DHCP is not the only way to obtain an IP address.

David Dolson
Senior Software Architect, Sandvine Inc.
  Original Message
From: Warren Kumari
Sent: Thursday, April 30, 2015 8:02 PM
To: Yaron Sheffer
Cc: captive-portals@ietf.org
Subject: Re: [Captive-portals] A new draft / idea - 
draft-wkumari-capport-icmp-unreach


On Thu, Apr 30, 2015 at 10:52 AM, Yaron Sheffer  wrote:
> Hi Warren.
>
> The security consideration (an attacker can send any arbitrary URL, and will
> redirect you at will) seems like a showstopper to me.

Yeah, we were a bit freaked about that too :-)

I have removed the URL / URI stuff - now this is simply annotates
Destination Unreachable to explain that the reason for the Dest
Unreachable is because of a captive portal.

>
> Also, once you have the DHCP mechanism, you can have client-initiated
> communication to a well-defined interface, and you don't need to deal with
> arbitrary connections being rejected. After all, the client needs to get an
> IP address from DHCP before it can initiate any such connection.


One reason that this is still useful is that eventually your captive
portal connection will expire and the CP will close. If you have
gotten CP information from DHCP, and then start getting these
Destination Unreachables you will know to connect to the captive
portal URL and pay again
So, basically, get CP information from DHCP and use it. After 4hours
(or whatever), you start getting these new unrechables and know to
connect and pay again...

I think that the security implications are now the same as for
"regular" (extended) Destination Unreachable.

Thoughts?

Thank you very much for your feedback,
W

>
> Thanks,
> Yaron
>
>
> On 04/29/2015 11:32 PM, Warren Kumari wrote:
>>
>> Hi y'all.
>>
>>
>> So, this short document discusses another way for Captive Portals to
>> inform users that they are behind a CP. Basically, it uses an extended
>> ICMP Destination Unreachable message to let the host know that the
>> reason it cannot reach a destination is because it is behind a CP and
>> also includes a URL to reach the CP.
>>
>> This idea is mainly David's, I'm largely the editor. We'd really like
>> some feedback on this idea and the implementation we've written up.
>> Obviously the document would need a bunch more work, but we'd like to
>> get some idea if folk think this is worth pursuing.
>>
>> URL:
>>
>> https://www.ietf.org/internet-drafts/draft-wkumari-capport-icmp-unreach-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-wkumari-capport-icmp-unreach/
>> Htmlized:
>> https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-00
>>
>> It is somewhat similar to the wkumari-dhc-capport document, but solves
>> a different issue, in a different way - I think that they are
>> complementary documents.
>>
>>
>> Any feedback gratefully accepted.
>> W
>>
>



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
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