Packet count attacks are extra spicy because routers often have a lower packets-per-second capacity than their bits-per-second capacity
Presumably this is even more true for things like the Smurf attack, where the origins of the reflected packets are different and so limits on packets-per-host don’t apply
Modern protocols (last 10 or 15 years) are designed to avoid amplification. QUIC is the best example: the client has to pad its initial packet to be larger than the server’s response, and the client is responsible for connection retries.
That’s nice. How variable is the response size? Can IoT devices try a small request and a larger one if needed, or do they need a large initial packet? I’m starting to look a bit (a very small bit so far) at QUIC for CHERIoT because it has a couple of potential memory reductions:
The TCP bit of the network stack is pretty big and includes a pile of buffering, whereas UDP can trivially do zero-copy and is smaller.
The TLS layer needs to buffer inbound data for, potentially, multiple packets because TLS over TCP doesn’t know about packets and the receiving stack can’t pass on the data until it’s got to a boundary where it has an HMAC to check. In contrast, QUIC is encrypted per-packet and so can have less buffering.
Needing larger transmit buffers may be less optimal.
More fundamentally, I think it’s a mistake to base a global network protocol on addresses
As I recall, this was one of the big disagreements with the design of IPv6 (are addresses routes?), and the consensus ended up in the opposite direction, though I’m not sure I understood the rationale.
How variable is the response size? Can IoT devices try a small request and a larger one if needed, or do they need a large initial packet?
The client has to send 1200 byte packet(s) before the connection is established. The server must not send more than 3x the number of bytes back to the client before it has verified the client isn’t spoofed. The main difficulty is the size of the server’s certificate. There’s more about the complications in RFC 9000 section 8.1.
the design of IPv6 (are addresses routes?)
As far as I know, there was a lot of discussion about how addresses are split into host and network parts, and how network parts are allocated (hierarchially, geographicaly, …) and about decoupling endpoint identity from the route used to reach it. This eventually became LISP, the location / identity separation protocol (terrible name). But it is just addresses with more steps: the location is a globally routable network prefix which is still limited to a few million in total globally and still spoofable. And unlike 30 years ago, we know that endpoint identity must be cryptographic in nature and it must appear random to on-path snoops.
Presumably this is even more true for things like the Smurf attack, where the origins of the reflected packets are different and so limits on packets-per-host don’t apply
That’s nice. How variable is the response size? Can IoT devices try a small request and a larger one if needed, or do they need a large initial packet? I’m starting to look a bit (a very small bit so far) at QUIC for CHERIoT because it has a couple of potential memory reductions:
Needing larger transmit buffers may be less optimal.
As I recall, this was one of the big disagreements with the design of IPv6 (are addresses routes?), and the consensus ended up in the opposite direction, though I’m not sure I understood the rationale.
score 2 · canonical
The client has to send 1200 byte packet(s) before the connection is established. The server must not send more than 3x the number of bytes back to the client before it has verified the client isn’t spoofed. The main difficulty is the size of the server’s certificate. There’s more about the complications in RFC 9000 section 8.1.
As far as I know, there was a lot of discussion about how addresses are split into host and network parts, and how network parts are allocated (hierarchially, geographicaly, …) and about decoupling endpoint identity from the route used to reach it. This eventually became LISP, the location / identity separation protocol (terrible name). But it is just addresses with more steps: the location is a globally routable network prefix which is still limited to a few million in total globally and still spoofable. And unlike 30 years ago, we know that endpoint identity must be cryptographic in nature and it must appear random to on-path snoops.
score 1 · canonical