Subject: [Webpush] Use Case related to subscription sets

From: Hervé Ruellan <[email-masked]>
Date: Wed, 18 Nov 2015 11:19:35 +0100

Hi all,

We, at Canon, have a use case that is dependent on the rules relating 
subscriptions and subscription sets.

In this use case, a device (e.g. a camera) connects to a push-server 
through a proxy (e.g. a mobile phone). The communication between the 
camera and the proxy uses an appropriate protocol (most possibly not 
HTTP). A notification goes from the push-server to the proxy (acting as 
a user-agent) through WebPush, then from the proxy to the device through 
the appropriate protocol.

We plan to use the same proxy for several devices. We would like to 
allow a device to change from a proxy to another seamlessly (e.g. going 
from the mobile phone to a PC when coming home). When a device moves 
from a proxy to another, we would like it to keep the same subscription. 
This means that each device would need to have its own subscription set 
to contain its subscription (or subscriptions).

Supporting this use case means that a client, here the proxy, is allowed 
to have several subscription sets. However, this number would be quite 
limited as we think only a few devices would connect through the same proxy.

This scenario is of importance for us, and we would like the WG to take 
it into account in the definition of subscription sets.

Cheers,

Hervé Ruellan

---

From: Benjamin Bangert <[email-masked]>
Date: Wed, 18 Nov 2015 10:20:57 -0800

I'm not sure any changes would be needed as is. If a Push Server is
limiting the concurrent streams, the proxy could just open several
connections, one for each device its proxying for that devices subscription
set.

When the device disconnects from the proxy, it would shut down that Push
Service connection, and the device could query the Push Service directly.

We currently field many connections from single IP's (proxies), and don't
plan on enforcing connection limits for a single IP since mobile proxies
are quite common.

Cheers,
Ben

On Wed, Nov 18, 2015 at 2:19 AM, Hervé Ruellan <[email-masked]>
wrote:

> through a proxy (e.g. a mobile phone). The communication between the camera
> and the proxy uses an appropriate protocol (most possibly not HTTP). A
> notification goes from the push-server to the proxy (acting as a
> user-agent) through WebPush, then from the proxy to the device through the
> appropriate protocol.
>
> We plan to use the same proxy for several devices. We would like to allow
> a device to change from a proxy to another seamlessly (e.g. going from the
> mobile phone to a PC when coming home). When a device moves from a proxy to
> another, we would like it to keep the same subscription. This means that
> each device would need to have its own subscription set to contain its
> subscription (or subscriptions).
>
> This scenario is of importance for us, and we would like the WG to take it
> into account in the definition of subscription sets.
>
> Cheers,
>
> Hervé Ruellan
>
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Nov 2015 11:31:12 -0800

On 18 November 2015 at 10:20, Benjamin Bangert <[email-masked]> wrote:
> I'm not sure any changes would be needed as is. If a Push Server is limiting
> the concurrent streams, the proxy could just open several connections, one
> for each device its proxying for that devices subscription set.

The HTTP/2 RFC is pretty clear about having multiple connections.

A very simple solution here is to have the client use some sort of
explicit correlator, as we have discussed.  Then there is no need for
multiple connections.  Of course, if the push service were disinclined
to permit multiple subscription sets then this wouldn't work, but
that's probably OK here.

n.b., the concurrent stream limit isn't a good signal to use for
negotiation, it's only a way of ensuring compliance in the presence of
bad actors.

---

From: Hervé Ruellan <[email-masked]>
Date: Fri, 20 Nov 2015 11:40:21 +0100

On 18/11/15 19:20, Benjamin Bangert wrote:
> connections, one for each device its proxying for that devices
> subscription set.

The main concern for us is a Push Server enforcing only one subscription 
set for a client: in our use case, this client would be the proxy (from 
the WebPush point of view). However, we could have several devices 
"hidden" behind this proxy, and we want to keep them independent.

Its true that a Push Server putting a severe limit to the number of 
concurrent streams could also be a problem. Using several HTTP/2 
connections would probably not be a good solution: as Martin pointed 
out, this is not allowed by the HTTP/2 spec. Moreover, a Push Server 
strongly limiting the number of concurrent streams would also probably 
check that a client doesn't using several connections.

> We currently field many connections from single IP's (proxies), and
> don't plan on enforcing connection limits for a single IP since mobile
> proxies are quite common.
>
> Cheers,
> Ben

