
So you wanna buy a used IP address block? - CrankyBear
https://blog.strom.com/wp/?p=7561
======
martinald
Interesting. My ISP has been obviously buying new (used) blocks and it is a
total nightmare. They bought a block which must have been used in China in
some way a year of so ago. Suddenly every site thinks you are in China, prices
start coming up in CNY and various georestictions apply.

Luckily you can power cycle the router and get a new IP quickly.

It's interesting as I imagine a lot of people (me included until I hit this)
did not put updating GeoIP databases high on their priority lists, but it is a
total pain when you're on the other side of it.

------
icedchai
I have a /24 (aka class C block) I registered back in the 90's. I currently
have it routed over my business internet connection. It predates ARIN, and is
considered a "legacy" block and requires no fees. I consider it personal asset
and not worth selling.

~~~
therockspush
Is this common? Might be a bit slow here but this sounds like hoarding.

~~~
big_chungus
I can only wish that I had this, but if I did, I'd absolutely keep it. I'd
love to give every device on a home network a publicly-routable address. No
more port forwarding, no more NAT garbage. On the other hand, I know a guy who
got a /24 way back when; I think he just gave it back at some point, though
not 100% sure.

~~~
jesterson
It gives you some overhead on security side if you're concerned about it since
you will need to filter incoming traffic once you device network interface
becomes routable from internet.

~~~
zAy0LfpBZLC8mAC
No, it doesn't. NAT does not prevent inbound connections, only a stateful
firewall does, and if you do have that, then NAT does not add anything.

~~~
jfindley
So how are you, with your publically routed IP of (for example) 56.10.10.100
planning to connect to the GP, who has (for example) a public egress IP of
73.100.100.10, but is in fact using NAT, and his desktop's real IP is
192.168.1.20? I feel like you might be trying to point out that NAT devices
_can_ be configured to forward all traffic to some backend device - while true
this is disingenous because they are basically always not configured like
this.

I realise NAT is unpopular with networking purists, but trying to claim that
it doesn't prevent inbound connections seems to be overstating your case quite
severely. I'd also note that if your firewall is stateful or not is irrelevant
for the point you were trying to make - oldfashioned stateless firewalls can
also block inbound connections just fine.

~~~
zAy0LfpBZLC8mAC
> So how are you, with your publically routed IP of (for example) 56.10.10.100
> planning to connect to the GP, who has (for example) a public egress IP of
> 73.100.100.10, but is in fact using NAT, and his desktop's real IP is
> 192.168.1.20?

By sending a packet to them that has the destination address 192.168.1.20?

You seem to be making the assumption that the only way to send a packet to the
WAN interface of a NAT router is through the public internet. While being able
to do that widens the attack surface, it absolutely is not the only way, and
your threat model is broken if you assume that it is.

> I realise NAT is unpopular with networking purists, but trying to claim that
> it doesn't prevent inbound connections seems to be overstating your case
> quite severely.

No, that belief is one of the big myths that keeps people configuring insecure
networks.

> I'd also note that if your firewall is stateful or not is irrelevant for the
> point you were trying to make - oldfashioned stateless firewalls can also
> block inbound connections just fine.

That's true and it's not. Of course, you can block all connections with a
stateless firewall, and thus obviously also block all inbound connections. But
a stateless firewall is very limited in selectively blocking specifically
inbound connections across random protocols, and especially so if it doesn't
know detailed information about your network and services to infer what
constitutes a packet establishing a connection, while with a stateful firewall
you can essentially just say "drop inbound connections" without any further
details about your networks, and it'll do a good job at it.

Plus, you could argue about whether, for example, dropping TCP SYNs but
forwarding all other TCP packets actually counts as "blocking inbound
connections", given that tons of potential "inbound packets" will be forwarded
to your internal systems and you really rely on your internal systems not
accepting any of them as "establishing a connection" or possibly just being
vulnerable to those "inbound but not establishing a connection" sort of
packets.

~~~
jfindley
Perhaps you could expand on the threat model you're talking about where you,
as a remote attacker, can somehow get a packet with an RFC1918 dest IP sent to
the WAN port of your intended victims home router.

