January 1994 - lir-wg - mailman.ripe.net

Draft Guarded Field document
by Tony Bates 24 Jan '94

24 Jan '94

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(a)ripe.net changed: tony(a)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(a)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(a)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(a)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(a)ns.ripe.net> From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net> Subject: Guarded attributes conflicts found To: as2122(a)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(a)ns.ripe.net> From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net> Subject: Guarded attributes conflicts found To: as1104(a)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

3 4

No Workshop !
by Daniel Karrenberg 23 Jan '94

23 Jan '94

Folks, as agreed last time there will be NO workshop this time. When I copied the boiler-plate draft agenda I erroneously included an item called "report from the workshop". Please disregard this. Daniel

1 0

Agenda for Next Week's Meeting
by Daniel Karrenberg 21 Jan '94

21 Jan '94

Sorry, forgot to send this: DRAFT Agenda "Local Internet Registries" WG at the 17th RIPE Meeting 0. Reports for Information - short reports of significant events at local IRs - short reports of significant events at the NCC - short report from local IR workshop the previous day 1. Local Registry Procedures - block delegation - network number assignment - AS number assignment - reverse name service 2. Proxy Network Entries in RIPE Database 3. Any other business

1 0

revised European IP template
by Anne Lord 18 Jan '94

18 Jan '94

Available from the ripe document store is the revised European IP application form (formerly ripe-098 and now ripe-107). It can be retrieved from directory: ftp:ftp.ripe.net:ripe/docs/ripe-docs/ripe-107.{ps,txt} The only changes made were: i) replace "non-service provider" references with "registry of last resort" and ii) to change the expiry date to 30 June 1994 (now 6 monthly intervals). Best wishes, -Anne

1 0

Latest on the dbase software
by Marten Terpstra 13 Jan '94

13 Jan '94

Folks, here is an update of what has happened with the database software over the last few months: - options have been added to whoisd (some you may have already seen): -r do NOT lookup referenced objects -F do fast lookup, in short format, without reformatting (implies -r) -V faciltates version numbers to be logged in queries this is used to identify prtraceroute and prcheck queries. For instance, prtraceroute is logged with -Vpt0.32 at the moment, where "pt" stands for prtraceroute and 0.32 is the version of prtraceroute used. This option is internal to special tools that use the database, and should NOT be used on command line. -k keepalive. This option will keep the connection between client and server open after a query. Also this option is ONLY used in tools that need a number of queries fast after one another (like prtraceroute) All the options (except the -V and -k) are available in the latest ripe whois client: ftp.ripe.net:tools/ripe-whois.tar.Z Please note that these options will NOT work with other whois servers, and only work with the latest beta whoisd. - the "notify" attribute as defined in ripe-096 has been implemented. The database has accepted "notify" and "maintainer" already for some months, but now the functionality of "notify" has been added last week. The functionality of "maintainer" is not implemented yet. You are welcome to use "notify" but please do not go mad on it. - the guarded stuff has (finally) been implemented, and is currently under heavy test at the NCC. It includes all the things needed to implement ripe-81 guarded attributes, including conflict handling and all other things needed. A document describing the procedures is being written (at this moment actually) and will be ready soon. - many many many small and big bugs have been reported and fixed. Most modules of the software have had some 5-10 fixes each, and the main programs like whoisd have had some 20 fixes. Many of these bugs were nasty little programming errors that appear in only some circumstances, and were thus hard to find. Also, many things have changed to speed things up a bit more. - the software is unfortunately still beta, simply because there are too many changes made every day. Once the guarded attributes have been debugged and the documentation written ;-( it will be an official release. - Some stats, taken out of the quarterly report December 93 (which will be published this week): (All stats over Oct, Nov and Dec 1993) queries: 177,423 e-mail messages with updates processed: 3,575 number of objects processed from these e-mails: 42,767 number of networks in database: 29,646 number of persons in database: 13,238 number of domains in database: 2,339 number of AS in the database: 224 More info of course at the RIPE meeting. If you have any questions about the database (from general to very specific) please send me a mail. See you in 11 days. -Marten

1 0

New at the RIPE NCC: Geert Jan de Groot
by Daniel Karrenberg 03 Jan '94

03 Jan '94

First, a successful 1994 from all of us at the RIPE NCC! As of today our staffing has changed. Marten Terpstra has joined Tony Bates on the PRIDE project full time and will help Tony to achieve the ambitious goals of PRIDE during the coming months. Marten's work at the NCC will be taken up by Geert Jan de Groot who joins us today. Geert Jan comes to us from Philips where he has supported various development projects by providing an excellent computing and communications infrastructure. He is a HAM, a qualified SUN field service engineer and an experienced system administrator. Some of you may have met him during the RIPE technical days where he helped us to show you IP over ISDN. Geert Jan will join Anne Lord and myself in providing the NCC's core services from today. I ask all of you to welcome Geert Jan and to help him get used to his new responsibilities quickly. The PRIDE and NCC staff work as one team. So it is quite possible that you might deal with Marten or Tony on NCC matters occasionally see Geert Jan or Anne involved in PRIDE activities. Regards Daniel Karrenberg RIPE NCC & PRIDE Project Manager

1 0