Draft Guarded Field document

Please find enclosed a DRAFT copy of a document describing the Guarded Field
procedure. This gives details of both the process for updating guardian files
as well as how conflicts are handled. 

The current status is that the software is in final beta test and all the
auto-generated "AS" accounts/files have been generated (see doc for more
details). 

Our plan is to turn the "guarded field" software on in the database on 
February 7th. There will be a short introduction for both the paper and
implementation given in the routing working group session at next weeks 
RIPE meeting. 

All comments welcome. We plan to agree and close this document at the RIPE
meeting.

		See you next week.

			--Tony.











         Support of Guarded fields within the RIPE Database
                             * DRAFT *


                             Tony Bates

                       Document-ID: ripe-1nn






1.  Introduction

The RIPE database contains several significant attributes which make
it  well suited for use as part of operational procedures and confi-
guration. Most significantly are the attributes which  make  up  the
RIPE  Routing  Registry  (RR) as specified in RIPE-81 [1][2], namely
the "aut-sys" and "comm-list" attributes.  For these  attributes  to
be of use to service providers they must be:


 o   Properly authorised.


 o   Efficient for both maintainers of the attributes and the  main-
     tainers of the whole database.

This document describes an overview of the RIPE database  attributes
which  are  guarded, the procedure for updating these guarded attri-
butes and the general use of "guarded" fields within the RIPE  data-
base.


2.  The Database Guarded Attributes

All the guarded attributes currently supported in the RIPE  database
are  contained  within the "inetnum" or network object. However, the
association corresponds to their relevant guarded database  objects.
If we look at a simple example this becomes clear:

inetnum:   192.87.45.0
netname:   RIPE-NCC
descr:     RIPE Network Coordination Centre
descr:     Amsterdam, Netherlands
country:   NL
admin-c:   Daniel Karrenberg
tech-c:    Marten Terpstra
connect:   RIPE NSF WCW
aut-sys:   AS1104



ripe-1nn.txt              January 19, 1994
                               - 2 -


comm-list: SURFNET
ias-int:   192.87.45.80  AS1104
ias-int:   192.87.45.6   AS2122
ias-int:   192.87.45.254 AS2600
rev-srv:   ns.ripe.net
rev-srv:   ns.eu.net
notify:    ops at ripe.net
changed:   tony at ripe.net 940110
source:    RIPE


This shows that the RIPE-NCC network belongs  to  autonomous  system
1104 and is in a community known as SURFNET. This is valuable infor-
mation that could easily be used for example for routing policy pur-
poses (as well as other operational uses). Currently support for the
following set of guarded attributes is implemented:


aut-sys
     The "aut-sys" attribute  has  a  direct  mapping  to  "aut-num"
     objects  as  defined  in RIPE-81. That is the Autonomous System
     (AS) that the network number is a part of. As defined in  RIPE-
     81, a network can only belong to one AS and hence the "aut-sys"
     attribute can only contain one AS number.  The  syntax  of  the
     "aut-sys" attribute is:

     AS<positive integer between 1 and 65535> (1). i.e. AS1104


comm-list
     The "comm-list" attribute has a direct mapping  to  "community"
     objects  as  defined  in  RIPE-81. A network can belong to more
     than one community. The syntax of "comm-list" is:

     Multiple text strings which cannot start with "AS"  or  any  of
     the <routing policy expression> KEYWORDS defined in RIPE-81.


routpr-l (2)
     The "routpr-l" attribute has  a  direct  mapping  to  "rout-pr"
     objects  as defined in RIPE-60 [4]. Networks can belong to more
     than one routing privilege. The list of networks within a rout-
     ing privilege represents the group of networks accepted/allowed
     by a set of routers described by the information in the  "rout-
     pr" object.  The syntax for "routpr-l" is as follows:

     Multiple text strings representing the routing privilege.
_________________________
  (1) This represents a change from RIPE-50  [3]  where
