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@ameritech.net admin-c: Andrew Schmidt tech-c: Mark Cnota notify: mlpa-participants@ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa@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@ameritech.net mnt-nfy: noc@ameritech.net auth: PGP-FROM noc@ameritech.net auth: PGP-FROM auto-mlpa@ameritech.net mnt-by: MAINT-AADSMLPA changed: noc@ameritech.net 971123 source: RADB In the above examples you will notice a reference to auto-mlpa@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@ameritech.net is authorised to submit changes to AS-AADSMLPA. The auto-mlpa@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@ameritech.net admin-c: Andrew Schmidt tech-c: Mark Cnota notify: mlpa-participants@ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa@ameritech.net 971123 source: RADB ^===============================================^ | | | [pgp -sta -u noc] [(sign via PGP) ] | +------------------- <noc@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@bogus.com mnt-by: MAINT-AS61234 changed: noc@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@bogus.com mnt-nfy: noc@nogus.com auth: PGP-FROM noc@bogus.com mnt-by: MAINT-AS6234 changed: noc@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@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@ameritech.net mnt-nfy: noc@ameritech.net auth: PGP-FROM noc@ameritech.net auth: PGP-FROM auto-mlpa@ameritech.net mnt-by: MAINT-AADSMLPA changed: noc@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@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@ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa@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@ameritech.net mnt-nfy: noc@ameritech.net auth: PGP-FROM noc@ameritech.net auth: PGP-FROM auto-mlpa@ameritech.net mnt-by: MAINT-AADSMLPA changed: noc@ameritech.net 19971123 source: RADB In the above examples you will notice a reference to auto-mlpa@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@ameritech.net is authorised to submit changes to as-aadsmlpa as-set. The auto-mlpa@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@ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa@ameritech.net 19971123 source: RADB ^===============================================^ | | | [pgp -sta -u noc] [(sign via PGP) ] | +------------------- <noc@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@bogus.com mnt-by: MAINT-AS61234 changed: noc@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@bogus.com mnt-nfy: noc@nogus.com auth: PGP-FROM noc@bogus.com mnt-by: MAINT-AS6234 changed: noc@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@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@ameritech.net mnt-nfy: noc@ameritech.net auth: PGP-FROM noc@ameritech.net auth: PGP-FROM auto-mlpa@ameritech.net mnt-by: MAINT-AADSMLPA changed: noc@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@Merit.Net khuon-004.txt December, 1997 #endinc /* khuon-004.txt */ -- /*====================[ Jake Khuon <khuon@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 ]==*/