Vanity IP addresses? WARNING: geeky content

As stated by many others, IP headers are trivial to forge, as long as one doesn't care about receiving a response. This is why it is mostly seen with UDP, as TCP requires a 3-way handshake. One notable exception is the SYN flood, which uses TCP and attempts to tie up resources on a receiving host; again, as the replies are discarded, the source address does not matter.

A particularly nasty side-effect of the ability of attackers to spoof source addresses is a backscatter attack. There is an excellent description here, but briefly, it is the inverse of a traditional DDoS attack:

1. Gain control of a botnet.
2. Configure all your nodes to use the same source IP address for malicious packets. This IP address will be your eventual victim.
3. Send packets from all of your controlled nodes to various addresses across the internet, targeting ports that generally are not open, or connecting to valid ports (TCP/80) claiming to be part of an already existing transaction.

In either of the cases mentioned in (3), many hosts will respond with an ICMP unreachable or a TCP reset, targeted at the source address of the malicious packet. The attacker now has potentially thousands of uncompromised machines on the network performing a DDoS attack on his/her chosen victim, all through the use of a spoofed source IP address.

In terms of mitigation, this risk is really one that only ISPs (and particularly ISPs providing customer access, rather than transit) can address. There are two main methods of doing this:

1. Ingress filtering - ensuring packets coming in to your network are sourced from address ranges that live on the far side of the incoming interface. Many router vendors implement features such as unicast reverse path forwarding, which use the router's routing and forwarding tables to verify that the next hop of the source address of an incoming packet is the incoming interface. This is best performed at the first layer 3 hop in the network (i.e. your default gateway.)

2. Egress filtering - ensuring that packets leaving your network only source from address ranges you own. This is the natural complement to ingress filtering, and is essentially part of being a 'good neighbor'; ensuring that even if your network is compromised by malicious traffic, that traffic is not forwarded to networks you peer with.

Both of these techniques are most effective and easily implemented when done so in 'edge' or 'access' networks, where clients interface with the provider. Implementing ingress/egress filtering above the access layer becomes more difficult, due to the complexities of multiple paths and asymmetric routing.

I have seen these techniques (particularly ingress filtering) used to great effect within an enterprise network. Perhaps someone with more service provider experience can give more insight into the challenges of deploying ingress/egress filtering on the internet at large. I imagine hardware/firmware support to be a big challenge, as well as being unable to force upstream providers in other countries to implement similar policies...

That's basically correct. An allocated address belongs to a pool from which it may be assigned but it hasn't yet been marked as in use. Pools are managed by various organizations like ISPs, Webhosting services, and Universities.

Keep in mind that the files you're parsing are going to be outdated the moment they're published, and that any given address may have been assigned for quite a while before it gets reported back.

Edit: It looks like the comment is correct. IP Addresses marked as assigned are managed by a sub-organization, but they may or may not actually be in use. Ranges marked as allocated should not be in use, except for where there is a lag in updating these reports. Keep in mind this comment about that data:

In particular, it should be noted that these reports seek to indicate where resources were first allocated or assigned. It is not intended that these reports be considered as an authoritative statement of the location in which any specific resource may currently be in use.

http://ftp.apnic.net/stats/apnic/