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

From: Martin Thomson <[email-masked]>
Date: Sat, 1 Apr 2017 15:40:32 -0500

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

---

From: David Bird <[email-masked]>
Date: Sat, 1 Apr 2017 17:18:45 -0700

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

Contributors (and co-authors) welcome!

---

From: Dave Dolson <[email-masked]>
Date: Sun, 2 Apr 2017 19:04:48 +0000

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: [email-masked]; [email-masked]
Subject: Re: [Captive-portals] Review of draft-wkumari-capport-icmp-unreach-01

On Sat, Apr 1, 2017 at 1:40 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
(As a contributor only.)

David, Warren,

# Extension payload

---

From: David Bird <[email-masked]>
Date: Sun, 2 Apr 2017 14:04:09 -0700

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 <[email-masked]> 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: [email-masked];
> [email-masked]
> *Subject: *Re: [Captive-portals] Review of draft-wkumari-capport-icmp-
> unreach-01
>

---

From: Dave Dolson <[email-masked]>
Date: Sun, 2 Apr 2017 21:54:21 +0000

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

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

David, Warren,

# Extension payload

---

From: David Bird <[email-masked]>
Date: Sun, 2 Apr 2017 15:45:52 -0700

I think it is helpful to think of it this way:

Validity is a way for the NAS to inform the UE of it's rate limiting
policy. As in, if you ask again within Validity, I'm going to ignore you.
(Also, the UE kernel or "icmpd" would hold on to that tuple for at least
that long for applications to query the Dest Unreach reason). This could
have security considerations, but a UE might decide to take the value with
a grain of salt and try a couple times in the meantime, just in case.

Delay is a way (albeit, largely vendor specific in how it would be
implemented with AAA infrastructures) for the NAS to poke the UE indicating
a future 'change in policy' to a specific flow (or overall). For a capport
compliant location, the UE knows it should 'suggest', not require, the user
visit the captive portal. Of course, the UE will continue connections past
the Delay timer, but will not be surprised when it starts to see capport
ICMP again. (The NAS who is enforcing max bytes up/down limitations --
common in hotspots -- is in a good position to calculate how long a session
has remaining in real-time).

On Sun, Apr 2, 2017 at 2:54 PM, Dave Dolson <[email-masked]> wrote:

> *Sent: *Sunday, April 2, 2017 5:04 PM
> *To: *Dave Dolson
> *Cc: *Martin Thomson; [email-masked];
> [email-masked]
>> *Subject: *Re: [Captive-portals] Review of draft-wkumari-capport-icmp-unr
>> each-01
>>