Communities in RIPE-81++

Marten, Tony, 

  Thanks for the pointers to "Authorization and Notification of
Changes..." and "RIPE Database Transition Plan".  The transition plan
is nicely detailed, and I really like the authorization options you've
built in.  

  I'll follow up with more minor comments about the texts, but I've
got one big confusion about what is happening with the Communities
(especially the "guarded attribute" processing for Communities).
Here's my best reading so far:

    - Community objects continue to exist, and have the benefit of
         the new Maintainer support (including authorization checking)
    - Community files continue to exist in nearly their current format.  
	 The entries in the Community file need to be changed to refer
	 to the prefix/length notation of Routes rather than the dotted
	 quad IPs of Inetnums, and need to be converted to refer to
	 what is actually registered as Routes (e.g. to reflect the
	 level of aggregation registered by the Route objects).
    - The process will still exist where all the Community designations
	 in the Inetnum or Route objects are deleted each night, and
	 are replaced by new Community designations generated from the
	 contents of the Community guardian files.  Users can still
	 submit new Inetnum/Route objects specifying Communities that
	 they do not actually belong to;  these are corrected only
	 during nightly processing (though the new text specifies that
	 a message will be sent immediately to the Community maintainer).

Have I got this right?  If so, I have the following comments about the
text in the papers:

>  [Transition] 3.1 Guarded Attributes:
>
>  As explained in [4], the current procedure for guarded attributes
>  is that guardians maintain files on the NCC database machine, from
>  which guarded attributes are added to objects to ["in"?] the database.
>  Although this has worked reasonably well for over a year, it can
>  be solved with a more general authentication and notification scheme.
>  This scheme is explained in [2].  ...

Would it be more accurate to replace "it can be solved" with "the 
authentication portion of guarded attribute handling can be solved..."?
As is, the text sounds like you're throwing out the whole idea of
guardian files.

>  The introduction of the "route" objects in the RIPE database (see
>  below) removes the necessity of guarded attributes in their current
>  form.  The primary reason for having guarded attributes (authenticity
>  guarantees becaue of their operational impact) can be solved by the
>  general authentication scheme.

It seems to me this is true for the "Origin"/"Aut-Sys" guarded attributes,
since they can now be contained in a Route object that is entirely owned
(at least usually) by the same group that owns the AS.  But it is not
true at all for Communities.  Communities still need to be owned by
separate maintainers, and the Community designations spread over all of
the Route objects need to be controlled by people other than the owners
of the Route objects.  This is not affected by the new general authentication
scheme.


>  [Transition] 5.1.3 After B2
>
>  Change
>      Guardian file mechanism is no longer needed and disabled

Huh?  "...is disabled for Inetnum Aut-Sys attribute" ?


>  [Authorization] Special Rules in the Routing Registry
>
>  ... However in order to support the necesary routing coordination, special
>  rules apply to the Route object:  Whenever a Route object is created or
>  deleted or the Comm-list attribute changes, the guardians of all
>  communities and ASes referenced by the old and new objects will be
>  notified in addition to the normal notifications.  This rule ensures
>  that community maintainers have retroactive control over community
>  membership and that ASes get notified if someone else adds a route
>  originated by them.

This "retroactive control" consists of:
   1) RIPE software will automatically delete unauthorized COMM designations
	overnight.
   2) They could call the person and who added themselves to the COMMunity
	and ask them to remove the designation.
   3) They could decide that the addition is ok, and add the new route to
	their Guardian file, thereby approving the change.

Is this correct?

----------------------

As we build a "PRConfig" capable of producing GateD files for AS690
from the Routing Registry, we need the ability to store multiple
AS:Metric designators for 40K+ nets.  (Essentially the information that
was contained in the old nsf-in attribute, though the new solution
needs to scalable to multiple networks).  The option of embedding 100K+
network numbers (40K * 2.3) directly in AS-in and AS-out lines doesn't
sound appealing or readable.  We've played with the option of using
300+ Community files with names like "COMM_AS690_1:200", though that
also seems awkward.  My message last week suggested a tiny change to
the Community Guardian file description ("consider everything after the
first blank to be a comment") that we could use with a DB_SELECTOR
designation to store this informaion in a *single* Community file that
would be owned by the AS generating the configs.

The features we need are:

  1) Maximally conformant with RIPE-81++ (and related documents) 
  2) Minimally unreadable (e.g. no 40K+ -token AS-in lines) 
  3) All information is part of the Global Routing Registry.  (If it
       isn't, then we haven't really registered our policy globally, 
       and it would not be possible for anyone to build tools
       (like prtraceroute) that could really tell if packets were
       taking the right paths or not).  
 [4) Preferably, a security system that does not allow any user to
       register himself as part of your routing base for up to 24
       hours, at his will.]

As I understand it, the guardian files themselves are not part of the
"Public Database":  if you ftp ripe.db you do not get them, and they
are not available via whois.  Instead, you get that same information
registered as "COMM" tokens spread over all of the Inetnum or Route
objects.  This is a nice solution for the "Public Database" problem,
except for the overnight delay in having that information security-
checked and updated.

There are some reasonably easy ways to fix the technical limitations
here (at least for the interactive servers), such as indexing the
community guardian files and generating the COMM lists for each route
whenever the Route is queried.  (Laurent has code much like this
working now in alc, and Rick has the same functionality built into a
modified RIPE whoisd).  (ftp access of the whole database would still
require periodic generation, however).

There could also be some very clean implementations of output for this,
as well.  If communities are used as is, each Route object will be tagged
with multiple Community tags:

   comm-list:  COMM_AS690_1:1800  COMM_AS690_2:1879

With an expanded Community guardian file (for use with DBSelector), there
could be a designated format for this in the Route object, e.g.:

   comm-list:  COMM_AS690( 1:800 2:1879 ... )
   comm-list:  COMM_AS999( xxxx )
   ...

(This becomes design of the "experimental" DB_SELECTOR...)

----------------------

I've strayed a bit here from just the text of the draft documents.  We are
in the process of building such a family of configuration generation tools
now (can we coordinate with you on this?), and we very soon will have to
decide on a representation for storing and using these massive net lists
within a RIPE-81++ registry.  This depends partly on understanding the
coming code (Rick expects to be porting Marten's release as soon as it is
out), and partly on finding ways that can be made to work within the 
current architecture.

Any suggestions for us?   :-)

--Dale



-------- Logged at  Wed Sep 14 23:07:38 MET DST 1994  ---------