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

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Sep 2016 15:46:48 -0400

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.

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: David Bird <[email-masked]>
Date: Tue, 6 Sep 2016 12:58:49 -0700

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

---

From: David Bird <[email-masked]>
Date: Tue, 6 Sep 2016 13:02:30 -0700

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

> walled
> JSON/REST

---

From: Dave Dolson <[email-masked]>
Date: Tue, 6 Sep 2016 20:56:06 +0000

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:[email-masked]]
Sent: Tuesday, September 06, 2016 4:03 PM
To: Michael Richardson
Cc: Dave Dolson; Alexander Roscoe; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Dave Dolson <[email-masked]>
Date: Tue, 6 Sep 2016 21:03:40 +0000

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:[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/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

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

---

From: Dave Dolson <[email-masked]>
Date: Tue, 6 Sep 2016 21:04:59 +0000

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

-Dave

-Dave

From: David Bird

---

From: David Bird <[email-masked]>
Date: Tue, 6 Sep 2016 14:25:48 -0700

> Then different users can be having different portal experiences from the

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

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.

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

> *Sent:* Tuesday, September 06, 2016 4:03 PM
> *To:* Michael Richardson
> *Cc:* Dave Dolson; Alexander Roscoe; [email-masked]

---

From: Dave Dolson <[email-masked]>
Date: Tue, 6 Sep 2016 21:31:44 +0000

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

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.

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:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, September 06, 2016 4:03 PM
To: Michael Richardson
Cc: Dave Dolson; Alexander Roscoe; [email-masked]<mailto:[email-masked]>
Subject: Re: [Captive-portals] API / ICMP for status and remaining time

---

From: David Bird <[email-masked]>
Date: Tue, 6 Sep 2016 15:14:23 -0700

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:

> *Sent:* Tuesday, September 06, 2016 3:59 PM
> *To:* Dave Dolson
> I've updated the I-D here https://github.com/
> wlanmac/draft-wkumari-capport-icmp-unreach, comments appreciated.
>
>
>