[routing-wg] AS43890

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 at 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 at 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:        ripe at netserv.ro.REMOVE 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: </ripe/mail/archives/routing-wg/attachments/20141117/7c1705aa/attachment.sig>