- db-wg - mailman.ripe.net

Mirroring of LEVEL3 database
by Koepp, Karsten 12 Mar '03

12 Mar '03

Hello around, does anyone besides me consider the Level (3) IRR database useful to be mirrored? I can find the Level(3) data on whois.ra.net but I would like to continue using whois.ripe.net. I understand the db admins position but I consider this source valuable. I have no statistics on the number of objects - I just happen to meet source LEVEL3 now and then. Karsten > Dear Karsten.Koepp, > > Regarding you question about the RIPE NCC mirroring the LEVEL > 3 database, > we currently have no plans on doing that as we were not requested by > LEVEL 3 to carry a mirror of their data. > > Our requirements for mirroring are: > 1. The source is a public IRR > 2. It should have considerable size > 3. It should be useful for the users in the RIPE region > > We don't seek out databases to mirror, although if a number > of our users > think that it can be useful we can ask permission for that. > > Best Regards, > Tiago Antao > ---------------------------- > RIPE Database Administration >

2 1

Proposed change 2003.1: notification for more-specific
by Shane Kerr 10 Mar '03

10 Mar '03

Colleagues, This is one of a number of proposed changes to the way the RIPE Database works. These are changes that are intended to make the database work more consistently, as well as provide an increased level of security and control to users. Please have a look, and discuss it here. [2003.1] Notification on more-specific object creation authorisation -------------------------------------------------------------------- Change: When the creation of an object requires authorisation by a less-specific object, normal mntner notification will apply; "upd-to:" is notified of failure, and "mnt-nfy:" is notified of success. Where there are multiple maintainers, only one is needed to successfully authorise the creation, but all the maintainers in the list will be notified. For example: inetnum: 192.168.101.0 - 192.168.101.255 . . . mnt-by: EXAMPLE-MNT mnt-lower: ANOTHER-MNT mnt-lower: YET-ANOTHER-MNT If the successful creation of the more specific inetnum: inetnum: 192.168.201.0 - 192.168.201.255 . . . mnt-by: SOME-MNT Is authorised by YET-ANOTHER-MNT in the less specific inetnum, notifications will be sent to the "mnt-nfy:" listed in both ANOTHER-MNT and YET-ANOTHER-MNT. Motivation: This is useful for two cases. The first is so that the maintainer of an object will be notified when unauthorised attempts to create objects occur and will receive confirmation when objects are successfully created. The second is for cases where there are multiple maintainers in a position to authorise a creation (as in the example above). The maintainers that did not specificially authorise the creation are still notified (this is how notification for updates works today). -- Shane Kerr RIPE NCC

4 5

Proposed change 2003.3: "reclaim:"-like functionality
by Shane Kerr 10 Mar '03

10 Mar '03

Colleagues, This is one of a number of proposed changes to the way the RIPE Database works. These are changes that are intended to make the database work more consistently, as well as provide an increased level of security and control to users. Please have a look, and discuss it here. [2003.3] Implementation of "reclaim:"-like functionality -------------------------------------------------------- Proposal: Any maintainer that would have been able to authorise the creation of an object can authorise the deletion of the same object. If creation of an object requires authorisation from multiple maintainers (e.g. route objects that require authorisation from an aut-num and an inetnum), then any of those maintainers may authorise the deletion. Motivation: The maintainer of an object is responsible for insuring that the data in the object is accurate. For hierarchical objects the maintainer can delegate responsibility for a subset. However, under the current implementation, there is no way for the maintainer to delete objects created and delegated to maintainers who should not or will not have access to the resources represented by these objects any more. For example, if the holder of portable address space changes ISP, then the address space will be advertised from a different AS. This means that the old route object is invalid and should be deleted. However, if the old ISP maintains the object, then the holder of the space has no way to delete the old object. This old route object will prevent the creation of a new route object that represents the new arrangement. The "reclaim:" attribute defined in RPSS allows for very similar functionality, but it may not be added to space that already has objects. This means that any existing more-specific objects cannot be deleted by the maintainers of the less-specific objects. For the case of old objects - the ones most likely to need such deletion - this means that the "reclaim:" attribute does not help. The "reclaim:" attribute also has a different syntax, depending on the specific object type that it is present in. This complicates parsing of objects. -- Shane Kerr RIPE NCC

