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

From: Erik Kline <[email-masked]>
Date: Tue, 18 Oct 2016 23:45:32 +0900

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 <[email-masked]> 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 <[email-masked]> 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:[email-masked]]
>> *Sent:* Tuesday, September 06, 2016 3:59 PM
>> *To:* Dave Dolson
>> *Cc:* [email-masked]; Alexander Roscoe
>> *Subject:* Re: [Captive-portals] API / ICMP for status and remaining time
>>
>>
>>
>> I've updated the I-D here https://github.com/wlanma
>> c/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 <[email-masked]>
>> 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:[email-masked]]
>> *Sent:* Wednesday, August 31, 2016 9:29 AM
>> *To:* Dave Dolson
>> *Cc:* [email-masked]; Alexander Roscoe
>>
>>
>> *Subject:* Re: [Captive-portals] API / ICMP for status and remaining time
>>
>>
>>
>> I am working updating https://tools.ietf.org/html/dr
>> aft-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" <[email-masked]> 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: [email-masked]
>>
>> *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 <
>> [email-masked]> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/captive-portals
>>
>>
>>
>>
>>
>>
>>
>
>
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>

---

From: David Bird <[email-masked]>
Date: Fri, 21 Oct 2016 14:06:10 -0700

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

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

---

From: Dave Dolson <[email-masked]>
Date: Fri, 21 Oct 2016 22:25:46 +0000

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; [email-masked]; 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, September 06, 2016 3:59 PM
To: Dave Dolson
Cc: [email-masked]<mailto:[email-masked]>; 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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 31, 2016 9:29 AM
To: Dave Dolson
Cc: [email-masked]<mailto:[email-masked]>; 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" <[email-masked]<mailto:[email-masked]>> 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: [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

--
Alexander Roscoe
484-716-9048<tel:484-716-9048>

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

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