On Tue, 15 Feb 2000 16:03:49 EST, Steve Sobol said:
<IANAL> The blocking issue is BS. Make the customers... all customers, dialup AND dedicated... sign something that says that they will agree to the AUP and Terms of Service, and specify that traffic will be filtered for security reasons. </IANAL>
The problem here is that although IANAL either, and YANAL, you WILL need one to craft an AUP and rules that will work, in spite of users. First thing to remember: The traffic we *want* to stop is the payload traffic of the DDOS system, which in general is NOT filterable. Fortunately, at the current time the *control* traffic is identifiable and filterable in most cases. Second thing to remember: The traffic is being generated by machines that are subverted - and the cracker didn't sign your AUP. You can't code "I will not allow my machine to be subverted" in the AUP, because it's unenforcable. Third thing to remember: Users can be incredibly stupid. Our abuse desk now has a form letter to send out to people who report that our NTP servers are portscanning/probing them. Yes, enough people poke our port 13/37/137 and forget to allow inbound packets for those that it's an issue. If we advertise a system/network change, and then cancel at the last minute, we will still get calls about the change breaking things. Warn your help desk, as they WILL get calls about how the (high-visibility) "filtering broke my Netscape". ;) Fourth thing to remember: Even if the user signs a form saying that traffic will be filtered for security reasons, they *will* either sue you or leave for another provider if down the road, you tweak your security filters and break something they were using. You can't specify up front what filters you will use - that keeps you from filtering new attacks. And you have *two* cases to worry about, one where you start filtering incorrectly and break somebody's service (which is *hopefully* already covered in your contract in the same paragraph as "what you can do if we accidentally unplug the router" ;), and the one where you install the right filter, but it still breaks something (it was alledged on the IETF list that ingress/egress filtering of "bad source address" packets breaks Mobile IP that doesn't implement RFC2344). Valdis Kletnieks Operating Systems Analyst Virginia Tech