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

From: Alexander Roscoe <[email-masked]>
Date: Tue, 30 Aug 2016 17:49:44 -0400

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

---

From: Erik Kline <[email-masked]>
Date: Wed, 31 Aug 2016 08:51:35 +0900

I would say please don't hack stuff into ICMP.

It will be easier for client platforms (mobile devices, laptop OSes,
...) to whip up a simple REST app than update ICMP handling.  Yes the
latter is certainly doable, but a REST API will be so much more
capable and future-proof, IMHO.

If this working group worked to spec v1 of the API that would make
sense to me.  :)

On 31 August 2016 at 06:49, Alexander Roscoe <[email-masked]> wrote:
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals

---

From: David Bird <[email-masked]>
Date: Tue, 30 Aug 2016 18:07:32 -0700

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.

---

From: Dave Dolson <[email-masked]>
Date: Wed, 31 Aug 2016 12:55:41 +0000

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

---

From: David Bird <[email-masked]>
Date: Wed, 31 Aug 2016 06:28:40 -0700

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

---

From: Alexander Roscoe <[email-masked]>
Date: Wed, 31 Aug 2016 09:46:42 -0400

I think a hybrid approach, ICMP/API, would be efficient .  One scenario I
see frequently is

User connects to access point 1 and has internet
User starts an internet session
User moves closer to access point 2(different network w/ captive portal)
automatically connects due to RSSIs
User sends packets as if the device has internet

Many devices won't even re-IP or send a DHCP discover even though are on a
different network completely. The ICMP response for these packets could
trigger the captive portal faster for a better user experience.

For the DHCP option from RFC7710, is it correct to say a device should not
assume the device is behind a captive portal based on that option being
present in the DHCP offer?  If the option stays after authentication, the
device can still receive that URL if it were used as an API endpoint.  Then
ICMP could be the mechanism for state.

On Wed, Aug 31, 2016 at 9:28 AM, David Bird <[email-masked]> wrote:

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

-- 
Alexander Roscoe
484-716-9048

---

From: David Bird <[email-masked]>
Date: Wed, 31 Aug 2016 07:37:45 -0700

Regarding DHCP, I think we have to assume the rfc 7710 attribute remains in
the responses always. Not all capport implementations use an integrated
DHCP server, and I don't think DHCP should be queried by clients for
capport state.

On Aug 31, 2016 6:47 AM, "Alexander Roscoe" <[email-masked]>
wrote:

>> I am working updating https://tools.ietf.org/html/dr
>> aft-wkumari-capport-icmp-unreach-01. I plan to add a 'policy class'

---

From: Dave Dolson <[email-masked]>
Date: Wed, 31 Aug 2016 21:00:22 +0000

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

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