FW: Re: Is there a line of defense against Distributed Reflective attacks?

Tue Jan 21 06:38:07 UTC 2003

VA> Date: Mon, 20 Jan 2003 19:59:08 -0800 (PST)
VA> From: Vadim Antonov

VA> Well, blocking TCP SYNs is not a way to block establishment
VA> of sessions between _cooperating_ hosts.

With cooperating hosts, anything goes.  Hack up the IP stack, and
have specially-crafted DNS queries carry the ISN.  Or use GRE
tunnels.  Or have special ICMP Unreachable packets...  Sort of
reminds me of the "email me a file" substitute for FTP that was
fairly popular years ago.

VA> To really block something you need an application proxy...
VA> and then there are always ways to subvert those. Elimination
VA> of covert channels is one of the hardest problems. In any
VA> case, no sane provider will restrict traffic only to
VA> applications which can be served by its proxies.

It would be nice if all protocols were proxy-friendly without
requiring proxies.  Of course, that does nothing for encrypted
and steganographic traffic.  Is elimination of covert channels
even possible?  I'd say not.

One of the most useful protocols (SMTP) is virtually always
proxied... rarely does anyone use end-to-end SMTP without any
intervening MX.  Allowing customer<-->* traffic vs. intercepting
and/or logging is up to the provider.  At least one then can have
known flows to inspect, rather than wondering what the "push the
button" vector is.

Sadly, port perversion seems very common.  I've added about a
dozen different ports on my home Squid cache.  Any attempts to
demand full RFC compliance seem futile.

It begins to sound like peering... are decisions made based on
technical merit, or on not losing customers who whine because
they demand to use a broken implementation?

Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist at brics.com>
To: blacklist at brics.com
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist at brics.com>, or you are likely to
be blocked.