3 3

Another Proposal: Sort of generated Authorized-by Attribute + some PGP stuff
by Ulrich Kiermayr 04 Mar '03

04 Mar '03

Hi List, Since Shane has posted some proposals for the RIPE-DB, I have another one: For Updates which have been authorized by someone using strong encryption it would be nice to reflect the key that has been used in the object. this is similar to the changed: attribute but should be generated by the robot and not filled in by the user. Why? At the moment there is no way to tell that data within the Database is authentic in a way that it was really put in by the person who is in the object (pls. correct me if I am wrong), and the mnt-* just prevents you from stealing an object and not from giving it away to pretend something. Usually this is not bad, but related to some irt-stuff it can give the people the opportunity to pretend to be someone else. If the authorizing key was reflected in the object, one can check if who sent the update.... Something else related to PGP (and discussed with wilfried a while ago): it would be really nice to be able to link key-certs and persons/roles together other than by using remarks.... (as we do it now). lG uk -- ------------------------------------------------------------------------ Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network Security Universitaetsstrasse 7, 1010 Wien, Austria ------------------------------------------------------------------------ eMail: ulrich.kiermayr(a)univie.ac.at Tel: (+43 1) 4277 / 14104 Hotline: security.zid(a)univie.ac.at Fax: (+43 1) 4277 / 9140 ------------------------------------------------------------------------ GPG Key fingerprint = BF0D 5749 4DC1 ED74 AB67 7180 105F 491D A8D7 64D8

1 0

Proposed change 2003.4: "mnt-lower:" on set objects
by Shane Kerr 04 Mar '03

04 Mar '03

Colleagues, This is one of a number of proposed changes to the way the RIPE Database works. These are changes that are intended to make the database work more consistently, as well as provide an increased level of security and control to users. Please have a look, and discuss it here. [2003.4] Addition of "mnt-lower:" to set objects ------------------------------------------------ Change: The "mnt-lower:" attribute will be optional for all set object types, which are as-set, filter-set, peering-set, route-set, and rtr-set. The "mnt-lower:" must authorise creation when hierarchical names are used. If it is not present, "mnt-by:" must authorise the creation. Motivation: The set objects in RPSL allow hierarchical names. The rules for authorising creation of such an object is documented in RPSS, and specifies that when an AS is used in the name, "mnt-lower:" on the aut-num object may authorise the creation, otherwise "mnt-by:" of the aut-num is used. In this case: as-set: AS1:AS-foo If AS1 had a "mnt-lower:" attribute, the maintainer listed there would have to authenticate the creation, otherwise the "mnt-by:" of AS1 would be used. This allows the administrator of an aut-num to delegate authority to create sets to maintainers without having to allow them to modify the aut-num itself. This functionality is not present within the set classes themselves. For example: as-set: AS1:AS-Foo:AS-Bar If AS1:AS-Foo object is allowed to have the "mnt-lower:" attribute, a maintainer that can create AS1:AS-Foo:AS-Bar but not modify AS1:AS-Foo can be used. -- Shane Kerr RIPE NCC

1 0

Proposed change 2003.2: removal of cross notifications
by Shane Kerr 04 Mar '03

04 Mar '03

Colleagues, This is one of a number of proposed changes to the way the RIPE Database works. These are changes that are intended to make the database work more consistently, as well as provide an increased level of security and control to users. Please have a look, and discuss it here. [2003.2] Removal of cross notifications in the routing registry --------------------------------------------------------------- Proposal: Deprecate cross notifications. This means removing "cross-mnt:" and "cross-nfy:" attributes from aut-num or route objects with them (150 and 555 of each, respectively). Motivation: Currently cross notifications provide a redundant facility now fully implemented by RPSL authorisation. Also, current implementation sends notifications to every possible overlapping route (-L + -M), which is not very consistent with RPSL hierarchical authorisation scheme. -- Shane Kerr RIPE NCC

1 0

Proposed change 2003.0: default to protected inetnum/inet6num/domain
by Shane Kerr 04 Mar '03

04 Mar '03

