This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
hierarchical route objects, part 1
- Previous message (by thread): hierarchical route objects, part 1
- Next message (by thread): hierarchical route objects, part 1
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Curtis Villamizar
curtis at ans.net
Fri Jan 10 23:33:59 CET 1997
In message <9701090843.AA22116 at ncc.ripe.net>, Daniel Karrenberg writes: > > > Schmitz at RUS.Uni-Stuttgart.DE (Joachim Schmitz) writes: > > > > * The root of the authorization tree is an AS-object (aut-num object). I > f > > it contains a "mnt-lower" attribute it controls all route-objects whic > h > > have this AS as origin. > > Agreed. > > > * Then for route-objects the same rules apply as for inetnum-objects wit > h > > respect to IP subranges: If a route-object contains a "mnt-lower" attr > i- > > bute it controls all more specific route-objects immediately below. > > This is flawed for several reasons: > > In the real world it is still the originating AS which has authority > over which routes they announce. Example: AS3333 could at this minute > decide to announce 129.69.18.28/32 (the address of Joachim's primary MX > host). There is nothing anyone can do about the announcement per se. I > can configure our routers to do that and chances are good that > -at least initially- large parts of the Internet will believe the route. > Of course other ASes can refuse to accept this route but that is routing > policy and has nothing to do with originating the route by AS3333 which > is the only significance of the route object. So the originating AS > should be the sole point of hierarchical *authorisation* for the route > object. Note that notification is different and refer to my earlier > message about this. The whole point of the hierarchical registration is to make the database good for some purpose. If people do announce bogus routes, as the routing protocols will allow them to do, then the IRR will protect the legitimate holder of that address space as long as the heirarchical registration is in place and in use. 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. Curtis
- Previous message (by thread): hierarchical route objects, part 1
- Next message (by thread): hierarchical route objects, part 1
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]