RE: ack priority

Neal Cardwell (cardwell@cs.washington.edu)
Sun, 17 May 1998 18:13:36 -0700 (PDT)

> I think denial of service attacks need to be handled separately. Note
> that there aren't currently deployed fixes to deal with the effect of
> SYN floods on the network, just their effects on the clients.
>
> If you are doing per-flow queuing then you can handle priority within
> your queuing discipline and denial of service attacks get handled
> automatically. Ultimately, a network mechanism/protocol that lets
> misbehaving flows be traced back to their source is going to be
> important.

Seems like this might be kinda hard, since each SYN is typically going to
be the only packet in its flow (i'd imagine; i'm not familiar with how syn
flood attacks are typically implemented). If we just prioritize SYNs
within their flows then we accomplish nothing, since SYNs are the only
packets in their flow (at least for the definition of flow i'm thinking
of). So we'd have to prioritize flows with SYNs over flows without SYNs.
In this case, if i send hundreds of SYNs with different (spoofed) source
IPs and ports, then i'm imagining that the router would stick them each in
a distinct flow and do round robin across the flows with SYNs, then
round-robin across the flows without SYNs. And this seems to leave the
router open to denial-of-service attacks. The same goes for ACKs (at least
for HTTP, where client ACKs are rarely mixed in the q with client data).
Or is there a better way?

Seems like, in general, prioritizing certain flows over others is going
to encourage people to play tricks to hog resources, unless the high
priority flows are paying more for their service.

neal