This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
Specifying a layer-3 MLPA in the IRR
- Previous message (by thread): No subject
- Next message (by thread): Proposed agenda (draft) for DB-WG at RIPE-29
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jake Khuon
khuon at Merit.Net
Fri Jan 16 02:56:43 CET 1998
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 at ameritech.net
admin-c: Andrew Schmidt
tech-c: Mark Cnota
notify: mlpa-participants at ameritech.net
mnt-by: MAINT-AADSMLPA
mnt-by: MAINT-RSPEER
changed: auto-mlpa at 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 at ameritech.net
mnt-nfy: noc at ameritech.net
auth: PGP-FROM noc at ameritech.net
auth: PGP-FROM auto-mlpa at ameritech.net
mnt-by: MAINT-AADSMLPA
changed: noc at ameritech.net 971123
source: RADB
In the above examples you will notice a reference to
auto-mlpa at 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 at ameritech.net is authorised to
submit changes to AS-AADSMLPA. The auto-mlpa at 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 at ameritech.net
admin-c: Andrew Schmidt
tech-c: Mark Cnota
notify: mlpa-participants at ameritech.net
mnt-by: MAINT-AADSMLPA
mnt-by: MAINT-RSPEER
changed: auto-mlpa at ameritech.net 971123
source: RADB
^===============================================^
|
|
|
[pgp -sta -u noc]
[(sign via PGP) ]
|
+------------------- <noc at 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 at bogus.com
mnt-by: MAINT-AS61234
changed: noc at 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 at bogus.com
mnt-nfy: noc at nogus.com
auth: PGP-FROM noc at bogus.com
mnt-by: MAINT-AS6234
changed: noc at 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 at 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 at ameritech.net
mnt-nfy: noc at ameritech.net
auth: PGP-FROM noc at ameritech.net
auth: PGP-FROM auto-mlpa at ameritech.net
mnt-by: MAINT-AADSMLPA
changed: noc at 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 at 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 at ameritech.net
mnt-by: MAINT-AADSMLPA
mnt-by: MAINT-RSPEER
changed: auto-mlpa at 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 at ameritech.net
mnt-nfy: noc at ameritech.net
auth: PGP-FROM noc at ameritech.net
auth: PGP-FROM auto-mlpa at ameritech.net
mnt-by: MAINT-AADSMLPA
changed: noc at ameritech.net 19971123
source: RADB
In the above examples you will notice a reference to
auto-mlpa at 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 at ameritech.net is authorised to
submit changes to as-aadsmlpa as-set. The auto-mlpa at 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 at ameritech.net
mnt-by: MAINT-AADSMLPA
mnt-by: MAINT-RSPEER
changed: auto-mlpa at ameritech.net 19971123
source: RADB
^===============================================^
|
|
|
[pgp -sta -u noc]
[(sign via PGP) ]
|
+------------------- <noc at 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 at bogus.com
mnt-by: MAINT-AS61234
changed: noc at 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 at bogus.com
mnt-nfy: noc at nogus.com
auth: PGP-FROM noc at bogus.com
mnt-by: MAINT-AS6234
changed: noc at 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 at 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 at ameritech.net
mnt-nfy: noc at ameritech.net
auth: PGP-FROM noc at ameritech.net
auth: PGP-FROM auto-mlpa at ameritech.net
mnt-by: MAINT-AADSMLPA
changed: noc at 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 at Merit.Net
khuon-004.txt December, 1997
#endinc /* khuon-004.txt */
--
/*====================[ Jake Khuon <khuon at 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 ]==*/
- Previous message (by thread): No subject
- Next message (by thread): Proposed agenda (draft) for DB-WG at RIPE-29
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]