It's perhaps worth pointing out that this discussion is very much in the
context of a home network, so well-actually arguments about "maybe I have a
GRE tunnel set up to this random users home router" or "maybe I'm their ISP
and want to break into the router I supplied them with" won't really carry
much weight - you mentioned the concept of a broken threat-model, but a threat
model needs to be grounded in reality, and the reality is that unless you go
_far_ out of your way to do silly things NAT is a reasonable and practical
protection for home users against accidentally exposing services on their
network to the internet at large.

~~~
zAy0LfpBZLC8mAC
> Perhaps you could expand on the threat model you're talking about where you,
> as a remote attacker, can somehow get a packet with an RFC1918 dest IP sent
> to the WAN port of your intended victims home router.

The threat model is really simple: If it's not under your control, then you
shouldn't needlessly rely on it for security. And from the point where the
wires leave your house, it's not under your control.

A random selection of possible attack scenarios:

\- Hooking up a DSLAM to your DSL somewhere along the path to the CO.

\- Compromising your ISP's edge routers through vulnerabilities/hard-coded
passwords.

\- If your router happens to also announce its RFC1918 prefix to the outside
world and your ISP's misconfigured edge routers propagate those routes in
their access network, being your neighbour might be enough.

\- If your ISP is incompetent at configuring VLANs so you end up in the same
VLAN as other customers in your area, again, being your neighbour might be
enough.

(And yes, those are things that have happened.)

> It's perhaps worth pointing out that this discussion is very much in the
> context of a home network,

Except it really isn't. For one, the context was the home network _of someone
who would prefer to assign a public prefix on their home network_. That is
probably very much not the kind of stereotypical home network that is
generally meant when you speak about "a home network" (i.e., a bunch of
consumer devices on a WiFi). And also, the distinction really is only relevant
in so far as specific home networks generally are not targeted, but that
doesn't really change that it's still a bad idea to completely unnecessarily
have a NAT run without a stateful firewall (the NAT needs to keep all the
state that the firewall needs to keep anyway), and that as soon as you do have
that firewall, NAT does not add anything at all.

So, yes, it might be that in some particular setups NAT without a stateful
firewall is good enough for your particular needs. But that doesn't change
that the general idea that "NAT prevents inbound connections" needs to die,
because it is (a) far from true in the general case and (b) even where/in so
far as it is true, you are almost always better off with a stateful firewall
instead, so it's a bad rule of thumb both because you actually have to
understand the limits of where it applies to not end up vulnerable and because
the alternative actually works better with no downsides, except in rare
circumstances, and even then, it's only an economical downside (namely: buying
a new device that does things properly instead of using what you already
have).

~~~
jfindley
Couple of points: Most of those vectors would represent extreme levels of
paranoia for the average home user. If you have sufficiently motified and
skilled adversaries that they are prepared to start hijacking your DSL
connection, you're probably screwed before you start.

Secondly: I never said you shouldn't also have a firewall - indeed basically
all NAT routers are also firewalls, and both are active by default. The added
protection NAT offers is that even if an inexperienced user accidentally opens
up too much in their firewall, it's unlikely that this will make their
internal home network publically accessible because ordinarily attackers
aren't going to be able to send packets there. This is a real and useful
feature for users who don't count the Mossad in their home network threat
model (which is likely almost everyone reading this).

~~~
zAy0LfpBZLC8mAC
> Couple of points: Most of those vectors would represent extreme levels of
> paranoia for the average home user.

That's not really a useful measure, though, because this can be said about
every single vulnerability used in a mass compromise up to the second when
that mass compromise happens. The difference between "extreme levels of
paranoia" and "common sense security practice" is someone somewhere deciding
to use that particular vulnerability in some malware because random
circumstances made a bunch of vulnerabilities that individually are kinda
useless align to make an exploit chain.

> If you have sufficiently motified and skilled adversaries that they are
> prepared to start hijacking your DSL connection, you're probably screwed
> before you start.

Yes, that is probably true. But for one, that's not the only option I listed,
and also, it doesn't change that the blanket statement "NAT prevents inbound
connections" is not true and is easily misapplied by people who do not
understand the details. Notice how noone ever says "NAT prevents inbound
connections well enough for low-value targets, kinda"? And so, people actually
believe that it does and then set up vulnerable company networks.

> The added protection NAT offers is that even if an inexperienced user
> accidentally opens up too much in their firewall, it's unlikely that this
> will make their internal home network publically accessible because
> ordinarily attackers aren't going to be able to send packets there.

