cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame?

Dear NANOG@,

I've had a Linode in Fremont, CA (within 173.230.144.0/20 and
2600:3c01::/32) for over a year, and, in addition to some development,
I sometimes use it as an ssh-based personal SOCKS-proxy when
travelling and having to use any kind of public WiFi.

Since doing so, I have noticed that most geolocation services think
that I'm located in NJ (the state of the corporate headquarters of
Linode), instead of Northern California (where my Linode is physically
from, and, coincidentally or not, where I also happen to live, hence
renting a Linode from a very specific location).

Additionally, it seems like both yelp.com and retailmenot.com block
the whole 173.230.144.0/20 from their web-sites, returning some
graphical "403 Forbidden" pages instead.

...

I would like to point out that 173.230.144.0/20 and 2600:3c01::/32,
announced out of AS6939, are allocated by Linode from their own
ARIN-assigned allocations, 173.230.128.0/19 and 2600:3C00::/30, which
Linode, in turn with their other ARIN-assigned space, allocates to 4
of their distinct DCs in the US, in Dallas, Fremont, Atlanta and
Newark.

However, Linode does not maintain any individual whois records of
which DC they announce a given sub-allocation from. They also do not
document their IPv6 assignments, either: if one of their customers
misbehaves, the offended network would have no clue how to block just
one customer, so, potentially, a whole set of customers may end up
being blocked, through a wrong prefixlen assumption.

I've tried contacting Linode in regards to whois, giving an example of
some other smaller providers (e.g. vr.org) that label their own
sub-allocations within their ARIN-assigned space to contain an address
of the DC where the subnet is coming from, and asked whether Linode
could do the same; however, Linode informed me that they don't have
any kind of mail service from the DCs they're at, and that their ARIN
contact, effectively, said that they're already doing everything right
in regards not having any extra whois entries with the addresses of
their DC, since that would actually be wrong, as noone will be
expecting mail for Linode at those addresses. (In turn, it's unclear
whether a much smaller vr.org has mail service at nearly a dozen of
the DCs that they have their servers at, and which they provide as the
addresses in ARIN's whois, but I would guess that they do not.)

This would seem like a possible shortcoming of ARIN's policies and the
whois database: with RIPE, every `netname` has a `country` associated
with it, seemingly without any requirements of a mailing address where
mail could be received; but with ARIN, no state is ever provided, only
a mailing address. (I've also just noticed that RIPE whois now has an
optional `geoloc` field in addition to the non-optional `country`.)

Now, back to ARIN: is Linode doing it right? Is vr.org doing it
wrong? Are they both doing it correct, or are they both wrong?

And in regards to yelp and retailmenot; why are they blocking Linode
customers in 173.230.144.0/20? I've tried contacting both on multiple
occasions, and have never received any replies from yelp, but
retailmenot has replied several times with a blanket "someone may have
tried to scrap, spam or proxy our site from this network". I have
repeatedly asked retailmenot if they'd block Verizon or AT&T if
someone tries to scrap or spam their web-site from those networks,
too, but have never received any replies. I have also tried
contacting Linode regarding this issue, and although they were very
patient and tried troubleshooting the problem, reporting that it
appears that other addresses within 173.230.144.0/20 are likewise
blocked, but some of their other address ranges at another DC are not,
they have not been able to get in touch with anyone at yelp or
retailmenot to isolate the problem.

Now, if you were operating yelp or rmn, would you not block an address
range with a fishy geoloc like that of Linode? I'm somewhat convinced
that 403 Forbidden stems entirely out of some logic that notes that
the geoloc data is likely fishy, or which [erroneously] concludes that
the address range is used for anonymity purposes.

Anyhow. How do I get my geoloc to show Fremont, CA? And to have yelp
stop returning 403 Forbidden?

Cheers,
Constantine.

Now, back to ARIN: is Linode doing it right? Is vr.org doing it
wrong? Are they both doing it correct, or are they both wrong?

ARIN Policies do require Linode to SWIP their customer allocations,
so the fact that they are not doing so is actually a violation of policy.

Linode (and VR) probably shouldn't SWIP their datacenter blocks,
but this isn't really covered in policy one way or the other.

Anyhow. How do I get my geoloc to show Fremont, CA? And to have yelp
stop returning 403 Forbidden?

Get Linode to SWIP your blocks for starters.

Owen

Now, back to ARIN: is Linode doing it right? Is vr.org doing it
wrong? Are they both doing it correct, or are they both wrong?

ARIN Policies do require Linode to SWIP their customer allocations,
so the fact that they are not doing so is actually a violation of policy.

They have repeatedly disagreed, on two separate occasions, effectively
claiming they themselves are the customers:

We now get all of our addresses assigned directly to us which is why our address is listed, however we still have some IP addresses in our pool with ...

So, the "new" addresses are all assigned directly to them.

Linode (and VR) probably shouldn't SWIP their datacenter blocks,
but this isn't really covered in policy one way or the other.

Anyhow. How do I get my geoloc to show Fremont, CA? And to have yelp
stop returning 403 Forbidden?

Get Linode to SWIP your blocks for starters.

Could work with IPv6, since I have a /56 from them, but I only have a
single IPv4, so, per my understanding, an IPv4 SWIP is not possible.

C.

Inline Reply

Dear NANOG@,

I've had a Linode in Fremont, CA (within 173.230.144.0/20 and
2600:3c01::/32) for over a year, and, in addition to some development,
I sometimes use it as an ssh-based personal SOCKS-proxy when
travelling and having to use any kind of public WiFi.

