Jeremy Hall <jhall@rex.isdn.net> wrote:
In order for your idea to work, the router where you're doing the filtering must know how to get to all destinations on the Internet, must not have a default network or route, and they must be symetrical.
Well, that is certainly not the case. For reverse-route filters to work paths do not have to be symmetrical. In fact, in interdomain routing the condition for applicability of reverse-route filters is that filtered AS must not do transit. (Note that reverse filters i described do _not_ require that the route back must be best. It just have to be present in the RIB corresponding to exterior routing session over the interface in question.)
As far as your other statement, when an instability occurs, all traffic starts getting slow because the routers are trying to reroute around a flapping t3 or whatever caused the outage. Since the whole point around a denial of service attack is to deny service, by adding in the fact that we need to know how to get to the source address before we forward the packet introduces more problems.
Ughm, i do not see the relation between flapping and more problems created by reverse-route filtering.
I think you would find this hurts more than it helps.
Would you elaborate? There's certainly little hope that SYN flooding (as well as most of other denial of service attacks) cannot be effectively prevented w/o more robust source identification, so pros are quite obvious. The fact that source identification works, and works well enough even to do billing is beyond any doubt. RELCOM does that on large scale.
Even if you limit this kind of lookups to when the packet happens to be a TCP packet with the syn option, you still have a problem in establishing a connection. This creates frustration on the part of the end user.
I will not comment, as that corollary is based on something which is not likely to be true. --vadim
--> -->Jeremy Hall <jhall@rex.isdn.net> wrote: --> -->>In order for your idea to work, the router where you're doing the -->>filtering must know how to get to all destinations on the Internet, must -->>not have a default network or route, and they must be symetrical. --> -->Well, that is certainly not the case. For reverse-route filters -->to work paths do not have to be symmetrical. In fact, in interdomain -->routing the condition for applicability of reverse-route filters is -->that filtered AS must not do transit. --> -->(Note that reverse filters i described do _not_ require that the route -->back must be best. It just have to be present in the RIB corresponding -->to exterior routing session over the interface in question.) --> You may not have said it, but I remember someone said the route had to be in the routing table. I would agree with you if it looked up the source in the BGP table and if it considered history or dampened paths valid. If your asymetry runs over multiple interfaces, then the best path might not be on the interface the packet is arriving on. -->>As far as your other statement, when an instability occurs, all traffic -->>starts getting slow because the routers are trying to reroute around a -->>flapping t3 or whatever caused the outage. Since the whole point around a -->>denial of service attack is to deny service, by adding in the fact that -->>we need to know how to get to the source address before we forward the -->>packet introduces more problems. --> -->Ughm, i do not see the relation between flapping and more problems -->created by reverse-route filtering. --> I am referring to end-user problems. When a line flaps, especially a backbone line, lots of destinations suddenly become unreachable. If you look at it in the light that one's source location will soon be one's destination location, then you didn't add to the confusion because, in theory, the returning traffic from the destination to the source would not know how to get to the source. That said, remember you threw in asymetry, meaning the return traffic might take a totally different interface or even router to get back to the original source. If you don't include dampened or history paths, then if the source gets dampened by the path the source packets enter your router, you will drop them because the path those packets arrived on "shouldn't" exist because it is dampened. -->>I think you would find this hurts more -->>than it helps. --> -->Would you elaborate? There's certainly little hope that SYN flooding -->(as well as most of other denial of service attacks) cannot be effectively -->prevented w/o more robust source identification, so pros are quite obvious. --> -->The fact that source identification works, and works well enough even -->to do billing is beyond any doubt. RELCOM does that on large scale. Do they deny packets because you aren't a relcom customer? This is a nice idea on a sunny day, don't get me wrong, but I am wondering how the routers would react when an unusual condition occurs. Are you certain relcom bills its customers for *EVERY* source packet, or can account for them at least? --> -->>Even if you limit this kind of lookups to when the packet -->>happens to be a TCP packet with the syn option, you still have a problem -->>in establishing a connection. This creates frustration on the part of the -->>end user. --> -->I will not comment, as that corollary is based on something which is -->not likely to be true. --> -->--vadim --> Please explain. If your router does not know how to get back to the source in the split second it got the packet, it might know how to get to the destination and could send the packet on its way. Maybe by the time the web server responded, traffic could resume a normal route, or perhaps outbound traffic for the web server is unimpared because you chose to implement asymetry. -- ------------------------------------------- | Jeremy Hall Network Engineer | | ISDN-Net, Inc Office +1-615-371-1625 | | Nashville, TN and the southeast USA | | jhall@isdn.net Pager +1-615-702-0750 | -------------------------------------------
-->(Note that reverse filters i described do _not_ require that the route -->back must be best. It just have to be present in the RIB corresponding -->to exterior routing session over the interface in question.) --> You may not have said it, but I remember someone said the route had to be in the routing table. I would agree with you if it looked up the source in the BGP table and if it considered history or dampened paths valid. If your asymetry runs over multiple interfaces, then the best path might not be on the interface the packet is arriving on. This behaviour is USEFULL in any case. If we can filter SRC addresses only in accordance with routing table - we'll prevent attackes from our direct customers. If this filtering will work in acordance with the total routing table (not best routes only) - OR, we'll prevent attack from some small ISP there too. But anyway this mechanism will work if it'll be available for us.
I never wrote we can prevent attack via other big ISP if they would not support this filtering. But if Cisco'll incorporate this in _provider_ revision - I think most of ISP will use this mechanism in near future. (it depends of extra CPU and memory it'll use certainly). --- Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
--> -->> -->(Note that reverse filters i described do _not_ require that the route -->> -->back must be best. It just have to be present in the RIB corresponding -->> -->to exterior routing session over the interface in question.) -->> --> -->> You may not have said it, but I remember someone said the route had to be -->> in the routing table. I would agree with you if it looked up the source -->> in the BGP table and if it considered history or dampened paths valid. If -->> your asymetry runs over multiple interfaces, then the best path might not -->> be on the interface the packet is arriving on. -->This behaviour is USEFULL in any case. If we can filter SRC addresses only in -->accordance with routing table - we'll prevent attackes from our direct customers. -->If this filtering will work in acordance with the total routing table (not best -->routes only) - OR, we'll prevent attack from some small ISP there too. But -->anyway this mechanism will work if it'll be available for us. --> -->I never wrote we can prevent attack via other big ISP if they would not -->support this filtering. But if Cisco'll incorporate this in _provider_ -->revision - I think most of ISP will use this mechanism in near future. -->(it depends of extra CPU and memory it'll use certainly). --> -->--- -->Aleksei Roudnev, Network Operations Center, Relcom, Moscow -->(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) -->(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) --> I think we're mixing two issues here. My train of thought was that you filter direct or dialup customers at the termination device for your network. This stops attacks from coming from your own customers. My second thought was this thread. It was my understanding this would be deployed on border routers to help stop attacks that come from other "neighbors". I haven't heard a good reason why this type of source filtering would help a customer during an outage. It has been suggested that blocking packets could help customers by reducing the load on the routers that are recalculating their routing tables. Would this really be beneficial, or would customers see a sudden stop in service every time a recalculation takes place? Obviously restoring service as quickly as possible is our main goal. Every morning, Coren reconfigures their routers on a timely schedule and this does not interrupt service. If you introduce this "switch", service might get interrupted every day during reconfig time or whenever somebody clears a BGP session. -- ------------------------------------------- | Jeremy Hall Network Engineer | | ISDN-Net, Inc Office +1-615-371-1625 | | Nashville, TN and the southeast USA | | jhall@isdn.net Pager +1-615-702-0750 | -------------------------------------------
participants (3)
-
alex＠relcom.eu.net -
Mr. Jeremy Hall -
Vadim Antonov