- routing-wg - mailman.ripe.net

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

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

Progressive BGP route flap dampening
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 02 Jan '97

02 Jan '97

Dear Routing WG members, sorry for not having had the opportunity to participate in the last few meetings. I'm trying hard for the January meeting ! In the meantime let me initiate an e-mail discussion wrt route flap dampening (I'm appending the relevant part of the minutes of the Sept. meeting, where further discussion was requested). Recently, following a scheduled router-maintenance on an Ebone backbone router, I had problems to communicate with NORDUnet (haven't explicitely tried PIPEX ;-) from /24 networks for about 2 hours ! This reminded me of the "progressive route flap dampening" discussion, and increased my motivation for throwing my 0.02 EUROs into the routing-wg list: - I can't beleive that it's really necessary and reasonable to kill a network (regardless of prefix-length) for two hours if it's flapping twice maybe within half an hour but not more frequently within a month ! - Imagine you're SW-upgrading a router and (very unlikely, as we all know ;-} detect that you have to step back ... BINGO, it's perfectly and innocently electrocuted :-( - I'd suggest that dampening (regardless of prefix length) shouldn't start before AT LEAST three flaps are happening in a row (let's say within half an hour). - Dampening should lockout real network instabilities not make worse even scheduled maintenance ! - Besides, I know applications where it might be perfectly reasonable to announce a single *providerindependent* /24 and where it's contraproductive and politically incorrect to include it into an ISP aggregate ! A solution could be to ask Internic/RIPE to define "PI" address-ranges which can and should be excluded from the /24 hostility acts. Kind regards Christian ===== Following quoted from = = RIPE 25, Amsterdam = Routing Working Group = Report of Meeting, 23rd September 1996 = = [...] = =6. Progressive BGP route flap dampening = ftp://ftp.ripe.net/ripe/presentations/ripe-m25-tbarber-bgp-damp.html = = Tony Barber gave a presentation on the strategies used by = UUnet-Pipex to reduce the effects of route flapping and to = try to prevent router table overflow. These were: = = - route dampening = - prefix filtering = - more router memory = = They had encountered many instabilities from peers and found = that many ISPs had not deployed CIDR; this gave rise to more = flapping as more routes, and particularly more specific ones, = were advertised. = = Tony explained the parameters used for route dampening on a = Cisco router. He had arrived at the following re-use times = for various route sizes: = = /24 and greater ~160 minutes = /23 and /22 ~60 minutes = /21 and less ~30 minutes = = He recommended filtering out all prefixes more specific than /24. = = While route dampening consumed router memory, this was more or = less balanced by a reduction in routing CPU cycles. = = He recommended that if route dampening was to be widely = deployed in Europe, consistency was important. In this sense, = the Routing WG should agree on guidelines for parameters to = be used. = = In discussion, the following points were made: = = - aggregation works in reducing router load and route = flapping. = = - route flapping is often a feature of certain autonomous = systems rather than a function of prefix length. = = - much instability was due to configuration changes and = errors as distinct from link failures. = = - making dampening dependent on prefix length could = penalise many stable /24s. = = - it might be useful to discriminate against /24s in the = 192.0.0.0/8 block (the swamp). = = - the focus should be on keeping noise out of the system = rather than trying to mitigate against it once in the = system. = = In summary, it was agreed that route dampening was an = important topic and that more discussion was needed. = ===== End quote

2 1

RAToolSet version 3.5.0 is now released
by Cengiz Alaettinoglu 17 Dec '96

17 Dec '96

RAToolSet version 3.5.0 is now available from: http://www.isi.edu/ra/RAToolSet ftp://ftp.isi.edu/ra/RAToolSet This version contains the beta release of aoe, Autonomous System Object Editor: aoe simplifies the creation of aut-num objects by employing some heuristics to add and modify as-in and as-out attributes. For example, given a BGP dump from a router inside your AS, aoe parses the AS_PATH attributes in the BGP dump, and determines the peer ASes, and the import policies for each peer AS. A template based mechanism is provided for users to create their own heuristics to augment the heuristics that we provide. aoe can register the aut-num object in the IRR after editing is done. aoe is implemented by WeeSan Lee. RtConfig has couple of new features: -supress_martian option -@RtConfig networks commands -@RtConfig default commands There are also some minor bug fixes. Please refer to the man pages for the details. We will be presenting the new features during the upcoming ietf. Precompiled binary versions for selected OSes will be made available after the IETF. As usual, bug reports, suggestions for improvements and particularly patches are welcome. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/~cengiz

2 1

RAToolSet 3.5.0 has in/out bug with export policy
by David M. Meyer 07 Dec '96

07 Dec '96

It looks like RtConfig 3.5.0 confuses "in" and "out" when a distribute-list command (instead of a route-map) is generated from an export command. In this case, the export policy is NOT ANY. To see this, consider the following RtConfig code: @RtConfig set cisco_map_name = "AS2914-EXPORT" @RtConfig export AS7396 198.32.162.100/32 AS2914 205.238.48.3/32 @RtConfig set cisco_map_name = "AS2914-IMPORT" @RtConfig import AS7396 198.32.162.100/32 AS2914 205.238.48.3/32 and consider this aut-num for AS7396: aut-num: AS7396 as-name: OREGON-IX descr: Oregon Exchange Route views (route-views.oregon-ix.net) as-in: from AS2914 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS3333 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS2497 100 accept ANY AND NOT {0.0.0.0/0} as-out: to AS2914 announce NOT ANY as-out: to AS3333 announce NOT ANY as-out: to AS2497 announce NOT ANY guardian: meyer(a)ns.uoregon.edu admin-c: DMM65 tech-c: DMM65 notify: nethelp(a)ns.uoregon.edu mnt-by: MAINT-AS3582 changed: meyer(a)ns.uoregon.edu 961206 source: RADB ` Then RtConfig 3.5.0 generates no access-list 1 access-list 1 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ! router bgp 7396 neighbor 205.238.48.3 distribute-list 1 in no access-list 2 access-list 2 deny ip 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 access-list 2 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ! ! no route-map AS2914-IMPORT route-map AS2914-IMPORT permit 1 match ip address 2 ! router bgp 7396 neighbor 205.238.48.3 route-map AS2914-IMPORT in neighbor 205.238.48.3 distribute-list 2 in Note that router bgp 7396 neighbor 205.238.48.3 distribute-list 1 in should be router bgp 7396 neighbor 205.238.48.3 distribute-list 1 out ^^^ At least this is what I would have expected. Dave

2 1

hierarchical auth with route objects
by Schmitz＠RUS.Uni-Stuttgart.DE 05 Dec '96

05 Dec '96

Dear colleagues, hierarchical authorization in the RIPE-db as a new feature presented at the last RIPE meeting is not limited to inetnum objects or the domain name space. It is also applicable to route objects. However, it has not yet been implemented for route objects because no consensus was found on how to do it. With this mail I want to start the discussion again. Please note, that this is only the draft of a draft - nothing final. So drop your comments here! In my opinion, route objects are not much different from inetnum objects regarding hierarchical authorization. Both span a certain range of IP addresses and in both cases hierarchical authorization controls definition of IP subranges. Following this reasoning it seems to be simple to implement within the IP prefix tree. However, route objects are not standing alone but are logically linked to AS objects via the origin tag. Applying hierarchical authorization within the IP prefix tree *alone* does allow uncontrolled creation of route objects of differing origin. Therefore, AS objects which match the origin AS of a route object may be considered as parent objects of route objects. I think this is a very useful approach (even though it links different types of objects in one authorization hierarchy). There have been ideas that route objects should only be created if proper address allocation occured. However, it has also been pointed out that it is not a good idea to mix address allocation and routing for several rea- sons, e.g. some registries are pure routing registries and all registries should have the same structure. Moreover, changes in routing might make changes in address registration necessary (and vice versa). There have been some good comments on this topic on the database wg mailing list. Never- theless, if no route objects exist for allocated address space, any AS owner may generate route objects uncontrolled in this registry (creation of objects in one registry which are protected by hierarchical authorization in another is also not covered but this is an entirely different problem). Obviously, there are still some loose ends. But I think that the approach of AS objects as parents of route objects from corresponding origin com- bined with hierarchical authorization within the IP prefix tree is very useful and may be applied here. Shall we go for this? Regards Joachim Schmitz _____________________________________________________________________________ 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) _____________________________________________________________________________

3 2