Hi, On Sun, Nov 16, 2014 at 07:32:25PM -0800, Ronald F. Guilmette wrote: > Based upon the information I am currently looking at (see below) I now > believe that it was perhaps a mistake for myself, and possibly others, > to have become focused on the issue of insuring the correctness and/or > validity of route objects within the RIPE data base only in those cases > where the IP blocks in question are under the dominion of other (non-RIPE) > RiRs. > > It now seems certain to me that the absence of anything even remotely > approximating proper validation of RIPE route objects is not, in fact, > a problem which is limited to just inter-RiR situations. Apparently, > RIPE member LIRs can just as easily hijack the IP blocks of other > RIPE members as they can in the case of IP blocks belonging to parties > in other regions.
Well, there's two aspects to it:
- hijacking blocks when the upstream ISP builds a BGP prefix filter from
the RIPE IRR DB -> this can be done of out-of-region networks but not
for in-region networks (unless someone is careless with their password),
and something can be done about it by the RIPE NCC (with a mandate from
one of these working groups)
- hijacking blocks when the upstream ISP just accepts and forwards anything
the customer announces by BGP -> this must be stopped at the ISP, and
the RIPE NCC can't really do something about it. OTOH, the operator
community should apply peer pressure here - as in: "dear ISP, if you
continue to announce unfiltered prefixes from your customers, this is
violating our AUP and we'll shutdown *your* link to us".
> Also, RIPE-resident hijackers can just as easily
> place validating route objects for these hijacked RIPE-issued IP blocks
> into the RIPE DB as they can for any other hijacked blocks taken from
> any other region(s).
No... the RIPE DB prevents route: objects for RIPE (NCC-issued) networks
by checking the maintainer authentication for inetnum: and aut-num: - so
unless the address holder is careless ("pick a 5 character easily guessable
password" or "reference a well-known maintainer") it is much harder to do,
if not impossible.
Now, I hear what you're saying and I look at 188.229.1.0/24 and wonder
what has happened, and why "whois --list-versions" isn't showing me the
update/creation history for the /24 route...
Ah.
Now this is an interesting example of "history" in the RIPE database:
gert@moebius3:/home/gert$ whois3 --show-version 4 188.229.0.0/17
% Version 4 of object "188.229.0.0 - 188.229.127.255"
% This version was a UPDATE operation on 2011-09-07 20:15
% You can use "--list-versions" to get a list of versions for an object.
inetnum: 188.229.0.0 - 188.229.127.255
netname: RO-NETSERV-20090729
descr: Netserv Consult SRL
...
mnt-routes: NETSERV-MNT
so, that /17 had, at some point in time, mnt-routes: pointing to
NETSERV-MNT.
gert@moebius3:/home/gert$ whois3 --show-version 5 188.229.0.0/17
% Version 5 (current version) of object "188.229.0.0 - 188.229.127.255"
% This version was a UPDATE operation on 2014-10-27 15:06
% You can use "--list-versions" to get a list of versions for an object.
inetnum: 188.229.0.0 - 188.229.127.255
netname: IR-MCI-20090729
descr: Mobile Communication Company of Iran PLC
...
mnt-routes: MCCI-MNT
So, in October 2014, the entry was changed to "mnt-routes: MCCI-MNT",
which prevents creating of route: objects unless you have the proper
auth codes.
Now, looking at the route:
route: 188.229.1.0/24
descr: Netserv-Client
origin: AS43890
mnt-by: NETSERV-MNT
changed: [email protected] 20130820
source: RIPE
... it claims to have been created in the time between (changed: is not
authoritative, but in this case looks plausible).
Checking object versions 1-4, it seems that this netblock was originally
given to Netserv, and then either sold to Iran, or withdrawn by the NCC
and reallocated to Iran (the published transfer statistics would clarify
this), but when that happened, the route: objects were not removed -
so, even when that network was no longer with Netserv, their route:
objects were still there.
This should not happen, of course, but it's not a technical weakness in
the RIPE DB (*phew*) but human mistake.
MCCI should really, really clean up all route objects that cover parts
of their address space but point to other origin ASes.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
pgpx4wW91H9Gt.pgp
Description: PGP signature
