[dns-operations] on fragmentation attacks; see also RFC 6013

[Paul Vixie]

Colm MacCárthaigh wrote:
>
> You write that it takes 3x RTTs to exchange a question and an answer
> over TCP. I think it takes 2x RTTs, simple as that. FIN plays no role
> in answer termination; clients don't wait on a FIN to decide that an
> answer is usable.

in this article i could not go into the details of FIN_WAIT_2 and the
lifetime costs of TCP state. we can discuss it here, of course. the fact
that the client and server are allowed to continue operations before the
FIN's have been exchanged does not bear on the total number of
connections either of them can make, given that their TCP resources will
be held uncompressed until the FINs are exchanged, and compressed for
the FIN_WAIT_2 interval.

the ceiling on TPS is at least partly built out of the need for memory
resources for new TCP state, which will be partly dictated by the number
of connections you've been involved in recently.

importantly, this is a solved problem, as any large web farm operator or
HTTP load balancer maker can explain. just as importantly, the fact that
other people's servers will not necessarily be strong in the ways that
modern TCP-based services can be made strong, limits our options in
designing defense for the initiators.

> You go on to write that servers following the specification don't
> unilaterally close the connection, but that's at odds with your
> description of the sequence of packets. (and even that "incorrect"
> sequence would not require 2x RTTs, since the server could dispatch
> its FIN without waiting). 

you're right of course, as to the inconsistency. the third round trip
(FIN exchange) is begun by the client.

> Although i think it is valid to argue that DNS TCP requires 3x RTTs if
> you want to count the original question over UDP + the TC=1 response.
> But I don't think that's what you are saying in the article. Am I
> interpreting it wrong?

i was not counting a UDP TC=1 round trip, because i wanted to loosely
model a TCP-only TCP-all-the-time scenario.

off topic:

sadly, none of this was well articulated at the time RFC 6013 was
written, so, the powers that be said "no" to our desire for a code
point. in a 6013 world, compressed state can be opportunistically held
long term at no cost, and back-channel broadcasted to all members of a
TCP anycasted cloud. this means your first TCP "session" takes three
round trips, but after that, it's one round trip per transaction, even
though you're "closing" each session. see also the associated Usenix
;login: article which preceded RFC 6013:

https://www.usenix.org/legacy/publications/login/2009-12/openpdfs/metzger.pdf


vixie