Subject: [Captive-portals] Requirements for "captive portal closed" notifications

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 20 Mar 2018 15:29:04 +0000

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

---

From: Dave Dolson <[email-masked]>
Date: Tue, 20 Mar 2018 11:39:37 -0400

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:
> 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 <popularwebsite>: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.
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals

---

From: David Bird <[email-masked]>
Date: Tue, 20 Mar 2018 08:44:09 -0700

On Tue, Mar 20, 2018 at 8:29 AM, Lorenzo Colitti <[email-masked]> wrote:

>    - 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 <popularwebsite>: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.
>
>
Is there any data that shows ICMP (and its insecurity) being used for
off-path attacks like this today? Networks (as they do today) may just
filter out ICMP they don't support from the edge.

>    -

Agreed.

> should not spend our time talking about it.

Can't a network have this policy irrespective of how we implement ICMP?
Can't they even today just use existing ICMP messages? I cringe when we
start dictating how PUBLIC ACCESS networks manage their walled garden and
businesses.

> than a binary "you are or will very soon be captive". Saying things like
> "an upgrade opportunity is available" may be hard to encode.
>

Agreed. That wasn't part of the draft.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 20 Mar 2018 16:01:44 +0000

> filter out ICMP they don't support from the edge.

Regardless of whether this is happening today, it seems unwise to propose
something with an obvious security hole like this. The risk is that we do a
bunch of work and then security review tells us "?REDO FROM START".

> start dictating how PUBLIC ACCESS networks manage their walled garden and

My point was that there's no use in having that discussion, because we know
there are strong opinions on both sides and thus we're not likely to get
consensus.

---

From: David Bird <[email-masked]>
Date: Tue, 20 Mar 2018 09:07:01 -0700

On Tue, Mar 20, 2018 at 9:01 AM, Lorenzo Colitti <[email-masked]> wrote:

> My point was that there's no use in having that discussion, because we
> know there are strong opinions on both sides and thus we're not likely to
> get consensus.
>

My point is that you are the one *making* this a discussion not likely to
get consensus by loading the question with statements like "you can reach
facebook, but to reach CNN you need to upgrade to another service plan"
...  which isn't a problem with ICMP per se, rather how you don't like how
some public access networks operate...

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 20 Mar 2018 16:11:50 +0000

> some public access networks operate...

Sure. I could be wrong. If you think you can reach rough consensus, don't
let me stop you from trying.

---

From: David Bird <[email-masked]>
Date: Tue, 20 Mar 2018 09:24:23 -0700

I meant the royal "you" (apologies :)

No, you are right about the consensus. The notion that this WG can and
should change the business practices of public access networks runs deep.

I'm not taking sides on these "net neutrality" issues... Indeed, they are
hugely important -- GO VOTE!

But, soapboxes aside, what we do with ICMP here will not change business
models that already exist today...

On Tue, Mar 20, 2018 at 9:11 AM, Lorenzo Colitti <[email-masked]> wrote:

>> get consensus by loading the question with statements like "you can
>> reach facebook, but to reach CNN you need to upgrade to another service
>> plan" ...  which isn't a problem with ICMP per se, rather how you don't
>> like how some public access networks operate...
>>
>

---

From: Pierre Pfister <[email-masked]>
Date: Tue, 20 Mar 2018 16:51:44 +0000

Turning the requirements around I would add that sending ICMP messages based on a session being ‘almost done’ might be challenging from a router/hardware perspective. Routers might have to rate-limit such messages, and sometimes fail to send them.

So I would add that the ICMP message should only be relied upon as a backup mechanism to detect that something is wrong while the API mechanism already failed to detect that the session is almost over.
In other words, I think the detection of a session being almost over is first and foremost a problem to be solved by the API mechanism, and as a backup (i.e. in case of inconsistency between the API and the Enforcement point), with the ICMP mechanism.

- Pierre

> Le 20 mars 2018 à 15:29, Lorenzo Colitti <[email-masked]> a écrit :
> 
> 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 <popularwebsite>: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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Mar 2018 19:08:21 +0200

Dave Dolson writes:
> 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."

That might be applicable for other cases too. I.e., we do not want
client to go to the API every second to be able to show the timeout on
the screen with one second accuracy.