Since doing so, I have noticed that most geolocation services think
that I'm located in NJ (the state of the corporate headquarters of
Linode), instead of Northern California (where my Linode is physically
from, and, coincidentally or not, where I also happen to live, hence
renting a Linode from a very specific location).

Additionally, it seems like both yelp.com and retailmenot.com block
the whole 173.230.144.0/20 from their web-sites, returning some
graphical "403 Forbidden" pages instead.

...

I would like to point out that 173.230.144.0/20 and 2600:3c01::/32,
announced out of AS6939, are allocated by Linode from their own
ARIN-assigned allocations, 173.230.128.0/19 and 2600:3C00::/30, which
Linode, in turn with their other ARIN-assigned space, allocates to 4
of their distinct DCs in the US, in Dallas, Fremont, Atlanta and
Newark.

However, Linode does not maintain any individual whois records of
which DC they announce a given sub-allocation from. They also do not
document their IPv6 assignments, either: if one of their customers
misbehaves, the offended network would have no clue how to block just
one customer, so, potentially, a whole set of customers may end up
being blocked, through a wrong prefixlen assumption.

I've tried contacting Linode in regards to whois, giving an example of
some other smaller providers (e.g. vr.org) that label their own
sub-allocations within their ARIN-assigned space to contain an address
of the DC where the subnet is coming from, and asked whether Linode
could do the same; however, Linode informed me that they don't have
any kind of mail service from the DCs they're at, and that their ARIN
contact, effectively, said that they're already doing everything right
in regards not having any extra whois entries with the addresses of
their DC, since that would actually be wrong, as noone will be
expecting mail for Linode at those addresses. (In turn, it's unclear
whether a much smaller vr.org has mail service at nearly a dozen of
the DCs that they have their servers at, and which they provide as the
addresses in ARIN's whois, but I would guess that they do not.)

This would seem like a possible shortcoming of ARIN's policies and the
whois database: with RIPE, every `netname` has a `country` associated
with it, seemingly without any requirements of a mailing address where
mail could be received; but with ARIN, no state is ever provided, only
a mailing address. (I've also just noticed that RIPE whois now has an
optional `geoloc` field in addition to the non-optional `country`.)

Now, back to ARIN: is Linode doing it right? Is vr.org doing it
wrong? Are they both doing it correct, or are they both wrong?

You need to give me what you need to give me, but if you give me more
am I going to complain? What about if you miss something?

And in regards to yelp and retailmenot; why are they blocking Linode
customers in 173.230.144.0/20? I've tried contacting both on multiple

Could be many reasons, I suspect they get little legitimate traffic
from there with their target audiences.

occasions, and have never received any replies from yelp, but
retailmenot has replied several times with a blanket "someone may have
tried to scrap, spam or proxy our site from this network". I have

Probably likely, many geo-restricted sites also block hosting providers.

repeatedly asked retailmenot if they'd block Verizon or AT&T if
someone tries to scrap or spam their web-site from those networks,
too, but have never received any replies. I have also tried

Residential provider: Block millions of users to stop a few scrapers.
Hosting provider: Block a couple of users to block 90% of the
scrapers, and all the places the scrapers go to when you block them.

contacting Linode regarding this issue, and although they were very
patient and tried troubleshooting the problem, reporting that it
appears that other addresses within 173.230.144.0/20 are likewise
blocked, but some of their other address ranges at another DC are not,
they have not been able to get in touch with anyone at yelp or
retailmenot to isolate the problem.

Now, if you were operating yelp or rmn, would you not block an address
range with a fishy geoloc like that of Linode? I'm somewhat convinced
that 403 Forbidden stems entirely out of some logic that notes that
the geoloc data is likely fishy, or which [erroneously] concludes that
the address range is used for anonymity purposes.

Have you done a lot of 'looking up IP addresses'?

Browse around some of the whois records from hosting providers, and
see if you can figure out how much to block. IPv6 makes this even more
fun, a /64 shared between customers or a /48 per server? have to read
their site, traceroute, etc...

Anyhow. How do I get my geoloc to show Fremont, CA? And to have yelp
stop returning 403 Forbidden?

SWIP? see owen..

If you can't get anyone who can change things to 'fix' it for you -
Change provider*?

- Mike

*I'm sure if you 'can't find a suitable one' you'll get off list replies :wink:

I've had a Linode in Fremont, CA (within 173.230.144.0/20 and
2600:3c01::/32) for over a year, and, in addition to some development,
I sometimes use it as an ssh-based personal SOCKS-proxy when
travelling and having to use any kind of public WiFi.

