January 1997 - db-wg - mailman.ripe.net

New Document available: RIPE-153
by RIPE NCC Document Annoucement Service 29 Jan '97

29 Jan '97

Revised RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Ref: ripe-153 Title: RIPE NCC Database Documentation Author: A. M. R. Magee Date: 28 Jan 1997 Format: PS=788414 TXT=137211 Obsoletes: Version 1.2 of the document. Obsoleted by: Updates: Updated by: See also: Short content description ------------------------- This document is an introduction to the use of the RIPE Network Management Database. Items marked with an "*" are still in production. Questions and comments should be sent to <ripe-dbm(a)ripe.net>. Accessing the RIPE document store --------------------------------- You can access the RIPE document store via the World Wide Web; ripe-153 is available at the following URL: http://www.ripe.net/docs/ripe-153.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The full filenames of the new documents on the FTP-server are: ripe/docs/ripe-153.ps for the PostScript version ripe/docs/ripe-153.txt for the plain text version Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to <mail-server(a)ripe.net> with "send HELP" in the body text.

1 0

Inverse Query Failures
by Daniel Karrenberg 17 Jan '97

17 Jan '97

I was asked to look into invers queries going wrong in order to determine which additional indices might be useful. I looked at 5245997 recent queries 6236 (0.11%) of which were reverse. Of these 1428 (24.72%) failed because no match could be found and 461 (7.39%) failed because either no attribute name was given or an attribute name which does not have an inverse index was given. Unfortunately no more details are logged about the latter type of failures. We will change that a.s.a.p. and report back if there are signigficant findings. I have looked at the data that was logged and could detect no clear trends pointing to the need for additional indices. Daniel

1 0

RE: Immediate - Date in Changed field
by Wilfried Woeber, UniVie/ACOnet 17 Jan '97

17 Jan '97

Hi DB-folks! On a slightly different aspect, and assuming that we change things anyway... How about running the RIPE-DB (and maybe gradually all the others :-) on a UTC basis, according to some recent suggestions? Just for a sneak preview on one of the small agenda items for the DB WG :-) Wilfried. ~~~~~~~~~~ Dear Database WG members, We have been requested to ease the restrictions on the date in the "changed" attribute to allow for dates with 4 digit years specifically those starting with "19" and eventually "20". For obvious reasons, we agree with this proposition. However, we also understand that some of you may have software which presumes the date has the yymmdd format. If anyone has a serious problem with this change, please notify me personally (orange(a)ripe.net) before the end of the week. If we don't hear any show stoppers before the end of the week, we will proceed. Thereafter, the following will be acceptable formats: 19yymmdd 20yymmdd (eventually) yymmdd Thanks for your ear, -- Carol Orange --------------------------------------------------------------------------------

7 6

Re: hierarchical route objects, part 1
by Schmitz＠RUS.Uni-Stuttgart.DE 16 Jan '97

16 Jan '97