Cheers,

Hervé

>
> On Wed, Nov 18, 2015 at 2:19 AM, Hervé Ruellan
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     We, at Canon, have a use case that is dependent on the rules
>     relating subscriptions and subscription sets.
>
>     HTTP). A notification goes from the push-server to the proxy (acting
>     as a user-agent) through WebPush, then from the proxy to the device
>     through the appropriate protocol.
>
>     allow a device to change from a proxy to another seamlessly (e.g.
>     going from the mobile phone to a PC when coming home). When a device
>     moves from a proxy to another, we would like it to keep the same
>     subscription. This means that each device would need to have its own
>     subscription set to contain its subscription (or subscriptions).
>
>     Supporting this use case means that a client, here the proxy, is
>     allowed to have several subscription sets. However, this number
>     would be quite limited as we think only a few devices would connect
>     through the same proxy.
>
>     This scenario is of importance for us, and we would like the WG to
>     take it into account in the definition of subscription sets.
>
>     Cheers,
>
>     Hervé Ruellan
>
>     [email-masked] <mailto:[email-masked]>

---

From: Benjamin Bangert <[email-masked]>
Date: Fri, 20 Nov 2015 08:42:21 -0800

On Fri, Nov 20, 2015 at 2:40 AM, Hervé Ruellan <[email-masked]>
wrote:

> set for a client: in our use case, this client would be the proxy (from the
> WebPush point of view). However, we could have several devices "hidden"
> behind this proxy, and we want to keep them independent.
>

If a Push Server chooses to constrain concurrent streams, that's entirely
within its right to do so. One solution for this use-case may be to have
the proxy register the subscription sets for each of the devices using it,
then switch to a polling model, polling each registered subscription set in
turn periodically, though that could bump into request limiting.

If a proxy is going to put additional load on a Push Server, then the
people running the proxy should run the Push Server as well so that they
can shoulder the burden of their use.

Since most push servers, as far as I know, will be using SSL, I don't know
how a proxy could even function since it would need to MITM the secured
connection which is obviously not good.

Either way, this situation and use-case seems accounted for by the spec as
it is, since those wishing to handle this scenario may run their own Push
Server without a low concurrent stream max, and unsecured so that a proxy
may function.

Cheers,
Ben

---

From: Martin Thomson <[email-masked]>
Date: Fri, 20 Nov 2015 08:56:10 -0800

> Server without a low concurrent stream max, and unsecured so that a proxy

That's only true if there were an explicit correlator.  In Herve's
case, the presence of multiple clients is hidden from the push
service.

In any case, I will generate a pull request that adds the explicit
correlator.  It's not at all complicated, I've just been working
through some of the encryption pieces.

---

From: Brian Raymor <[email-masked]>
Date: Fri, 20 Nov 2015 17:49:33 +0000

On Fri, Nov 20, 2015 at 8:43 AM, Benjamin Bangert <[email-masked]> wrote:
> Since most push servers, as far as I know, will be using SSL, I don't know how a proxy could even function
> since it would need to MITM the secured connection which is obviously not good.

The mobile phone ("proxy") acts as the user agent in this case with a HTTPS connection to the push service. A different protocol than HTTP may be required between phone and the camera. Sounds similar to a field gateway scenario?

> Either way, this situation and use-case seems accounted for by the spec as it is, since those wishing to handle
> this scenario may run their own Push Server without a low concurrent stream max, and unsecured so that a
> proxy may function.

Regarding "unsecured", Section 9 requires HTTPS - This protocol MUST use HTTP over TLS [RFC2818].

---

From: Hervé Ruellan <[email-masked]>
Date: Mon, 23 Nov 2015 10:56:29 +0100

On 20/11/15 18:49, Brian Raymor wrote:
> > Since most push servers, as far as I know, will be using SSL, I
> don't know how a proxy could even function
> The mobile phone ("proxy") acts as the user agent in this case with a
> HTTPS connection to the push service. A different protocol than HTTP
> may be required between phone and the camera. Sounds similar to a
> field gateway scenario?

Yes, the HTTPS connection is between the mobile phone and the push 
server. And another protocol is used between the camera and the phone.

> > Either way, this situation and use-case seems accounted for by the
> spec as it is, since those wishing to handle