Colleagues, This is one of a number of proposed changes to the way the RIPE Database works. These are changes that are intended to make the database work more consistently, as well as provide an increased level of security and control to users. Please have a look, and discuss it here. [2003.0] Default to protected for inetnum, inet6num, and domain objects ----------------------------------------------------------------------- Change: All hierarchical object types will now default to requiring authorisation for more-specific object creation. Motivation: In RPSS, objects use "mnt-lower:" to specify a maintainer which has the ability to authorise the creation more-specific objects. If a "mnt-lower:" attribute is not present, then the "mnt-by:" of the less-specific object is used. For example: route: 192.168.100.0/24 origin: AS1 mnt-by: EXAMPLE-MNT mnt-lower: ANOTHER-MNT . . . Authorisation for creation of a more-specific route must be given by ANOTHER-MNT. inetnum: 192.168.200.0/24 origin: AS1 mnt-by: EXAMPLE-MNT . . . Authorisation for creation of a more-specific route must be given by EXAMPLE-MNT (in the absence of an exact match or less specific route object). For object types not defined in RPSS, the current behaviour is as defined in RIPE-181. This includes inetnum, inet6num, and domain objects. In RIPE-181 if no "mnt-lower:" attribute is present, then requests to create more-specific objects require no authorisation from the less-specific inetnum. The proposal is to bring this into line with the new default. For example: inetnum: 192.168.101.0 - 192.168.101.255 mnt-by: EXAMPLE-MNT mnt-lower: ANOTHER-MNT . . . Authorisation for creation of a more-specific inetnum must be given by ANOTHER-MNT. inetnum: 192.168.201.0 - 192.168.201.255 mnt-by: EXAMPLE-MNT . . . Authorisation for creation of a more-specific inetnum does NOT currently require authorisation by EXAMPLE-MNT. The proposed change would require authorisation by EXAMPLE-MNT. -- Shane Kerr RIPE NCC

1 0

RIPE NCC network affected by the DDoS attack
by Andrei Robachevsky 27 Feb '03

27 Feb '03

Dear Colleagues, Starting from 14:00 UTC today, 27 February, RIPE NCC network suffered a large DDoS attack. It was a distributed ICMP echo attack. The attack caused various congestion related problems for the RIPE NCC's network, to the extent that our BGP peering sessions were affected, and non-ICMP traffic was being randomly dropped. The attack was successfully mitigated with cooperation of our peer networks at AMS-IX. Network condition returned back to normal at 16:30 UTC. As a result some of our services, including www.ripe.net (web), whois.ripe.net (RIPE Database), ns.ripe.net (DNS) and ftp.ripe.net (FTP) were not accessible during this timeframe. Now all services are back to normal. Regards, Andrei Robachevsky CTO, RIPE NCC

1 0

route aggregation and RFC2725
by Frank Bohnsack 18 Feb '03

18 Feb '03

