Re: Fwd: Re: Digital Island sponsors DoS attempt?
As an infrastructure owner, the important thing is that if you're going to announce reachability, it should be real. If you blackhole stuff in the middle of a netblock and distribute it as an untainted netblock in your BGP, you're depriving people of clean routes.
ok, so how do you handle a situation like orbs/abovenet as in late 1999? a /16 owned by a transit customer of as6461 had in it a /24 used by orbs. the orbs traffic violated as6461's aup, which the /16's owner had signed. the /16 owner had a less restrictive aup for its downstreams (including orbs) than as6461 had, and thus had a weak contractual basis for enforcing the as6461 aup on orbs. as6461 had three possible choices: (a) ignore it and hope the nonuniform enforcement of the aup didn't show up as a problem elsewhere at a later time; (b) disconnect orbs' upstream on the basis of their inability to conform to the aup they had signed; or (c) block traffic to/from the /24 in question after carefully notifying the /16 owner that this would be done and why. as we all know, (c) was chosen. great was the hue and even greater the cry. a recommendation was even made that if as6461 wasn't going to carry the whole /16 that it ought to chop it up and only advertise the parts it could reach, in spite of what these more-specifics would have done to the /16 owner's own routing policy (they were multihomed.) what would YOU have done? justify your answer. (show all work.)
On Mon, Oct 29, 2001 at 11:53:05AM -0800, Paul A Vixie wrote:
ok, so how do you handle a situation like orbs/abovenet as in late 1999?
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. 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 point, I guess, is you're AUP wasn't propagated. You can only enforce the AUP with your direct customer.
(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.
as we all know, (c) was chosen. great was the hue and even greater the cry. a recommendation was even made that if as6461 wasn't going to carry the whole /16 that it ought to chop it up and only advertise the parts it could reach, in spite of what these more-specifics would have done to the /16 owner's own routing policy (they were multihomed.)
what would YOU have done? justify your answer. (show all work.)
I've noted my preferred solution (equivalent to the DON'T PREFER ME community proposed some time ago). I also noted my opinions on this a while back in the "How does one make not playing nice with each other scale? (Was: net.terrorism)" thread. 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? -- Jeff Haas NextHop Technologies
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.
participants (3)
-
Jeffrey Haas -
Paul A Vixie -
Paul Vixie