Talking about contrived examples ... in consumer devices, you rarely can
actually configure firewall rules? What you can configure is "port
forwarding", and that then automatically implies that tt is actually open not
not just NATted. So, at best that applies to inexperienced users setting up
somewhat professional equipment, presumably in a context where security
matters a bit more and targeted attacks are more likely, and where the belief
that "NAT prevents inbound connections" now actually puts them at risk?

edit: And not only does it put them at risk, it also makes it hard for them to
notice that they are vulnerable. If you have a firewall without NAT, it's
trivial to check that inbound connections are refused. If a random access from
anywhere on the internet is rejected, then your default DENY rule is probably
effective. With NAT, not so much.

~~~
jfindley
> That's not really a useful measure, though, because this can be said about
> every single vulnerability used in a mass compromise up to the second when
> that mass compromise happens.

No. The difference between the vectors you described and "mass compromise
malware" is that your vectors are targetted at one (or a very small number of)
individual user(s), who are probably screwed either way, if a skilled attacker
_really_ wants to mess with them this badly. There is no realistic way to
hijack DSL connections en-masse, and an attacker skilled enough to compromise
an entire ISP to the point they can start doing these sorts of things has far
better options available to them than anything we're talking about here.
There's a huge difference between mass-deployed malware and complex targetted
attacks, which is a point you seem to continually miss in this thread.

> it doesn't change that the blanket statement "NAT prevents inbound
> connections" is not true

More verbosely this could have been expressed as "NAT prevents inbound
connections unless you have a NAT device that for some reason accept incoming
packets for which it has no session and pick a device on the private network
to route these packets to, not to mention the difficulty of getting those
packets there in the first place". This "unless" is not normally needed
though, as this is widely regarded to be a sufficiently difficult thing to
achieve it's not worth mentioning.

>in consumer devices, you rarely can actually configure firewall rules?

On every consumer firewall/NAT box I've ever seen, it was possible to
configure firewall rules. Perhaps this is a regional difference?

I also note that although you've presented a couple of ways you might be able
to send arbitrary packets at the public IP of the NAT device (although I
strongly dispute how practical they are), this isn't yet sufficient to manage
to connect to arbitrary machines behind the NAT device - you must also find a
way to force the NAT device to accept packets for which it has no existing
session. Otherwise you're really just limited to things like tcp hijacking to
try to MiTM a session - something you can likely do regardless of the presence
of a firewall, if you really care enough.

~~~
zAy0LfpBZLC8mAC
> There is no realistic way to hijack DSL connections en-masse

So, exactly what people always say exactly up to the point where someone
demonstrates the exploit chain?

> and an attacker skilled enough to compromise an entire ISP to the point they
> can start doing these sorts of things has far better options available to
> them than anything we're talking about here.

So ... exactly what people always say exactly up to the point where someone
launches some malware?

> There's a huge difference between mass-deployed malware and complex
> targetted attacks, which is a point you seem to continually miss in this
> thread.

Except there really isn't. Yes, obviously there is a difference, but you can't
measure how well an attack _can_ be scaled based on how well it _has_ been
scaled. Now, deploying rogue DSLAMs sure is really impractical to scale, so
that's not a concern other than for targeted attacks. But abusing
misconfigured ISP networks might very well be easy to scale under the right
circumstances. Mind you that the attacker doesn't have to be an actual
neighbour, it might very well be enough to compromise one machine in a
neighbourhood and then start attacking the neighbourhood from there, and if
this is a misconfiguration of a large ISP, you might be able to just leverage
an existing bot net to compromise large parts of their customer base.

> More verbosely this could have been expressed as "NAT prevents inbound
> connections unless you have a NAT device that for some reason accept
> incoming packets for which it has no session

May I rephrase this slightly for clarity?

"NAT prevents inbound connections unless it doesn't happen to be paired with a
stateful firewall."

Erm ... yeah, thanks for making my point for me? Except the actually non-
confusing way to put this is "NAT does not prevent inbound connections, but
stateful firewalls do", obviously.

> and pick a device on the private network to route these packets to

Could it be that you just don't even understand the attack? This sounds like
you think that the owner of the router would have to explicitly configure a
target that could be attacked or something? If that's how you understand it,
you might want to brush up on how IP routing works.

> This "unless" is not normally needed though, as this is widely regarded to
> be a sufficiently difficult thing to achieve it's not worth mentioning.

