Implementation practices

Jake Khuon khuon at merit.edu
Wed Oct 9 01:10:14 UTC 2002


### On Tue, 8 Oct 2002 19:15:34 -0400, "Jason Lixfeld"
### <jlixfeld at andromedas.com> casually decided to expound upon
### <nanog at 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 at 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 at 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 at 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 ]==*/





More information about the NANOG mailing list