Since doing so, I have noticed that most geolocation services think
that I'm located in NJ (the state of the corporate headquarters of
Linode), instead of Northern California (where my Linode is physically
from, and, coincidentally or not, where I also happen to live, hence
renting a Linode from a very specific location).

If you care about geolocation of your IP addresses, submit that
information to the geolocation services. For the $20/month you're
paying Linode (or do you have the expensive account?), why would they
care about geolocation?

Additionally, it seems like both yelp.com and retailmenot.com block
the whole 173.230.144.0/20 from their web-sites, returning some
graphical "403 Forbidden" pages instead.

At a glance, I'd bet this has more to do with Linode being a VPS
provider (not an eyeball network) than anything else. Despite
everything VPS service providers do to prevent it, they do get abused
by folks attempting every sort of fraud imaginable. As they're not an
eyeball network, the fraud to not-fraud ratio of eyeball activities is
not ideal.

This would seem like a possible shortcoming of ARIN's policies and the
whois database: with RIPE, every `netname` has a `country` associated
with it, seemingly without any requirements of a mailing address where
mail could be received; but with ARIN, no state is ever provided, only
a mailing address. (I've also just noticed that RIPE whois now has an
optional `geoloc` field in addition to the non-optional `country`.)

Now, back to ARIN: is Linode doing it right? Is vr.org doing it
wrong? Are they both doing it correct, or are they both wrong?

They are both correct. ARIN allows address holders to SWIP down to
whatever level they want, but only requires them to SWIP assignments
of /29 or more addresses. Some service providers prefer that abuse be
immediately the subscriber's problem, so they put the info in the
whois system. Others come down on the side of keeping their customer
database out of the hands of competitors, so they publish the minimum
required information. In both cases, the smaller the account the less
willing they are to deviate from the corporate standard.

Anyhow. How do I get my geoloc to show Fremont, CA? And to have yelp
stop returning 403 Forbidden?

Contact customer support. Tell them you're blocked. Ask them not to
block you. Same as you would for any encounter where the service
provider has blocked your source address.

Regards,
Bill Herrin

Although I have knowledge of either of those sites, I'd put money on the
fact they they simply got sick of the repeated site scraping or similar
activity from Linode and blocked the entire range. I've spoken to many
other sites that have done exactly this, with a fairly clear inverse
relation between the cost of the hosting provider and the likelihood of
such behavioral (with Linode and Hetzner pretty much being at the top of
that list)

  Scott.

