|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Fwd: Re: Digital Island sponsors DoS attempt?
It took me a while to get back to this. There's actually some operational content this time. > I don't have the AUP's in question so my speculation is going to be > tainted. I would probably have told them that I would continue announcing > their route (with the known hole) and prepended the heck out of it > to cause people to deprefer that prefix. That wouldn't've solved the problem others have described here -- since some people in some places would end up seeing that route. The customer in question was given several choices, and could have depref'd on their end, or withdrawn the route from the session, or whatever. The end result was the maximum overlap between the interests of the route-owner and the interest of the network-owner, and for that reason I deem the result to have been the best success possible under the circumstances. > Additionally, I might have added a new community 6461:foo and registered > that info in the IRR saying that 6461:foo means that some customer is > being abusive and you're protecting the Internet from them. The network owner in question wasn't concerned with protecting the Internet from anybody, it was protecting its own backbone from AUP-violating traffic. > The point, I guess, is you're AUP wasn't propagated. You can only > enforce the AUP with your direct customer. I must be missing that point, then. Abovenet's AUP is a contract term with every one of its customers. It is applied at the point where the customer's traffic enters Abovenet's backbone. Where the traffic came from before that and whose customers is downstream of whom is not even a tertiary concern other than to ensure that whatever filters are in place are the bare minimum needed to enforce the AUP. No customer is ever allowed to point downstream and say "but the traffic that violates the AUP didn't come from here, it came from a customer's customer." When traffic violates an AUP, that traffic is subject to border filtering, no matter how far downstream it might have come from originally. > > (c) block traffic to/from the /24 in question after carefully notifying > > the /16 owner that this would be done and why. > > This causes the least problems to your direct customer. I can > understand, from a business perspective, how this was the preferred > option. However, it punished those who used your routes and wanted > <no-value-judgement> to reach ORBS </no-value-judgement> and rewarded > your customer for lax AUP. "Punish" is an interesting word and I reject its use here since its definition requires that pain be a goal. I know that some ill effects were felt by some consumers of this route. The owner of the route was given choices, like "look here, see this bad traffic? it has to stop coming here, so if you don't stop it on your side, we will have to stop it on ours, and we have no technology available which would prevent our stoppage from having a global impact, so you might just as well stop it on your side." > > what would YOU have done? justify your answer. (show all work.) > ... > I'm asking/suggesting: Is this just a business issue? Given the > way the routing system works today are we going to see a lot more > blackholes in the system? Does the routing protocol need to be adjusted > to deal with this business need or should the AUP deal with it? I'm told that on some modern Cisco boxes it is now possible to drop traffic based on its source rather than on its destination, but still feeding the ACL from a distributive source (which is a "avibgp" session in AS6461's case). I don't know whether Juniper can do this yet. I hope so, or if not, soon. Assuming that this technology comes into wide use, it will become possible to block AUP-violating _packets_ rather than prevent AUP-violating _sessions_ from becoming established, which would make an ORBS-vs-Abovenet issue into a strictly local event. (The /16 netblock owner tried to send this /24's transit through a non-Abovenet path, but since many of the destinations were inside AS6461 and most of the SYN-ACK's came back through AS6461, this didn't help as much as it should have.) To your question, though, I think the answer is "yes." We will see a lot more blackholes in the system, because the technology needed to perform an end to end policy verification before beginning a new session is on the same order as "call setup" and there are just too many "calls" for a core of this size.
|