- db-wg - mailman.ripe.net

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

Announcement RIPE NCC RRC Training Course
by RIPE NCC Training 17 Feb '03

17 Feb '03

Dear Colleagues, [apologies for duplicate postings] As a new service to its members the RIPE NCC offers the "Routing Registry Training Course". The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using (RPSL) Routing Policy Specification Language and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course. It will: - NOT teach the basics of routing - NOT describe how to receive Internet resources from the RIPE NCC not describe to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. Hostmasters) . It is assumed that all attendees will be familiar with Border Gateway Protocol routing and with the RIPE Database (i.e. creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with the following: - A working Ethernet card, - Three meters of Ethernet cable, - A secure connection client, - A web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. The Routing Registry Training Course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the Routing Registry Training Course can be found at: http://www.ripe.net/training/rr/ REGISTRATION: You can register for a Routing Registry Training Course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to <training(a)ripe.net> . In order to register for a Routing Registry Training Course you must be an employee of an LIR and either: - be an LIR contact - be confirmed by an LIR contact LIR contacts are those employees of an LIR who are registered with RIPE NCC as authoritative contact persons. It is expected that most of those interested in the Routing Registry Training Course will not be an authoritative contact person for their LIR, and therefore will be, refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to <training(a)ripe.net>. Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, The RIPE NCC Training Team ----------------------------------------------------------------------- COURSE DATES AND VENUES ======================== Date: Monday 14 April 2003 Time: 0900 - 1700 Location: Amsterdam, The Netherlands AND: Date: Friday 20 June 2003 Time: 0900 - 1700 Location: Kiev, Ukraine ------------------------------------------------------------------------ REGISTRATION FORM ================= %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

syncupdates source code release
by RIPE Database Administration 11 Feb '03

11 Feb '03

[apologies for duplicate messages] Dear Colleagues, We are happy to announce the syncupdates source code release. The release contains: - syncupdates, infrastructure facility to update the Whois server online and synchronously. - webupdates, web based graphical interface for updating objects. The software is available at ftp://ftp.ripe.net/ripe/dbase/software/syncupdates-1.0.1.tar.gz Please contact dbtools(a)ripe.net for any comments. Best regards, -- Can Bican DB Group RIPE NCC

1 0

hint: IPv6 whois presentation in IPv6 WG (only)
by Wilfried Woeber, UniVie/ACOnet 28 Jan '03

28 Jan '03

Dear DB-WG, to avoid duplicating effort in various WGs, there is a presentation about the IPv6 capabilities of the NCC's whois service scheduled in the IPv6 WG _only_. We do _not_ plan to repeat that in DB-WG - although I'd like to add a minor item to the DB agenda to _start_ a "review" activity on IPv6 facilities for the whole machinery. Bottom line: if you are interested in v6 whois - pls. go to IPv6; if you are interested in v6 DB stuff in general - stop by at DB :-) Wilfried. ______________________________________________________________________ Date: Tue, 28 Jan 2003 12:58:33 +0100 From: Andrei Robachevsky <andrei(a)ripe.net> [ ... ] Dear Wilfried, My own opinion: [ ... ] - ipv6 in the DB. Shane is making a presentation on ipv6 whois server (the proxy we put online) This can be replicated at the DB meeting. [ ... ] Thanks, Andrei -- Andrei Robachevsky CTO, RIPE NCC --------------------------------------------------------------------------------

1 0

IPV6 Whois
by DB-News 27 Jan '03

27 Jan '03

[apologies for duplicate messages] Dear Colleagues, We are happy to announce the availability of RIPE Whois servers on IPv6 network. It is now possible to query whois.ripe.net and test-whois.ripe.net from an IPv6 host, using an IPv6 enabled whois client. If your system doesn't already have one, you can find the latest RIPE Whois client at: ftp://ftp.ripe.net/ripe/tools/ripe-whois-latest.tar.gz You can read the full anouncement at: http://www.ripe.net/ripencc/pub-services/db/whois-ipv6.html Best regards, -- Can Bican Database Group RIPE NCC

3 3