Ettiquette and rules regarding Hijacked ASN's or IP space?

Mailman List Mirror (Read Only)
1

So, with all this lifting the curtains on hijacked ASN's and ipblocks
recently I have a few general question...

1) Should the rules be uniformly applied?
2) Should these rules be applied even when something 'bad' might happen?
3) How much involvment should ARIN have in enforcing these rules?

Now, by 'rules' I mean:

If you steal something you have to give it back, regardless of who you
are.

So, for an example, if I steal ASN 8143 (already stolen so its mute) and
I'm 'a good guy', all I want to do is run a network no spam/abuse eminates
from it, should I be subject to the 'witch hunt' that my fellow ASN
stealer who does abuse/spam deals with? The same is asked for hijacked ip
space. If I steal/hijack a large netblock, not from an active org so there
is no 'damage' done, and I don't spam/abuse from it should I be compelled
to return it also? Compelled in the same way that my brother stealer who
spams/abuses is?

I am not advocating one or the other, and to me the rules should apply to
both groups (all theives treated equally)... I'm just curious as to the
general thought on this subject.

Additionally, how should ARIN go about verifying proper 'ownership' (that
I am still me after all these years of 'inactivity'), how much is enough
research on these issues? I know that at the ISP there is a measure of
trust placed on the customer, and upstream/downstream, when it comes to
ASN's and ip announcements. ARIN is in the same position as near as I can
tell. They have to trust that the community both is trustworthy (to an
extent) and conscientious. If there are bad actors out there that go to
enough trouble they can make ASN's or ip blocks appear to be registered to
themselves. There may be breadcrumbs of evidence if you look hard enough,
perhaps there won't be. How hard should ARIN be looking at these issues
and at specific instances? Should they apply their rules without
prejudice?

Sorry for the latenight not-completely-operational question :slight_smile: but it
seems as though there is some abmiguity in the current
process/procedure/rules and I'd like to atleast start some discussion on
the topic.

Thanks.

--Chris
(chris@uu.net)

2

Well as some of you know as of late I've been involved in investigations of
number of hijacked ip blocks (about 40 and looking at more) and can tell
you that for greater majority of companies (especially for companies that
had /16s but even for companies that had /24) the records on internet do
exist and not just in the whois - these are email messages in newsgroups,
webpages, passing refernces, etc. In fact I'm able to trace what happened
to original company that had ip block in 90% of the cases and based on
that can tell if the company currently using the ip block had any relation
with original or not - that is primary criteria to determine if ip block is
hijcked. I'll release my finding on this list in week or two and you'll
all be able to see this all.