For our scenario, we would like to be able to use a generic push server. 
I agree that the spec supports the use-case, but we would also like the 
implementations to support the use-case.
A short mention of the use-case in the spec would be really helpful. The 
consequences for an implementation would be to allow a user agent to 
create a *few* subscription sets, and not limit it to *1*, and also to 
allow a user agent to open a *few* streams to subscription resources.

Hervé

---

From: Benjamin Bangert <[email-masked]>
Date: Mon, 23 Nov 2015 09:31:15 -0800

On Mon, Nov 23, 2015 at 1:56 AM, Hervé Ruellan <[email-masked]>
wrote:

> Yes, the HTTPS connection is between the mobile phone and the push server.
> And another protocol is used between the camera and the phone.
>
> For our scenario, we would like to be able to use a generic push server. I
> agree that the spec supports the use-case, but we would also like the
> consequences for an implementation would be to allow a user agent to create
> a *few* subscription sets, and not limit it to *1*, and also to allow a
> user agent to open a *few* streams to subscription resources.

Implementation-wise, the only reason a client using our service is
restricted to one active subscription set at a time is due to the
concurrent stream limit setting. It is however, just that, a setting.

Someone could use our eventual implementation and set the stream limit
setting to whatever they want to support at scale. Our specific deployment
will restrict our clients to 2 concurrent streams via this setting.

I'm assuming there will be multiple implementations out there to choose
from if you don't want to implement your own, and many/most of them will
likely implement the ability to restrict subscription sets in a similar
manner... merely by setting a config flag.

Cheers,
Ben

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Nov 2015 10:16:44 -0800

As Ben says here, I think that the question of limits is something
that is specific to a service.  The concurrent stream limit is a valid
way of limiting load, certainly.

However, I don't think that it makes the problem go away.  It's a
second order solution in the sense that it attempts to address the
consequences of bad behaviour.  I would rather have a service reject
attempts to create unlinked subscriptions.

An explicit link between subscriptions isn't that hard to do.  I've
created a pull request that illustrates how simple it would be to
accommodate Hervé's request.

https://github.com/webpush-wg/webpush-protocol/pull/67

On 23 November 2015 at 09:31, Benjamin Bangert <[email-masked]> wrote:
>> a *few* subscription sets, and not limit it to *1*, and also to allow a user
>> agent to open a *few* streams to subscription resources.
>
>
> restricted to one active subscription set at a time is due to the concurrent
> stream limit setting. It is however, just that, a setting.
>
> I'm assuming there will be multiple implementations out there to choose from
> if you don't want to implement your own, and many/most of them will likely
> implement the ability to restrict subscription sets in a similar manner...
> merely by setting a config flag.
>
> Cheers,
> Ben
>

---

From: Brian Raymor <[email-masked]>
Date: Mon, 23 Nov 2015 21:46:48 +0000

> https://github.com/webpush-wg/webpush-protocol/pull/67

Thanks for creating the pull request, Martin. I've added specific comments there.

The question is whether the WG prefers "user agent decides" - which is the case
where the push service advertises the availability of sets in its response to
the first subscription request and the user agent can then decide whether to
pass the push:set with subsequent subscription requests for aggregation. This is
definitely a very flexible approach although with a  few more moving parts.

In previous discussions, one of the concerns about "user agent decides" is what
happens if a push service strongly wants to require aggregation, but the user agent
fails to include the advertised push:set with its subsequent subscription requests?
This was one of the motivations for the current approach of "push service decides".

Perhaps the combination of "user agent decides" with "push service *encourages*"
by limiting concurrent HTTP/2 streams is the potential compromise.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Nov 2015 15:19:59 -0800

> by limiting concurrent HTTP/2 streams is the potential compromise.

That's where I'm headed.  Though I'm also adding "spec *encourages*"
by using the word MUST.  I don't think that we get any gains for the
important scenarios if we don't provide at least some encouragement to
aggregate into a set.

I've added text to the PR that explains what the push service might do
to punish user agents that don't allow for aggregation.  It's relying
on the same magical anti-DoS stuff again, which is hardly ever
perfect, but often adequate in practice.

Here I expect that looking at the connection will work to catch
genuine but innocent mistakes.  The bad guys are always going to be
harder to pin down.

---

From: Hervé Ruellan <[email-masked]>
Date: Tue, 24 Nov 2015 19:21:48 +0100

Thanks for the pull request.

I find it a good compromise: it covers our use-case while still encouraging UA to reuse subscription sets.

Hervé