- db-wg - mailman.ripe.net

auto-dbm
by RIPE Database Administration 06 Apr '98

06 Apr '98

Dear Colleagues, There is a problem with auto-dbm today. We are working to fix it, but there will be a delay before your mail is processed. If you have already sent an update, it is in the queue and it will be processed. Thank you for your patience. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

Advertisement: Website Hosting
by info＠inexchange.net 26 Mar '98

26 Mar '98

http://www.inexchange.net info(a)inexchange.net InExchange would like to introduce our complete Hosting and Promotional service. FOR ONLY $19.95 PER MONTH ! * 20 MB (megabytes) of disk space * 750 MB of data transfer per month * 5 E-mail accounts * INTERNATIONAL Hosting * Access to your account anytime via the Web Control Panel * Full MS Front Page support * Unlimited FTP updates * Personal CGI directory for your own scripts (or use ours) * The best statistics analyzer in the industry * E-mail forwarding, auto responders and vacation reply * Domain name registration (www.yourname.com) * FREE registration of your domain with over 250 search engines * Real Audio/Video support * Inquire about our $16.95 plan * Other plans also include: Shopping cart application and database access/utilities Cold Fusion Hosting CyberCash, iBill and VersaNet ready Instant on-line credit card processing For additional details, please refer to our website: http://inexchange.net info(a)inexchange.net

1 0

performance patch
by Curtis Villamizar 19 Mar '98

19 Mar '98

I hope this is the right place to send a tiny patch. In any case, this minor recoding makes the syntax check go a whole lot faster. Curtis Index: src/syntax.pl =================================================================== RCS file: /usr/local/CVS-routing-dev/irr-source/dbase/src/syntax.pl,v retrieving revision 2.4 diff -c -r2.4 syntax.pl *** syntax.pl 1997/11/14 20:49:12 2.4 --- syntax.pl 1998/03/17 19:59:25 *************** *** 490,501 **** # # Now check the actual keywords # ! while($tmppol =~ s/(\S+)//) { ! if (!&isaskeyword($1)) { ! return $O_ERROR, ! "syntax error in \"$ATTL{$key}: peer $as cost $pref\"\n\t$1 ". ! ! "is not a routing policy KEYWORD"; } } return $O_OK; --- 490,501 ---- # # Now check the actual keywords # ! local($tmpword); ! foreach $tmpword ( split("\\s+", "$tmppol") ) { ! if (!&isaskeyword($tmpword)) { ! return $O_ERROR, ! "syntax error in \"$ATTL{$key}: peer $as cost $pref\"\n". ! \t$tmpword is not a routing policy KEYWORD"; } } return $O_OK;

6 8

auto-dbm "bad hair day".
by RIPE Database Administration 03 Mar '98

03 Mar '98

Dear Colleagues, There is a significant delay with <auto-dbm> today. This is due to a rare combination of events which have caused a heavy demand for resources. We have taken steps to improve the situation, and I do expect the situation to improve, although not as fast as I would like. Your updates are currently being queued and eventually they will be processed in the order in which they were delivered. However, some users continue to send very large updates during office hours and this slows the entire system down for everyone. I realise how important this is to you and that it is inconvenient. I take a personal pride in the speed at which auto-dbm responds and I wish to assure you that we are doing everything possible to restore the service to its usual level. Thank you for your patience today. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

None
by LOPEC, S.L. 14 Feb '98

14 Feb '98

Muy Sr. nuestro: Solicitamos su atención para presentarle nuestra publicación semanal "Confidencial de Economia, Negocios y Bolsa" En ella encontrara junto a noticias y comentarios de actualidad tratados con un rigor, profundidad y seriedad difíciles de hallar en otras publicaciones de difusion masiva, otras secciones de gran interes profesional referidas al mundo de los negocios, tales como oportunidades, ofertas y demandas de empresas extranjeras interesadas en encontrar socios españoles o viceversa, concursos, licitaciones tanto a nivel autonomico como nacional y comunitario, asi como una extensa referencia al mundo de la Bolsa, con especial informacion de las apuestas mas osadas (compras y ventas) de la semana. En el caso de que, como esperamos, sea de su interes conocer la publicacion, adjunto a la presente le adelantarnos el sumario, al tiempo que le ofrecemos la posibilidad de que pueda recibir gratruitamente y sin compromiso la publicacion durante las cuatro proximas semanas, sin otro requisito que faciltarnos los datos que le solicitamos al final de la presente para poder asi cumplimentar el envio. Atentamente, CONFIDENCIAL DE ECONOMIA Y BOLSA ref: CNN98 NOMBRE: DOMICILIO: DP-POBLACION PROVINCIA PAIS ACTIVIDAD TELEFONO E-MAIL