Now, back to ARIN: is Linode doing it right? Is vr.org doing it
wrong? Are they both doing it correct, or are they both wrong?

ARIN Policies do require Linode to SWIP their customer allocations,
so the fact that they are not doing so is actually a violation of policy.

They have repeatedly disagreed, on two separate occasions, effectively
claiming they themselves are the customers:

We now get all of our addresses assigned directly to us which is why our address is listed, however we still have some IP addresses in our pool with ...

So, the "new" addresses are all assigned directly to them.

Not really...

The relevant section of the NRPM is 6.5.4 et. seq.

They are, for all practical purposes, acting as an LIR. They receive space from ARIN and then assign it to their customers (such as you).

According to 6.5.5.1, if they are assigning you a /64 or more, they must register that with ARIN through SWIP or RWHOIS.

If you are getting less than a /64, then, yes, you are out of luck.

Linode (and VR) probably shouldn't SWIP their datacenter blocks,
but this isn't really covered in policy one way or the other.

Anyhow. How do I get my geoloc to show Fremont, CA? And to have yelp
stop returning 403 Forbidden?

Get Linode to SWIP your blocks for starters.

Could work with IPv6, since I have a /56 from them, but I only have a
single IPv4, so, per my understanding, an IPv4 SWIP is not possible.

Correct... For IPv4, you're kind of hosed.

Geolocation of IP addresses has always been an ill-conceived quagmire. This is not news.

However, in terms of getting the best you can out of a bad situation, the advice above is about as good as it gets.

Owen

I'll leave the rest of your comments/questions to others, but on this:

And in regards to yelp and retailmenot; why are they blocking Linode
customers in 173.230.144.0/20? I've tried contacting both on multiple
occasions, and have never received any replies from yelp, but
retailmenot has replied several times with a blanket "someone may have
tried to scrap, spam or proxy our site from this network".

Only yelp and retailmenot can answer that question precisely, but:
I've seen MANY instances of Linode-originated spam. Attempts to get
Linode to exercise a modicum of professionalism and make it stop on
their side have not been successful, therefore I've taken steps to make
it stop on my side. If it continues and escalates (both of which seem
very likely) then eventually I'll upgrade those steps to "firewall rules".

So I suggest that your complaints about yelp and retailmenot blocking you
should be directed not to them, but to Linode: you should ask Linode
why they made it *necessary* for yelp and retailmenot to defend themselves
in that fashion. You should ask them what remedial action they're currently
taken to no longer make it necessary. And you should ask them when they
will be contacting yelp/retailmenot in order to (a) apologize and (b) request
their access privileges back.

---rsk

Have we *really* sunk so low that inline replies need to be flagged as
such, because people *expect* top-posting and if they don't see it they
assume it's a MUA misfire rather than an inline reply?

Have we *really* sunk so low that inline replies need to be flagged as
such, because people *expect* top-posting and if they don't see it they
assume it's a MUA misfire rather than an inline reply?

SATSQ: Any time the question is "have we *really* sunk so low?" the answer
is yes.

Constantine,

I'm afraid you might be confusing the NANOG list with
support@linode.com (which, incidentally, I've found to be good at
providing timely assistance, more often than not).

In any event, I've found that commercial GeoIP services rely on data
from RIRs and the global routing table a bit less than you'd expect.
I'm not finding any supporting documentation right now, however I
remember reading in their FAQ that harvested website user registration
data was MaxMind's primary source, which makes life particularly fun
when you're a hosting shop with no real "eyeball" customers to speak
of. Add to the list of challenges being allocated an aggregate block
from ARIN/RIRs, and the advertising regionalized de-aggregates out of
various datacenters -- itself a relatively common, and sometimes
technically beneficial, practice -- as appears to be happening here
with Linode.

If accuracy matters, I'd suggest that you and/or your provider start
by working individually with MaxMind, Quova (now Neustar?), Google
(who purportedly uses Quova, but sometimes needs a kick to refresh
things), and Akamai. It would be interesting to see a table of which
large websites get their data from which geolocation provider(s), but
this should give you a good start.

