Best Common Practice - Listening to local routes from peers?
Hello: We have a customer of a customer who is attempting to send traffic from IP space we control, through the Internet and back into us via one of our transit connections. I have filters in place that block all inbound traffic from the blocks I announce coming in over my transit and peering connections. This is breaking the downstream customer ability to route from them, through UUNet, and back to me. I'm curious what the Best Common Practice is for this type of scenario. I have always used this type of filtering as a way to bury source-spoofed traffic in a DDOS situation but I'm not sure if it's appropriate, generally speaking. If other operators would like to reply directly to me I would be more than happy to summarize to the list. Thank you for any assistance you can provide. Michael Smith mksmith@noanet.net
On Feb 26, 2004, at 11:22 PM, Michael Smith wrote:
We have a customer of a customer who is attempting to send traffic from IP space we control, through the Internet and back into us via one of our transit connections.
I have filters in place that block all inbound traffic from the blocks I announce coming in over my transit and peering connections. This is breaking the downstream customer ability to route from them, through UUNet, and back to me.
I'm curious what the Best Common Practice is for this type of scenario. I have always used this type of filtering as a way to bury source-spoofed traffic in a DDOS situation but I'm not sure if it's appropriate, generally speaking.
It is a good idea to filter source IP on the edge. Since your customer has more than one upstream, filtering their IP space at your border is not "the edge". Filter their source IP where your network meets their network. Filter your source IP at your upstream borders. My $0.0000003411284. :) -- TTFN, patrick
On Thu, 2004-02-26 at 21:22, Michael Smith wrote:
Hello:
We have a customer of a customer who is attempting to send traffic from IP space we control, through the Internet and back into us via one of our transit connections.
Gotta ask, Why ? They have a direct connection (few hops) to you and are trying to go the long way, right ?
On Feb 27, 2004, at 1:21 AM, James Edwards wrote:
On Thu, 2004-02-26 at 21:22, Michael Smith wrote:
Hello:
We have a customer of a customer who is attempting to send traffic from IP space we control, through the Internet and back into us via one of our transit connections.
Gotta ask, Why ? They have a direct connection (few hops) to you and are trying to go the long way, right ?
Well, there are possible cost considerations. Also, and perhaps more importantly, if the customer's line to his network drops, should the customer be incapable of getting to content hosted on his network? -- TTFN, patrick
: Also, and perhaps more importantly, if the customer's line to his : network drops, should the customer be incapable of getting to content : hosted on his network? Simple. I am not going to break something all the time to counter something that might break every once and a while. When Nagios pages me that a multihomed customer is down, I will allow that address space to enter all my gateways, as a source address. James Edwards Routing and Security Administrator jamesh@cybermesa.com At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
On Feb 27, 2004, at 1:51 PM, james wrote:
: Also, and perhaps more importantly, if the customer's line to his : network drops, should the customer be incapable of getting to content : hosted on his network?
Simple. I am not going to break something all the time to counter something that might break every once and a while. When Nagios pages me that a multihomed customer is down, I will allow that address space to enter all my gateways, as a source address.
To quote someone on this list: "It doesn't scale." Additionally, if I'm a customer and my line goes down and it takes you 15 minutes to fix it, I'm not going to be happy about it. Finally, you "fix" it at the *edge*, that won't break either. -- TTFN, patrick
On Thu, 26 Feb 2004, Michael Smith wrote:
We have a customer of a customer who is attempting to send traffic from IP space we control, through the Internet and back into us via one of our transit connections.
I have filters in place that block all inbound traffic from the blocks I announce coming in over my transit and peering connections. This is breaking the downstream customer ability to route from them, through UUNet, and back to me.
Yes, I've had this back in the days when I used to attempt to do fascist filtering and security ... the short answer is you cant do this kind of filtering in the backbone, you need to push it to the edge (defined in my mind as stub areas of network.. in this case thats likely not in your network but in the customer's network)
I'm curious what the Best Common Practice is for this type of scenario. I have always used this type of filtering as a way to bury source-spoofed traffic in a DDOS situation but I'm not sure if it's appropriate, generally speaking.
Am not convinced the benefit of dropping that traffic is worth the effort tbh (that is stuff coming in with obviuosly spoofed addresses.. there is so much legit space available to spoof). Steve
If other operators would like to reply directly to me I would be more than happy to summarize to the list. Thank you for any assistance you can provide.
Michael Smith mksmith@noanet.net
participants (5)
-
james -
James Edwards
-
Michael Smith -
Patrick W.Gilmore -
Stephen J. Wilcox