So perhaps UE MUST rate-limit API requests in general, not only
ICMP-triggered ones. 

Also if the UE uses HTTP keepalive and keeps API connection open for
60 seconds or so after use, that will of course also limit traffic
generated, especially in case if the API connection is over TLS.

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

Yes.

Also if authenticating ICMP messages would be easy there would already
be authentication in them :-)
-- 
[email-masked]

---

From: David Bird <[email-masked]>
Date: Tue, 20 Mar 2018 17:15:34 +0000

On Tue, Mar 20, 2018, 9:56 AM Pierre Pfister <[email-masked]>
wrote:

> Turning the requirements around I would add that sending ICMP messages
> based on a session being ‘almost done’ might be challenging from a
> router/hardware perspective. Routers might have to rate-limit such
> messages, and sometimes fail to send them.
>

My feeling is just the opposite.. the NAS knows perfectly when it will or
will not hold a session captive. If that NAS is being told what to do (e.g.
it isn't working on it's own counters, but relying on a radius server),
then the radius CoA could just come early with extra parameters (e.g.
'grace period' or even how many and how often to send icmp warnings...)

> So I would add that the ICMP message should only be relied upon as a
> backup mechanism to detect that something is wrong while the API mechanism
> already failed to detect that the session is almost over.
> In other words, I think the detection of a session being almost over is
> first and foremost a problem to be solved by the API mechanism, and as a
> backup (i.e. in case of inconsistency between the API and the Enforcement
> point), with the ICMP mechanism.
>
> - Pierre
>

---

From: David Bird <[email-masked]>
Date: Tue, 20 Mar 2018 17:40:59 +0000

Likewise, I'm not saying the API can't play a role either (especially in
verifying / confirming ICMP) ...

My biggest concern with the API providing this kind of notification,
instead of the NAS/network, is that the API can so very easily be wrong or
misinformed - especially when you consider how some hotspots may have
multiple RADIUS servers because of roaming partners and the like. Sure, it
requires "more work" to get the ICMP feature plumbed through a hotspot
architecture (e.g. RADIUS client updates, development required, etc). But,
that is *good* that all that must take place before the feature can be
used... opposed to creating an API with these features and worrying about
the network integration later (with a broken network in the meantime). By
"broken" ... I mean a network that works fine with older devices, just
generating a lot of complaints from UE users with the new Capport enabled
UE devices...

On Tue, Mar 20, 2018 at 10:29 AM Pierre Pfister <[email-masked]>
wrote:

>
>
> Le 20 mars 2018 à 17:06, David Bird <[email-masked]> a écrit :
>
>
>
> 'grace period' or even how many and how often to send icmp warnings…)
>
>
> Which would rely on the CoA to tell the NAS to let the client know in an
> unauthenticated way (and if it ever sees traffic, and if it doesn’t get
> rate-limited) that it should maybe contact the API…
> On the other hand we can leverage the direct and secure protocol between
> the API and the client.
>
> I am not saying the ICMP message is useless. It might even be necessary.
> But it should be used as a backup to the API<->client interactions.
>
> - Pierre
>
>
>
>>    - 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.
>>
>>

---

From: David Bird <[email-masked]>
Date: Tue, 20 Mar 2018 18:04:38 +0000

If we hammer in that the feature allows "you to reach all government
websites for free, where everything else is paid" and focus on that, we can
get more consensus. ;-)

On Tue, Mar 20, 2018 at 9:07 AM David Bird <[email-masked]> wrote:

>>>>    - 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 <popularwebsite>:443. Getting a UE to trust such a
>>>> 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

---

From: Nicolas Mailhot <[email-masked]>
Date: Tue, 20 Mar 2018 21:11:48 +0100

Le mardi 20 mars 2018 à 09:07 -0700, David Bird a écrit :
> 
> > > > 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.
> > > > 
> > > 
> > > Can't a network have this policy irrespective of how we implement
> > > ICMP? Can't they even today just use existing ICMP messages? I
> > > cringe when we start dictating how PUBLIC ACCESS networks manage
> > > their walled garden and businesses.
> > > 
> > 
> > My point was that there's no use in having that discussion, because
> > we know there are strong opinions on both sides and thus we're not
> > likely to get consensus.
> 
> 
> My point is that you are the one *making* this a discussion not likely
> to get consensus by loading the question with statements like "you can
> reach facebook, but to reach CNN you need to upgrade to another
> service plan" ...  which isn't a problem with ICMP per se, rather how
> you don't like how some public access networks operate... 