Hope this helps,
-a

Yes.

In article <215377.1362329066@turing-police.cc.vt.edu> you write:

Now, back to ARIN: is Linode doing it right? Is vr.org doing it
wrong? Are they both doing it correct, or are they both wrong?

They have repeatedly disagreed, on two separate occasions, effectively
claiming they themselves are the customers:

... they are assigning IP addresses to their own equipment, which
belongs to the provider at all times, and the contact can be the same
contact for all their resources, therefore: they are not necessarily
required to display a SWIP in WHOIS. They just need to keep certain
documentation.

Network service providers that allocate or assign IP addresses are
required to display allocations/assignments of /29 and larger in
WHOIS; they can display any additional divisions in WHOIS that the
org deems sensible for their network.

However, (1) This isn't very pertinent to gelocation. ARIN resource
holders don't have to SWIP their different datacenter networks that
are all assigned to the provider, and (2) don't need to provide a
street address for their listings that has a bearing on where the
network is actually geographically located, WHOIS listings are
contacts.

Also, a SWIP would probably not stop have stopped Yelp, et al. from
blocking the network.

If it's in the IP address space of a VPS hosting provider. If the
provider is large enough, it is almost certain that someone will have
conducted activity, causing large portions of the provider's IP space
to be blocked, and this is just part of the risk cost of hosting your
site there.

(You get a lower upfront dollar price, compared to setting up your own
network and obtaining /24 direct assignment from an upstream, because
you are sharing a network with other subscribers, but when one of
those other subscribers commits some abuse -- your orgs VPS could be
on the blocked network too)

If you have issues with Linode's WHOIS listing policies, there are
plenty of alternative providers; although they may be susceptible to
similar blocks by Yelp etc.

Could work with IPv6, since I have a /56 from them, but I only have a
single IPv4, so, per my understanding, an IPv4 SWIP is not possible.

It's conceivable to list a /32 on a RWHOIS server.
But Linode do not have to do it, and most likely they will not be
willing to do it.

It is not unusual that a hosting provider would be unwilling to take
on the additional cost of maintaining indinvidual WHOis listings for
each subscriber.

Or to change their WHOIS policy based on the request of one customer;
possibly increasing their WHOIS record management costs by a
significant amount.

The addresses assigned to their hardware interfaces may fit that
argument.

The addresses assigned to customer virtuals, OTOH, IMHO do not
really meet that test. The virtual and its content are not property of
Linode, they belong to the customer. Yes, the customer is using
Linode's hardware as an execution environment for their virtual, but
the address range is assigned to the customer virtual. At that point,
I would argue that the policy for SWIP does, in fact, apply.

Owen

Constantine A. Murenin(mureninc@gmail.com)@Sat, Mar 02, 2013 at 01:58:09PM -0800:

Dear NANOG@,

<snip>

Additionally, it seems like both yelp.com and retailmenot.com block
the whole 173.230.144.0/20 from their web-sites, returning some
graphical "403 Forbidden" pages instead.

<snip>

And in regards to yelp and retailmenot; why are they blocking Linode
customers in 173.230.144.0/20? I've tried contacting both on multiple
occasions, and have never received any replies from yelp, but
retailmenot has replied several times with a blanket "someone may have
tried to scrap, spam or proxy our site from this network". I have
repeatedly asked retailmenot if they'd block Verizon or AT&T if
someone tries to scrap or spam their web-site from those networks,
too, but have never received any replies. I have also tried
contacting Linode regarding this issue, and although they were very
patient and tried troubleshooting the problem, reporting that it
appears that other addresses within 173.230.144.0/20 are likewise
blocked, but some of their other address ranges at another DC are not,
they have not been able to get in touch with anyone at yelp or
retailmenot to isolate the problem.

For what it's worth, I've contacted Yelp about this issue a number of
times, and they're wholly uninterested in traffic from Linode. They're
also unwilling to discuss the issue with someone coming from Linode. So,
good luck on that front!

With all the garbage I've seen from placed with race to the bottom
pricing I can't blame them.

~Seth