Do today's routers prevent fake IP headers?

Question

I know people can modify the IP headers and change source IP address, but it should be simple for network devices to detect those messages. If they don't, why is it so hard? Does it add too much overhead?

Answer 1

I know people can modify the IP headers and change source IP address, but it should be simple for network devices to detect those messages.

Fake IP source addresses in headers can be detected and blocked in commercial network gear; other fake IPv4 headers can be a bit harder to identify. Most people refer to the function to detect fake source IP addresses as "Unicast Reverse Path Forwarding", which is abbreviated uRPF; uRPF is defined in RFC 3704 and is considered an internet Best Current Practice. uRPF should be applied at the first router from the customer premise equipment, or at the edge router in a corporate network.

If they don't, why is it so hard? Does it add too much overhead?

As long as the router isn't a CPU-based router there isn't a performance penalty. Many of the routers / switches used by ISPs have this feature built into an ASIC in hardware; normally there is not a huge performance penalty for turning it on. Sometimes there are feature conflicts, but again this is not a huge deal in most cases.

The policies and competency of the ISP engineering/operational personnel varies, and many ISPs (particularly in smaller countries) are so busy with making things "work" that they don't have cycles to make things "work well".

Answer 2

Preventing change of source IP address requires either access lists (ACL) or unicast reverse path filtering (uRPF).

Neither come for free. uRPF typically requires additional lookup or more complex single lookup, so it could even halve your lookup performance in some platforms. ACL will slow down lookup and use memory.

uRPF is maintenance free, you just configure it once and forget it. ACL needs system which knows which addresses are behind interface and makes sure the ACL stays up-to-date.

ACL more widely supported than uRPF, uRPF is comparatively rare feature in L3 switch level devices. In 'real' routers usually both features are available.

Even if both features are available, configuring uRPF in wrong place of the network can break the network, not understanding platform specific ACL limitations can cause outages.

Usually you yourself don't benefit in preventing source address spoofing, it's mostly the Internet at large who benefits. You carry non-zero risk trying to do it, as you may end-up breaking stuff. And your customers won't gain any benefit, no one will pay you more to implement them. So reward is low doing it.

Responsible service provider do it, because it's the right thing to do, but it's unrealistic to expect that we'll get antispoofing in relevantly large portion of access devices deployed. Much more realistic goal is, if we do ACL in IP transit connections, as there are only about 6000 or so stubby AS numbers there.

Why this is even issue is because of UDP reflection attacks, which can be fixed by protocols such as QUIC and MinimaLT which ensure that reflection has no gains, as incoming query is guarantee to be larger than outgoing answer, so spoofing loses its benefit.

It's again recently become quite popular to use UDP reflection as DDoS attack. There are lot of wide open DNS servers in consumer CPE devices which the consumers are not aware, so those consumers suffer as their home connection is congested as it's used to reflect attack. And it's also easy way to gain significant amplification small query of tens of bytes can yield large answer of over thousand bytes. There have been reflection DDoS attacks which are several hundred gigabits per second, and smaller are daily, just sunday night we transported 43Gbps attack to one of our customer.

Answer 3

Source address filtering is nontrivial in the real world, because Internet routing is asymmetric, so in principle we need an educated guess whether a packet from this source is likely to appear on this incoming interface.

There is no easy formula for that, because for every rule that works for almost all cases, there is also a use case that makes business sense that would break then.

Reverse path filtering works great on edge routers, where there is a clear definition of "inside" and "outside" -- you do not allow outsiders to use "inside" addresses and vice versa. It gets more complicated as soon as I start using multiple edge routers for redundancy.

For backbone routers, the only way reverse path filtering could be implemented is to allow incoming packets when the peer announces a working route (regardless of whether it would be our preference). That would be a prohibitively long lookup, easily circumvented and breaks the use case where I deliberately buy transit but do not announce my prefix down that link.