As far as rules being uniformerly applied - yes they should be, its not a
matter of if the abuse exists from that ip block or not, its a matter of
somebody using ip block that they are not authorized and is basicly theft
or resources (if that company does not exist their resources should be
back with ARIN - but this is actually rare, usually some other company
buys the original and very few companies I'v seen just disappeared entirely).

As for ARIN this question I expect would be raised on the next meeting and
should be properly discussed at their ppml mailing list. I'm not sure how
much they can or should do and don't want to give my recommendation about
it right now. What I can tell you is that they are not proactive right
now - for all the reports they received from me (and this is as I said
almost 40 reports, the reports were very details about which company
should have ip block and and case was quite well proved with materials
from multiple sources) - ARIN has not tried to contact the companies,
maximum they did is to restore original whois records before ip block
got hijacked. I do hope that based on what they have seen ARIN will be a
little more carefull about changes to whois and will require more
documentation before doing change to particular old record - I personally
think they should proactively investigate to confirm information similar
to how I've been doing it before proceeding with changes.

BTW: On particular case of AS8143 - it was hijacked, but it also appears
that original company that had used this AS is not entirely dead, they are
in process of restructuring and some of the use for that AS is valid.
Basicly it appears hijacker took particular AS they just used for their
announcements of hijacked ip space which were independent of other
announcements of AS8143 which were ok.

3

Fear leads to Hate, which leads to Evil, the way of the darkside :wink:

RIR's are not and should not be in the business of dictating what
goes into the routing table, or what label is used on what goes
into the routing table.

I think part of the issue here is that to many providers don't filter
what they receive from their BGP speaking peer.

Its not that hard to build tools to drop known IANA reserved space
packets, or even AS ranges.

If we get into RIR's processing witch hunts, we run the strong and real
risk of dropping real live users right off the net. Then that causes
the risk for greater legal cost and exposure to happen.

At the end of the day, RIR's make sure the bit strings are unique, and
that reasonable costs for do that job are covered in registration fees.

Its up to each provider to verify their BGP config and the data received
from those peers.

If this was easy everyone would or could do it.

4

I'm not as interested in proving something was "stolen," but how do
you prove you have a "legitimate" claim? To me, the difference is
important, because the record keeping is so iffy you can question almost
everything. For example, NSI messed up the creation date on my domain,
changing to 2002 instead of the original date. How do I prove NSI screwed
up (again)?

Trust
Verify
Remember

What is the role of IANA and the regional registries?

IANA/RIR are the recordkeepers. You should be able to get a "certified"
history of the records for an ASN, IP address, etc. Not just the "last"
owner of record, but the equivalent of a transcript of the history of an
ASN, IP address, etc. showing all the changes to the records since their
original allocation.

"Certified" doesn't mean IANA/RIR guarantees the "ownership" or that the
person is who they claim to be. Like a college transcript, the user must
authorize IANA/RIR to send the transcript directly to the ISP. I would
expect IANA/RIR to charge a fee for the service.

What about fraudlent transfers?

This is difficult, because the crooks know all the loopholes. And often
make bogus legal threats to keep their operation going. They share
information about ISPs, but ISPs don't share information about bad
customers. Eventually I think we are going to have to do something like
banks, and report when accounts are closed for cause. And I don't mean
vigilante black lists, but something that follows the law like Equifax or
ChexSystems.

If IANA/RIR recinds a transfer, as a recordkeeper, they would notify
all the ISPs which had received a "transcript" involving the individual,
ASN or IP address. As we've seen, most of these people are repeat
offenders.

What about mistakes?

Mistakes happen. That's why I would prefer more information to make
a decision rather than a binary accept/reject. It may be a legitimate
transaction, but IANA/ARIN/RIPE/APNIC/LACNIC's records are out of date.
With a complete transcript, I may contact the previous registrant and
verify the information pending the update of the registry records.

What proof should IANA/RIRs accept for a transfer?

History is against us. The "rules" have changed over the years. Its
difficult to say what is really legitimate. How do we reclaim abandoned
space before a squatter moves in? What is acceptable legal proof of
transfer of "ownership" of something some people say isn't an asset?
How much detective work is IANA/RIR expected to do? How much should you
have to pay for IANA/RIR to do that work?

When is someone going to get prosecuted?

Fraud, theft, conversion, etc.

5

Just the other day I heard of a new customer of an ISP in Toronto who had requested transit for particular blocks. The numbers in question were registered to a tyre company in South Africa, and were now in use by a hosting company based in Sacramento, who now wanted the block announced in Toronto.

The ISP in Toronto asked for an LOA, and got one, neatly presented on company letterhead, and accompanied by e-mail from the tech contact for the block confirming that the request to advertise the block was authorised.

Is that enough justification to perform the announcement? Where exactly should the line be drawn?

Someone made the point from the floor mike in Salt Lake City during the SBGP/SoBGP panel discussion that until there is an easy, manual way to answer the questions "should I accept this route from this AS" and "should I originate this route", no amount of crypto or automation is really going to help anything.

Maybe some service akin to a credit check is required.

   "Hello, I have a request to accept an announcement of 203.97.0.0/17 from AS 4768."
   "That request is legitimate according to our records, here is your auth code."

   "Hello, my new customer with the following contact details has asked me to originate 203.167.0.0/18 from AS 9327."
   "We cannot confirm the legitimacy of that request, and the listed contact for 203.167.0.0/18 has been informed of your request."

   "Hello, my customer gave me the following pre-auth code together with a request to originate 203.97.128.0/17 on his behalf"
   "That pre-auth code matches the prefix, here is your auth code for this request."

Since the RIRs contain the information required to answer those questions, you'd expect them (or their data) to be involved in the process of answering them.

Joe

6

The ISP in Toronto asked for an LOA, and got one, neatly presented on
company letterhead, and accompanied by e-mail from the tech contact for
the block confirming that the request to advertise the block was
authorised.

Is that enough justification to perform the announcement? Where exactly
should the line be drawn?

Unfortunately, probably not. How do they know it was company letterhead?
Had they ever seen the company's letterhead before? How do they know I
didn't just create that LOA and letterhead in OpenOffice?

Maybe some service akin to a credit check is required.

   "Hello, I have a request to accept an announcement of 203.97.0.0/17
from AS 4768."
   "That request is legitimate according to our records, here is your
auth code."

Trouble is, how do you/they know if both the space and ASN have been
hijacked?

   "Hello, my new customer with the following contact details has asked
me to originate 203.167.0.0/18 from AS 9327."
   "We cannot confirm the legitimacy of that request, and the listed
contact for 203.167.0.0/18 has been informed of your request."

The listed contact may not be who ARIN [or other local RIR] thinks it is.

Since the RIRs contain the information required to answer those
questions, you'd expect them (or their data) to be involved in the
process of answering them.

They really don't. Thus far, when space is assigned, the RIRs have no way
to later authenticate that an organization using the space is the same one
that they assigned it to.

As for the current state of BGP authentication/sanity checking, I can say
2 of my 4 upstreams take whatever I put in the routing registry. The
other two require an email be sent requesting prefix filter updates. I
was just told by one, that they'll accept whatever I request, only
questioning it if someone complains to them about it. The other, I
haven't asked, but I assume they work similarly. On the bright side, all
of them are at least filtering.

7

Since the RIRs contain the information required to answer those
questions, you'd expect them (or their data) to be involved in the
process of answering them.

They really don't. Thus far, when space is assigned, the RIRs have no way
to later authenticate that an organization using the space is the same one
that they assigned it to.

The RIRs definitely hold some of the data that would be required to make educated pronouncements (although clearly not all of it).

Note that I'm not talking about absolute accuracy here; as long as people are able to change companies, change their names, die, forge documentation and otherwise lie, there will always be fraud. What is needed is some trusted resource who can say "our best guess is that this is legitimate".

At the moment there is no clear procedure for any ISP to follow to even get a best guess as to whether an advertisement should be accepted or not.

As for the current state of BGP authentication/sanity checking, I can say
2 of my 4 upstreams take whatever I put in the routing registry.

I have met people who think that the existence of a route in the IRR is somehow demonstrable evidence that a route should be accepted. I'm not quite sure why they think that way.

Joe

8

> Since the RIRs contain the information required to answer those
> questions, you'd expect them (or their data) to be involved in the
> process of answering them.

They really don't. Thus far, when space is assigned, the RIRs have no way
to later authenticate that an organization using the space is the same one
that they assigned it to.

RIPE at least uses a hierarchical authorisation scheme which means you cannot
register routes to an ASN and prefix you dont have authorisation on, where
authorisation on those blocks is passed down from supernets and superblocks
ultimately controlled by RIPE.

This means for me to add a route I effectively have proof from my authorisation
being granted by RIPE that this is mine to play with.

It doesnt entirely preclude hijacking by way of stealing authorisation but its
more difficult and they're making it tougher.

Why cant this be extended?

All my customers (who fall under RIPE) must have routes registered from their
ASN before I accept them. My peers and transits I trust a little more but dont
have to providing I'm willing to build filters.

As for the current state of BGP authentication/sanity checking, I can say
2 of my 4 upstreams take whatever I put in the routing registry. The
other two require an email be sent requesting prefix filter updates. I
was just told by one, that they'll accept whatever I request, only
questioning it if someone complains to them about it. The other, I
haven't asked, but I assume they work similarly. On the bright side, all
of them are at least filtering.

I suspect the filtering is more to protect them from route leaks than checking
your netiquette.

Bad :frowning:

Steve

9

Speaking as someone who is extremely annoyed by providers/peers/etc proxy
registering IRR routes, I think a system which locks down registrations
within specific prefixes to a specific maintainer, and an approval system
for people who want to register blocks within your space, would be
insanely useful. Someone please implement this for us US folks using irrd.

10

See RIPE database.

http://www.ripe.net/ripencc/faq/database/route-creation-checks.html

Regards,
Daniel

11

Fear leads to Hate, which leads to Evil, the way of the darkside :wink:

RIR's are not and should not be in the business of dictating what
goes into the routing table, or what label is used on what goes
into the routing table.

Certainly not, but if the information we (isp's/Network operators) need to
verify that our 'customer' has the right to route a block isn't correct or
is easily subverted they have some responsibility there I'd think, right?

I think part of the issue here is that to many providers don't filter
what they receive from their BGP speaking peer.

Hrm, I've heard this alot, and seen some other providers that clearly
don't filter... but even more insidious are the ones that DO filter and
rely on the information provided by an RIR to validate the 'ownership' of
the blocks they build their filters for.

Its not that hard to build tools to drop known IANA reserved space
packets, or even AS ranges.

that's not the issue here (or it wasn't the thrust of the original
question atleast)

If we get into RIR's processing witch hunts, we run the strong and real
risk of dropping real live users right off the net. Then that causes
the risk for greater legal cost and exposure to happen.

Sure, this is true... so, how much is enough? and should the 'rules' still
be applied equally, despite the fact that the nuns at Mother Jessica's
Monestary who use Asn 8143 for upstream will get booted off the network
because 8143 was hijacked?

At the end of the day, RIR's make sure the bit strings are unique, and
that reasonable costs for do that job are covered in registration fees.

Its up to each provider to verify their BGP config and the data received
from those peers.

Sure, you are announcing 196.1.1.0/24 and only that, fine, but are you
allowed to announce that prefix? Are you "Centre for Monitoring Indian
Economy" ?? Or is this your direct customer and you are just the sat-link
provider for him?

12

Being able to answer such 64,000-dollar-questions with authority is the
issue ARIN's registry operations are facing, pass or fail. And you can
take that literally: the recent hijacking events have put ARIN's rules,
procedures and current registry data so much into question - it'll be
(do || die) for them. The inherited Internic data going back almost 20
years doesn't help things. Indeed, I think that any and all legacy
assignments should be purged, like the old Usenet, one by one. Some
things that could be done:

- contact all owners of IP space or ASNs with a demand to show legal, notarized
  paperwork showing their company's status as incorporated/active, and/or
  legal successor to the original registrant. Gotta use those 7 years of
  business records you're required to hold for something!

- non-announced IP space with defunct contacts: -> reserved status, no
  AS may route those, until resolved per above

- non-announced IP space with working contacts: email to POC every
  30 days with the legal demands (email/paper mail). After 90 days:
  network set to 'reserved' status, no AS may announce these,
  until resolved per above.

- announced IP space: announcing AS to be contacted in addition to POC
  for the network object. For AS's in violation, this shall mean that
  all upstream ASs as visible at popular exchange points should be
  contacted (at least once) as well.

- announcing AS's that violate the 'do not announce' rule shall be
  dealt with in ways similar to the non-cooperating entities described in:
  http://www.arin.net/policy/2003_1.html - they will get their own network
  objects suspended.

- complete publicly accessible list of all 'reserved' networks - the
  DNSBLs and private BGP blackhole feeds will do the rest.
  Wouldn't you want to know how quiet your inbox can be, when you
  have a BGP4 blackhole feed with SPEWS L1 as the source...

13

Hello Kia , In line

> Sure, you are announcing 196.1.1.0/24 and only that, fine, but are you
> allowed to announce that prefix? Are you "Centre for Monitoring Indian
> Economy" ?? Or is this your direct customer and you are just the sat-link
> provider for him?

Being able to answer such 64,000-dollar-questions with authority is the
issue ARIN's registry operations are facing, pass or fail. And you can
take that literally: the recent hijacking events have put ARIN's rules,
procedures and current registry data so much into question - it'll be
(do || die) for them. The inherited Internic data going back almost 20
years doesn't help things. Indeed, I think that any and all legacy
assignments should be purged, like the old Usenet, one by one. Some
things that could be done:

- contact all owners of IP space or ASNs with a demand to show legal,
notarized
  paperwork showing their company's status as incorporated/active, and/or
  legal successor to the original registrant. Gotta use those 7 years of
  business records you're required to hold for something!

  Already in progress . Using DNS lameness as start basis . I just
  got a note for an old ip-range I had promised the owner I'd keep
  active and forgot about over the years .

- non-announced IP space with defunct contacts: -> reserved status, no
  AS may route those, until resolved per above

  How would you go about admonishing hijackers (or what appears as a
  hijacker) OR the provider that has been given a letter of approval
  from the agency that appears to have the lease ? ... lots more
  questions in this vein ? For all of the items mentioned below .
  Just one foopah with a blackhole server & NOone is going to remain
  attached to it . That has been proven over & over again . If you
  can not implicitely trust the operator(s) of the blackhole(s)
  operators will etierh run their own of ignore the blackholes .

14

At the moment there is no clear procedure for any ISP to
follow to even
get a best guess as to whether an advertisement should be accepted or
not.

What about requiring that a route appear in an RIR database period?
Maybe that would be a good start. It's easy enough to do but virtually
no one seems to do it. We've seen how lengthy The CIDR Report's list of
unregistered (but nonetheless advertised) routes is -- why are these
advertisements being accepted?

This doesn't directly address hijacking, but it seems to me that there's
no reason to spend time looking for old, unused, potentially hijackable
address blocks if just about any ISP out there will accept your
announcements of blocks that aren't even allocated. (Note: I'm not
talking about IANA Reserved space.)