- db-wg - mailman.ripe.net

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

Re: setuid dbupdate
by Gabor Kiss 09 Dec '96

09 Dec '96

> I have not tested this code. Please let me know if it works. No need to > CC the whole db-wg mailing list since it is not really a design issue ... Sorry... Gabor

1 0

setuid dbupdate
by Gabor Kiss 06 Dec '96

06 Dec '96

Dear Ambrose, The ripe-dbase-2.0.4/README file writes: - perl has some build in checks for suid perl scripts. These are all taken care of, so dbupdate should not complain about not being able to do things because it is running suid or sgid. Have a look in the code for dbupdate to see what silly things one has to do to get around these checks ... kissg writes: This is not enough. ;-) Under Solaris 2.5, and with ... This is perl, version 5.003 with EMBED built under solaris at Sep 17 1996 16:40:19 + suidperl security patch I get: "Insecure dependency in open while running with -T switch at /usr/local/whois/lib/addkey.pl line 52." 52: if (open(OVERFLOWADD, ">>".$db[1].$OVERFLOWEXTENSION.$value)) { I tried at least six different tricks to avoid this message. No success. (Hardcoded direct setuid C wrapper is not included in the six.) Any suggestion? Gabor

2 1

None
by Paul Libauer 14 Nov '96

14 Nov '96

subscribe

1 0

Re: [RADB #2390] RADB Timezone
by sds＠jazzie.com 13 Nov '96

13 Nov '96

Gerald Winters suggests (see below) that this work group might be a good place to discuss the timezone used when calculating a proper date for the changed: field of RADB objects. Is there a valid rationale for the RADB's use of a local timezone rather than Universal Time? If not, can this work group make a recommendation (formally or otherwise) to the RADB suggesting Universal Time be used to calculate the date for this field? The other inter-registry consistency issues Gerald mentions are likely important too, but this one seems ... totally without controversy. Or am I missing something? -- Sean Shapira sds(a)jazzie.com +1 206 443 2028 Gerald A. Winters (gerald(a)merit.edu) > > Sean, > > Actually there are some good reasons to use universal > time. For example, we import the ripe registry and they > are not using EST as we are. So there is some conflict > there. > There has been talk of enforcing consistency among the > registries (ie, aut-num policy, maintainer registration, ...) > and the changed date (ie, time-stamping) will undoubably play > an important role. > I think the changed data is ignored to a certain extent because > humans supply the date and not the software. The software only > checks for dates in the future, I believe, but will accept dates > in the past. So the changed date is more like a hazy indicator > rather than a precise time stamp. You know the the real/exact > changed date is <= to the actual changed date. > The place to bring this point up is at the RIPE meetings > to the data base working group. > > --Gerald > > Sean Shapira writes: > >In response to a recent RADB update request I received: > >> WARNING: date in "changed" (961113) is in the future - changed to 961112 > > > >The trouble? I'm guessing auto-dbm(a)ra.net was using Eastern > >Standard Time; I was using Universal Time. It seems a window > >of vulnerability exists during which auto-dbm has an incorrect > >idea of the "one true date" ;-). > > > >Seriously, as the global route registration database of last > >resort, doesn't using Universal Time in the RADB make sense? > > > >-- > >Sean Shapira sds(a)jazzie.com +1 206 443 2028 > > Serving the Net since 1990. > > -- > Gerald A. Winters gerald(a)merit.edu > Merit Network, Inc. (313) 747-3522 (office) > 4251 Plymouth Road, Suite C. (313) 747-3745 (fax) > Ann Arbor, MI 48105-2785

2 1