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

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. :slight_smile:

Gotta ask, Why ? They have a direct connection (few hops) to you and are
trying to go the long way, right ?

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

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?

: 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

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.