From: don-lartc@isis.cs3-inc.com (Don Cohen)
To: lartc@vger.kernel.org
Subject: Re: [LARTC] why shape incoming traffic
Date: Mon, 04 Mar 2002 15:22:48 +0000 [thread overview]
Message-ID: <marc-lartc-101525554431343@msgid-missing> (raw)
In-Reply-To: <marc-lartc-101494774514020@msgid-missing>
> 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.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2002-03-04 15:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-01 1:53 [LARTC] why shape incoming traffic Don Cohen
2002-03-01 10:04 ` bert hubert
2002-03-01 15:47 ` Don Cohen
2002-03-01 15:50 ` bert hubert
2002-03-01 19:27 ` Michael T. Babcock
2002-03-01 19:34 ` Michael T. Babcock
2002-03-01 21:48 ` Don Cohen
2002-03-02 11:16 ` Michael T. Babcock
2002-03-04 5:05 ` Michael T. Babcock
2002-03-04 15:22 ` Don Cohen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-101525554431343@msgid-missing \
--to=don-lartc@isis.cs3-inc.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.