[anti-abuse-wg] Reporting Fraud

Ronald F Guilmette <rfg at tristatelogic.com>

> Hummm... OK.  I didn't realize things were that bad.

Unfortunately, as has been confirmed by others, they certainly are!

> So, ah, maybe the Right Place To Start would be for somebody (perhaps
> even this working group?) to propose at least some sort of a policy
> (e.g. on hijacked ASNs and/or address blocks) for RIPE's consideration

We do need a number of policies to help redress the balance on abuse.

A Working Group cannot propose a policy, a member has to propose
a policy.  I had been thinking of proposing several, as I made clear
in my report at the AAWG in Prague.  The limitations are time and my
inexperience (I have never worked through that process before), plus
I'm somewhat discouraged from doing it by the resistance I encounter
from RIPE NCC staff when pursuing these issues.  In other words, even
if there were such policies agreed through the PDP, it seems to me
possible that the NCC staff might find some way to ensure that the
policies as agreed do not end up having the effect that we want.

The other problem is the obvious Conflict of Interest.  Although the
policies I believe should be proposed, would gain considerable support
in this Working Group, there is no guarantee that the decision would
be allowed to be made in this Working Group.  Other Working Groups
have legitimate interests in the areas of concern (such as Address
Policy, Database, etc) and their members may be less supportive as
in some cases their existing freedoms (which are being abused by only
a small number of LIRs) would then need to be reined in for all LIRs.

The decision as to where each policy proposal is discussed and agreed,
is made by the Working-Group Chairs collective.  Brian Nisbet and I are
obviously members of that collective, but we have to overcome the hurdle
that no Policy proposal that impacts on what the RIPE NCC do, has ever
(as far as I can see) been put through the Policy Development Process
within the AAWG or its predecessor, the ASWG.  Additionally if I were
the actual proposer of a policy, I would be unable to contribute to
that (or any related) decision-making-process.  Which is why I'd be
a lot happier if other participants would consider making proposals.

> Short of traveling a long distance by plane and showing up physically to
> the next RIPE meeting, is there any way for me to find out why an ASN
> (AS50877) and also a non-trivial amount of IPv4 space (195.80.148.0/22)
> would have been assigned by RIPE staff to a company that, according to
> the RIPE whois records themselves, is domiciled in Latin America?

Well, WE have to travel long distances by plane every time there is a
RIPE meeting ;-)  But (a) you wouldn't be likely to get any meaningful
information by attending in person (the answer to "why" will doubtless
be that "a RIPE LIR submitted an application which appeared to comply
with the relevant policy and so the allocation was made")  And for the
record, policy decisions are only made in RIPE Working Groups, and not
at RIPE meetings.  The only decision-making part of a RIPE meeting such
as is coming up in Rome in November, would be the RIPE Members' meeting.
RIPE Members are limited to the LIRs, and not the likes of you or me.

> (Separate question:  Is there any way to obtain archived dumps of the
> RIPE whois data base, e.g. from April of this year, so that I might be
> able to check and see if the original whois for the AS & IP block also
> said "Belize", as I suspect it did?)

Have you been introduced to the RIPE Resource Explainer yet?
See: http://albatross.ripe.net/cgi-bin/rex.pl
It does not show the original WHOIS data (sadly) but it can be helpful.

We can be reasonably sure that the resource holder for 195.80.148.0/22
is not in Belize because the phone numbers in the WHOIS record are in
an invalid format for Belize.  (See: http://wtng.info/wtng-501-bz.html)
If they really were in Belize, they would know the local phone number
format and so even if they wanted to submit fake phone numbers, they
would probably get them in the correct format.  Incidentally, we see
that CIDR currently routing to Starnet, Moldova.  No surprise there.

But the BGP PATH downstream of Starnet (AS31252) is most unusual:
"31252 12968 40975 41665 30968 50877" which tells us that packets
are (allegedly) passing through routers announcing these networks:

AS31252  STARNET            MOLDOVA
AS12968  CROWLEY DATA       POLAND
AS40975  CHML WEB SERVICES  ROMANIA
AS41665  HOSTING.UA         UKRAINE
AS30968  INFOBOX.RU         RUSSIA
AS50877  INSTANTEXCHANGER   "BELIZE"

But what may well be an ICMP filter at Starnet prevents traceroutes.

I think what we are seeing here is an ASN simulator, similar in concept
to the traceroute simulators that have been used by the Russian Business
Network.  It is probably being used as part of a non-physical routing
technology, such as BGP-VPN.  If you go to route-views.routeviews.org,
log in, and issue "sh ip bgp regex 12968" (without the quotes, natch!)
Routeviews will show you all routes that have been contributed to
Routeviews which allegedly pass through AS12968.

It takes some time to get usable data from Routeviews' output but when
you do you will see that the upstreams for AS12968 are AS1299, AS2914,
AS3356, AS6939 and AS9002: there is no mention of AS31252 except for
routing to AS40975 et al, and for one other /24 (which is also suspect).
Now it is entirely possible for some Routeviews data to be misleading
(not through any fault of Routeviews, but anyone who understands BGP
will know what I'm referring to) and it's also possible for the above
to happen for legitimate reasons, so other checks were needed to make
certain that my results are meaningful: those checks have been done
and they passed: I'm not going to post details for obvious reasons.

Similarly, querying Routeviews for announcements transiting AS40975
tells us that AS40975 has just two upstreams: AS5606 and AS8751, but
for the single route that ends up at AS50877 it has an extra upstream
AS12968.  Its own IP ranges are not announced to AS12968 (and it has
no downstream customers)

For the record, upstreams of Starnet are:
[AS2905|AS3257|AS3267|AS3549|AS5459|AS6939|AS8218|AS13101|AS16150]

> Why would anyone bother to hijack an IP block or an ASN if RIPE
> will just issue you either of those things, willy nilly, no matter
> where you live?

The only advantages of hijacking a block in the RIPE service region
are (a) that you would then avoid having to pay for it, and (b) that
your conscience would be less likely to be troubled by the fact that
some LIR had taken your money for submitting (probably) exaggerated
information about your hardware etc to the RIPE NCC on your behalf.

-- 
Richard Cox
Co-Chair AAWG