- routing-wg - mailman.ripe.net

proposed way to proceed...
by Schmitz＠RUS.Uni-Stuttgart.DE 14 Feb '97

14 Feb '97

Dear colleagues, there is work to do and I would appreciate your input very much. We have several actions open from our last wg session at Amsterdam and I would like to continue on them. This week I circulated the 1st draft minutes of our session on the mailing list. For reference, it is now also available on the RIPE NCC webserver. Moreover, I have prepared several new pages for our wg and they are also now available on the RIPE NCC webserver (start out at http://www.ripe.net/wg/routing/index.html) I would like to focus the discussion on two topics: * hierarchical authorisation for route objects - we should first find some consensus on immediate solutions possible as they became apparent from our last wg session; I will send an additional mail immediately following this one - then there are lots of nice problems to solve in general and we need more input on them - for reference read/attack/tear apart/abuse the compilation at http://www.ripe.net/wg/routing/haro-d.html - this thing is completely draft and comments are a *must* - Wilfried Woeber as chair of the database wg asked that contributions should not only be sent to the routing wg mailing list but please be copied to the database wg mailing list as well (because there are also lots of issues regarding the implementation in the database) * future tool development project - this action is open too long for my feeling (and partly due to me because I did not pursue it, sorry). I will prepare some call for ideas and present it on the mailing list in the near future. So, let's continue (and for those who are not yet with us: let's get going ;-) 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

1st draft minutes of Routing WG session at RIPE 26
by Schmitz＠RUS.Uni-Stuttgart.DE 11 Feb '97

11 Feb '97

Here are the 1st draft minutes of the Routing WG session at RIPE 26. Thanks to Chris Fletcher for keeping track of the major points during the session! Maybe, some of the URLs need adaptation as the presentation become available on the RIPE FTP-Server. Comments, input, and improvements to the draft minutes are welcome (but please keep discussion of topics separate from the minutes themselves, thank you) Joachim ----- -- 1. D R A F T -- RIPE 26, Amsterdam Routing Working Group Report of Meeting, 20th January 1997 -- 1. D R A F T -- A. Administrative Issues Joachim Schmitz, Chairman, presided and welcomed people to the meeting. There were 95 attenders. Chris Fletcher took minutes. The draft agenda circulated in the previous week was agreed. A copy is displayed at the end of this summary. There were no additions or changes to the minutes of the RIPE 25 Routing WG session. A short overview of open actions was given. Action 22.10 on Joachim Schmitz To trigger the discussion on the mailing list of the Routing WG, which focus to choose for a future tool development project and to come to consensus on it is still open. It will be pursued after the current meeting. Action 24.4 on Joachim Schmitz To investigate the status of the CIDR FAQ and see whether additions are needed, probably by triggering a discussion on the mailing list According to the result of the investigation no official additions by the Routing WG are needed. Therefore, the WG agreed to close this action. However, it was felt that further distribution of knowledge about CIDR is needed and therefore a pointer to the CIDR FAQ location should be included on the Routing WG pages at the RIPE NCC weg server. New Action 26.R1 on the RIPE NCC To add a link on the RIPE web server from the Routing WG pages to the CIDR FAQ location B. Hierarchical authorisation for route objects (J.Schmitz) One major topic of this session was the discussion on hierarchical authorisation for route objects. There was already some discussion on the mailing list regarding various issues involved. To continue with the discussion J.Schmitz compiled the current state in a presentation. The transparencies of the presentation are available at ftp://ftp.ripe.net/ripe/presentations/ripe-m26-jschmitz-haro.html Based upon this several of the open issues were discussed in the WG session. Last year improvements to authorisation during the interaction with the database were discussed. One of the elements is *hierarchical* authorisation and the first implementations of it were done for inetnum objects and domains. Up to now there is no hierarchical authorization scheme for route objects. Following the same reasoning as for inetnum objects - to protect the objects against unauthorized changes - there definitely is a need to apply hierarchical authorisation also to route objects; route objects in the RIPE database are already used by some ISPs to build configuration elements for their routers. Obviously, this calls for stronger protection. The route objects do not stand alone. They do have relationships to other objects in the database * Relation to the autnum object AS numbers constitute routing entities defined in the autnum object. They are closely related to routing and from a logical point of view are hierarchically higher than route objects. However, they form a flat space of numbers and a hierarchy among themselves is difficult to apply. Moreover, autnum objects in the current version of the database do not point to route objects making it difficult to implement a top-to-down search mechanism from autnum objects to route objects. Therefore, some hierarchical authorisation scheme starting from the autnum objects seems to be unapplicable on first sight. Yet, route objects point to two other objects at the same time, both pointers being mandatory: first they point to corresponding autnum objects via the "origin" attribute, and in addition a maintainer must be specified. Interesting enough this maintainer needs not be the same as the maintainer specified in the autnum object allowing creation of route objects for some AS using a completely independent maintainer. Obviously, there should be a possibility to prevent it introducing a hierarchical scheme: the proposal is to allow "mnt-lower" attributes within autnum objects defining which maintainers may create route objects for the AS of the corresponding autnum object. * Relation to inetnum objects Several people are not happy about the fact that there is no reference to address allocation for route objects because address space and its routing are somehow related. There are proposals to make route objects dependent on inetnum objects. The big advantage of such a scheme is that there will be no routes without allocation of address space which is a very appealing approach! However, it is not at all applicable to pure routing registries. Therefore, a dependency of route objects on inetnum objects seems to make the overall handling too complicated. Establishing a mere combination of address space ownership and route objects might be more easy. This may be (and in most cases already is) done somehow by the maintainer object. However, it is again not applicable to pure routing registries. Moreover, ownership and routing often differ, and changes in routing may demand changes in inetnum objects. In general, there are also many more inetnum objects than route objects (because of CIDR) which makes the relation again more complicated. There also is the opinion that the philosophy of the database should be to mirror the real world. In the real world advertised routes are completely controlled by an AS making other authorisation irrelevant. No policy should be enforced which does not exist in the real world. Maybe, consistency can be achieved through notification to flag discrepencies. Obviously, the relationship is difficult and there was not yet any consensus on how to deal with it. The problems might be solved in a unified distributed global registry but there is no immediate solution. More discussion is needed. * A prefix based hierarchical scheme With inetnum objects in the database a prefix based hierarchical scheme is used making shorter prefixes hierarchically higher than longer ones, controlling longer prefixes below them. This scheme could also easily be applied to route objects. Its big advantage is that already a working mechanism exists. However, there are also several problems in it: o To make authorisation work some starting point in form of top level route objects must be created in each registry in order to prevent that anybody may gain control of the whole tree of route objects. These top level route objects are kind of artificial because they do not reflect any routing at all. Starting points are especially diffi- cult to apply to the swamp 192.x. o If a hierarchical authorisation based on prefix length is *enforced* only one route object per IP-range would be allowed. This is different from what can be found in usage of the database today. It will cause difficulties in several cases: - Multihoming today is expressed by several route objects of differing origin. If only one route object is allowed multihoming could not be expressed in the database. This again might be circumvented by intro- ducing multiple origins per route object which again raises the question of authorisation by maintainers. - Relatively often specific IP-subranges are routed by another AS than a given IP-range. If the maintainer of the IP-range allows handling of IP-subranges in general (by specifying a corresponding "mnt-lower" attribute), any IP-subrange may be captured by the maintainers given in the mnt-lower attribute. This may not be intended. A possible solution might be in extending the usage of the "hole" attribute being already an optional attribute of the route object: holes could be excluded from hierarchical authorisation down to the next longer prefix specified. - If a customer changes from one ISP to another the origin of the corresponding route object changes, too. To facilitate the change, currently for a few weeks both ISPs keep a route object of the same IP range with their AS as origin. This is especially important if they generate elements of their router configurations from route objects in the database. The problem is similar to multihoming however with the focus on transition of maintainers. o Even though route objects could be secured by hierarchical authorisation in one registry they are not necessarily protected in another registry because data in different registries do not depend on each other. As a consequence duplication not only of the data but also of the specific hierarchy is indispensable. Obviously, enforcement of a prefix based hierarchical authorisation causes troubles which can not be solved within a short time. * A temporary suggestion The prefix based scheme is very valuable and should be applied somehow. A temporary suggestion is to apply it but not to enforce it, just to notify. The advantages are that it is built upon a working mechanism and nothing much changes. A starting point in form of top level route objects is not needed and duplication in several routing registries has no consequences. Still several route objects of differing origin per IP range are allowed and conflicts with current practice in using the data- base do not occur. Yet, a simple notification does not solve conflicts. The "owner" can not remove conflicting records - but with conflicts two parties exist and both must resolve the problem together. The notification does not solve the problem in itself but it will flag it to exist and that a solution is needed. However, objects in one registry remain unsecure if hierarchical authori- sation is applied in another and in the end this is no real solution. Nonetheless, this is a slight improvement to the current situation which is upwards compatible because notification is also needed if authorisation is enforced in the future. There was a general consensus that pure notification as a temporary solution should be applied. Later, on the way to enforcing authorisation some kind of approval mechanism could be probably installed if errors occur which come from insufficient authorisation for the action requested. With notification several new questions arise: - To keep notification traffic low it might be useful to notify only if it is requested by an object hierarchically higher. Currently, in the database notification only occurs if requested. Because of the impor- tance of route objects one might choose to notify for overlapping routes in all cases. - It might be useful to trigger notification by route objects only. To take the importance of inetnum objects into account one might think of notifications in cases of inetnum objects of overlapping address space. - It might be useful to notify the creator of route objects of the other notifications for coordination purposes. - Up to now notification is done only for the creation of objects, not for changes or deletions. To prevent floods of mail this should be kept. In general, several issues could be clarified but there remains quite a lot to do. The items where consensus was found should be implemented soon and discussion on the other items (still the majority) must continue. New Action 26.R2 on Joachim Schmitz To trigger database implementation of first discussion results from hierarchical authorization for route objects New Action 26.R3 on Joachim Schmitz To finalize the hierarchical authorization for route objects together with the Routing WG C. Report on route aggregation by the RIPE NCC (D.Karrenberg, RIPE NCC) The report on route aggregation could not be given because the statistics mechanism was offline for two months. Therefore, nothing new can be re- ported. DK was asked to fix it and to report again at the next RIPE meeting. Action 25.R1 on Daniel Karrenberg/RIPE NCC To report on the results from the route aggregation analysis on the next RIPE meeting There is other data available from SURFnet showing growth of the Internet: New Action 26.R4 on Eric-Jan Bos To circulate the URL of his analysis of routing table size on the mailing list This has already been done - the URL is ftp://ftp.surfnet.nl/surfnet/net-management/ip/nets.ps and it contains data on the growth of the global routing table since 1 January 1994. D. New Developments of RATools (D.Kessens, ISI) The RATools as part of the Routing Arbiter Project of Merit and ISI are a valuable means to make use of registry data and to compare it to the real world. David Kessens (formerly RIPE NCC, now at ISI) gave an overview of new developments in version 3.4.x and 3.5.1 of the RAToolSet. There were noticable enhancements for RtConfig, a tool which allows automatic gene- ration of router configuration elements from registry data. Moreover, the aoe (autnum object editor) is now in production. The overview of the RAToolSet news is available as ftp://ftp.ripe.net/ripe/presentations/ripe-m26-davidk-ratools.ps.gz and contains information about where to find the software (WWW, ftp). In a second presentation David Kessens introduced the aoe (autnum object editor). With this new tool autnum objects can be automatically generated for registries. Data of neighbors and for the policies can be taken from existing databases, from real life BGP dumps, or entered manually inclu- ding heuristics. It has a user friendly interface including a GUI (based on X.11 Tcl/Tk), an "on-line" help, and it makes updates to IRRs easy. The functionality of aoe was explained by various examples and it turns out that aoe can make work with autnum objects much easier. In the future, RPSL will also be supported (up to now aoe generates RIPE-181++ syntax), cooperation with other tools will be implemented, and more and better heuristic methods will be included. The aoe shares the same requirements with the RAToolSet (which it is part of) being - gcc 2.7.2 or later - libg++ 2.7.2 or later - Tcl 7.5/Tk 4.1 or later in version 3.5.1 of the RAToolSet. The presentation of aoe is available as ftp://ftp.ripe.net/ripe/presentations/ripe-m26-davidk-aoe.ps.gz During the RIPE meeting a test installation of the RA ToolSet was accessible to the participants. E. Report on routing stability (G.Winters, Merit) Since routing stability has become a major issue in the Internet it was very interesting to have a presentation of recent measurements done by Merit. Gerald Winters of Merit showed results from Craig Labovitz which he (Craig) had presented at the May '96 Nanog meeting supplemented by some newer studies. The presentation of Craig Labovitz is available as ftp://home.merit.edu/pub/users/labovit/talks/nanog-9605/instability.ps and further information may be found at http://nic.merit.edu/~ipma/ The presentation was very interesting and caused a lot of discussion. Topics from the presentation and the discussion are comprised below: As it turns out there are peaks of close to 10 million BGP announcements and withdrawals in a given day with more than 100 BGP updates per second. Major providers are not major causes of instability while individual ISPs and end-sites can have a disproportionate effect on routing stability. It is interesting that BGP traffic is a function of weekday/weekend and even of the time of the day. A correlation to the amount of traffic is speculative, however there might be an indication of some correlation to maintenance work. Up to now there has been no analysis whether long holi- days show in the statistics as well. For real big instability incidents (abnormal events) Merit people called the originators of the instability to find out the reason. From a relatively low number of 36 incidents it turned out that - links are nearly no problem - hardware is rarely a problem (but approx 3 times as often as link problems) - software and configuration problems cause more than 50% of BGP updates However, this does not give much indication on the reasons for the general instability below major incidents. A graph showing the number of BGP announcements (normalized to the number of routes) seemed to indicate that the instability grows because a linear regression of the data showed an increase. However, in the discussion it was noted that there was a very large variance in the samples taken and a linear regression may not be justified and therefore misleading. Moreover, the growth in complexity of the Internet may introduce another effect: more routes are seen because of an increasing number of peerings. There- fore, a mere normalisation of the number of BGP announcements to the num- ber of routes may not be sufficient. In the end (because the increase was not very steep), there might be no indication for a growing instability at all. A more elaborated analysis of the BGP announcements shows that most of the BGP updates are redundant or unnecessary with a large percentage of duplicates. 99% of the BGP traffic is withdrawals. One reason for this might be that withdrawals are *always* sent to all peers and accepted there regardless of outgoing or incoming filters. It is suspected that this behaviour is actually wanted because especially if a new filter is set up, previously valid routes should be withdrawn anyway. Another interesting analysis showed the frequency of BGP updates for the same prefix and origin. There were pronounced peaks at 30sec intervals. A close relation to IGP updates is suspected. However, in the discussion it was also mentioned that with Cisco routers the default keepalive on lines is 10sec and the line protocols go down after three missed keep- alives which is 30sec. If immediate BGP update is configured (which is the default) then the corresponding routes are immediately withdrawn. Obviously, there are other sources for this specific frequency and a more detailed analysis should be performed. It was a bit disappointing to have no statistics on the instability depending on the prefix length. With all the data collected an analysis like this should be possible. Recommendations to improve routing stability were - to use BGP route flap dampening - to aggregate as much as possible using CIDR - to filter As already seen at previous RIPE meetings route flap dampening is an impor- tant topic which has been dealt with before. A BOF on this topic was announced (see below). Y. General input from other WGs There was no current input from other WGs. Z. AOB Christian Panigl announced that a BOF session on route flap dampening was planned. The minutes of this session are included here. <at this place the BOF minutes will be included> Summary of Actions ------------------ Action 22.10 on Joachim Schmitz To trigger the discussion on the mailing list of the Routing WG, which focus to choose for a future tool development project and to come to consensus on it Action 25.R1 on Daniel Karrenberg/RIPE NCC To report on the results from the route aggregation analysis on the next RIPE meeting Action 26.R1 on the RIPE NCC To add a link on the RIPE web server from the Routing WG pages to the CIDR FAQ location Action 26.R2 on Joachim Schmitz To trigger database implementation of first discussion results from hierarchical authorization for route objects Action 26.R3 on Joachim Schmitz To finalize the hierarchical authorization for route objects together with the Routing WG Action 26.R4 on Eric-Jan Bos To circulate the URL of his analysis of routing table size on the mailing list Action 26.R5 on Christian Panigl To collect reasonable route flap dampening parameter values and to present them at the next RIPE meeting in the Routing WG Agenda ------ - Routing Working Group Meeting - Agenda for RIPE-26, Jan 1997, Amsterdam A. Administrative issues (J.Schmitz) - volunteering of the scribe - agenda bashing - minutes from last meeting - open actions B. Hierarchical authorisation for route objects (J.Schmitz) - current state - discussion C. Report on route aggregation by the RIPE NCC (D.Karrenberg, RIPE NCC) - in general - route aggregation D. New Developments of RATools (D.Kessens, ISI) - new tools - aoe E. Report on routing stability (G.Winters, Merit) - measurements by Merit - route flap dampening Y. General input from other WGs Z. AOB ---- _____________________________________________________________________________ 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

Global routing table size graph
by Erik-Jan Bos 23 Jan '97

23 Jan '97

Routing WG, during the Routing WG meeting I promissed to e-mail you the URL of the graph that shows the global routing table size since 1 January 1994. Measurements are done every hour on the hour, by a script I run on my workstation. This graph is updated automatically, every hour. The URL is: ftp://ftp.surfnet.nl/surfnet/net-management/ip/nets.ps The first real dip in the graph was after the Houston (?) IETF, where during the CIDRD working group meeting almost all ISPs present decided to start using CIDR. __ Erik-Jan.

1 0

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

RIPE 26 Routing WG Draft Agenda
by Schmitz＠RUS.Uni-Stuttgart.DE 16 Jan '97

16 Jan '97

- Routing Working Group Meeting - Proposed Agenda (1st draft) for RIPE-26, Jan 1997, Amsterdam A. Administrative issues (J.Schmitz) - volunteering of the scribe - agenda bashing - minutes from last meeting - open actions B. New Developments of RATools (D.Kessens) C. Hierarchical authorisation for route objects (J.Schmitz) D. Report on route aggregation by the RIPE NCC (D.Karrenberg, RIPE NCC) E. Report on routing stability (G.Winters, Merit) Y. General input from other WGs Z. AOB _____________________________________________________________________________ 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 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

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

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