Erm ... in other words: People are generally mistaken about this? Yeah, I
agree.

> On every consumer firewall/NAT box I've ever seen, it was possible to
> configure firewall rules.

As in, if you want to make some internal service publicly reachable, you have
to separately set up a "port forwarding rule" and a "firewall rule"? That sure
is how professional equipment/software does it, but not something I have seen
in home routers in a long time.

> I also note that although you've presented a couple of ways you might be
> able to send arbitrary packets at the public IP of the NAT device

No, I haven't. I have been talking about sending packets to the private IP
addresses, the public IP address is completely not involved in any of this.

> this isn't yet sufficient to manage to connect to arbitrary machines behind
> the NAT device - you must also find a way to force the NAT device to accept
> packets for which it has no existing session.

Yeah, it seems like you don't understand IP routing or how the attack works.

No, you don't. You just don't. That's not how NAT works or how IP works.
__Unless there is a stateful firewall on that device, in which case removing
the NAT does not change anything about being able to establish inbound
connections. __

To take the example of a common VLAN with your neighbours: What you need is
the MAC address of the WAN interface of your neighbour that you want to
attack. You might be able to just guess it, or you could find it via an ARP
request, or maybe you just can see some random packets leaking from the
switch. Then, you send an IP packet with your public IP address as the source
IP address and your MAC address as your source MAC address to their MAC
address as the destination MAC address and their internal IP address as the
destination IP address. Their router, being an IP router with NAT but without
a stateful firewall, will check their NAT state for the connection, not find
it, check NAT rules, not find any either, therefore not rewrite anything, then
do a routing table lookup which says that it should be delivered on the LAN
interface, and then, potentially after an ARP lookup, deliver it to the LAN.
That just is how IP works. Again: __unless there is a stateful firewall on the
device __.

------
jedberg
My first thought when I read this was, "Why would you sell a /24, it's so
valuable!". This was after reading that the whole thing is worth maybe $6,000.
Which in the grand scheme of internet things, isn't that much.

But I guess they just aren't as valuable as I thought. Or the price is coming
down now that ipv6 is viable.

I wonder what the peak per ip price was.

~~~
CKN23-ARIN
I bought a /24 3 years ago (from the same broker as OP) for about $3500. The
price is still increasing.

~~~
jedberg
If $6,000 really is the peak then I've been severely overstating the value of
an IPv4 address for a long time. :)

~~~
jldugger
Well, the market's been active for a while now, feel free to park your money
in underpriced ipv4 if you want.

~~~
eloisant
I think the idea is not that ipv4 is underpriced, but not worth as much as we
thought...

------
Taniwha
A little history: I got an /24 in the early 90s, it was how you got on the
internet back then, you sent an email to a well known email address and they
sent you back a class C, no money changed hands, you couldn't get anything
smaller. Also almost no one had firewalls, your subnet was open to the world.

Last month I got an out of the blue offer for the class C I registered for a
startup I worked for about the same time ~3k I'm still the technical contact,
the company is long gone, a drawer in a filing cabinet in a lawyer's
repository somewhere, it's probably the company's largest asset now

~~~
lostlogin
Company IP that the lawyers didn’t screw down.

------
billpg
Please jealously hoard your IPv4 blocks to make migration to IPv6 more
attractive.

~~~
hnarn
I heard somewhere that some developing countries as basically ipv6 only since
there is no reasonable/economical way for them to get ipv4 connectivity, so
maybe the problem will take care of itself as more and more people in the
world come online. People have money and as long as it makes economical sense
to serve more people, ipv6 will win in the end.

------
4cao
From the article:

(1) Rent for $0.20-1.20/mo - or -

(2) Sell for $20-24

Sell/rent ratio is 17-120 months. These numbers seem very different than for
real estate. It's as if the cost to rent a $1M property could be as high as
$60k/mo. Not really sure what to think of it, perhaps the comparison is too
simplistic.

~~~
xvedejas
I think this implies that IP addresses are expected to be a worse investment
than property? Landlords would probably be more willing to sell their land if
it didn't appreciate. Conversely higher rents would be needed in order to
justify holding land that depreciates.

The other possibility I can this of is that renting the block might have
greater liabilities compared to outright selling it.

