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?

  • note: the correct phrase is "anti-spoofing". fake says to me "counterfeiting rolexes" (which, btw is a completely different network hack/attack)
    – Ricky
    Jul 17 '13 at 7:12

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".

  • 1
    What if isp a and isp b are connected to each other. If isp a doesn't use uRPF, can isp b do anything about it?
    – Nachos
    Jul 16 '13 at 11:05
  • By "do anything about it", I assume you're assuming that ISP B doesn't have the first router from the CPE. Yes, ISP B can also use uRPF, but they have to deploy it in something called loose mode due to the asymmetric nature of bgp routing. This means it isn't as effective at blocking fake headers... it essentially just makes sure that a route for source IP address exists in the routing table... so if someone sends traffic that is completely unroutable, it can be blocked.
    – This
    Jul 16 '13 at 11:08
  • It's not strictly true that only CPU based suffer performance penalty. For example in 7600/6500/PFC3 without uRPF you can observe linerate at minimum size packets in WS-X67040-10GE, turn up uRFP and smallest frame is almost doubled to 101B which you can send at linerate. Newer devices which are NPU based (ASR9k, MX, SR etc) also have non-zero cost in uRPF, packet processing engine takes more time when it's enabled than when it's disabled, over-dimensioning can help to abstract the cost.
    – ytti
    Jul 16 '13 at 11:10
  • 4
    @ytti, internet traffic averages well above 101 bytes. This isn't a serious problem for imix.
    – This
    Jul 16 '13 at 11:11
  • 1
    @ytti, I was very clear in qualifying my answer... I said "normally there isn't a huge performance penalty for turning it on". Let's not forget that the 6500 Sup7203BXL is a 400Mpps machine when fully populated with DFCs; put one DFC per WS-X6704 in the chassis, and there is nothing to worry about... if you're crazy enough to only depend on the PFC3 forwarding for the entire chassis, well you asked for the problem you got.
    – This
    Jul 16 '13 at 11:32

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.


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.

  • 1
    Source address filtering is nontrivial in the real world, this should be changed to uRPF/strict. As source address filtering via use of ACL is agnostic to routing symmetry. That is, it's not possible for me to uRPF/strict my multiconnected IP-transit customers, but it's easy for me to ACL them.
    – ytti
    Jul 16 '13 at 13:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.