Yes, this is a strawman scenario. Entities that sell plans sell will
just parcel out bandwidth for stuff you haven’t paid for, they don’t
need such a mechanism, the entities that need it are networks where some
accesses are restricted for work or legal reasons.

Most walled gardens will want something like 'free access to
pr.institutionalsite.com/intranet.mybusiness.net/library.school.com',
downloading gigs of videos from youtube requires autorisation,
sex.xxx.com, playingatwork.net and examsolutions.cheater.org are
forbidden.

Regards,

-- 
Nicolas Mailhot

---

From: David Bird <[email-masked]>
Date: Wed, 21 Mar 2018 02:23:20 +0000

Thanks Nicolas. Perhaps there is more consensus in the broader group after
all...

There is a very long-tail in purposes for captive portals. The IETF can't
police which are "bad" vs. "good" business models. Let laws do that.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Mar 2018 13:14:04 +0000

Lorenzo Colitti <[email-masked]> wrote:
    david>     Is there any data that shows ICMP (and its insecurity) being used
    david> for off-path attacks like this today? Networks (as they do today) may
    david> just filter out ICMP they don't support from the edge.

    > Regardless of whether this is happening today, it seems unwise to
    > propose something with an obvious security hole like this. The risk is
    > that we do a bunch of work and then security review tells us "?REDO
    > FROM START".  

We have secdir secretary Tero on the list now...

Even if offpath attacks are challenging, given typical coffee shop wifi,
on-path attacks are trivial.

The ICMP is a hint.  That's also good for many reasons involving rate
limiting and idempotency.

(Sorry I missed the WG session. IASA2 was more important)

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Mar 2018 14:09:30 +0000

Aside from the business model of upgrades, there is also the academic
institution situation which you mention, where captive portals are often used.

The student or faculty must login.
It's not just for WIFI (there may be an additional layer of security there!).

There may be filters which will prevent:

    > sex.xxx.com, playingatwork.net and examsolutions.cheater.org are

And there may be different responses needed for:

1) a specific login/upgrade/override code (from the teacher) will allow
   access to X.   I think that this is common.

2) no matter what you enter, you won't get to sex.xxx.com.
   I don't think we need anything new for this, ICMP Admin prohibit is good.

---

From: David Bird <[email-masked]>
Date: Wed, 21 Mar 2018 14:23:35 +0000

Indeed... a long-tail of purposes.

We should NOT intentionally limit the protocol because of a single
scenario, which somehow is considered a non-starter for the feature (of
including the traditional ICMP payload).

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 21 Mar 2018 18:11:28 +0200

> limiting and idempotency.

Yes. This has been also used in the security protocols like IKEv2. For
example section 2.4 in RFC7296 (IKEv2 [1]) says following:

   Since IKE is designed to operate in spite of DoS attacks from the
   network, an endpoint MUST NOT conclude that the other endpoint has
   failed based on any routing information (e.g., ICMP messages) or
   IKE messages that arrive without cryptographic protection (e.g.,
   Notify messages complaining about unknown SPIs). An endpoint MUST
   conclude that the other endpoint has failed only when repeated
   attempts to contact it have gone unanswered for a timeout period or
   when a cryptographically protected INITIAL_CONTACT notification is
   received on a different IKE SA to the same authenticated identity.
   An endpoint should suspect that the other endpoint has failed based
   on routing information and initiate a request to see whether the
   other endpoint is alive. To check whether the other side is alive,
   IKE specifies an empty INFORMATIONAL request that (like all IKE
   requests) requires an acknowledgement (note that within the context
   of an IKE SA, an "empty" message consists of an IKE header followed
   by an Encrypted payload that contains no payloads). If a
   cryptographically protected (fresh, i.e., not retransmitted)
   message has been received from the other side recently, unprotected
   Notify messages MAY be ignored. Implementations MUST limit the rate
   at which they take actions based on unprotected messages.

So using ICMP as hint and doing rate limited operatins based on that
is acceptable.

[1] https://www.rfc-editor.org/rfc/rfc7296.txt
-- 
[email-masked]