1) Hardware. ALL routers performance degrades. Sometimes up to unsuitability. 2) Software. No commonly agreed way to maintain route and route6 object. No federation for them 3) Administrative. Lack of network hygiene. Keyword: BCP38 Relevant document https://tools.ietf.org/pdf/bcp38.pdf

BCP 38 on ingress at edges is trivial performance-wise (a few ACL entries in TCAM).

It's just that there is no incentive to stop lazy ISPs from allowing everything since that's easier.

It's not few. It's a very common mistake. Say I have 20 10G ports on line card. Mid size ISP has from hundreds to thousands routes. Thus we will end up with tens of hundreds ACLs per line card. That affects performance, dramatically. Say on older yet supported Cisco 7600 you can apply about 10k entries per port, ~ 100k totaling per card. That's limit, after that performance degrades. Another question what to do on peer-peer links, like say NTT<->Centrylink? Both on them have interconnects across the globe ad sending each other hundreds of thousands prefixes on 100G ports. That's the challenge as well. Hardware is not there, it's coming slowly but not yet there. Most of the big players DO one or another form of ingress filtering on some ports. Valid point is that smaller players are arrogant ob the issue and dump all all the garbage to the upstream.

Do it on ingress of regular customers or very small peering interfaces, not peering links with other ISPs.

If all ISPs did this, there would be no ACL issue and BCP 38 would solve the problem. No need to make it harder than it is.

This is why handwaving and shouting "BCP38" is not sufficient. I could live with half-baked BC38 deployment as it is now, if only I had other tools to trace malicious actors - netflow.

Wouldn't it be enough to check the source IP against the ip/mask at ISP pairing sites...

I suspect it might reduce out-of-network traffic a bit too..

Or ISPs could check source IPs at edge routers maybe?

Incase of huge DoS attacks they do something similar. But with DDoS attacks the spoofed packets are coming from so many different locations that it is hard to identify them, and often it is just stuff like compromised toasters.

> compromised toasters.

Only on HN. Haha.

Here is a previous HN discussion on the topic -

https://news.ycombinator.com/item?id=12661227

Because UDP is fire and forget, you don't have to be able to respond to packets you send; this is why you can't do the same with TCP packages.

To impose fixes upstream, you'd have to do DPI on all data; which is not allowed under some laws (i.e. net neutrality).

In this case, you don't have to care about UDP or TCP, only IP.

RFC2827, which should fix the problem where SSDP can be used for DDoS, was published in 2000: https://tools.ietf.org/html/rfc2827

Is ingress filtering on layer 3 considered DPI?

I am not this kind of network engineer, HOWEVER. Both IPv4 and IPv6 are versioned by the first 4 bits of the packet. Depending on that value the address size and location are fixed.

I would not consider the comparison of the source address of packets crossing an ingress link to be 'deep'. I consider that check to be very shallow. It needn't even be every packet from a set, merely picking a random (actually random) packet and testing for conformity is a good quality control measure that SHOULD be taken.

What would the comparison be against? Routers are supposed to know which links are on the other side of all down-stream connections so that they can effectively route.

Why would your ISP allow you to send packets with a source address it hasn't allocated to YOU? That kind of check/enforcement is pretty cheap and simple.

Does any leading ISP allow IP spoofing from their client?