Dear Curtis, you wrote: > > > Here is an example. The registries approve of the top level blocks, > > > that is the aggregates (or blocks that should be announced as > > > aggregates). Whoever the aggregate is allocated to creates the top > > > level route object and can delegate below that. For example, ANS has > > > 207.24/14. There were two route objects needed to handle multihomed > > > (a /22 and a /24) prefixes. The usual way a provider would delegate > > > would be to reference more than one maintainer in the route object > > > (the provider and the customer, and probably the other provider if the > > > route object had a unique origin AS). > > > > > This scheme sounds reasonable but it raises the question of coordination > > among different registries... > > I would not expect to see the same address space allocated by more > than one registry. All registries would have a top level 0/0 route > object which prevents registry of bogons. RIPE would have a hierarchy > under 0/0 and the RA would have a hierarchy tracking InterNIC assigned > addresses. I would not expect the two to overlap, therefore there is > no real coordination problem beyond initial setup or new blocks > allocated to a registry. > This is more difficult than it looks from the beginning. As an example we ourselves register all our objects (inetnum, routes, persons...) in RIPE database (because we are in Europe). However, among others we peer with MCI and MCI insists on having route objects in their registry in order to allow routing. If the route objects are secured by hierarchical authorisation in the RIPE database we would also like to have them secured in the MCI registry. Following the scheme above MCI would have to include inetnums (while it is a pure routing registry) *and* would have to generate top level route objects allowing specific access by us to our route objects (this is a very tiring job especially regarding "the swamp" 192.x). Of course, they could copy from RIPE database... (ask them why they don't...) I guess, this problem may only be resolved by the GRR (which is yet to come) From the ongoing disussion I conclude for myself (at the current state of the discussion) that we can not impose a strict security mechanism at the time being without breaking too many things. Maybe, I am too dumb to see a simple solution which might be just at hand... I will summarise the things said here on the mailing list for the routing wg session next week and try to think some more about it (I guess, Daniel was right from the start when he said that we should begin with a bare notification mechanism...) Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________

2 1

An AUP for the RIPE DB ?!
by Daniel Karrenberg 16 Jan '97

16 Jan '97

Another short discussion paper. As you see I'd like to keep this general issue separate from the immediate measures discussed in the other paper. Again comments are welcome. Daniel Some Toughts about an Acceptable Use Policy for the RIPE Database Scope This is a discussion paper intended to lay the groundwork for the development of a more explicit acceptable use policy (AUP) for the RIPE database. Motivation For the past six years we have been able to avoid the issue of codifying acceptable use of the RIPE database because the user community was limited. Conventions and peer pressure were sufficient to prevent abuse. This is changing rapidly. Therefore I believe we have to develop a written AUP and enforce it. Format As with any AUP is it difficult to anticipate any potential usage. It is even impractical to codify something for all usages that can be envisioned. In our case a good approach would be to list a number of common usages that are clearly acceptable, such as searching for contact points in case of operational problems or access by routing policy tools. Subsequently we can list a number of usages that are clearly not acceptable such as obtaining addresses for mass mailings or unauthorised changing of data. I think it will be rela- tively easy to obtain consensus about that. One can then state that any use which is comparable to one of those listed falls under the policy for the listed use. Any use not comparable at all will need to be determined by the database WG and added to the AUP. Enforcement If we have a written AUP and consensus that it should be enforced the NCC can get legal advice on how to best enforce it. However I would like to have the AUP defined first because otherwise thinking about enforcement tends to be less effective and also influences our goals, e.g. the desired AUP. Further Steps I'd like to see some discussion and resolution on two issues: Is an explicit AUP needed? and Is the format sug- gested above appropriate?

1 0

Preventing Abuse of Postal&Email Address Info
by Daniel Karrenberg 16 Jan '97

16 Jan '97

Dear colleagues, below you find a short discussion paper with concrete proposals to address some abuse of the RIPE DB which we start seeing. It is input for that point at the meeting next week. Comments welcome. Daniel Short Term Measures to Protect Postal and E-Mail Address Information in the RIPE Database Against Abuse Scope This is a discussion paper about immediate measures to pro- tect postal and e-mail address information stored in the RIPE database against abuse. Mass mailings are the kind of abuse we are focussing on. There is consensus that these activities clearly constitute abuse of the RIPE database. An general acceptable use policy is a separate issue that needs to be addresses separately. Current Situation The database can currently be accessed by WHOIS, WAIS and as FTPable files. A copyright notice appears at the top of the FTPable files: Copyright (c)1992/.../1997 by Daniel Karrenberg and TERENA Restricted rights. Except for agreed Internet operational purposes, no part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, without prior permission of the RIPE NCC on behalf of the copyright holders. Any use of this material to target advertising or similar activities are explicitly forbidden and will be prosecuted. The RIPE NCC requests to be notified of any such activities or suspicions thereof. The access methods most suitable to obtain mass mailing data are the FTP and WAIS access methods. New Trend During first six years of operation no significant abuses of the database have come to our attention. In the past few months however there have been at least two instances where addresses from the have been sold or otherwise re-dis- tributed to address mailings. The NCC has taken appropriate action in these cases. I believe that this is a significant trend and we have to take measures to prevent such abuse in the future. In the following paragraphs I will outline pos- sible measures to that end. Assert Copyright More Prominently Currently the database copyright is asserted only in the FTPable files. Therefore any user of data obtained via other services may claim not to be aware of the copyright. In past discussions I have argued against cluttering WHOIS output with copyright notices. In the light of developments I now recommend to insert a one line copyright notice at the top of each WHOIS response roughly like: % Copyright (c)1997, see http://www.ripe.net/.... for details I have not checked yet whether this is sufficient notice in terms of legal procedures. However a user can then no longer claim ignorance. A similar solution needs to be implemented for the WAIS service. Remove Person Objects from FTP Access Person objects should be removed from public FTP access. This means both removing the person.db file and the person objects from the ripe.db file. The main purpose of these files is to allow mirroring of the database and convenient local access for various purposes. The mirroring function- ality has to be maintained differently. See below for details. The convenience of other uses in my opinion does no longer justify the potential for abuse this convenient public access has. Of course individual access can be granted if the user has a valid reason and agrees not to further distribute. Restrict Access if Abuse is Suspected I would like the database WG to explicitly authorise the NCC to restrict access to the database if abuse is suspected. The restrictions I envisage are artificial exponential delays if query patterns suggest abuse and blocking access for individual users as an ultimate measure. Of course any such measures will be reported back to the database WG. Consequences for Mirror Sites All these measures have little effect if any mirror site does not implement them. Therefore I propose that mirror sites will have to agree formally to implement any restric- tions the RIPE NCC has to implement. Further the mirror sites will have to change the procedure to obtain the person information to a restricted method. Further Steps I encourage everyone to critically read the proposals above and give me feedback, especially on aspects not considered. I ask the database WG to endorse the measures proposed and to give guidance on how they should be published, i.e. does this need to be written up as a RIPE document or is it suf- ficient in the database WG minutes/archives.

1 0

Re: hierarchical route objects, part 1
by Schmitz＠RUS.Uni-Stuttgart.DE 16 Jan '97

16 Jan '97

Dear Curtis, dear David, you both wrote: > > > Your black hat example is also flawed. At the top of the heirachy can > > > be 0/0 registered to IANA and withdrawn (not announced). The > > > registries themselves can have top level objects below that. In order > > > to make any changes, you need to have been given authorization from a > > > higher level. You can then assign authorization to lower blocks to > > > other parties. > > > > This works for IP network objects since the registries need to add these > > objects manually anyway. > > > > This is not that obvious for 'route' objects. Are you proposing that the > > registries have to approve (manually) all the route objects that are > > in the route hierarchy directly below their own allocated space ? > > Tie the hierarchy to the inetnums. Continue to flog the InterNIC for > non-participation in the IRR. The maintainer of a database such as > the RADB that uses InterNIC as the number registry may have to take > InterNIC data (ftp) and load it into inetnum records. I wonder about the effort necessary to do this. Moreover, we should not forget about pure routing registries - they would be forced to include inetnums as well (and I wonder whether they are willing to do so) > > An inetnum references one or more maintainer (in mnt-by). To create a > route object, you must satisfy one of the criteria: > > 1. You must be in the maintainer field in a less specific route > object (used to create route objects for more specific prefixes; > hopefully these get aggregated somewhere ). > > 2. You must be in a maintainer for the exact inet-num and for the > AS that you are putting in the route object (used after the > initial top level route object is created). > > Once a top level route object is created, a more specific route object > can be created and the mnt-by field can reference more than one > maintainer. > > Here is an example. The registries approve of the top level blocks, > that is the aggregates (or blocks that should be announced as > aggregates). Whoever the aggregate is allocated to creates the top > level route object and can delegate below that. For example, ANS has > 207.24/14. There were two route objects needed to handle multihomed > (a /22 and a /24) prefixes. The usual way a provider would delegate > would be to reference more than one maintainer in the route object > (the provider and the customer, and probably the other provider if the > route object had a unique origin AS). > This scheme sounds reasonable but it raises the question of coordination among different registries... Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________

2 1

RIPE-26, DB-WG, Proposed Agenda, 2nd Draft
by Wilfried Woeber, UniVie/ACOnet 15 Jan '97

15 Jan '97

Dear all! This is the 2nd draft of the proposed agenda for the January 1997 DB-WG Meeting in Amsterdam. I forgot to include the proposed DB copyright item in the 1st draft, my apologies. There's a couple of additional minor changes. As usual any and all comments and input appreciated. See you in Amsterdam, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-26, January 1997, Amsterdam 2nd Draft, 8.1.1997 A. Administrative stuff (W. Woeber, chair) - volunteering of the scribe - WG-agenda bashing B. DB-SW status report by the RIPE NCC (DB-SW maintainers, RIPE-NCC) - recent changes - recent bug fixes and development (if any) - feedback and experience C. RIPE-DB copyright (D. Karrenberg, RIPE NCC) - proposal to include copyright line in whois output D. Report on DB evaluation by VUA - consistency - usage E. Reports (D. Kessens, ISI) - on RPSL - on 'ride' (registry data exchange format) F. Documentation (DB-SW maintainers, RIPE-NCC) - current status, progress, review, test-driving - availability G. New functionality, proposals, reports - IPv6 object proposal (D. Kessens, ISI) - hierarchical authorisation for route: obj (J. Schmitz, DFN NOC) (**note: this item might be discussed in the Routing-WG and consequently be moved to agenda item Y.) - short report on improving DB security and authentication (**to be confirmed, J. Schmitz, DFN NOC) - extension for inet-rtr: obj (tentatively, W.Woeber/E.J.Bos/et.al.) - extending the list of attributes that can be used in -i lookup? - improved url handling (in HTML interface) - handling of timestamps (changed:, different time-zones, UTC,...) - report on/review of the consolidated wish-list Y. General input from other WGs Z. AOB -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

4 4

Person-Objects with multiple adresses + phones
by Nacamar AS Guardian 15 Jan '97

15 Jan '97

Hello, there are a number of persons with multiple _entries_ in the RIPE-Database, because they have multiple _adresses_, and I think, this is not handled well with our current implementation. To make this more acceptable for such people, something like the following should be possible: >>> person: Thomas Peters remarks: -- #1 - Main office: address: Thomas Peters address: Nacamar Data Communications GmbH address: Frankfurter Strasse 141 address: D-63303 Dreieich address: Germany phone: +49 6103 9901 14 fax-no: +49 6103 9901 18 e-mail: info(a)nacamar.net remarks: -- #2 - South office: address: Thomas Peters address: Herd-Weg 8 address: D-69198 Schriesheim OT. Ursenbach address: Germany phone: +49 6220 9111 25 fax-no: +49 6220 9111 259 e-mail: peters(a)nacamar.net remarks: -- #3 ... nic-hdl: TP65-RIPE ... <<< This applies too for people working as tech-c for several companies. It should be possible for each address-block to have its own phone/fax/eMail with it. As I understand the operation of the database now, all phone-numbers etc. are collected together, so the relationship to the addresses are lost. Best Regards, HaJo Gurt ------------------------------------------------------------------- Nacamar Network Administration NACAMAR Data Communications guardian(a)nacamar.net Frankfurter Str. 135-141 D-63303 Dreieich +49 6103 9901 ?? Voice Germany +49 6103 9901 18 FAX gurt(a)nacamar.de -------------------------------------------------------------------

4 3

Re: again: hierarchical route objects
by Schmitz＠RUS.Uni-Stuttgart.DE 15 Jan '97

15 Jan '97

Dear all, was my last mail too long? I did not yet see any comments... (or is it that disgusting :-( I hope not ;-) Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________

1 0

Re: NIC Handle's postfix
by Steven Bakker 15 Jan '97

15 Jan '97

==> From: Suwat Panitkullawat <suwat(a)rs.thnic.net> ==> Wed, 15 Jan 1997 21:43:39 +0700 (GMT+7:00) > From instruction in RIPE's configuration file. There is a suggestion that > we should not use NIC handle's postfix differrent from the source name. > > Can someone explain me why? Are there any serious errors if I do so. Depends on your definition of "serious" :-) If you set up your own database, with source "SUWAT" for example, but you choose to keep the "RIPE" postfix for NIC handles, you might be able to register a record for yourself, with handle "SP-RIPE". However, there is already an "SP-RIPE" in the RIPE database, causing some confusion. The idea of a NIC handle is to have a unique key pointing to a person. Using the "source:" as the postfix helps you identify in which database the handle is registered and avoids conflicting registrations for the same key. To be fair it's also a bit of a kludge, but probably the only thing that will work until we have a truly global IRR. And may facilitate merging existing operational databases once a global IRR is there, avoiding NIC handle clashes across databases. Of course, the postfix trick only works as long as the "source:"'s are allocated in a unique way. Hope this helps, Steven

1 0

RIPE-26, DB-WG, Proposed Agenda, 3rd Draft
by Wilfried Woeber, UniVie/ACOnet 14 Jan '97

14 Jan '97

Dear all! This is the 3rd draft of the proposed agenda for the January 1997 DB-WG Meeting in Amsterdam. This one - takes care of minor changes and some re-sequencing, - tries to estimate the time needed per topic (if it's not agreed already, please confirm presentation times!) - has some modifications for item F. As usual any and all comments and input appreciated. See you in Amsterdam, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-26, January 1997, Amsterdam 3rd Draft, Jan. 13, 1997 A. Administrative stuff (W.Woeber, chair) 10min - volunteering of the scribe - WG-agenda bashing - handling of minutes and actions in the future? B. DB-SW status report by the RIPE NCC (DB-SW maintainers, RIPE-NCC) 10min - recent changes - recent bug fixes and development (if any) - feedback from the users (if any) C. Report on DB evaluation by VUA 20min - consistency - usage D. Reports (D.Kessens, ISI) 30min - on RPSL - on 'ride' (registry data exchange format) E. Documentation (DB-SW maintainers, RIPE-NCC) 10min - current status, progress, review, test-driving - availability F. New functionality, proposals, reports 40min - IPv6 object proposal (D.Kessens, ISI) - summary report on issues to improve DB security and authentication (J.Schmitz, DFN NOC) - extension for inet-rtr: obj (tentatively, W.Woeber/E.J.Bos/et.al.) - extending the list of attributes that can be used in -i lookup? - improved url handling (in HTML interface) - proposed/implemented changes in date format for changed: attribute - handling of timestamps (changed:, different time-zones, UTC,...) - multiple contact "body parts" for a person: object - report on/review of the consolidated wish-list G. General input from other WGs 10min - hierarchical authorisation for route: obj (from Routing WG) Y. RIPE Database AUP (D.Karrenberg, RIPE NCC) 10min - short term measures to prevent abuse - defining an AUP Z. AOB # - . - # -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

Re: Immediate - Date in Changed field
by Wilfried Woeber, UniVie/ACOnet 14 Jan '97

14 Jan '97

=>> =>> I definitely agree for the need for this. But the changed attribute is =>> inserted by the person who registers the object, not by the database =>> software, he has the full control over which timezone he uses and to =>> lie. =>> =>> May be what we really want is a timestamp field with the granularity =>> you suggest and in UTC zone, but inserted to the objects automatically =>> by the database software. I see a lot of value in this. =>> => I completely agree with you. This can only be done if the database software => sets the time stamp. I guess this also solves most of the race conditions => otherwise implied. = =This would most definitely be a significant improvement (but is a =different point than the "changed" field) I believe this is on the =the list of Open Issues to be reviewed next week. If not it will be =then. = =Greetings, = =-- Carol Carol, I'm aware of that. And yes, in principle (by definition) the submitter of an object has to care about the date field supplied. But! - first of all, the DB-SW checks the date supplied against a date "in the future" (or has done that?, I think) and, - if *no* date field is supplied int the update message, then the software supplies the local date. And this *can* make a diference, isn't it? Of course, solving that in a decent way is preferred. Otoh, if (as long as) we rely on the user, we might add an (optional?) offset +/-xx hours from GMT if "The Solution to Everything" takes another couple of month to implement. (We might end up with 42 for a solution anyway :-) Cheers and let's see next week, Wiflried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

Immediate - Date in Changed field
by Carol Orange 13 Jan '97

13 Jan '97

Dear Database WG members, We have been requested to ease the restrictions on the date in the "changed" attribute to allow for dates with 4 digit years specifically those starting with "19" and eventually "20". For obvious reasons, we agree with this proposition. However, we also understand that some of you may have software which presumes the date has the yymmdd format. If anyone has a serious problem with this change, please notify me personally (orange(a)ripe.net) before the end of the week. If we don't hear any show stoppers before the end of the week, we will proceed. Thereafter, the following will be acceptable formats: 19yymmdd 20yymmdd (eventually) yymmdd Thanks for your ear, -- Carol Orange

1 0

hierarchical route objects, part 1
by Schmitz＠RUS.Uni-Stuttgart.DE 11 Jan '97

11 Jan '97

Dear colleagues, regarding hierarchical authorization of route objects in the RIPE database: from what I have heard there is a general feeling that it is needed and the basic scheme to implement it should follow the lines: * The root of the authorization tree is an AS-object (aut-num object). If it contains a "mnt-lower" attribute it controls all route-objects which have this AS as origin. * Then for route-objects the same rules apply as for inetnum-objects with respect to IP subranges: If a route-object contains a "mnt-lower" attri- bute it controls all more specific route-objects immediately below. * The authorization is checked against - more or less specific route-objects, or existence of the route-object itself with same origin (differing origin rejected) - if no route-objects exist: which authorization is specified for the autnum-object referred to by the origin attribute (rejected if this authorisation is not met) - if not even an autnum-object exists no action is taken However: there is still a problem that route-objects are somehow logically linked to allocated address space. The question how to deal with this is still open - I continue on this in a separate mail. Yet, the three rules for route-objects described above are a kind of common denominator(*) and moreover a very reasonable approach (these rules are also independent of the address space allocation relation to route-objects). If there are no further denials I suggest to implement it that way. Regards Joachim (*) Yes, I know: When aiming for the common denominator, be prepared for the occasional division by zero. _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________

5 5

Re: hierarchical route objects, part 1
by Steven Bakker 10 Jan '97

10 Jan '97

==> From: Gabor Kiss <kissg(a)sztaki.hu> ==> Thu, 9 Jan 1997 11:28:52 +0100 CA> I disagree that this is a good idea. If I register the following route CA> object (which actually exists): CA> CA> route: 128.0.0.0/1 CA> descr: HALF-DEFAULT-ONE CA> origin: AS1800 CA> advisory: AS690 1:1800 2:1239 CA> mnt-by: MAINT-AS1800 CA> mnt-lower: MAINT-AS1800 CA> CA> nobody else can register any route objects. GK> This can be prevented by this object GK> route: 0.0.0.0/0 GK> descr: for authorisation purposes GK> origin: AS0 GK> mnt-lower: MAINT-INTERNIC GK> etc. GK> GK> Internic (or whatever else) may delegate maintainer rights as well GK> as allocates address ranges. That still doesn't help you if the 128.0.0.0/1 is already registered (which it is); I imagine the proposed auth scheme would look for the most specific enclosing route object, which is 128.0.0.0/1 and not 0.0.0.0/0 (for most routes nowadays anyway). Steven

2 1

again: hierarchical route objects
by Schmitz＠RUS.Uni-Stuttgart.DE 09 Jan '97

09 Jan '97

Dear all, this is quite some discussion (I really did not expect this). Obviously, I could have been doing some more thinking before writing my earlier mail... Now, I try to summarize some of the points. I think Havard made some good comments. He really had me reconsider the effect of a "mnt-lower" attribute in the aut-num object. Actually, "mnt-lower" makes perfect sense if some hierarchically lower object exists (which is valid for IP address ranges). From some logical point of view, aut-num objects may well be understood as being hierarchically higher than route objects. However, to create a route object in the database the current imple- mentation already demands a reference to an autnum object and a main- tainer object: route: [mandatory] [single] descr: [mandatory] [multiple] origin: [mandatory] [single] hole: [optional] [multiple] withdrawn: [optional] [single] comm-list: [optional] [multiple] advisory: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [mandatory] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] By the mandatory mnt-by attribute some authorisation is already needed (as specified in the maintainer object). Adding a mnt-lower attribute to the *aut-num* object does not change much, and raises the question what objects are actually hierarchically below it - these are not necessarily route objects. I guess, this is one of the reasons why several people feel that a closer relationship to allocated IP address space should be established. As the mnt-lower attribute in an aut-num object seemingly does not lead to additional hierarchical authorisation we arrive at the question what we want to achieve with hierarchical authorization of route objects. For me the rationale behind it are similar to inetnum objects: to exert control. If some origin AS routes an IP range, no other AS shall claim this range or subranges. However, we must ask ourselves how reasonable this approach is because we run into several problems here (Cengiz, Gabor, Steven, and earlier Curtis discussed this): - There must be some starting point for the authorization - otherwise anybody may create route objects of IP address ranges where none do yet exist. This seems to tie the route objects closely to allocated address space (which again leads to problems - as noted before - be- cause several registries are pure routing registries). Moreover, route objects may be created in one registry which are forbidden by authorisation in another. This really calls for "the GRR" (where pure routing registries might be regarded as less authoritative). I fear we do not have a solution for this problem today. - Multihoming will be impossible if authorization is based upon IP address ranges alone because in this case only one route object of one origin is allowed in the registry for each IP range. - Situations may arise where IP subranges must be routed by another AS than specified in an less specific route object. To restrict access to these subranges the "hole" attribute might be applicable. Subranges defined by "hole" could be excluded from the authorization as long as no route object exists which covers this subrange. I can imagine that this is complicated regarding implementation in the database software. - Handing over route objects from one maintainer to another will become difficult - up to now this is solved by allowing existence of several route objects for the same address space but of differing origin. This is a very convenient solution thinking of cases where filters for router configurations are built from route objects in the database. If two identical route objects of different origin exist this may allow a smooth switch over from one AS to another. With an authorisation scheme solely based upon IP address ranges as specified above this would no longer be possible. - Others? While with inetnum-objects the "mnt-lower" attribute leads to strong control there was a suggestion by Daniel that for route objects noti- fication may be sufficient. On the one hand (taking it to the extremes) this might lead to cases where an organisation controls an inetnum object but others control the route objects of the same address range (this may be reasonable but also a real competitive problem). On the other hand is this restriction needed because then at least multi- homing will probably become impossible? Anyway: obviously, checking hierarchical authorization with route objects is quite complex regard- less of the fact whether notification only or restrictive authorization is applied. This whole thing became longer than I first intended. It seems there is more in it than we all thought first ... however, some of the problems we have run into look similar to those of inetnum objects ... may I ask for additional comments? Any further suggestions, problems,... ? Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________

1 0

Re: hierarchical route objects, part 1
by Gabor Kiss 09 Jan '97

09 Jan '97

Dear Cengiz, > I disagree that this is a good idea. If I register the following route > object (which actually exists): > > route: 128.0.0.0/1 > descr: HALF-DEFAULT-ONE > origin: AS1800 > advisory: AS690 1:1800 2:1239 > mnt-by: MAINT-AS1800 > mnt-lower: MAINT-AS1800 > > nobody else can register any route objects. This can be prevented by this object route: 0.0.0.0/0 descr: for authorisation purposes origin: AS0 mnt-lower: MAINT-INTERNIC etc. Internic (or whatever else) may delegate maintainer rights as well as allocates address ranges. Gabor

2 1

Re: hierarchical route objects, part 1
by Havard.Eidnes＠runit.sintef.no 08 Jan '97

08 Jan '97

Hi, just a few quick comments to your proposal. > regarding hierarchical authorization of route objects in the > RIPE database: from what I have heard there is a general > feeling that it is needed and the basic scheme to implement it > should follow the lines: You say very little about the reasons and motivations for wanting the modified behaviour. I think that is important to state. I've made some guesses below -- correct them as appropriate. > * The root of the authorization tree is an AS-object (aut-num > object). If it contains a "mnt-lower" attribute it controls > all route-objects which have this AS as origin. Aren't the route objects with a given origin already controlled by the authorization specified in the aut-num object? (Sorry, it's been a while since I twiddled "my" route objects, so I'm a bit rusty on this now.) If I'm in error here and this is modified behaviour, what would the motivation be for it? > * Then for route-objects the same rules apply as for > inetnum-objects with respect to IP subranges: If a > route-object contains a "mnt-lower" attribute it controls > all more specific route-objects immediately below. The motivation seems to be to have the option of controlling the use of the given address space covered, e.g. to require intervention by the maintainer/"owner" of the address space should a customer want to leave and take the address space within this address block with him, or to prevent such a move. (?) Other than that I think your suggestions make sense. - Håvard

1 0

RIPE-26, DB-WG, Proposed Agenda, 1st Draft
by Wilfried Woeber, UniVie/ACOnet 07 Jan '97

07 Jan '97

Dear all! This is the initial draft of a proposed agenda for the January'97 DB-WG Meeting. As usual any and all comments and input appreciated. Best regards, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Database Working Group Proposed Agenda for the meeting during RIPE-26, 1st Draft, 7.1.1997 A. Administrative stuff - volunteering of the scribe - WG-agenda bashing B. DB-SW status report by the RIPE NCC - recent changes, - recent bug fixes and development (if any) - feedback and experience C. Report on DB usage evaluation by VUA D. Reports by D. Kessens, ISI - on RPSL - on 'ride' (registry data exchange format) E. Documentation - current status, progress, review, test-driving - availability F. New functionality - IPv6 object proposal (D. Kessens, ISI) - hierarchical authorisation for route: obj (J. Schmitz, DFN NOC) - extension for inet-rtr: obj (tentatively, W.Woeber/E.J.Bos/et.al.) - extending the list of attributes that can be used in -i lookup? - handling of timestamps (changed:, different time-zones,...) - things on the consolidated wish-list - improved url handling (in HTML interface) Y. General input from other WGs Z. AOB -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0