Subject: Security of coalesced packets

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 11 Jul 2018 23:44:50 -0700

An issues was recently closed regarding what to do when UDP datagrams
contain coalesced QUIC packets where some are not understood. The
requirement is that the connection ID must match in all QUIC packets but
otherwise packets that do not verify should be buffered or ignored
independently of other packets.

https://github.com/quicwg/base-drafts/issues/1319#issuecomment-404403569

There are good reasons to coalesce because it makes the early handshake
much more efficient and there are good reasons to allow packets that do not
verify because they may relate to key material not yet available.

However, considering the effort spend in trying to avoid linkability, it
appears to me that third-parties can easily inject tracking information in
ordinary QUIC packets using the coalescing mechanism.

Even if the connection ID must match, it is easy to just copy the
connection ID from the primary packet and insert a global tracking cookie
near the source of the packet, such as in a compromised home NAT router.

Tracking can also be done with ordinary tunnelling but that is sometimes
desirable inside infrastructure, and far more difficult to manipulate
outside such boundaries - e.g. a compromised NAT router would not be able
to do it.

These issues could be avoided by only permitting certain early packets to
coalesce.

I do not have the overview of other possible valid uses of coalescing such
as during migration or rekeying.

Kind Regards,
Mikkel Fahnøe Jørgensen

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jul 2018 16:53:33 +1000

On Thu, Jul 12, 2018 at 4:45 PM Mikkel Fahnøe Jørgensen
<[email-masked]> wrote:
> However, considering the effort spend in trying to avoid linkability, it appears to me that third-parties can easily inject tracking information in ordinary QUIC packets using the coalescing mechanism.

Yes, this is possible.  It is also possible at the IP layer through
the use of IPv6 header extensions.  A MitM attacker can also embed
signals in flows by altering the rate at which packets are
transmitted.

> These issues could be avoided by only permitting certain early packets to coalesce.

In the current design, you need to use the long header to coalesce
(the trailing packet can use the short header).  And packets with the
long header only appear during connection setup.  It is possible that
we could prevent this sort of covert channel from being created using
long header packets by saying that coalescing isn't allowed after the
connection is established.   Not sure that it gains us much though.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 12 Jul 2018 00:02:22 -0700

In the current design, you need to use the long header to coalesce
(the trailing packet can use the short header). And packets with the
long header only appear during connection setup.

The thing is that any MitM can add a long header at any point in time. So
long headers can appear throughout the connection alhough not a meaningful.
For the same reason it is also easy to disallow later in the connection,
but it isn’t.

I get you point about other signals in rate and IP headers. The IP headers
could be monitored and are less likely to be abused - but my knowledge is
limited here. Of course unexpected long headers could also raise a flag,
but disallowing would be simpler.

Traffic rate signalling is hard to avoid, it is known that THOR traffic is
identified this way, albeit based on the inherent traffic pattern of the
original user. (Which is also why I’m dubious about trying so hard to avoid
linkability).

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 12 Jul 2018 16:30:00 +0900

2018-07-12 15:44 GMT+09:00 Mikkel Fahnøe Jørgensen <[email-masked]>:
> There are good reasons to coalesce because it makes the early handshake much
> more efficient and there are good reasons to allow packets that do not

Would you mind elaborating what the additional attack vector by
allowing on-path devices to embed octets introduces?

Current design just throws away the junk. It does not affect the state
of the connection. So while it is possible for an on-path device to
alter the packet, the device cannot see if it reached the peer.

To me the situation seems indifferent to on-path devices sending
additional packet using the 5-tuple when it sees a packet belonging to
the QUIC connection.

>
> Even if the connection ID must match, it is easy to just copy the connection
> ID from the primary packet and insert a global tracking cookie near the
> source of the packet, such as in a compromised home NAT router.
>
> outside such boundaries - e.g. a compromised NAT router would not be able to
> do it.
>

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 12 Jul 2018 00:50:51 -0700

It is widely known that there are is broad logging of traffic at major
distribution points, typically controlled by various state actors or
related agencies. Hence, if you can inject a signal early on the path, you
can collect it later for correlation.

Additionally script kiddies might be able to inject traffic monitoring at
corporate traffic gateways so work at home employees could ferry payload
via their NAT router to somewhere inside the firewall, and vice versa. Thus
you could download massive amounts of sensitive data undetected such as
stealing operating system source code or the latest release of Shawn the
Sheep extended DVD edition.

On 12 July 2018 at 09.30.01, Kazuho Oku ([email-masked]) wrote:

> There are good reasons to coalesce because it makes the early handshake
much

> Even if the connection ID must match, it is easy to just copy the
connection
> outside such boundaries - e.g. a compromised NAT router would not be able
to

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 12 Jul 2018 00:52:32 -0700

On 12 July 2018 at 09.50.51, Mikkel Fahnøe Jørgensen ([email-masked])
wrote:

It is different because if the source is a NAT home router, or a
compromised mobile phone, it does not matter how you migrate, or change
connection ID, you would still end the same cookie.

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 12 Jul 2018 17:32:14 +0900

2018/07/12 16:52、Mikkel Fahnøe Jørgensen <[email-masked]>のメール:

> 
>> On 12 July 2018 at 09.50.51, Mikkel Fahnøe Jørgensen ([email-masked]) wrote:
>> 
> It is different because if the source is a NAT home router, or a compromised mobile phone, it does not matter how you migrate, or change connection ID, you would still end the same cookie. 
> 

Thank you for elaborating.

I think that the attacks you describe can be mounted *without* using coalesced packets.

A malicious device (could be a router or a compromised mobile phone) can observe the TCP/UDP packets being transmitted, craft a new packet that has the same 5-tuple (and possibly also the first few octets that contain the packet header) and emit them. An observer will observe those crafted packets to track the connection.