network failed, was re: Notification of RIPE Database changes
Dear RIPE Routing WG Please forgive me if this is a topic that has been closed by the WG. I was advised by a mentor to write to you. I am AL7-AFRINIC the technical and general contact for AS Number 37199 and IPV4 LIR for • 41.76.128.0/21 • 197.155.0.0/19 When I search the RIPE database (all) my details come up correctly (pasted below). This morning we experienced downtime but we managed to recover within a few hours due to a last minute warning issued to our upstream provider Cybersmart (original message pasted below bottom). From what I can gather I can hypothesise that our previous upstream provider Frogfoot, had created a route object in your database without our knowledge or authority. Subsequently they relinquished control of this object to their new upstream (AfricaINX in the email below) without our knowledge or authority. And subsequently AfricaINX deleted this object from your database without our authority or knowledge. And finally our new upstream created a route object in your database without our knowledge or authority. Yeah I am sorry it's a bit naive of me. :( I live to learn, please advise if it's a dumb question to request a policy consideration that you send LIR organisation and contacts some kind of notifications to general and billing contacts, even if only as notification if not the ability to suspend such actions as a delete request. Sincerely and humbly Alan inetnum: 41.76.128.0 - 41.76.135.255 netname: VANILLA descr: Future Perfect Corporation cc T/A Vanilla country: ZA admin-c: DUMY-RIPE tech-c: DUMY-RIPE org: ORG-FPCc1-AFRINIC status: ALLOCATED PA mnt-by: AFRINIC-HM-MNT mnt-lower: VANILLA-MNT notify: alan@vanilla.co.za notify: accounts@vanilla.co.za changed: unread@ripe.net 20000101 source: AFRINIC-GRS remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** organisation: ORG-FPCc1-AFRINIC org-name: Future Perfect Corporation cc T/A Vanilla org-type: LIR address: 125 Buitengracht St, #611 address: Cape Town 8018 e-mail: alan@vanilla.co.za e-mail: accounts@vanilla.co.za phone: +27214097997 fax-no: +27214097050 admin-c: AL7-AFRINIC tech-c: AL7-AFRINIC mnt-ref: AFRINIC-HM-MNT mnt-by: AFRINIC-HM-MNT notify: hostmaster@afrinic.net changed: hostmaster@afrinic.net 20100412 source: AFRINIC-GRS -----Original Message----- From: RIPE Database Administration local [mailto:unread@ripe.net] Sent: 11 June 2013 10:34 To: ripe Subject: Notification of RIPE Database changes This is to notify you of changes in RIPE Database or object authorisation failures. This message is auto-generated. Please DO NOT reply to this message. If you do not understand why we sent you this message, or for assistance or clarification please contact: RIPE Database Administration <ripe-dbm@ripe.net> Change requested from: - From-Host: 41.66.168.1 - Date/Time: Tue Jun 11 10:33:47 2013 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Some object(s) in RIPE Database that you either maintain or you are listed in as to-be-notified have been added, deleted or changed. --- OBJECT BELOW DELETED: route: 41.76.128.0/21 descr: Borwood via AS29606 origin: AS29606 mnt-by: BORWOOD-MNT mnt-by: RIPE-NCC-RPSL-MNT changed: paulo@borwood.net 20120508 source: RIPE ***Info: Customer request INC-36148 The RIPE Database is subject to Terms and Conditions: http://www.ripe.net/db/support/db-terms-conditions.pdf For assistance or clarification please contact: RIPE Database Administration <ripe-dbm@ripe.net> Generated by RIPE WHOIS Update version 1.66.3 on WHOIS2 Handled sync update (RIPE, 2013-06-11 10:33:47) % Information related to '41.66.128.0 - 41.66.191.255' inetnum: 41.66.128.0 - 41.66.191.255 netname: AFRICAINX-NET descr: AfricaINX country: ZA admin-c: EP1-AFRINIC tech-c: EP1-AFRINIC org: ORG-AINE1-AFRINIC status: ALLOCATED PA mnt-by: AFRINIC-HM-MNT mnt-lower: AFRINIC-HM-MNT source: AFRINIC # Filtered parent: 41.0.0.0 - 41.255.255.255 organisation: ORG-AINE1-AFRINIC org-name: Africa Independent Network Exchange (Pty) LTD (AfricaINX) org-type: LIR country: ZA address: PO Box 6458 address: Halfway House address: Midrand 1685 e-mail: erik@africainx.net e-mail: noc@africainx.net phone: +27 11 243 3000 fax-no: +27 11 507 5057 admin-c: EP1-AFRINIC tech-c: EP1-AFRINIC mnt-ref: AFRINIC-HM-MNT mnt-by: AFRINIC-HM-MNT source: AFRINIC # Filtered person: Erik Pretorius nic-hdl: EP1-AFRINIC address: Ground Floor, Bates House, Corner Howick address: & Treur Close, Waterfall Office Park address: Midrand 1685 address: South Africa e-mail: erik@africainx.net phone: +27112664000 org: ORG-EBS1-AFRINIC remarks: Network Engineer source: AFRINIC # Filtered
This morning we experienced downtime but we managed to recover within a few hours due to a last minute warning issued to our upstream provider Cybersmart (original message pasted below bottom).
From what I can gather I can hypothesise that our previous upstream provider Frogfoot, had created a route object in your database without our knowledge or authority. Subsequently they relinquished control of this object to their new upstream (AfricaINX in the email below) without our knowledge or authority. And subsequently AfricaINX deleted this object from your database without our authority or knowledge. And finally our new upstream created a route object in your database without our knowledge or authority.
[ aside from a side rant about rpki certificates ] has anyone at the ncc looked into this and can give us a post mortem? it is a bit scary. randy
On 2013-06-15, at 10:11, Randy Bush <randy@psg.com> wrote:
This morning we experienced downtime but we managed to recover within a few hours due to a last minute warning issued to our upstream provider Cybersmart (original message pasted below bottom).
From what I can gather I can hypothesise that our previous upstream provider Frogfoot, had created a route object in your database without our knowledge or authority. Subsequently they relinquished control of this object to their new upstream (AfricaINX in the email below) without our knowledge or authority. And subsequently AfricaINX deleted this object from your database without our authority or knowledge. And finally our new upstream created a route object in your database without our knowledge or authority.
[ aside from a side rant about rpki certificates ] has anyone at the ncc looked into this and can give us a post mortem? it is a bit scary.
I've noticed over the years that many people use RPSL quite badly. If I (AS 1000) have a customer (AS 2000) that is announcing 192.0.2.0/24, and I want to propagate that route to my transit providers, there are many transit providers that will insist on seeing a route: object for 192.0.2.0/24 with origin: 1000 and can do nothing with the origin: 2000 that is already there. There are others whose entire question about RPSL is "what is your as-set?" which in this example could contain both as1000 and as2000 without such nasty route/origin lies. Nobody seems to have heard of aut-num objects, or if they have, they have no interest in parsing export/import attributes. Which is a shame, since all anybody ought to have to know is your AS number. The end result, IRR-wide (if I can use "IRR" to mean anything these days) is that there are endless duplicate route objects with inaccurate origin attributes. After spending a few weeks trying to contact people to have them deleted from one registry, and then noticing that there are eleventy others that all contain variously mirrored or duplicated junk, I think people generally give up. It's all a horrible mess. If only people had read ripe-181 and descendants before ever trying to talk to auto-dbm, instead of relying upon the same oral tradition that also brought us "DNS over TCP is only for zone transfers" and "ICMP is a security risk and should be blocked everywhere". Generally (no warranty expressed or implied) the only thing you need to worry about is that the correct objects are present and protected from change by others with an appropriate maintainer. You hope that all other objects referring to the same routes are benign, in the sense that although they would potentially allow a bad thing to happen, at least they don't mess with the good thing that you want to happen. Joe
[ discussion about st00pidity omitted ]
Generally (no warranty expressed or implied) the only thing you need to worry about is that the correct objects are present and protected from change by others with an appropriate maintainer. You hope that all other objects referring to the same routes are benign, in the sense that although they would potentially allow a bad thing to happen, at least they don't mess with the good thing that you want to happen.
which is what seems to be what happened here, though i do not completely understand. was hoping someone could explain the sequence of events, and what alan should/could have done. randy
Randy Bush wrote:
[ discussion about st00pidity omitted ]
Generally (no warranty expressed or implied) the only thing you need to worry about is that the correct objects are present and protected from change by others with an appropriate maintainer. You hope that all other objects referring to the same routes are benign, in the sense that although they would potentially allow a bad thing to happen, at least they don't mess with the good thing that you want to happen.
which is what seems to be what happened here, though i do not completely understand. was hoping someone could explain the sequence of events, and what alan should/could have done.
randy
Randy, all, I already do have a response (and sort of explanation) from the NCC DB folks. I received it just before hopping on a plane to Asia. I'll dig it up soon and forward to the list. Sorry for the delay, Wilfried.
Folks, this is what I got back from the DBM folks. I think it does explain what happened, and "how". But at the same time it opens a new set of Q.s, in particular how to deal with the fact that no registry, at least as of now, has implemented "rpsl-dist". Wilfried. PS: on top of my journey to BKK, another reason for the delay in forwarding was double-checking that the original question was public already, as I initially read the copy to the DB-WG Chairs, and not on the Routing WG list. _____________________________________________________________________________ Dear Wilfried, Thank you for contacting us. It is possible to create a route object in the RIPeDatabase for an address space which is registered outside the RIPE Region. In order to create the route object you will need to pass the authentication of RIPE-NCC-RPSL-MNT which is a public maintainer. The authentication password for this maintainer is written in the remarks of the mntner object itself: % Information related to 'RIPE-NCC-RPSL-MNT' mntner: RIPE-NCC-RPSL-MNT descr: This maintainer may be used to create objects to represent descr: routing policy in the RIPE Database for number resources not descr: allocated or assigned from the RIPE NCC. admin-c: RD132-RIPE auth: MD5-PW # Filtered remarks: ******************************************************* remarks: * The password for this object is 'RPSL', without the * remarks: * quotes. Do NOT use this maintainer as 'mnt-by'. * remarks: ******************************************************* mnt-by: RIPE-DBM-MNT referral-by: RIPE-DBM-MNT source: RIPE # Filtered However please note that we do not control routing configuration and do not have an active role in the configuration of the routers and BGP setting being used. Entering Route object into the RIPE Database does not automatically mean those routes will be picked up by the providers/networks. Some networks filter and configure their routers automatically using the RIPE Database Internet Routing registry (IRR). The RIPE Database is authoritative only for the address space which is registered under the RIPE Region. If you want to see which Database is authoritative for a certain address space you can use the --resource option: $ whois --resource 41.76.128.0/21 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Information related to '41.76.128.0 - 41.76.135.255' inetnum: 41.76.128.0 - 41.76.135.255 netname: VANILLA descr: Future Perfect Corporation cc T/A Vanilla country: ZA admin-c: DUMY-RIPE tech-c: DUMY-RIPE org: ORG-FPCc1-AFRINIC status: ALLOCATED PA mnt-by: AFRINIC-HM-MNT mnt-lower: VANILLA-MNT notify: alan@vanilla.co.za notify: accounts@vanilla.co.za changed: unread@ripe.net 20000101 source: AFRINIC-GRS remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** organisation: ORG-FPCc1-AFRINIC org-name: Future Perfect Corporation cc T/A Vanilla org-type: LIR address: 125 Buitengracht St, #611 address: Cape Town 8018 e-mail: alan@vanilla.co.za e-mail: accounts@vanilla.co.za phone: +27214097997 fax-no: +27214097050 admin-c: AL7-AFRINIC tech-c: AL7-AFRINIC mnt-ref: AFRINIC-HM-MNT mnt-by: AFRINIC-HM-MNT notify: hostmaster@afrinic.net changed: hostmaster@afrinic.net 20100412 source: AFRINIC-GRS % Information related to '41.76.128.0/21AS29606' route: 41.76.128.0/21 descr: Borwood via AS29606 origin: AS29606 mnt-by: BORWOOD-MNT mnt-by: RIPE-NCC-RPSL-MNT changed: unread@ripe.net 20000101 source: RIPE-GRS remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** % This query was served by the RIPE Database Query Service version -- If you have any questions, please feel free to contact us. Best regards, Andrea Di Menna Customer Services RIPE NCC RIPE NCC Customer Satisfaction Survey ************************************* Take the RIPE NCC Survey 2013 and tell the RIPE NCC what you think! Participants will be entered into prize draws to win an iPad. https://www.ripe.net/survey2013 On Thu, 13 Jun 2013 14:16:09 +0200, <Woeber@CC.UniVie.ac.at> wrote:
Dear RIPE-DBM Team!
Please have a look at the mail exchange below, and in particular towards the end.
We would like to understand whether our assessment of the situation is correct and whether you can add anything relevant or helpful to that?
Best regrds, TIA, Wilfried.
Sander Steffann wrote:
Hi,
thanks for the forward!
Looking at the output for 41.76.128.0/21 in the RIPE DB and the AFRINIC DB it looks like the block was subject to transfer from RIPE to AFRINIC, when this new RIR was created.
There is no inetnum: entry in the RIPE DB for this address space, but it does exist in the AFRINIC's:
mnt-by: AFRINIC-HM-MNT mnt-lower: VANILLA-MNT notify: alan@vanilla.co.za notify: accounts@vanilla.co.za changed: unread@ripe.net 20000101
I also understand from 2nd-hand reports, that AFRINIC does *not* operate a Routing Registry.
Thus, the safeguards that we do have in place in our region, that a route object can only be created if and when both parties (address and AS# holders) supply the authorisation credentials.
So you feel that this should be dicussed publicly on the DB-WG mailing list?
Personally, I would like to ask for clarification by the NCC's DB group, what the bahaviour is - or shiuld be - when a route: object is created for which no corresponding inet[6]num entra exists.
Sounds like a plan :-)
Also ask why the NCC seems to have helped to create this object, as authorisation from RIPE-NCC-RPSL-MNT is necessary:
route: 41.76.128.0/21 descr: Borwood via AS29606 origin: AS29606 mnt-by: BORWOOD-MNT mnt-by: RIPE-NCC-RPSL-MNT changed: paulo@borwood.net 20120508 source: RIPE
Cheers, Sander
participants (4)
-
Alan Levin -
Joe Abley -
Randy Bush -
Wilfried Woeber