~~~
egdod
Right. Most of their value is in the short-mid term. At some point everybody
will be using IPv6 and these old addresses won’t matter much.

~~~
NotSammyHagar
Ha, been hearing that exact idea since the 90s when I got on the net. ip4 will
become increasingly valuable until the day it goes to almost 0. This
discussion makes me want to invest in some.

------
gerdesj
I have six internet connections at work. 4 x /29 + 2 x /28 and a /26 on top of
one of the others. I also have six IPv6 allocations.

Anyway, there is absolutely no real value in IPv4. You should always be able
to find a small chunk somewhere. A proxy will work wonders with one IP.

Lack of imagination, or expertise will make IPv4 very expensive when it
becomes scarce but unlike a diamond ...

~~~
Nextgrid
IPv4s are absolutely needed if you're an ISP/hosting provider or if you run
something else than HTTP where there's no concept of "Host" header and it's
assumed that 1 IP/port == one instance of the server.

~~~
words3425434
I really wish HTTP and other protocols embraced SRV records.

~~~
teddyh
Hope is on the horizon:

[https://tools.ietf.org/html/draft-ietf-dnsop-svcb-
httpssvc-0...](https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-01)

------
9nGQluzmnq3M
If they had gotten a Class B block instead, it would be worth a cool $1.3
million at the same price point.

Anybody got a figure for how much a Class A would cost these days in the
unlikely event of one being up for sale? The straight-line-extrapolation $300M
seems a bit high.

~~~
wmf
Amazon bought 44.192.0.0/10 for "over $50M" so a /8 would be worth over $200M.

~~~
dx034
Any reason Amazon would pay more for larger blocks instead of soaking up many
small blocks? Shouldn't VPS providers care less about having fragmented
blocks?

~~~
manquer
Lot more overhead for their teams to find and buy as /10 then lots of /20 .
Also they publish ranges for whitelisting etc easier with fewer ranges for
customers

------
myrmi
Is it possible for an individual to purchase a IPv6 block?

~~~
kemotep
Yes it appears so. But there seems to be a few requirements [0].

Also bear in mind a /64 is more than 18 quintillion addresses so it might be a
bit more expensive. And it appears they only offer /48's to individual
businesses if they meet the criteria but that is still billions of IPs.

[0]:[https://www.arin.net/resources/guide/ipv6/first_request/](https://www.arin.net/resources/guide/ipv6/first_request/)

~~~
garaetjjte
/64 is just normal allocation that every home connection should get. (/48 in
this notation is bigger) Given these amounts of addresses subnetting
philosophy is quite different from IPv4.

~~~
kemotep
I completely forgot about that difference with IPV6 and IPV4. You are right.
There are still many thousands if not millions of addresses available to those
who want them. And compared to IPV4 everyone on the planet could have a /64.

Here is a decently comprehensive serverfault post[0] on the subject of IPV6
subnetting.

[0]:[https://serverfault.com/questions/426183/how-does-
ipv6-subne...](https://serverfault.com/questions/426183/how-does-
ipv6-subnetting-work-and-how-does-it-differ-from-ipv4-subnetting)

------
paulgerhardt
What are the practical differences in registering a block with ARIN vs APNIC
vs RIPE? If one buys a legacy block does one have to transfer it to ARIN?

~~~
toast0
Different registries have different policies about where the registrants are
located. It's least complicated to manage blocks that are in the registry
appropriate for your entity's location.

That said, I thought all of the legacy blocks were ARIN blocks, since they
actually predate ARIN and the regional registies; but ARIN took responsibility
for managing them. (I could easily br wrong)

------
dkroy
Is there any ongoing cost to staying registered with ARIN or any other
registry if you own a block like this?

~~~
CKN23-ARIN
ARIN registration fees start at $250/yr for a /24\.
[https://www.arin.net/resources/fees/fee_schedule/#service-
ca...](https://www.arin.net/resources/fees/fee_schedule/#service-categories-
and-fees-1)

------
Danieru
Sounds interesting, anyone investing using IP blocks? Seems like it would be
an weird non-correlated asset with maybe some tax advantages? How would
depreciation work for IP blocks?

~~~
wmf
The hippie powers that be consider IP speculation to be immoral hoarding and
try to prevent it. Somewhere I saw projections that prices will rise for the
next few years then start to fall (but I also saw projections of BTC going to
$100K so YMMV).

