The only real way to deal with denial of service is to define what a
service class is and incorporate mechanisms in the network (edge or
core) that isolate those classes from one another. One reasonable
approach wrt SYNs is to perhaps place a limit on transaction rate from a
particular host, site or prefix. In the absence of authenticating to
the network, the only way to deal with IP spoofing is to filter at the
edges. Some places do this now, but not everyone.
Anyway, I don't think we want to confuse those mechanisms that we use to
make life better for well-behaved traffic from those we use to police
poorly behaved traffic. I think we can have both. Clearly, the later
problem needs to be addressed, but that doesn't mean we have to rule out
the former.
- Stefan
> -----Original Message-----
> From: Neal Cardwell [SMTP:cardwell@cs.washington.edu]
> Sent: Sunday, May 17, 1998 6:14 PM
> To: syn@cs.washington.edu
> Subject: RE: ack priority
>
>
> > 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
>
>