Defeating DoS Attacks Through Accountability
I'm very pleased to see how much enthusiasm there is for cooperating. Since we have identified the problem, and the reasonable technical solution (filtering) is apparent, we should now focus on discussing complications and a strategy for widespread implementation. For the purposes of this discussion, I'd like to remain as focused as possible: while I'd love to spread the clue about things such as turning off directed broadcasts, I feel that bringing accountability to IP is by far the most important issue. If we had accountability, all of the other DoS-related problems would be so much easier to respond to. The very first step, if you haven't done so already, is to push your own organization to implement ingress and egress filtering. This is NANOG, and there are enough clueful NANOs reading with the resources needed to accomplish this on a number of small- and medium-sized networks in the short term. With RFC 2827 in hand, use egress filters to make sure that your networks don't permit packets with spoofed source addresses from entering the Internet. If you have customers, as many (most? all?) of us do, use ingress filters to make sure that spoofed packets don't even enter your network. The key to solving this problem, though, is to push the large-sized networks - the Tier 1s and 2s of the world - into aggressively implementing ingress filtering on customer links. Most of these providers already have the necessary information to do so: BGP announcements from a customer are already restricted to customer address blocks, and known static routes are used for singly-homed customers not running BGP. If ingress filtering were to be implemented to the same degree that route advertisement filtering has been, this problem would be, for the most part, solved. The beauty of this is that filtering packets to eliminate spoofed source addresses comes down to the same exact restrictions as filtering routing advertisements. If a provider is able to filter BGP announcements for the greater good of the Internet, then that same provider is also able to filter packets by source address for the same reason. Not only do we get to use the same list of blocks for filtering, but we get to justify filtering with the same arguments that are already being used for other forms of filtering. This is not, as one poster suggested, ones and zeros without discretion. This is true within the network core, but at the customer edge, there are definite policy restrictions that are in force today, and that can be put in to force tomorrow. For the record, I haven't seen any evidence indicating that filtering at the edges would impact performance. All of the NSPs do have employees with enough technical know-how to get this done, and to get it done properly. Assuming that widespread ingress filtering could be implemented by these people at the NSP level, it wouldn't matter that the networks without clueful NANOG-reading operators (or without operators at all, for that matter) never bothered modifying a single router configuration. If an uncared-for network lacks ingress filtering but is connected to an NSP that filters all inbound customer traffic, individuals on the uncared-for network would only be able to spoof using addresses that are supposed to be on that network. If such a DoS attack were to be launched, then the source network would be known, even if the source party's identity would still be a mystery. This is of little consequence, though, because the pool of suspect source networks has been reduced from hundreds of thousands to one, and that's enough for law enforcement to launch a successful investigation. If the Internet were built around one central NSP, we'd be able to stop here, but since that's not the case, there are additional complications to deal with. Specifically, ingress filtering at the customer edges of a network implies that the network core is safe. As we all know, though, the network core is not safe, because it's not controlled by any single organization. It is impossible to implement filtering at peering points between NSPs, for example. The only solution is to get all of the NSPs to agree to implement filtering. If even one big-time operator refuses, then we cannot be sufficiently assured of accountability. One way I see to handle this issue requires a decree from one or two of the big NSPs requiring that all unfilterable connections (peering links and any other link so large as to make filtering infeasible or impossible) aggressively implement ingress filtering. (Come on, you big NSP types, I know you're reading, what do you think?) Customer links with more than a certain chunk of associated address space should also be held to the same standard of filtering. The only effective way of enforcing such a policy would be to unplug noncompliant networks. For those of you out there who followed me right up to this point, yes, I am suggesting forcing networks to behave. Others have pointed out, and I agree, there are too many networks which will not comply unless there's no alternative. This is a topic which can be expanded on; the enforcement issue especially is more related to policy. I also foresee complications due to the global nature of the Internet. Hopefully, these same principles could be extended beyond North America into other regions of the world. Thoughts? Mark
On Thu, 2 Nov 2000, Mark Mentovai wrote:
Thoughts?
Where does asymetric routing fit into your vision of heaven? The main large scale use I have seen of route filters is by a large Australian provider which uses them to enforce it's interconnect charging. It tends to break a couple of smaller ISPs every week ( and larger ones every month). -- Simon Lyall. | Newsmaster | Work: simon.lyall@ihug.co.nz Senior Network/System Admin | | Home: simon@darkmere.gen.nz ihug, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz
Simon Lyall wrote:
Where does asymetric routing fit into your vision of heaven?
It's a non-issue. This is an important point, I'm not advocating widespread use of "ip verify unicast reverse-path," although I see how my discussion of BGP may have led people to that conclusion. Providers would permit packets with source addresses that their customers are allowed to generate, which can be the same as or some superset of the source addresses that they are allowed to announce via BGP. "Best path," and the actual routing for that matter, never enters into the equation. Mark
Where does asymetric routing fit into your vision of heaven? The main large scale use I have seen of route filters is by a large Australian provider which uses them to enforce it's interconnect charging. It tends to break a couple of smaller ISPs every week ( and larger ones every month). It's not the route filters per se, it's the fact that the principle we use is if you don't announce the route to us we won't accept traffic sourced by that network. Saying that you are the source for the network but not advertising the route doesn't cut it. Mark.
Mark Prior wrote:
It's not the route filters per se, it's the fact that the principle we use is if you don't announce the route to us we won't accept traffic sourced by that network. Saying that you are the source for the network but not advertising the route doesn't cut it.
Not so fast, there are situations when you are authorized to have a certain chunk of address space but elect not to advertise it a certain way for whatever reason. Maybe someone has a pipe that they want to use for outbound traffic only and they don't want to use it at all inbound traffic, and as a result, they don't advertise their routes across it. What justification do you use for dropping traffic that falls into this category? Obviously, I wouldn't want a situation where I could simply give my provider a list of addresses for them to permit without checking that I'm authorized - providers should always check that their customers are authorized to use the blocks they intend to use. I'll put it this way: filtering should be done against blocks that a customer can announce, not against blocks that a customer is actively announcing. If you're filtering purely against current advertisements, you're bound to break something sooner or later. Mark
I'll put it this way: filtering should be done against blocks that a customer can announce, not against blocks that a customer is actively announcing. If you're filtering purely against current advertisements, you're bound to break something sooner or later.
Good theory. But what one public source do all the ISP agree to validate the authority to announce? Barry
I'll put it this way: filtering should be done against blocks that a customer can announce, not against blocks that a customer is actively announcing. If you're filtering purely against current advertisements, you're bound to break something sooner or later.
Good theory. But what one public source do all the ISP agree to validate the authority to announce?
Barry
Seems that the closest thing available today is the in-addr tree. --bill
On Sat, Nov 11, 2000 at 01:46:45PM -0800, Barry Raveendran Greene wrote:
I'll put it this way: filtering should be done against blocks that a customer can announce, not against blocks that a customer is actively announcing. If you're filtering purely against current advertisements, you're bound to break something sooner or later.
Good theory. But what one public source do all the ISP agree to validate the authority to announce?
CW? (ha ha) Who says you have to have use a public authority to filter your customers against? You can have your own private authority, if you really want. You just have to get the customer to populate/maintain their data in it. Austin
Barry Raveendran Greene wrote:
I'll put it this way: filtering should be done against blocks that a customer can announce, not against blocks that a customer is actively announcing. If you're filtering purely against current advertisements, you're bound to break something sooner or later.
Good theory. But what one public source do all the ISP agree to validate the authority to announce?
Regional IP address allocating bodies - in other words, ARIN. If you aren't listed as responsible for the block in question, you should either have the information updated (SWIP or rwhois) or obtain written authorization from a representative of the organization controlling the block. It's far from perfect because enthusiasm for providing accurate data via SWIP and rwhois doesn't really exist as it should, but it's probably the best anyone can come up with. Perhaps putting SWIP and rwhois data to a good use such as this would increase awareness of it and cause the databases to become more appropriately populated. Mark
On Sat, 11 Nov 2000, Mark Mentovai wrote:
Barry Raveendran Greene wrote:
I'll put it this way: filtering should be done against blocks that a customer can announce, not against blocks that a customer is actively announcing. If you're filtering purely against current advertisements, you're bound to break something sooner or later.
Good theory. But what one public source do all the ISP agree to validate the authority to announce?
Regional IP address allocating bodies - in other words, ARIN. If you aren't listed as responsible for the block in question, you should either have the information updated (SWIP or rwhois) or obtain written authorization from a representative of the organization controlling the block. It's far from perfect because enthusiasm for providing accurate data via SWIP and rwhois doesn't really exist as it should, but it's probably the best anyone can come up with. Perhaps putting SWIP and rwhois data to a good use such as this would increase awareness of it and cause the databases to become more appropriately populated.
Mark
Filtering based on assigned/allocated address space should be the norm, not the exception. If a customer isn't listed in the ARIN database, or whichever RIR has authority for the address space in question, we won't accept announcements from them for that space, period, the end. If the entity who assigned/allocated the address space to them is unwilling to provide up-to-date information via SWIP/RWHOIS, we are very happy to point out to the customer how lazy/stupid/irresponsible that entity is and explain our reasons for not accepting announcements for said address space. We have run into some delays with providers when we obtained new address space and needed to announce it. The prefix-list filters that were in place said "I don't think so!" So, it took 20 mins to get someone with the authority to change the prefix-list on the phone and another 5 minutes for them to change the prefix-list and another 30 seconds for me to type "clear ip bgp NNNN soft out". It's a small price to pay for the peace of mind of knowing that in the event we misconfigure something, we're not going to leak transit routes, default, blah blah blah into the global routing table. --- John Fraizer EnterZone, Inc
> I'll put it this way: filtering should be done against blocks that a > customer can announce, not against blocks that a customer is actively > announcing. If you're filtering purely against current advertisements, > you're bound to break something sooner or later. Good theory. But what one public source do all the ISP agree to validate the authority to announce? I can't ever see this problem being solved while legacy (swamp) space exists and the organisations using it can just appear anywhere. Mark.
On Sat, 11 Nov 2000 11:27:20 EST, Mark Mentovai said:
Not so fast, there are situations when you are authorized to have a certain chunk of address space but elect not to advertise it a certain way for whatever reason. Maybe someone has a pipe that they want to use for outbound traffic only and they don't want to use it at all inbound traffic, and as a result, they don't advertise their routes across it. What justification do you use for dropping traffic that falls into this category?
It's a general principle. Anyhow, they're going to get damned little inbound traffic unless they announce a route for it to *someplace*. I think the original *general* policy was "If we don't have ANY route for it, we don't accept the traffic", which sort of makes sense - how would you get through a TCP 3-way handshake if the SYN+ACK always got back a ICMP Host Unreachable? I saw no requirement that the routing not be assymetric, only that routing exist. I'm sure Mark Prior will correct me if I mis-read him... ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
> Not so fast, there are situations when you are authorized to have a certain > chunk of address space but elect not to advertise it a certain way for > whatever reason. Maybe someone has a pipe that they want to use for > outbound traffic only and they don't want to use it at all inbound traffic, > and as a result, they don't advertise their routes across it. What > justification do you use for dropping traffic that falls into this category? It's a general principle. Anyhow, they're going to get damned little inbound traffic unless they announce a route for it to *someplace*. I think the original *general* policy was "If we don't have ANY route for it, we don't accept the traffic", which sort of makes sense - how would you get through a TCP 3-way handshake if the SYN+ACK always got back a ICMP Host Unreachable? I saw no requirement that the routing not be assymetric, only that routing exist. I'm sure Mark Prior will correct me if I mis-read him... ;) Actually since we use "ip verify unicast reverse-path" we expect the route to come from the same place as the traffic. Mark.
>It's not the route filters per se, it's the fact that the principle we >use is if you don't announce the route to us we won't accept traffic >sourced by that network. Saying that you are the source for the >network but not advertising the route doesn't cut it. Not so fast, there are situations when you are authorized to have a certain chunk of address space but elect not to advertise it a certain way for whatever reason. Maybe someone has a pipe that they want to use for outbound traffic only and they don't want to use it at all inbound traffic, and as a result, they don't advertise their routes across it. What justification do you use for dropping traffic that falls into this category? Obviously, I wouldn't want a situation where I could simply give my provider a list of addresses for them to permit without checking that I'm authorized - providers should always check that their customers are authorized to use the blocks they intend to use. As there is no real way to determine who is authorised to announce a prefix we must rely on some measure of "reasonableness", ie does it look likely that a customer should announce that prefix, and in the case of BGP announced routes we would look in the routing table to see if the route is already being announced. I'll put it this way: filtering should be done against blocks that a customer can announce, not against blocks that a customer is actively announcing. If you're filtering purely against current advertisements, you're bound to break something sooner or later. Our agreement with the customer is to supply them with access to the Internet and so our billing model is formulated on the proposition, ie we charge for bytes delivered to the customer. If the customer doesn't want us to do that for a network why should we allow them to send out traffic sourced from that network? Especially since doing that makes it more difficult to debug routing problems and for others to track unacceptable behaviour. Just because a network is registered with us doesn't mean that any third parties know this. Mark.
On Thu, 2 Nov 2000 19:44:06 -0500 (EST), "Mark Mentovai" <mark-list@mentovai.com> wrote:
The very first step, if you haven't done so already, is to push your own organization to implement ingress and egress filtering. This is NANOG, and there are enough clueful NANOs reading with the resources needed to accomplish this on a number of small- and medium-sized networks in the short term. With RFC 2827 in hand, use egress filters to make sure that your networks don't permit packets with spoofed source addresses from entering the Internet. If you have customers, as many (most? all?) of us do, use ingress filters to make sure that spoofed packets don't even enter your network.
I'm fairly sure our network is all set, but does anyone have a good test procedure to make sure? I think it would be really beneficial to have a utility/procedure that can, in fairly short order, test one's configurations to make sure that everything is OK. -rt -- Ryan Tucker <rtucker@netacc.net> Network Operations Manager NetAccess, Inc. Phone: +1 716 419-8200 1159 Pittsford-Victor Road, Pittsford NY 14534 http://www.netacc.net/ "Wouldn't you rather help make history than watch it on TV?" - Jello Biafra
On Thu, 2 Nov 2000, Ryan Tucker wrote:
term.With RFC 2827 in hand, use egress filters to make sure that your networks don't permit packets with spoofed source addresses from entering the Internet.If you have customers, as many (most? all?) of us do, use ingress filters to make sure that spoofed packets don't even enter your network.
Oh, Ryan, on this subject specifically, the downstream providers should not count on the upstream to check if they send spoofed packets to them, and they should also filter them on egress. If all ISPs took care of this (and it ain't that hard to configure), this could make life for NSPs alot easier. We should balance responsibility among clients and providers, and not just pin it all on the NSPs. The game is cooperation..... --Ariel
-- Ryan Tucker <rtucker@netacc.net> Network Operations Manager NetAccess, Inc. Phone: +1 716 419-8200 1159 Pittsford-Victor Road, Pittsford NY 14534 http://www.netacc.net/ "Wouldn't you rather help make history than watch it on TV?" - Jello Biafra
-- Ariel Biener e-mail: ariel@post.tau.ac.il Work phone: 03-6406086 fingerprint = 07 D1 E5 3E EF 6D E5 82 0B E9 21 D4 3C 7D 8B BC
participants (10)
-
Ariel Biener -
Austin Schutz -
Barry Raveendran Greene -
bmanning＠vacation.karoshi.com -
John Fraizer -
Mark Mentovai -
Mark Prior -
Ryan Tucker -
Simon Lyall -
Valdis.Kletnieks＠vt.edu