Dear colleagues, we have three side by side "assigned PI" inetnum blocks 193.17.60.0/24, 193.17.61.0/24 and 193.17.62.0/23. To reduce routing table space we want to create only one aggegated route for these blocks instead of three seperated. But the authentication process of RFC2725 does checks exact or less specific routes or inetnums only and will go wrong in this case. My question: Is this a known/proposed "feature" or should we think about a modification of the authentication process of RFC2725 to support this case? Thanks Frank fb@OC3 20> whoisRIP -r -M 193.17.60.0/22 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 193.17.62.0 - 193.17.63.255 netname: HOFMANN-LAN descr: Enno Hofmann descr: D-58089 Hagen country: DE admin-c: EHO-RIPE tech-c: EHO-RIPE tech-c: EHO-RIPE rev-srv: auth04.ns.de.uu.net rev-srv: auth54.ns.de.uu.net status: ASSIGNED PI notify: eho(a)de.uu.net mnt-by: UUNETDE-I mnt-by: HOFMANN-MNT mnt-lower: HOFMANN-MNT changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921216 changed: eho(a)de.uu.net 19991008 changed: eho(a)de.uu.net 20020621 source: RIPE inetnum: 193.17.61.0 - 193.17.61.255 netname: GSD-HH descr: GSD Berlin descr: - Geschaeftsstelle Hamburg - descr: D-W-2000 Hamburg 53 country: DE admin-c: JA1966-RIPE tech-c: RG2666-RIPE tech-c: MF3386-RIPE mnt-by: UUNETDE-I status: ASSIGNED PI changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921015 changed: hostmaster(a)de.uu.net 20020205 changed: eho(a)de.uu.net 20020807 source: RIPE inetnum: 193.17.60.0 - 193.17.60.255 netname: GSD-BLN descr: GSD descr: D-10785 Berlin country: DE admin-c: JL15-RIPE tech-c: TM2554-RIPE status: ASSIGNED PI mnt-by: UUNETDE-I changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921015 changed: eho(a)de.uu.net 20020807 source: RIPE route: 193.17.62.0/23 descr: HOFMANN-LAN origin: AS702 member-of: RS-UUNETEUDE mnt-by: UUNET-MNT changed: eho(a)de.uu.net 20020611 source: RIPE fb@OC3 21> whoisRIP -r -l 193.17.60.0/22 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 193.16.0.0 - 193.31.255.255 netname: EU-ZZ-930921 descr: block for PI assignments maintained by RIPE NCC former address space of de.zz country: EU admin-c: CREW-RIPE tech-c: CREW-RIPE status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: marten(a)ripe.net 19930921 changed: hostmaster(a)ripe.net 20020621 source: RIPE

2 1

route aggregation and RFC2725
by Frank Bohnsack 18 Feb '03

18 Feb '03

Dear colleagues, we have three side by side "assigned PI" inetnum blocks 193.17.60.0/24, 193.17.61.0/24 and 193.17.62.0/23. To reduce routing table space we want to create only one aggegated route for these blocks instead of three seperated. But the authentication process of RFC2725 does checks exact or less specific routes or inetnums only and will go wrong in this case. My question: Is this a known/proposed "feature" or should we think about a modification of the authentication process of RFC2725 to support this case? Thanks Frank fb@OC3 20> whoisRIP -r -M 193.17.60.0/22 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 193.17.62.0 - 193.17.63.255 netname: HOFMANN-LAN descr: Enno Hofmann descr: D-58089 Hagen country: DE admin-c: EHO-RIPE tech-c: EHO-RIPE tech-c: EHO-RIPE rev-srv: auth04.ns.de.uu.net rev-srv: auth54.ns.de.uu.net status: ASSIGNED PI notify: eho(a)de.uu.net mnt-by: UUNETDE-I mnt-by: HOFMANN-MNT mnt-lower: HOFMANN-MNT changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921216 changed: eho(a)de.uu.net 19991008 changed: eho(a)de.uu.net 20020621 source: RIPE inetnum: 193.17.61.0 - 193.17.61.255 netname: GSD-HH descr: GSD Berlin descr: - Geschaeftsstelle Hamburg - descr: D-W-2000 Hamburg 53 country: DE admin-c: JA1966-RIPE tech-c: RG2666-RIPE tech-c: MF3386-RIPE mnt-by: UUNETDE-I status: ASSIGNED PI changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921015 changed: hostmaster(a)de.uu.net 20020205 changed: eho(a)de.uu.net 20020807 source: RIPE inetnum: 193.17.60.0 - 193.17.60.255 netname: GSD-BLN descr: GSD descr: D-10785 Berlin country: DE admin-c: JL15-RIPE tech-c: TM2554-RIPE status: ASSIGNED PI mnt-by: UUNETDE-I changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921015 changed: eho(a)de.uu.net 20020807 source: RIPE route: 193.17.62.0/23 descr: HOFMANN-LAN origin: AS702 member-of: RS-UUNETEUDE mnt-by: UUNET-MNT changed: eho(a)de.uu.net 20020611 source: RIPE fb@OC3 21> whoisRIP -r -l 193.17.60.0/22 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 193.16.0.0 - 193.31.255.255 netname: EU-ZZ-930921 descr: block for PI assignments maintained by RIPE NCC former address space of de.zz country: EU admin-c: CREW-RIPE tech-c: CREW-RIPE status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: marten(a)ripe.net 19930921 changed: hostmaster(a)ripe.net 20020621 source: RIPE

1 0