1 0

Re: Efficent allocation of sub blocks from a CIDR allocation
by Mike Norris 10 Feb '98

10 Feb '98

> Have you looked at TREE? > There ought to be a valid pointer from teh NAP page. Try ftp://ftp.bt.net/pub/networking/tools/tree/tree-2.1.5.tar.Z Mike

2 1

Efficent allocation of sub blocks from a CIDR allocation
by Mark Prior 10 Feb '98

10 Feb '98

Does anyone have any suggestions, or example code, on how to handle allocation of sub blocks from a CIDR allocation. Previously Connect has allocated a /24 as the minimal block but now the APNIC have advised that they do not consider this allocation policy to be efficent as defined by RFC 2050 and so I am trying to recode our procedures. I would like to find (or else write) some code that will "optimally" allocate sub blocks and generally manage our allocation (so I can return blocks to the pool when customers leave etc). For routing convenience (optimisation) I would like to also collect together sub /24 allocations for specific POPs so that we don't need to announce all the sub /24 blocks to multihomed customers, peers and providers. Any ideas? Or pointers to other people to ask (the APNIC have been silent on the issue after requiring us to do it before they will issue us another block). Mark.

2 1

at last: minutes for the September'97 DB-WG meeting
by Wilfried Woeber, UniVie/ACOnet 21 Jan '98

21 Jan '98

