If you're thinking of residential ISPs which own the IPs that their customers use, it's mostly pretty simple to prevent spoofing (or at least, prevent spoofing outside their address range), but once you get customers that can bring their own IPs, it can be more cumbersome and the default is to not care.

There are, of course, proposals and protocols to make things better, but not caring is easier, and strict enforcement is hard, especially as the bandwidth goes up.

There's also enough ISPs that don't do egress filtering that name and shame isn't effective, and anyway, what am I going to do if I'm connected to an ISP that doesn't filter? I have exactly one meaningful offer of connectivity, so that's the one I've accepted, regardless of its merits. Many ISPs have a similar hold on customers.

Thanks.

> but once you get customers that can bring their own IPs (...)

You know these IPs though, since you route to your customer. So you could drop the offending packets. (I may be getting over my head here).

The routing need not be symmetric. If I've got two /24s and two ISPs, maybe I advertise each /24 on only one ISP, for traffic engineering purposes (I want to steer some of my clients to send through one ISP and some clients to send through another), but that doesn't mean I want or need to send the return traffic back through the same way it came in.

Also, the routing/BGP configuration is often separate from the filtering config, so making sure things are synchronized can cause problems.

It's far less time intensive as an ISP to just not filter once it starts getting complex. After all, you don't get a lot of customer service calls when you let ill-advised packets through, but you do get calls when you break things by dropping packets your clients were authorized to send.

> I may be getting over my head here)

It may be so, however my own need for clarification was the same as yours. If ISP xyz operates a /16 ip block, and only forwards source packets from its /16... Then, I guess, my question: how do spoofed packers usually travel past their first hops on their route to the target?

[edit] after-thought: I imagine attackers might easily spoof their source as any of their ISPs /16 or /8. Feels like that's not entire story here though.

I think you're still missing the point. Let's say I run John Doe's chop shop. I have purchased my own /24 (192.168.1.0/24). I want redundant connectivity so I have service from Comcast and qwest. I use bgp to decide every I'm routing my IP through Comcast or qwest at any given moment so they both need to allow traffic from that IP space even though it may not be from me. X100000. So it's easier to just not filter at all.

"I have 192.168.1.0/24 to sell you..."

"Ignore that guy. I'll offer you 172.16.0.0/12 for the same price."

Blocking outgoing spoofed packets requires time and money.

No carrier will shut down an ISP paying them 100k/month just because of some spoofed traffic.

The ISP originating the spoofed packets isn’t apparent to the person receiving the attack. The source is spoofed to the victim’s address so neither the DNS operator nor the victim can see where the spoofed packets originated.

I know. But one layer below, there's still a chain linking back to the origin ISP. The DNS operator can ask his own ISP about it.

(Also, to people down-voting a genuine question ? wth..)

Anecdotally I've noticed bot-like behavior on HN down-voting posts almost immediately, before a human could have read them. This is followed, typically, by a correction over a few minutes and then regular up- (or down-) voting resumes. I can imagine that HN is subjected to quite a lot of novel attacks of this nature, and I don't think it's in anyone's interest that they broadcast the details of it. My advice: be patient and take downvotes with a big grain of salt. They may not mean what you think they mean.

I’ve noticed it too. I think there are features of some sort already on on the backend, though obviously not fool-proof.

Who the fuck cares about downvotes as long as your sincere about your opinions?

Hard to be the smuggest dude in the valley at 1% opacity. Gotta keep the points up

The mac addresses on the ethernet layer are rewritten at each hop. You would only see the mac address of the router your router is connected to, not a chain linking back to the origin.

> The DNS operator can ask his own ISP about it.

Who would then have to determine where it's coming into their network from, and go ask that ISP, who would have to do the same, ad nauseum. And all parties would have to be paying enough staff to handle that load in addition to, you know, making sure their services work.

Two problems:

- the DNS operator doesn’t care. These look like normal requests.

- if they did care, asking an ISP to packet trace ingress traffic is not trivial. At any large scale ISP there are hundreds to thousands of direct peers that could have originated that traffic.

When you get to the level of traffic that it matters to check this, you are at the point that you cannot actually check this. Just think of the amount of traffic per second, the number of source addresses, and how many people it will take for how long to research that minute worth of traffic from last month.

I'm no sure how things are now, but 15 years ago (back when I was doing network admin type stuff), most routers did destination routing in hardware, source routing hit the CPU and was thus, very slow. I think that was the primary reason not to do that back then---perhaps it's still the case now?