Implementation practices
Irrd-discuss didn't have anything at all to say about this, so I thought I'd bring it here for a different, practical perspective. I'm wondering what the general concensus is with regards to IRR implementation practices. I've done a little digging and have tried to find practical examples of networks listing their detailed peering sets and detailed aut-num objects to see how their import and export entries look for things like community strings, MEDs, Local-Pref, etc. I haven't had much luck in finding any detailed, practical examples. I can come up with only two conclusions: 1) Security policies for most networks networks likely mandate against disclosing routing policy by means of mirroring your database with RADB. 2) People just don't use the irrd to it's fullest extent, hence no detailed entries. I'd like to think that the former is true :) so if that's the case, what are some of the best practices? Is it just as simple as creating a database which RADB mirrors, containing general maintainer, as and route objects then having a private, un-mirrored/non-exported database containing all the nuts and bolts which you run ratoolset (or other, home made widget) against?
### On Tue, 8 Oct 2002 19:15:34 -0400, "Jason Lixfeld" ### <jlixfeld@andromedas.com> casually decided to expound upon ### <nanog@merit.edu> the following thoughts about "Implementation ### practices": JL> Irrd-discuss didn't have anything at all to say about this, so I thought JL> I'd bring it here for a different, practical perspective. Hmm... apparently I'm not allowed to post to irrd-discuss since I'm not a member. I'm getting mail through group-wide exploder. Rather than wait for me to be added I thought I'd send a reply to this one. JL> I'd like to think that the former is true :) so if that's the case, what JL> are some of the best practices? Is it just as simple as creating a JL> database which RADB mirrors, containing general maintainer, as and route JL> objects then having a private, un-mirrored/non-exported database JL> containing all the nuts and bolts which you run ratoolset (or other, JL> home made widget) against? This brings to mind a proposal I made many years ago while at a previous employ. We saw the need to maintain both public and private data and one thought was to extend the RPSL spec to do it. We were also attempting to modify IRRd to support this. I know this is not quickly implimentable nor a BCP and I'm not sure anyone would still be interested but I thought I'd throw it out again. Basically, add two optional attributes to each object. These will be local-acl and access-by. Here is an example aut-num object with the extensions. aut-num: AS3549 ... as-in: AS3967 10 AS-EXODUS AND NOT {0.0.0.0/0} ... as-out: AS3967 AS-GLOBALCENTER ... local-acl: as-in(FGCSTAFF+rw), as-out(FGCSTAFF+rw, EXODUS+r) access-by: ACCESS-FGCSTAFF In addition, all people/objects referenced in the maint-by: field should probably have explicit +rw access. All fields should probably have implicit ALL+r associated with them, too. I guess the regex format for the local-acl: object would be local-acl:\s*(([^\(]+)\(([^-+]+)([+-][rw]+)(\s*,\s*([^\(]+)\(([^-+]+)([+-][rw]+))*)+ or the like. The local-acl attribute is a local override to the access object which I will describe below. The access-by references the access object from within the controlled object. Although I have not fully fleshed out the access object, here are the key attributes. access: ACCESS-FGCSTAFF acl: aut-num(ALL+r), mnt-by(ALL+r) acl: as-in(ALL-rw), as-out(ALL-rw) acl: ALL(ALL-rw), access(FGCSTAFF+rw) local-acl: acl(FGCSTAFF+rw) ... mnt-by: MAINT-AS3549 ... The syntax of the local-acl and acl atribute is as follows: local-acl | acl: attribute(ACLGROUP operator perm) ACLGROUP will reference another object which defines the entity of the access and can define method as well as criteria. The operator is either a + or - that permits or denies the permission which is either r or w for read or write. Note that referencing a primary key attribute in an acl or local-acl attribute will cause any attributes of that object type to inherit the permissions of the primary key attribute unless explicitly defined by another acl or local-acl. The aclgroup can define a single person or group of persons/networks/hosts/etc. We haven't fully fleshed this out either but I'm envisioning something like this: aclgroup: FGCSTAFF ... acl-permit: khuon@decaf.gctr.net acl-permit: 204.71.194.200, watchtower.snv2.gctr.net acl-permit: 206.251.8/24 acl-permit: .neebu.net acl-deny: .aol.com ... The first acl-permit specifies a user@host. The second specifies individual host control. The third is a network access description. The fourth describes domain access. And the acl-deny is an example of how to deny based on domain. -- /*===================[ Jake Khuon <khuon@Merit.EDU> ]======================+ | Systems Research Programmer, HPN-Global Routing /| /|[~|)|~|~ NETWORK | | Ofc: +1 (425) 391-2262 Fax: +1 (425) 391-6772 / |/ |[_|\| | Inc. | +==[ Suite C2100, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]==*/
participants (2)
-
Jake Khuon -
Jason Lixfeld