At last here are the draft minutes for the DB-WG meeting during RIPE-28 in Amsterdam. Thanks to Mike Norris for taking notes and for providing me with the file shortly after the meeting. The delay is exclusively my fault, 'cause I wanted to fix a broken name and a few other things - but didn't get aroud doing it in time. Eso es la vida... Apologies for the delay, and comments, corrections, etc. welcome as ususal. Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ D R A F T D R A F T D R A F T Database Working Group Minutes of Meeting, 24th September 1997 at RIPE 28 in Amsterdam The meeting began at 16:00. Wilfried Woeber chaired. 1. Admin Stuff Mike Norris acted as scribe. An agenda of business, as circulated, was agreed. The draft minutes of the DB WG meeting at RIPE 27 had been circulated recently. Comments and corrections were welcome on the mailing list. 2. DB AUP Enforcement Carol Orange reported steps to prevent misues of the RIPE database. Responses to database queries were now prefixed with a copyright notice, with a URL for full details. Those who wished to mirror the database for local use, or to copy it for any other purpose, had to enter into a contract with RIPE NCC; this stipulated, inter alia, that the copyright notice must always be displayed in responses. The NCC was alert to abuse of the database by massive querying. 3. DB SW Status Report Ambrose Magee reported on the status of the database software. whois client - refinements to the -v flag were almost complete - the copyrigt notice (see #2 above) Ack/notification messages - these could now be suppressed RPSL - to be dealt with in a special BoF the next day DSTF - is now active - details in plenary Cross notification - now implemented - available on TEST database New software - new release soon DB consistency project - work has started - deals only with internal inconsistencies at first - three phase approach - state of DB report - prevention - cleanup of existing objects - report by Hallowe'en Statistics - 500,000+ objects - 150,000 updates in August, a peak month - 2,000,000 queries in August Ambrose reminded people to use the -k (keep session open) when making a larger number of queries in a row. Immediate plans - cross notification - DB consistency - "to do" list in line with RIPE NCC activity plan In discussion, it was reported that the NCC would undertake work on referral (to other databases) on completion of cross notification. Results could be expected by RIPE 29. Dana Hudes complained of someone else using his Graphnet trade name as a net-name in the RIPE database. It was agreed that it was not the function of RIPE to enforce any laws, nor to interfere with data entered by users in the database. 4. Registry Data Exchange (RIDE) David Kessens gave a presentation. He said that RIDE would define a standard format for Internet registries, and would define and use a protocol for exchanging and retrieving objects in such registries. A draft charter for the work was ready and there was a mailing list (subscription requests to ride-request(a)isi.edu). Status was summarised at http://www.isi.edu/~david/ride/ In discussion, David said that RIDE involved RIPE, Internic and ARIN people. An overriding goal was to make the standard as simple as possible. 5. Merit/RSng Jake Khuon reported on work being done by Merit on privacy of attributes. For example, in the inet-rtr object, rs-in: and rs-out: would be public, but contact details would be private. A new PRIV attribute applied to all objects and used the existing security model. In discussion, it was agreed that real-time editing using RA tools would be nice, but needed more authentication. 6. RAWhoisd Compatibility David Kessens reported RAWhoisd extensions. The RAToolSet didn't use all the features of RAWhoisd. He listed some of the new server features that the ToolSet needed, and also some of the outstanding requirements of the server. Performance enhancements would require a lot of effort. Wilfried would circulate Cengiz Alaettinoglu's summary to the mailing list and would invite comments. 7. Input from other WGs The Local IR WG was considering new mechanisms of allocation and reverse delegation. Due care would be exercised with any changes, particularly concerning entries in the database. The Routing WG reported that the aut-num object would have a mnt-route: attribute which would specify one or more maintainers of route objects of the same origin. The attribute would not be mandatory, though; if absent, anyone could add a route object with the aut-num as origin. Joachim Schmitz also reported that controls were still needed to effect hierarchical authorisation. 8. Activity Plan Carol Orange spoke of the RIPE NCC activity plan for 1998 insofar as it concerned work on the database. Resources had been budgetted for database security. Also, the growth of the database might lead to a requirement for new software. In these areas, she looked to the WG for support in specifying what was required. Blasco Bonito asked how many orphan person: objects there were in the database. Carol said that there were many such objects and speculated that aging might be used to help maintain the consistency of the database. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB (&NIC) Handle: WW144 --------------------------------------------------------------------------

1 0

Proposed agenda (draft) for DB-WG at RIPE-29
by Wilfried Woeber, UniVie/ACOnet 21 Jan '98

21 Jan '98

This is the first draft agenda (proposal) for the DB-WG meeting next week. Some of the items with relevance for a broader audience are being put on the agenda for the plenary. Thus I suppose that we can finish business during the 1st of the two assigned slots. Nevertheless, there is a lot of things which could need attention, potentially by a bunch of people "representing" different WGs. Therefore I'd like to keep the 2nd slot open for last minute activities. As usual, comments, additions, etc. welcome! See you! Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-29, January 1998, Amsterdam Draft, Jan. 20, 1998 A. Administrative stuff (Wilfried Woeber, chair, 5min) - appointment of scribe - agenda bashing B. NCC Update (Ambrose Magee, 10min) C. DB Consistency: state of the database report (Kurt Dirnbauer, Horst Koenigshofer, 15min) D. DB SW Re-engineering (Mal Morris, 10min + discussion) - NCC proposal/status - new/changed functionality - user community involvment - implementation scenario(s) - application and/or environment specific aspects (exchange point administration, ...) E. Other developments - Registry data exchange (RIDE) - IRR security Y. Input from other WGs - t.b.d. Z. AOB -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB (&NIC) Handle: WW144 --------------------------------------------------------------------------

1 0

Specifying a layer-3 MLPA in the IRR
by Jake Khuon 16 Jan '98

16 Jan '98

Although I've already sent this to the routing WG mailing list, Gerald Winters suggested that the DB WG might be interested in at least the authorisation schema. I have written two draft proposals (one for RIPE-181 and the other for RPSL) on how to specify layer-3 MLPAs in the IRR. I'd like to welcome any comments. I'm including a copy of each draft below and they can also be found at: http://espresso.merit.net/~khuon/khuon-003.txt http://espresso.merit.net/~khuon/khuon-004.txt #include <khuon-003.txt> Specifying and Supporting a Layer-3 MLPA Using as-macros Jake Khuon Merit Network, Inc. Document ID: khuon-003 November, 1997 ABSTRACT This document describes a procedure and mechanism for implementing layer-3 MLPA support in the Internet Routing Registry using RIPE-181 as-macros. khuon-003.txt November, 1997 - 2 - Table of Contents 1 Introduction ................................................ 2 2 Organisation of this Document ............................... 2 3 Proposed Construction of an MLPA as-macro ................... 2 4 Architecture for an Authorisation and Control Mechanism for Maintaining an MLPA as-macro ................................ 3 5 References .................................................. 5 6 Author Address .............................................. 6 1. Introduction Several exchange points are making use of Multi-Lateral Peering Agreements to simplify both layer-2 and layer-3 peering. However, there is currently no mechanism to support those agreements to simplify router configuration. The most logical vehicle for specifying such an arrangement is the as-macro which is defined in [1]. Please refer to that document for more details. In the most general case, an MLPA is an agreement signed by members who wish to participate in a mutual full-mesh peering environment. This full-mesh may inhabit both layer-2 and/or layer-3. The concern with using as-macros for specifying an MLPA is that of scope of control. This macro must be modifiable by all organisations listed in the object, but one organisation should not be able to modify an attribute which references another organisation. I would like to acknowledge the contributions made by several people during the development of this document. Abha Ahuja helped in the initial design of the prescreening authorisation mechanism and Gerald Winters provided valuable input about the security considerations of the RIPE-181 language. 2. Organisation of this Paper This paper acts as both a guideline for registering MLPA-based as-macros and provides a schema for implementing a mechanism by which to handle proper control of those objects. Section 3 provides a suggested method for construction of the as-macro. Section 4 provides an architecture to be used to control maintenance of that object. 3. Proposed Construction of an MLPA as-macro The MLPA as-macro is constructed in much the same way as any other as-macro with the exception that the specified mnt-by references a controlling body which does not belong to any one organisation khuon-003.txt November, 1997 - 3 - listed. To provide for simpler implementation of the control mechanism, it is suggested that only one aut-num be referenced in each as-list attribute. It is also suggested that no as-macros be referenced by an as-list and that naming convention be strictly adhered to which would reference an aut-num to its mntner. Example: as-macro: AS-AADSMLPA descr: MLPA participants at the AADS NAP as-list: AS4550 as-list: AS683 as-list: AS2551 as-list: AS5646 as-list: AS2685 guardian: auto-mlpa(a)ameritech.net admin-c: Andrew Schmidt tech-c: Mark Cnota notify: mlpa-participants(a)ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa(a)ameritech.net 971123 source: RADB The mntner MAINT-AADSMLPA referenced above may look something like: Example: mntner: MAINT-AADSMLPA descr: People authorised to make changes for the AADS MLPA as-macro admin-c: Andrew Schmidt upd-to: noc(a)ameritech.net mnt-nfy: noc(a)ameritech.net auth: PGP-FROM noc(a)ameritech.net auth: PGP-FROM auto-mlpa(a)ameritech.net mnt-by: MAINT-AADSMLPA changed: noc(a)ameritech.net 971123 source: RADB In the above examples you will notice a reference to auto-mlpa(a)ameritech.net. Behind this email address will reside the actual gateway by which each of the organisations listed in the as-lists can submit changes. The details of this mechanism will be described below in Section 4. 4. Architecture for an Authorisation and Control Mechanism for Maintaining an MLPA as-macro The difficulty with using as-macros to specify an MLPA is the inability to implement a distributed and scoped authorisation mechanism for a single object. This document proposes a workaround by which an automated mailing list feeds a preprocessor that in turn will pre-authorise any object submissions before it itself submits the object through the traditional auto-dbm processor. Using the example above, auto-mlpa(a)ameritech.net is authorised to submit changes to AS-AADSMLPA. The auto-mlpa(a)ameritech.net mail khuon-003.txt November, 1997 - 4 - alias should point to a process which examines the submitted object and performs the following actions in the following order: 1. Determine the difference between the submitted object and current object. It should categorise these differences as one of the following operations: A. Addition of a new as-list B. Deletion of a current as-list If the submitted object contains an addition, it is advised that an as-macro containing a list of all the organisation's ASes present at that exchange point be further interrogated to determine if the addition may proceed. This is to prevent someone from just simply adding bogus ASes to the as-macro. 2. Interogate the aut-num reference listed in the as-list and determine via that aut-num's mnt-by if the submitter of the object is authorised. 3. Extract the object from the original email submission and resubmit it to the auto-dbm process of the database using the authentication method listed in the mntner of the as-macro (PGP signed in the above example). The following outlines an example of the process architecture: Suppose AS61234 (bogus.com) wishes to add itself to the AS-AADSMLPA macro. The submitter at AS1234 would submit a copy of the changed as-macro to the auto-mlpa preprocessor/gateway... v===============================================v as-macro: AS-AADSMLPA descr: MLPA participants at the AADS NAP as-list: AS4550 as-list: AS683 as-list: AS2551 as-list: AS5646 as-list: AS2685 as-list: AS61234 guardian: auto-mlpa(a)ameritech.net admin-c: Andrew Schmidt tech-c: Mark Cnota notify: mlpa-participants(a)ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa(a)ameritech.net 971123 source: RADB ^===============================================^ | | | [pgp -sta -u noc] [(sign via PGP) ] | +------------------- <noc(a)bogus.com> khuon-003.txt November, 1997 - 5 - | | | v [ -- auto-mlpa -- ] [1. Identified: add AS61234] [2. Query aut-num's mnt-by ] ????? ? ? ? v===============================================v aut-num: AS61234 descr: Bogus Organisation descr: Snerd Inc. as-in: from AS-AADSMLPA 100 accept ANY as-out: to AS-AADSMLPA announce AS61234 admin-c: Alonzo Snerd tech-c: Alonzo Snerd notify: noc(a)bogus.com mnt-by: MAINT-AS61234 changed: noc(a)bogus.com 970727 source: RADB ^===============================================^ | | | [3. Query mntner ] <---+ ? ????????????????????????????? ? ? ? v===============================================v mntner: MAINT-AS61234 descr: People authorised to make changes for AS61234 admin-c: Alonzo Snerd upd-to: noc(a)bogus.com mnt-nfy: noc(a)nogus.com auth: PGP-FROM noc(a)bogus.com mnt-by: MAINT-AS6234 changed: noc(a)bogus.com 970727 source: RADB ^===============================================^ | | | [4. Authentication satisfied] ---+ The preprocessor checks the submission and notices an addition for AS61234. It then queries for the mntner MAINT-AS61234 and checks the auth against the submitter. If the authentication scheme is satisfied, it will submit by-proxy the request to auto-dbm (using the proper auth scheme) thorisation against the mnt-by listed in the as-macro. Since the auth attribute lists auto-mlpa(a)ameritech.net as an authorised submitter, the checks will complete and the new macro with the addition of "as-list: AS61234" will take effect in RADB. khuon-003.txt November, 1997 - 6 - [5. Submit to auto-dbm ] | | v [auto-dbm] ??????????????????????? ? ? ? v===============================================v mntner: MAINT-AADSMLPA descr: People authorised to make changes for the AADS MLPA as-macro admin-c: Andrew Schmidt upd-to: noc(a)ameritech.net mnt-nfy: noc(a)ameritech.net auth: PGP-FROM noc(a)ameritech.net auth: PGP-FROM auto-mlpa(a)ameritech.net mnt-by: MAINT-AADSMLPA changed: noc(a)ameritech.net 971123 source: RADB ^===============================================^ 5. References [1] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., Karrenberg, D., Terpstra, M., Yu, J., "Representation of IP Routing Policies in a Routing Registry", ripe-181, October 1994. 6. Author's Address Jake Khuon Merit Network Inc. Bldg. 1, Ste. C2122 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 USA +1 (313) 763-4907 khuon(a)Merit.Net khuon-003.txt November, 1997 #endinc /* khuon-003.txt */ #include <khuon-004.txt> Specifying and Supporting a Layer-3 MLPA Using as-sets Jake Khuon Merit Network, Inc. Document ID: khuon-004 December, 1997 ABSTRACT This document describes a procedure and mechanism for implementing layer-3 MLPA support in the Internet Routing Registry using RPSL as-sets. khuon-004.txt December, 1997 - 2 - Table of Contents 1 Introduction ................................................ 2 2 Organisation of this Document ............................... 2 3 Proposed Construction of an MLPA as-set ..................... 2 4 Architecture for an Authorisation and Control Mechanism for Maintaining an MLPA as-set .................................. 3 5 References .................................................. 5 6 Author Address .............................................. 6 1. Introduction Several exchange points are making use of Multi-Lateral Peering Agreements to simplify both layer-2 and layer-3 peering. However, there is currently no mechanism to support those agreements to simplify router configuration. The most logical vehicle for specifying such an arrangement is the as-set which is defined in [1]. Please refer to that document for more details. In the most general case, an MLPA is an agreement signed by members who wish to participate in a mutual full-mesh peering environment. This full-mesh may inhabit both layer-2 and/or layer-3. The concern with using as-sets for specifying an MLPA is that of scope of control. This macro must be modifiable by all member organisations listed in the object, but one organisation should not be able to modify an attribute which references another organisation. I would like to acknowledge the contributions made by several people during the development of this document. Abha Ahuja helped in the initial design of the prescreening authorisation mechanism and Gerald Winters provided valuable input about the security considerations of the RIPE-181 and RPSL languages. 2. Organisation of this Paper This paper acts as both a guideline for registering MLPA-based as-sets and provides a schema for implementing a mechanism by which to handle proper control of those objects. Section 3 provides a suggested method for construction of the as-set. Section 4 provides an architecture to be used to control maintenance of that object. 3. Proposed Construction of an MLPA as-set The MLPA as-set is constructed in much the same way as any other as-set with the exception that the specified mnt-by references a controlling body which does not belong to any one organisation khuon-004.txt December, 1997 - 3 - listed. To provide for simpler implementation of the control mechanism, it is suggested that only one aut-num be referenced in each members attribute. It is also suggested that no as-sets be referenced by a members attribute and that naming convention be strictly adhered to which would reference an aut-num to its mntner. Example: as-set: as-aadsmlpa descr: MLPA participants at the AADS NAP members: AS4550 members: AS683 members: AS2551 members: AS5646 members: AS2685 admin-c: Andrew Schmidt tech-c: Mark Cnota notify: mlpa-participants(a)ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa(a)ameritech.net 19971123 source: RADB The mntner MAINT-AADSMLPA referenced above may look something like: Example: mntner: MAINT-AADSMLPA descr: People authorised to make changes for the AADS MLPA as-set admin-c: Andrew Schmidt upd-to: noc(a)ameritech.net mnt-nfy: noc(a)ameritech.net auth: PGP-FROM noc(a)ameritech.net auth: PGP-FROM auto-mlpa(a)ameritech.net mnt-by: MAINT-AADSMLPA changed: noc(a)ameritech.net 19971123 source: RADB In the above examples you will notice a reference to auto-mlpa(a)ameritech.net. Behind this email address will reside the actual gateway by which each of the organisations listed in the memberss can submit changes. The details of this mechanism will be described below in Section 4. 4. Architecture for an Authorisation and Control Mechanism for Maintaining an MLPA as-set The difficulty with using as-sets to specify an MLPA is the inability to implement a distributed and scoped authorisation mechanism for a single object. This document proposes a workaround by which an automated mailing list feeds a preprocessor that in turn will pre-authorise any object submissions before it itself submits the object through the traditional auto-dbm processor. Using the example above, auto-mlpa(a)ameritech.net is authorised to submit changes to as-aadsmlpa as-set. The auto-mlpa(a)ameritech.net mail alias should point to a process which examines the submitted object and performs the following actions in the following order: khuon-004.txt December, 1997 - 4 - 1. Determine the difference between the submitted object and current object. It should categorise these differences as one of the following operations: A. Addition of a new members B. Deletion of a current members If the submitted object contains an addition, it is advised that an as-set containing a list of all the organisation's ASes present at that exchange point be further interrogated to determine if the addition may proceed. This is to prevent someone from just simply adding bogus ASes to the as-set. 2. Interogate the aut-num reference listed in the members and determine via that aut-num's mnt-by if the submitter of the object is authorised. 3. Extract the object from the original email submission and resubmit it to the auto-dbm process of the database using the authentication method listed in the mntner of the as-set (PGP signed in the above example). The following outlines an example of the process architecture: Suppose AS61234 (bogus.com) wishes to add itself to the as-aadsmlpa macro. The submitter at AS1234 would submit a copy of the changed as-set to the auto-mlpa preprocessor/gateway... v===============================================v as-set: as-aadsmlpa descr: MLPA participants at the AADS NAP members: AS4550 members: AS683 members: AS2551 members: AS5646 members: AS2685 members: AS61234 admin-c: Andrew Schmidt tech-c: Mark Cnota notify: mlpa-participants(a)ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa(a)ameritech.net 19971123 source: RADB ^===============================================^ | | | [pgp -sta -u noc] [(sign via PGP) ] | +------------------- <noc(a)bogus.com> | | | v [ -- auto-mlpa -- ] khuon-004.txt December, 1997 - 5 - [1. Identified: add AS61234] [2. Query aut-num's mnt-by ] ????? ? ? ? v========================================================v aut-num: AS61234 as-name: bogus descr: Bogus Organisation import: from as-aadsmlpa action pref=1; accept ANY export: to as-aadsmlpa announce AS61234 admin-c: Alonzo Snerd tech-c: Alonzo Snerd notify: noc(a)bogus.com mnt-by: MAINT-AS61234 changed: noc(a)bogus.com 19970727 source: RADB ^========================================================^ | | | [3. Query mntner ] <---+ ? ? ? ????????????????????????????? ? ? ? v===============================================v mntner: MAINT-AS61234 descr: People authorised to make changes for AS61234 admin-c: Alonzo Snerd upd-to: noc(a)bogus.com mnt-nfy: noc(a)nogus.com auth: PGP-FROM noc(a)bogus.com mnt-by: MAINT-AS6234 changed: noc(a)bogus.com 19970727 source: RADB ^===============================================^ | | | [4. Authentication satisfied] ---+ The preprocessor checks the submission and notices an addition for AS61234. It then queries for the mntner MAINT-AS61234 and checks the auth against the submitter. If the authentication scheme is satisfied, it will submit by-proxy the request to auto-dbm (using the proper auth scheme) thorisation against the mnt-by listed in the as-set. Since the auth attribute lists auto-mlpa(a)ameritech.net as an authorised submitter, the checks will complete and the new macro with the addition of "members: AS61234" will take effect in RADB. [5. Submit to auto-dbm ] | khuon-004.txt December, 1997 - 6 - | | v [auto-dbm] ??????????????????????? ? ? ? v===============================================v mntner: MAINT-AADSMLPA descr: People authorised to make changes for the AADS MLPA as-set admin-c: Andrew Schmidt upd-to: noc(a)ameritech.net mnt-nfy: noc(a)ameritech.net auth: PGP-FROM noc(a)ameritech.net auth: PGP-FROM auto-mlpa(a)ameritech.net mnt-by: MAINT-AADSMLPA changed: noc(a)ameritech.net 19971123 source: RADB ^===============================================^ 5. References [1] C. Alaettinoglu. Routing Policy Specification Language (RPSL)., Internet Draft draft-ietf-rps-rpsl-03.txt, July, 1997, Work in progress. 6. Author's Address Jake Khuon Merit Network Inc. Bldg. 1, Ste. C2122 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 USA +1 (313) 763-4907 khuon(a)Merit.Net khuon-004.txt December, 1997 #endinc /* khuon-004.txt */ -- /*====================[ Jake Khuon <khuon(a)Merit.Net> ]=====================+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | Vox: (734) 763-4907 Fax: (734) 747-3185 / |/ |[_|\| | Incorporated | +==[ Suite C2122, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]==*/

1 0