The InternetMCI Routing Registry Users Guide 8 May 1995 Table of Contents 1 Introduction ................................................ 3 2 The Authentication Process .................................. 3 2.1 Getting Started ........................................... 5 3 Update Procedures ........................................... 6 3.1 Sending in Entries ........................................ 12 3.1.1 A Simple Acknowledgment ................................. 12 3.1.2 A WARNING message ....................................... 13 3.1.3 An ERROR message ........................................ 14 3.2 Changing Entries .......................................... 15 3.3 Deleting Entries .......................................... 15 3.4 RR Response Times ......................................... 16 4 Getting a Copy of All of Your Route Objects ................. 17 5 The Router Configuration Process ............................ 17 MCI Routing Registry 1 Users Guide 5.1 Emergency Updates ......................................... 18 6 Interaction with the RA and other RRs ....................... 18 7 References .................................................. 20 Appendix A -- Example NACR .................................... 21 MCI Routing Registry 2 Users Guide 1. Introduction This document outlines the basic user guide for the InternetMCI Routing Registry (RR). It should be used in conjunction with the overview document as detailed in [1], which details the routing related objects which should be used and updated in the RR. It cov- ers the authentication process used for making updates and how this is linked to the configuration process. It also includes details of future enhancements and how interaction will be made with other RRs. 2. The Authentication Process The authentication process is the same as that proposed in [2]. Essentially each MCI customer will be issued a mntner object. A sam- ple object is given below: mntner: BT-MAINT-MCI descr: BT maintainer object admin-c: Nigel Titley tech-c: Peter Willis upd-to: pjw@galadriel.bt.co.uk auth: MAIL-FROM pjw@galadriel.bt.co.uk auth: CRYPT-PW UNXaSXyzyxTgQ. notify: pjw@galadriel.bt.co.uk mnt-by: BT-MAINT-MCI changed: mci-rr@mci.net 941107 source: MCI The mntner object represents an entity maintaining objects in the RR. The maintainer is identified and referred to by a unique main- tainer name. The mntner object is used every time a database object with a mnt-by attribute is added, updated or deleted to determine whether the originator of the update request is authorized to make the update. In addition the mntner object provides the same kind of notification ability that is also available with the notify attribute. When using the notify attribute, the user must specify who to notify in every object that he is responsible for. If he wants to change who is notified, every object must be changed. By putting this notifi- cation information in the mntner object, that information is cen- tralized and can be managed more easily. Adding a new mntner object has to be authorized manually by the RR by sending mail to mci-rr@mci.net. Updates to mntner objects follow the normal authorization rules but receive special scrutiny by InternetMCI RR staff. The authorization model supports multiple authentication schemes. Please note again that the authentication scheme and the additional is public information avail- able in the database. Currently the following methods are available: MCI Routing Registry 3 Users Guide MAIL-FROM This authentication method checks the content of the RFC822 From header of an update request against the regular expression specified as . If the regular expression matches the content of the From header the update request is authenti- cated successfully. The regular expressions supported are described in POSIX 1003.2 section 2.8. As it is expected that most regular expressions will either be literals or of a form similar to .*@some\.domain\.or\.other an extensive description of the possibilities will not be given. Note that the matching is applied to the whole content of the From header, including comments if present -- no attempt is made to isolate the mail- box part. It should be stressed that this authentication scheme is very weak. Forging RFC822 headers does not take much effort or ingenuity. The reason for the scheme's existence is that it easily prevents accidental updates rather than allowing them first and fixing them later when notified. CRYPT-PW This scheme uses the Unix crypt(3) routine, which is also used for login passwords under Unix. This routine provides a so called "trap door" function, the inverse of which is somewhat hard to calculate. The password provided by the user is encrypted with this function and stored in its encrypted form only. When the user later provides the password again for authentication, the encryption is repeated and the results are compared. Since the original (cleartext) password cannot eas- ily be computed from the encrypted version the encrypted pass- word does not have to be kept secret. The is the encrypted password. This can either be obtained locally with the appropriate Unix tools or on e-mail request from . When sending in update requests the cleartext password has to be provided in the mes- sage body by specifying password: cleartext-password at the beginning of a line and preceding any update requests to be thus authenticated. The password will remain valid for all requests following it in the same e-mail message or until another password is specified. Multiple authentication methods can be specified in the same mntner object. These will be used alternatively, i.e. any one of the authenticators is sufficient to authenticate the update request from the maintainer. Note specifically that this means if you have both MAIL-FROM and CRYPT-PW attributes, then the password is not neces- sary to make additions and modifications -- the From field alone is enough to authorize the operation. If multiple maintainers maintain MCI Routing Registry 4 Users Guide an object this feature should not be used. Multiple maintainers should be represented by multiple mntner objects referenced in the mnt-by attribute. Within the near future a PGP based authentication mechanism will be available and this will be the recommended method of RR update authentication. 2.1. Getting started Each MCI customer should send in their mntner object to mci- rr@mci.net. This will then be added manually after some verification into the RR. Once this is done you are free to send in automatic updates to the automatic mailbox auto-rr@mci.net for objects which have a corresponding mnt-by attribute set. All authorization and notification will be based on the information detailed in the mntner object. Once you have your issued mntner object you are free to change this directly. In simple terms the following should be done: 1) Send in your maintainer object to mci-rr@mci.net. Each mntner object sent into the RR MUST contain the CRYPT-PW auth attribute to be acceptable. It can also contain the MAIL-FROM auth attribute if required. The preferred convention for mntner object in InternetMCI RR is to label them NNN-MAINT-MCI where NNN is your defined name. 2) When you receive confirmation that your object has been accepted and is in the RR, query the RR to check by using: whois -h rr.mci.net OBJECT-NAME 3) Send in your routing objects to auto-rr@mci.net If this is your first aut-num or as-macro object, it should be sent to mci-rr@mci.net as these objects are deemed to carry important information which should be manually verified before being added for the first time to the RR. If it is not the first time they are being added or the object is a route object or some other object then these can be sent directly to auto- rr@mci.net 4) Verify your objects in the RR by using the whois client. MCI Routing Registry 5 Users Guide 3. Update Procedures As detailed above, once you have been issued with your mntner object you are free to update any object within the RR for which you are authorized to do so. Below are sample forms of each of the possible types of entries which can be sent into the RR along with an example entry. [1] gives an overview of what these objects mean and how they are used. All mandatory fields must be filled in: route route: [mandatory] [single] descr: [mandatory] [multiple] origin: [mandatory] [single] hole: [optional] [multiple] withdrawn: [optional] [single] advisory: [optional] [single] comm-list: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [mandatory] [multiple] changed: [mandatory] [multiple] source: MCI Example: route: 204.71.0.0/20 descr: MCI-POP-AGG origin: AS3561 advisory: AS690 1:3561(147) 2:3561(218) 3:3561(27) 4:3561(11) 5:3561(144) mnt-by: MCI changed: tony@mci.net 950323 source: MCI MCI Routing Registry 6 Users Guide The advisory attribute deserves some special attention at this point, starting with some background. In the past, the NSFNET ser- vice provided by ANS was configured from its Policy Routing Database (PRDB). Operations against the database were made by customers by submitting Network Announcement Change Requests (NACRs), which are similar to route objects in the RR. One of the attributes in a NACR, called aslist, contains an ordered list of ASs that peer with ANS. The list specifies, in order, the preferred paths for ANS to use when routing to the network. As of this writing, the NSFNET service is going away, but ANS is remaining as a service provider. In addition, ANS is keeping its PRDB/NACR-style configuration (though the "new PRDB" is called the Routing Arbiter Database (RADB)). Because of this, in order for MCI customers to be able to reach customers of ANS (or, more accurately, for ANS to route back to that MCI customer), the MCI customer's route(s) must be regis- tered in the RADB. In the very near-term, MCI customers still need to submit NACRs for their routes (or have MCI do it for them in proxy, depending on the customer's size). However, in the not too distant future, ANS will mirror MCI's registry and use that data during its configuration process. Once this is done, MCI customers will have to deal only with the registry as opposed to both the reg- istry and the PRDB. However, in order for the MCI registry to con- tain the necessary data, an additional attribute needed to be added to the route object -- this is the advisory attrbiute. The contents of the advisory attribute for supporting ANS's needs are: advisory: AS690 (Note that the advisory field must be in one line, even if it is very long.) The exact string to use for the advisory field depends on which MCI POP you connect to. The following list gives the strings to use for all of the POPs: Atlanta: 3561(147) 3561(218) 3561(27) 3561(11) 3561(144) Boston: 3561(218) 3561(147) 3561(27) 3561(11) 3561(144) Chicago: 3561(27) 3561(218) 3561(147) 3561(11) 3561(144) Denver: 3561(11) 3561(144) 3561(147) 3561(218) 3561(27) San Francisco: 3561(11) 3561(144) 3561(27) 3561(147) 3561(218) Houston: 3561(27) 3561(147) 3561(11) 3561(218) 3561(144) Kansas City: 3561(27) 3561(218) 3561(147) 3561(11) 3561(144) New York: 3561(218) 3561(147) 3561(27) 3561(11) 3561(144) Los Angeles: 3561(11) 3561(144) 3561(27) 3561(147) 3561(218) Seattle: 3561(11) 3561(144) 3561(27) 3561(218) 3561(147) Washington: 3561(147) 3561(218) 3561(27) 3561(11) 3561(144) Note that the preceeding discussion assumes that you are not homed to another provider in addition to MCI; in cases such as being multi-homed, some special coordination may be required. If you have route objects registered without the advisory field, or if the field is incomplete or incorrect, that should be corrected to prepare for when ANS bases its configuration on the registry to MCI Routing Registry 7 Users Guide ensure that connectivity will be maintained with ANS customers. To add or modify the advisory field, start by following the instruc- tions in section 4 for getting a copy of all of your route objects, and put the line-oriented format into a file named "my_routes". You may then use an editor to add or modify the advisory field. Note that for adding the advisory field, you may add it at the end of the line, but you need to terminate the line with a '|' symbol; for example, append the lines with: advisory: AS690 3561(147) 3561(218) 3561(27) 3561(11) 3561(144) | (The '|' symbol is used by the rrformat.pl as the attribute/value boundary.) Finally, you would convert the route objects back to the block-oriented format and submit the updates to the registry. Before leaving this subject, it is worth reminding readers that until ANS mirrors the MCI RR and bases their configuration on that mirrored data, MCI customers must continue to submit NACRs to ensure connectivity to ANS customers. Depending on the size of the MCI customer, MCI will either forward NACRs from the customer to ANS/Merit or will authorize the the customer to submit NACRs directly to ANS/Merit. If you have questions about the process, send a message to nacr@mci.net. An example NACR is included in Appendix A. MCI Routing Registry 8 Users Guide aut-num aut-num: [mandatory] [single] as-name: [optional] [single] descr: [mandatory] [multiple] as-in: [optional] [multiple] as-out: [optional] [multiple] interas-in: [optional] [multiple] interas-out: [optional] [multiple] as-exclude: [optional] [multiple] default: [optional] [multiple] guardian: [optional] [single] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [mandatory] [multiple] changed: [mandatory] [multiple] source: MCI Example: aut-num: AS225 as-name: ASN-VIRGINIA descr: University of Virginia (VIRnet) as-in: from AS86 100 accept {128.167.0.0/16, 192.221.3.0/24} as-out: to AS86 announce AS225 default: AS86 100 {128.167.0.0/16} guardian: nacr@sura.net admin-c: JAJ17 tech-c: JAJ17 notify: jaj@VIRGINIA.EDU mnt-by: SURA changed: sherk@sura.net 941019 source: MCI MCI Routing Registry 9 Users Guide as-macro as-macro: [mandatory] [single] descr: [mandatory] [multiple] as-list: [mandatory] [multiple] guardian: [mandatory] [single] tech-c: [mandatory] [multiple] admin-c: [mandatory] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [mandatory] [multiple] changed: [mandatory] [multiple] source: MCI Example: as-macro: AS-SURANORTH descr: Stub ASs of SURAnet North (AS86) as-list: AS86 AS-SURASMDS AS1236 AS225 AS2532 AS2274 AS2714 AS548 AS686 guardian: nacr@sura.net tech-c: SURA-NOC admin-c: SURA-NOC remarks: Stub ASs of SURAnet North (AS86) notify: nacr@sura.net mnt-by: SURA changed: sherk@sura.net 941107 source: MCI MCI Routing Registry 10 Users Guide person person: [mandatory] [single] address: [mandatory] [multiple] phone: [mandatory] [multiple] fax-no: [optional] [multiple] e-mail: [optional] [multiple] nic-hdl: [optional] [single] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [mandatory] [multiple] changed: [mandatory] [multiple] source: MCI Example: person: Tony Bates address: RIPE Network Coordination Centre (NCC) address: PRIDE Project address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5064 fax-no: +31 20 592 5090 e-mail: Tony.Bates@ripe.net nic-hdl: TB230 notify: Tony.Bates@ripe.net mnt-by: EUROBOYZ changed: Tony.Bates@ripe.net 940920 source: MCI Each of this templates can also be checked by using the the -t flag to the whois server on rr.mci.net. i.e. % whois -h rr.mci.net "-t route" route: [mandatory] [single] descr: [mandatory] [multiple] origin: [mandatory] [single] hole: [optional] [multiple] withdrawn: [optional] [single] advisory: [optional] [single] comm-list: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] MCI Routing Registry 11 Users Guide 3.1. Sending in Entries All entries should be sent in by electronic mail. Multiple objects can be sent in at one time. All entries will be authenticated as described above and either a warning, error or positive acknowledg- ment will be given. Here are some examples of the types of responses you can expect to see. All examples involve a single object to make things a little clearer. In practice, you can send many objects in at once. They will be processed in turn and the results will be mailed back in a single mail message. 3.1.1. A Simple Acknowledgment In this example a person object was mailed into to auto-rr@mci.net. The original mail message looked like this: person: Tony Bates address: RIPE Network Coordination Centre (NCC) address: PRIDE Project address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5064 fax-no: +31 20 592 5090 e-mail: Tony.Bates@ripe.net nic-hdl: TB230 notify: Tony.Bates@ripe.net mnt-by: MCI changed: Tony.Bates@ripe.net 940111 source: MCI The response mail showed the update was processed successfully and denotes which object was updated: MCI Routing Registry 12 Users Guide Date: Fri, 11 Nov 1994 11:30:36 -0500 From: InternetMCI Routing Registry To: Tony Bates Subject: Your e-mail: > From: Tony Bates > Subject: > Date: Fri, 11 Nov 1994 11:30:31 -0500 > Msg-Id: <199411111630.LAA12365@lovefm.reston.mci.net> has been processed by the automatic update procedure at InternetMCI. Diagnostic output follows: ------------------------------------------------------------------------ Update OK: [person] Tony Bates No error/warnings were found in your database update. Congratulations. ------------------------------------------------------------------------ This acknowledgment was sent to you by the InternetMCI RR software. If you wish to receive a copy of the whole object you should add the keyword LONGACK in the Subject field of the mail message. 3.1.2. A WARNING message Some object submissions may generate warnings. This means there was a slight problem in the object but it was processed and modified on your behalf. For example, the following route entry was sent in: route: 193.0.0.0 descr: RIPE-NCC origin: AS3333 notify: tony@ripe.net mnt-by: MCI changed: tony@mci.net 941111 source: MCI The resulting message gave the following warning: MCI Routing Registry 13 Users Guide Date: Fri, 11 Nov 1994 11:39:49 -0500 From: InternetMCI Routing Registry To: Tony Bates Your e-mail: > From: Tony Bates > Subject: > Date: Fri, 11 Nov 1994 11:39:44 -0500 > Msg-Id: <199411111639.LAA12587@lovefm.reston.mci.net> has been processed by the automatic update procedure at InternetMCI. Diagnostic output follows: ------------------------------------------------------------------------ Update OK: [route] 193.0.0.0/24 route: 193.0.0.0/24 descr: RIPE-NCC origin: AS3333 mnt-by: MCI changed: tony@mci.net 941111 source: MCI WARNING: route re-written to 193.0.0.0/24 from 193.0.0.0 Objects that just generated a WARNING have been updated as shown. Objects that generated an *ERROR* have NOT been updated as requested. Please re-submit corrected objects. ------------------------------------------------------------------------ This acknowledgment was sent to you by the InternetMCI RR software. As you can see the route entry was updated OK but modified to the correct syntax. This will not always be possible but the software tries to help wherever possible. 3.1.3. An ERROR Message Any syntax errors will be mailed back. If we look at the same object above but this time with an obvious error: route: 193.0.0.0-X descr: RIPE-NCC origin: AS3333 mnt-by: MCI changed: tony@mci.net 941111 source: MCI MCI Routing Registry 14 Users Guide This results in the following response: From: InternetMCI Routing Registry To: Tony Bates Your e-mail: > From: Tony Bates > Subject: > Date: Fri, 11 Nov 1994 11:44:03 -0500 > Msg-Id: <199411111644.LAA12700@lovefm.reston.mci.net> has been processed by the automatic update procedure at InternetMCI. Diagnostic output follows: ------------------------------------------------------------------------ Update FAILED: [route] 193.0.0.0-X route: 193.0.0.0-X descr: RIPE-NCC origin: AS3333 mnt-by: MCI changed: tony@mci.net 941111 source: MCI *ERROR*: 193.0.0.0-X is not an representation I understand Objects that just generated a WARNING have been updated as shown. Objects that generated an *ERROR* have NOT been updated as requested. Please re-submit corrected objects. ------------------------------------------------------------------------ This acknowledgment was sent to you by the InternetMCI RR software. Clearly, we can see where the error occurred and this can be cor- rected, If you have any problems or queries regarding a bounce or warning please send a message to the human staffed mailbox mci-rr@mci.net. 3.2. Changing Entries If you have an existing object and you wish to change the object, this can be achieved very easily. All that is needed is to change the data and make sure you update the changed attribute associated with the object. Whenever you send in an update you should always make sure that the changed attribute is correct. 3.3. Deleting Entries If you need to delete an entry, send in the object exactly as it MCI Routing Registry 15 Users Guide appears currently and add the following as the last attribute of the object: delete: XXXXX Where XXXXX is your e-mail address or handle. This is used as part of the audit-trail system when possible conflicts arise. 3.4. RR Response Times The following response times can be expected from the RR. 1) Automatic update method (auto-rr@mci.net) -- The average time is between 2 - 10 minutes1 -- The maximum time is 20 minutes 2) Manual update and query method (mci-rr@mci.net) -- The average time is between 2 - 4 hours within the normal working day. -- The maximum time is 1 full working day. _________________________ 1 This is time taken to process the update and be passed out to the mail spooler for shipping the re- sponse. The rest of the time is dependent on electronic mail services. MCI Routing Registry 16 Users Guide 4. Getting a Copy of All of Your Route Objects Sometimes there is a need to get a copy of every route object in the registry (e.g., to add or modify the advisory attribute). The "whois" client does not currently support this feature, so this sec- tion describes one way to do it. As noted elsewhere in this document, the contents of the registry are available via FTP in several formats. One of the formats is broken out by object type (e.g., aut-num, route, etc.). To get a copy of all of your route objects, start by getting ftp://ftp.mci.net/pub/rr/mci.db.rt.gz (all of the route objects) and uncompressing it with the "gunzip" command. Also FTP a small tool by getting ftp://ftp.mci.net/.coren/tools/rrformat.pl. The program is written in Perl, and it simply converts a registry object from a multi-line object to a single line object, allowing you to use line- oriented UNIX programs like "grep". The tool also converts in the opposite direction (from line- to block-oriented format). To find all route objects maintained by EXAMPLE-MAINT-MCI, you would do the following: rrformat.pl mci.db.rt | grep EXAMPLE-MAINT-MCI > tmp_file.line At this point, "tmp_file.line" would contain a line-oriented version of all route objects maintained by EXAMPLE-MAINT-MCI. To convert these objects to block-oriented format, you would do the following: rrformat.pl -r tmp_file.line > my_routes So at this point the file "my_routes" would contain the block- oriented format of every route object maintained by EXAMPLE-MAINT- MCI. 5. The Router Configuration Process As detailed in [1], the InternetMCI routers will be directly config- ured from the data derived from the RR. This will take the form of access-lists which will be generated once every 24 hours and depend- ing on whether they have changed, loaded in the relevant border router. The exact time for these access-list reloads to occur will be 06:00 ET (recognizing daylight savings). If an access-list has changed, the relevant BGP neighbor will be reset. The following ser- vice interruptions can be expected if the BGP neighbor peer connec- tion is reset: -- The average time for interruption will be 2-3 minutes. -- The maximum time for interruption will be 15 minutes. They will be coordinated with the MCI NOC. Copies of these access- MCI Routing Registry 17 Users Guide lists will be made available to the MCI NOC and via anonymous ftp2 for problem diagnosis and information. It is also expected that the relevant parts of the router configuration associated with these access-lists will be made available. 5.1. Emergency Updates As the update window for adding routing information into backbone configurations is once per day, emergency updates can be made. An emergency update needs to be sent to mci-rr@mci.net with the key word EMERGENCY set in the subject. This will be automatically for- warded to the MCI NOC and also to the MCI engineering team for veri- fication. Once verified as a genuine emergency, the update will be processed and the relevant configuration change made. It should be noted that this method of configuration update should be used only in the event of a real emergency. 6. Interaction with the RA and other RRs The InternetMCI RR is publicly available from ftp://ftp.mci.net/pub/rr/mci.db.gz This dump of the database is made available once a day at 01:00 ET (recognizing daylight sav- ings). It is expected that the RA will directly use this data to update the RA database. Currently, the exact procedures for this are still under discussion with the RA and dependent on the RA proce- dures being put in place. However, InternetMCI plans to be part of the Internet Routing Registry (IRR) and facilitate as little amount of RR updates for its customers as possible. As soon as the RA is in place the MCI RR will make updates directly to RA as part of its automatic update procedure. The expected maximum time for this to occur is no more than 60 minutes dependent on the RA being able to receive and process the registry updates from the InternetMCI RR. Customers with large routing registries should contact mci- rr@mci.net directly. The RR currently shadows all the major routing and allocation reg- istries currently in existence. This can be looked at in one of two ways within the RR. 1) using the -a flag to whois You can use the -a flag which will look at all database infor- mation sources stored in the RR. 2) using the -s flag to select the database information you are interested in. The current database information sources available are: _________________________ 2 The details of this will be given in due course. MCI Routing Registry 18 Users Guide Database source -------------------------------------- InternetMCI RR MCI (default) RIPE database RIPE InterNIC network data INTERNIC NSFNET PRDB database PRDB Internic AS data MCI-AS-LIST CA*NET data CANET So for example you could look at an entry in the RIPE database as follows: % whois -s RIPE 193.0.0.0/24 route: 193.0.0.0/24 descr: RIPE-NCC origin: AS3333 remarks: ias-int: 193.0.0.221 AS1104 remarks: ias-int: 193.0.0.157 AS1104 notify: ops@ripe.net changed: ripe-dbm@ripe.net 941017 source: RIPE MCI Routing Registry 19 Users Guide 7. References [1] Bates, T., "Introduction to the InternetMCI Routing Registry", DRAFT, November 1994. ftp://ftp.mci.net/.coren/mci-rr-over.ps [2] Bates, T., Karrenberg, D., Terpstra, M., "Support for Classless Internet Addresses in the RIPE Database", RIPE-121, October 1994. ftp://ftp.ripe.net/ripe/docs/ripe-121.ps MCI Routing Registry 20 Users Guide 8. Appendix A -- Example NACR %begin nsfnet nacr v7.1 netnum: 150.9.0.0/16 netname: HANNAN-NET netcc: JP orgname: Hannan University orgaddr: 5-4-33 Amami-Higashi orgcity: Matsubara orgstate: Osaka orgzip: 580 orgcc: JP orgtype: C2 bbone: T3 homeas: 2520 aslist: 3561(11) 3561(144) 3561(27) 3561(147) 3561(218) 297(144) 297(145 ) aup: N action: A comment: %end nsfnet nacr MCI Routing Registry 21 Users Guide