> From: "Michael T. Babcock" <mbabcock@fibrespeed.net> > On Sat, Mar 02, 2002 at 11:00:20AM -0800, Don Cohen wrote: > > > That depends on your configuration; Squid can be set up as a transparent > > > proxy so that all requests made to given ports (80, 443, etc.) are forced > > > through Squid instead so that the user doesn't have the choice. > > So squid is intercepting packets addressed to somewhere else? > > How is it doing that? > > Usually through port redirection using your firewall (or ipchains ;-). Ok, so I think it's reasonable to view the outgoing http client packets as coming from the squid machine, and they can/should be shaped/accounted as such. That brings us back to my original argument that it's not necessary to shape incoming traffic that is to be forwarded, since that traffic can be shaped on the way out. This is not strictly true, since the work at input could save some work between the input and output, but it's a pretty good approximation. On the other hand, if you accept my argument that it's useful to shape traffic to the local machine, then you agree with me that it would be worth while to add shaping at input, in which case the case above that I suggest is unnecessary comes for free. > > SFQ is not a good defense - the attacker just sends you random source > > addresses and ports and now his packets have priority over yours > > (which all come from the same address/port). But you're close. > > That only works if traffic is generated on all of those hashed address/port > pairs in which case the attacker's data flow is just as stymied as mine. Attackers generally don't really want to communicate with you. They just want to prevent others from doing so. In any case, I'm trying to protect legitimate communication even when under an attack by that sort of attacker.