Subject: Re: [hybi] Websocket over TLS keep-alive overhead

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 6 Dec 2012 16:34:49 +0900

On Fri, Nov 30, 2012 at 3:42 AM, Roberto Peon <[email-masked]> wrote:

> ++
> On Nov 29, 2012 2:11 AM, "Jamie Lokier" <[email-masked]> wrote:
>
snip

>  It might make sense if TLS could transmit its own, much shorter,
>> keepalive messages, which are for the sole purpose of keeping the link
>> alive.  I would guess, since they have no other effect, that they
>> wouldn't be exploitable in the same way.  Is that right?
>>
>>
There might be some nop available at TLS level, but I'm not sure. I heard
that old attempt (0/n record splitting) to address ancestor of the BEAST
attack faced a problem that some of existing NWs can't handle empty record
correctly.

How about allowing the API to invoke TCP layer keepalive (null TCP packet)
instead of nop TLS record?

I found similar discussion in these threads for
http://tools.ietf.org/html/rfc6520.
- http://www.ietf.org/mail-archive/web/tls/current/msg07986.html
- http://www.ietf.org/mail-archive/web/tls/current/msg07987.html

>  It would be best if they could be invoked from the higher layer rather
>> than generated in TLS itself (because the higher layer will have a
>> better idea of the keepalive patterns that it needs), and if they were
>> one-way keepalives rather than PING/PONG to avoid amplification
>> attacks, and because PING/PONG is not the most efficient keepalive
>> pattern.
>>
>> Is there provision in TLS for that sort of thing now?
>>
>> (Of course over mobile links, it would make much more sense for power
>> efficiency to have a single, aggregated keepalive stream for all
>> sockets rather than one per active websocket, or some other way of
>> taking advantage of the phone's existing mobile link-level keepalives
>> which it already does and are designed for efficiency.)
>>
>>

---

From: <[email-masked]>
Date: Fri, 7 Dec 2012 09:40:34 +0000

Hi,

Yes, these are all very good points. Just one comment.

Jamie Lokier wrote:
>efficiency to have a single, aggregated keepalive stream for all sockets rather
>than one per active websocket, or some other way of taking advantage of the
>phone's existing mobile link-level keepalives which it already does and are
>designed for efficiency.)

Yes, aggregation is very important. If the keep-alive streams are independent, power consumption is typically also multiplied. But I'm not sure what type of "link-level" keep-alives you are thinking about. In both cellular and Wi-Fi links there is some messaging/paging going on, but that is typically in the timescale of hundreds of milliseconds. So, it's not relevant to TCP or websocket level keep-alives. However, synchronizing keep-alives with any other IP traffic the device sends/receives is useful.

Markus

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>ext Jamie Lokier
>Sent: 29 November, 2012 12:11
>To: Takeshi Yoshino
>Cc: [email-masked]
>Subject: Re: [hybi] Websocket over TLS keep-alive overhead
>
>Takeshi Yoshino wrote:
>>    Hi,
>>    Chromium is using 1/n-1 record splitting for TLS 1.0 connection w/ CBC
>>    mode cipher to work around BEAST exploit. So, even a WebSocket frame
>>    with 1 octet payload (client -> server, 7 octets in total. AES block
>>    size (16) * 2 - SHA1 HMAC size (20) - padding length field size (1) >
>>    7, so 1 application data record with 32 octets payload is enough) will
>>    be packed into two TLS records with big padding.
>>    re: TLS compression, it's disabled on Chromium to address another
>>    exploit called CRIME.
>
>It might make sense if TLS could transmit its own, much shorter, keepalive
>messages, which are for the sole purpose of keeping the link alive.  I would
>guess, since they have no other effect, that they wouldn't be exploitable in
>the same way.  Is that right?
>
>It would be best if they could be invoked from the higher layer rather than
>generated in TLS itself (because the higher layer will have a better idea of the
>keepalive patterns that it needs), and if they were one-way keepalives rather
>than PING/PONG to avoid amplification attacks, and because PING/PONG is
>not the most efficient keepalive pattern.
>
>efficiency to have a single, aggregated keepalive stream for all sockets rather
>than one per active websocket, or some other way of taking advantage of the
>phone's existing mobile link-level keepalives which it already does and are
>designed for efficiency.)
>
>-- Jamie
>_______________________________________________
>hybi mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/hybi

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 10 Dec 2012 09:52:15 +0000

> Yes, aggregation is very important. If the keep-alive streams are
> independent, power consumption is typically also multiplied. But I'm
> not sure what type of "link-level" keep-alives you are thinking
> about. In both cellular and Wi-Fi links there is some
> messaging/paging going on, but that is typically in the timescale of
> hundreds of milliseconds. So, it's not relevant to TCP or websocket
> level keep-alives. 

Hi Markus,

It's the difference in timescale which makes it work.  A longer
keepalive at a higher layer in the stack can be piggybacked
efficiently ("free") on a shorter keepalive at a lower layer in the
stack.

(It can also make the keepalive even more effective than the usual "1
per minute" approach at application level, guaranteeing more rapid
notification to the application of when the link is lost, or more up
to date confirmation the link is still live so synchronised state is
still valid.)

This works for mobile, wireless, and wired links.  I don't know
details but suspect it's particularly effective in terms of mobile
power usage.

WebSocket/TLS level keepalive power can be *eliminated entirely*
(saving maximum possible power) if a protocol extension allows the
handset and mobile network to recognise them and, using an
intermediary-permitted transformation to the message stream, the
mobile network sends keepalives to the WS server as long as the
network has link-level confirmation of the handset presence, and the
handset sends keepalives to the WS client application as long as the
handset has link-level confirmation of the network's presence.

That can't happen as long as the keepalives are generated by the
applications in an application-specific way.

And it isn't safe to do it on the existing ping/pong messages, because
it does change the nature of the end-to-end guarantees, suitable for
some applications but not all, so it needs to be opt in by application.

And it can't be done with WS over TLS, unless there is a recognisable
TLS-level message the intermediary is able to transform.

Aside from link-level power savings, a very similar possibility
applies aggregating multiple keepalive streams from different
Javascript applications within a single browser, and different
keepalive streams from different non-browser applications; and even
from different machines behind any bandwidth-limited link.

Again it needs to be opt-in because it changes the nature of the
end-to-end guarantees, and it needs messages that are recognisable and
safe to change by an intermediary.

> However, synchronizing keep-alives with any other
> IP traffic the device sends/receives is useful.

Typically there are many applications where the keepalives are 90% or
more of the total traffic, because they are just to stay "present",
while very little is really happening.

For example an application simply checking for short messages, which
you don't receive often, but are expected to show on the client when
they do.

It needs a keepalive - or repeated connections - just to receive a
message from the server when something changes.  Especially if you
want fast notification.  Yet, that might only happen once a day, and
transfer just a few bytes - about 3 packets per day.  Whereas 1
keepalive per minute over TCP is 4320 packets per day.

In such applications, using the above figures keepalive is >99.9% of
the traffic.

That overhead can be mostly eliminated, with a protocol extension that
allows smart interaction with intermediaries, and this is useful for
saving handset power, and reducing bandwidth use in all applications
where you have a lot of applications per client with similar behaviour
- few data updates, lots of presence.  Mobile handsets tend to have
both of these at the same time, increasingly as more apps want to
subscribe to notifications from their own services.

(This whole idea can be developed further by ideas such as named
liveness subscriptions, which would provide stronger end-to-end
guarantees and so be suitable for more applications.)

Best,
-- Jamie