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@brics.com> To: blacklist@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@brics.com>, or you are likely to be blocked.