the  "aut-sys"  attribute  was defined to be a positive
integer only, not containing the  string  "AS"  at  the
start.  This change has been made to be consistent with
the "aut-num" object syntax.




ripe-1nn.txt              January 19, 1994
                               - 3 -


bdrygw-l
     The "bdrygw-l" attribute has  a  direct  mapping  to  "bdry-gw"
     objects  as defined in RIPE-60 [4]. Networks can belong to more
     than one boundary gateway. The list of networks within a  boun-
     dary  gateway  represents the group of networks advertised by a
     set of routers described by the information  in  the  "bdry-gw"
     object.

     The syntax for "bdrygw-l" is as follows:

     Multiple text strings representing the boundary gateways  iden-
     tification.

As these attributes are tightly coupled to their associated  objects
it makes sense for these attributes to be updated not by the network
maintainer but by the maintainer of the referenced  object(s).   The
basic  premise  behind  this is that these attributes should be used
for various operational procedures such as setting  routing  policy,
accounting  and  so  on.  For these attributes to be used by network
operators for day to day operations they need to be guarded in  such
a way that can be trusted and are guaranteed to be unique - with any
conflicts quickly and easily resolved. The procedure  for  achieving
this is detailed below.

3.  The Basic Procedure

For each of the guarded attributes detailed above,  a  list  of  all
networks  having  this attribute is kept separately from the general
database itself.  These lists (also called `guarded files') will  be
maintained and be served as the `only' source of membership informa-
tion used in the database.  Normal database updates  `never'  change
these  attributes.   If  an  update includes such an attribute and a
discrepancy between the values in the update and those in the  data-
base  is  found, a diagnostic message will be sent to the originator
of the update and the guarded value(s) will not  be  affected.   The
attributes  as  defined in these files are incorporated in the data-
base once a day.  To ensure proper control and authorisation,  these
lists  will  be  maintained at the RIPE NCC on the same machine that
contains the RIPE database.  The "guardians"  of  the  corresponding
database objects will have to maintain their own guarded files.  The
guardians are provided with individually assigned login accounts  at
the  RIPE  NCC.   The guardians can themselves decide in what manner
they want to update their file.   The  NCC  will  offer  interactive
logins, ftp logins or any other means that might be deemed useful.



_________________________
  (2) It should  be  noted  that  both  "routpr-l"  and
"bdrygw-l" attributes have been agreed to be phased out
in preference of the "aut-sys" and  "comm-list"  attri-
butes  as  soon  as the `guarded field' mechanism is in
place.




ripe-1nn.txt              January 19, 1994
                               - 4 -


3.1.  Some Details

As stated each guardian will be issued with an account on  the  cen-
tral  NCC  machine  known as `guardian.ripe.net'.  This account will
contain a `restricted' environment which will allow the guardian  of
the relevant object to update their associated  guardian  file  (3).
Wherever  possible  the  account name issued to the guardian will be
the same as the object name.

For example, the guardian of the AS1104 aut-num object will  receive
an  account  known  as  "AS1104".  With  each  guardian  account the
corresponding file will be parsed at each update run (once  a  day).
This  file  will  contain  the  list on networks associated with the
object. See appendix A for details of the format and syntax  of  the
guardian files.

A tool will also be provided within the  restricted  environment  to
syntax  check  the  guarded file to avoid against possible typos and
errors.

With each account, an electronic mail address (this is  a  mandatory
attribute for all guarded objects) will be used by the NCC and data-
base software. To make this flexible for the guardian  a  ".forward"
file  with  the account which can be change when required. This will
mean mail sent to <guardian-name at guardian.ripe.net> will go  the  to
correct guardian.

3.2.  How does it work ?


For each of the guarded files found on `guardian.ripe.net' the data-
base  software will load any guarded attribute value(s) for the net-
work object(s) listed in the guarded file. This will take  place  at
the  same  time  as  the database is garbage collected (currently at
0500 MET). If a conflict is found (i.e if more than one entry exists
for  an  attribute  which can only contain one entry, currently only
"aut-sys" contains this property), the  current  value  will  remain
unchanged and all guardians involved in the conflict will be sent an
electronic mail message informing them of the conflict. See Appendix
B for an example.

If no conflict is found the  attribute  will  be  updated  with  the
guarded value.

Correspondingly, to remove a guarded attribute just remove the  net-
work  entry from the relevant guarded file and it will be deleted at
the next update run. To be notified  of  this  delete  the  "notify"
attribute should be used.
_________________________
  (3) As stated, the mechanism for updating the guardi-
an  file will initially be by interactive login or file
transfer. However, this doesn't preclude other  mechan-
isms in the future.




ripe-1nn.txt              January 19, 1994
                               - 5 -


If a guardian file contains an entry which is not  in  the  database
then  the guardian will be notified as part of the conflict handling
procedure.

If an update is sent to the database software using another  mechan-
ism  (i.e. mail to auto-dbm at ripe.net) that contains a guarded attri-
bute, this will not be allowed to change the guarded  attribute.  If
the  value  of  the  attribute  is  the  same  as  what is currently
registered in the database then no warnings will be given.  However,
if  the update contains a value for a guarded attribute that is dif-
ferent to that registered in the database, a warning will be sent to
the originator and the guarded value will remain unchanged.

Although the guarded process will run once a  day  as  part  of  the
database  garbage  collection procedure it will also be possible to,
"on request to the NCC", run an emergency guarded update process for
a particular guarded object.

4.  Getting it started

As this is a new (and much  needed,  especially  for  the  "aut-sys"
attribute)  mechanism, a degree of `bootstrapping' is needed to make
it easier for network providers and IRs to transition to  using  the
guarded  file  procedure.  The NCC has built an automated generation
scheme for attributes that are known to be in use  (currently,  this
means  AS  numbers).  For  all  the  AS numbers seen to be routed in
Europe, accounts for the guardians have already been  put  in  place
having  the  guardian's  mailbox point to a mailbox at the RIPE NCC.
For these ASs currently guarded files are generated on a daily basis
by  analyzing  European  full routing tables. This means there could
(and almost certainly will) be some conflicts within  the  generated
guardian files.

As soon as the account is handed over, the auto-generation for  that
guardian  account  stops  and  the mailbox is changed to the correct
guardian mailbox. Guardians can of course  make  use  of  the  auto-
generated  guarded  files  if  they  wish to check against their own
records.  From the moment of `hand-over' it  is  now  the  guardians
responsibility  to  make  sure  their  associated network(s) get the
correct guarded attributes by listing them in the guarded files.

The advantage of having this `bootstrap'  method  is  that  it  will
allow  population  of  the guarded "aut-sys" attribute to take place
immediately this functionality  is  enabled  in  the  RIPE  database
software.   It  also acts as an incentive for networks operators and
local IR's to transition to the guarded file procedure  as  soon  as
possible.

5.  Conclusion

The update procedure as detailed above has the following advantages:


 o   Authorisation of adding/deleting is guaranteed.



ripe-1nn.txt              January 19, 1994
                               - 6 -


 o   No need for mailing back and forth of authorisation messages.

 o   Simple procedure for both database maintainers and guardians.

 o   Guardians keep full control of their attribute.

It allows for the addition of any number of  guarded  attributes  in
the future.  It describes a simple but effective procedure for main-
taining the guarded files whilst not precluding alternate mechanisms
in the future.

6.  References


[1]  Bates, T.,  Jouanigot,  J-M.,  Karrenberg,  D.,  Lothberg,  P.,
     Terpstra,  M.,  "Representation  of  IP Routing Policies in the
     RIPE Database", RIPE-81, February 1993.

[2]  Bates, T., Karrenberg, D., "Description of Inter-AS Networks in
     the RIPE Routing Registry", RIPE-103, December 1993.

[3]  Karrenberg, D., "RIPE Database Template for Networks", RIPE-50,
     April 1992.

[4]  J.-M. Jouanigot, "Policy based routing within RIPE", May 1992.
































ripe-1nn.txt              January 19, 1994
                               - 7 -


Appendix A - Format of Guardian Files.

We propose to keep the file format as simple as possible.  The  name
of  the  file is identical to the name of guarded object. The format
used within the file is kept simple. It allows lines  to  be  either
comments or the actual object entry that is to be guarded. A comment
must contain either a semi-colon (;) or hash (#) at the beginning of
the  comment  line. The object name entries must be exactly the same
as they are in the database. Currently, the only  object  containing
guarded  attributes  is the "inetnum" object so the file can contain
either the `well-known' dotted quad network notation or RIPE  dotted
quad  range  notation.  Here  is a simple example of what the AS1104
guarded file would look like. The file would be stored in  the  home
directory  of  the AS1104 account on guardian.ripe.net and be called
AS1104 (told you it was simple). It would contain something like the
following:

#
# File : AS1104
#
; An alternate comment format
;
; This file was updated jan.dijkstra at gouda.nl
; on 940109
;
192.16.183.0
192.16.185.0 - 192.16.186.0
192.16.194.0
192.16.199.0
192.87.45.0


Empty lines in the file are also ignored but you are  encouraged  to
keep the file as concise as possible.

As stated above, a tool known as `checkguard' will be  available  to
make it simple to check the syntax of the guarded file.




















ripe-1nn.txt              January 19, 1994
                               - 8 -


Appendix B - Example of conflict handling

If a conflict occurs (e.g. by listing the  same  network  number  in
more  han  one AS guarded file), then each of the guardians involved
will be notified on the conflict by electronic mail. Let's look at a
simple  example.  Suppose the guardians for AS1104 and AS2122 update
their relevant guardian files and create a conflict  by  having  the
same  network  in  them.  For this example he network in question is
"192.16.183.0".  Here is the AS1104 guardian file:

#
192.16.183.0
192.16.185.0
192.16.186.0
192.16.194.0
192.16.199.0
192.87.45.0

And here is the AS2122 guardian file:

#
192.16.183.0
193.0.0.0 - 193.0.7.0

As you can see "192.16.183.0 exists in both files.

At update time the following mails are generated.  Firstly,  to  the
guardian of AS2122.

Date: Fri, 14 Jan 1994 13:22:43 +0100
Message-Id: <9401141222.AA07125 at ns.ripe.net>
From: RIPE Database Conflict Handler <ripe-dbm at ripe.net>
Subject: Guarded attributes conflicts found
To: as2122 at ripe.net

Dear Guardian,

One or more conflicts have been found regarding guarded
attributes in the RIPE database. Some of the conflicts
concern the guarded values you are a guardian for.

Please verify and correct the conflicts below.
The guarded values for objects below have been set to
the value they had in the database before this guarded
attributes run.

Kind Regards,
RIPE Database Conflict Department

------

"192.16.183.0" also appears in guardian files: AS1104

And similarly to the AS1104 guardian.



ripe-1nn.txt              January 19, 1994
                               - 9 -


Date: Fri, 14 Jan 1994 13:22:42 +0100
Message-Id: <9401141222.AA07121 at ns.ripe.net>
From: RIPE Database Conflict Handler <ripe-dbm at ripe.net>
Subject: Guarded attributes conflicts found
To: as1104 at ripe.net

Dear Guardian,

One or more conflicts have been found regarding guarded
attributes in the RIPE database. Some of the conflicts
concern the guarded values you are a guardian for.

Please verify and correct the conflicts below.
The guarded values for objects below have been set to
the value they had in the database before this guarded
attributes run.

Kind Regards,
RIPE Database Conflict Department

------

"192.16.183.0" also appears in guardian files: AS2122

>From this you can see conflict can be quickly and  easily  resolved,
assuming  good  collaboration  between  the guardians.  The existing
database entry will of course not be  changed  with  regard  to  the
guarded attribute) as long as there exists a conflict.





























ripe-1nn.txt              January 19, 1994