Guard initial packet against amplification attack via compression

[mikkelfj]

If an attacker has access to a network with efficient IP payload compression, it may be comparatively cheap for the sender to transmit Client Initial packets even if the packets are required to be 1280 bytes long. This can be mitigated by replacing padding with random data, or a some pattern that is not trivially compressible.

I am not familiar with options today, but the following RFC do discuss such a compression technology, and other options may appear in the future:
https://tools.ietf.org/html/rfc3173

[martinthomson]

Why do you think that an attacker would want to follow your advice to randomly pad? I would have thought that allowing randomized data would give them a greater advantage in constructing a packet that is otherwise valid, but that decompresses to something insane.

FWIW, I don't think that this is worth worrying about.

[mikkelfj]

It would be a pseudorandom verifiable sequence, such as the fibbonnachi sequence of some initial seed.

I don't know if this is worth worrying about or not, I am just raising the potential issue. Attacks appear to come frome the most unexpected angles.

[mikkelfj]

Related: there may be other ways to deal with this, such as proof of work instead of large packet size, but that obviously has its own issues.

[ianswett]

To clarify, you're imagining an attacker behind a proxy which compresses packets? Given the vast majority of packets flowing through 443 are encrypted, and a large portion of the rest is the TLS handshake(which encrypts poorly), I'm not sure why one would deploy such a proxy?

If there is no reason to believe this sort of proxy is common, I would tend to agree with Martin that this isn't worth worrying about.

[mikkelfj]

I am, for example, imagining a large cloud hosting environment with high bandwidth compressed backbone for inter-datacenter links. You could feed outbound traffic at high rates that condense at server elsewhere. Such a backbone would have no concern for port 443 at the point of compression and if a common server vulnerability was found, many hosted services could join in a DDoS attack.

For comparison, some storage networks for iSCSI do terminate TCP connections near sender and internally transfer packets using larger MTUs and possible with hardware compression to move large data volumes over a distance.

Still, I am no saying this is a major concern, just pointing out the possibillity.

[mikkelfj]

Another example would be government controlled internet backbones used in cyber warfare that exploit a backbone compression standard at IP level or below.

[mikkelfj]

https://arstechnica.com/security/2015/03/massive-denial-of-service-attack-on-github-tied-to-chinese-government/

[martinthomson]

If this is indeed a problem, then it is a generic IP problem. We need to constrain what it is that we want to solve. I'm going to risk the wrath of our chairs and close this as out of scope.