- routing-wg - mailman.ripe.net

minutes of the RIPE 28 session
by SchmitzJo 19 Jan '98

19 Jan '98

Dear all, at last - the minutes of our last session at the RIPE 28 meeting are available. Obviously, I did not yet distribute them (shame on me). The responsibility for late delivery is on me alone. Please compile your additions or comments and distribute them to the mailing list before our session next week. Thanks Joachim ---- Minutes Routing WG ------------------ Chair: Joachim Schmitz (JS395-RIPE) Minutes: Julia Edwards (JE316-RIPE) Attenders: 75 A. Preliminaries Joachim Schmitz opened the working group, introduced himself, passed the attenders' list around, and asked for a volunteer scribe. Julia Edwards volunteered as scribe. The working group agreed upon the minutes of the previous meeting, and accepted the draft agenda earlier circulated on the mailing list. Review of actions RIPE 27 Action 26.R3: J. Schmitz - open. To finalize the hierarchical authorization for route objects together with the Routing WG Action 27.R1: Carol Orange, RIPE NCC - suggested to be closed. To implement cross notification in the RR with modifications as agreed at the meeting of the 27th RIPE Routing WG. Action 27.R2: Carol Orange, RIPE NCC - suggested to be closed. To implement aut-num authorisation in the RR Action 27.R3: RIPE NCC - closed. To ask Tony Bates to send a copy of his regular CIDR report to the general RIPE mailing list as well. Action 27.R4: Task Force (Tony Barber, Sean Doran, Daniel Karrenberg and Christian Panigl) - suggested to be closed. To write proposal document and circulate to the RIPE Routing WG mailing list for discussion as soon as possible. B. Current developments A glance at IETF activities shows two important groups RIDE - Registry Information Data Exchange Chairs: David Kessens, Dhaval Shah http://www.isi.edu/~davidk/ride There have been 2 BOF sessions up to now, and it will become an IETF working group soon. Major objective of the group is how registries can exchange data from their databases. RPS - Routing Policy Systems Chairs: Daniel Karrenberg, Cengiz Allaettinoglu http://www.ietf.org/html.charters/rps-charter.html This is already a working group with considerable work being done. Major objective is a formalized and extensible description of routing policies on the Internet. One of the results from the RPS working group is RPSL, the Routing Policy Specification Language. It goes far beyond the possibilities offered by RIPE-181, and it is planned to implement it at RIPE. To give the RIPE community an overview of the current situation and of planned activities a joint session of the Routing and DB working groups will be held this RIPE meeting. RPSL Transition Session Featuring issues around RPSL and its implementation 25 September 1997, 9:00am C. Report from RIPE NCC (Carol Orange) There are currently two important topics regarding routing issues the RIPE NCC is working on. On the one hand RPSL has a lot of attention where the RPSL Transition Session is meant to give an overview. Work on this field at the current stage consists of coordination for the most part, but in the near future database coding will be the most important item. On the other hand the notification schemes discussed with the Routing WG are currently implemented. D. Authorisation/Notification with Route Objects in the RIPE DB * Cross Notification (Carol Orange) Cross notification got approval to be implemented at the last RIPE meeting. Implementation has actually started but has not yet finished due to restricted manpower. Chris Fletcher has been working on it and cross notification will be available on the RIPE Test DB in October. * Aut-num Authorization revisited (Joachim Schmitz) Joachim Schmitz again summarized several questions on aut-num authorization. Some of those had already been decided in a previous wg session but the discussion led to final consensus in all points. The results summarized are - If aut-num objects carry "mnt-route" attributes specifying maintainers, *only those listed* are allowed to *add* route objects of same origin - If *no* "mnt-route" attributes are present, *anybody* may *add* route objects of same origin - Independently from "mnt-route" attributes, maintainers of route objects may *always delete* them However, these rules at this time can only be enforced for one single registry. There is no mechanism in place which prevents someone to register the routes he wants with another registry if it does not work for the one he originally intended to use. This again triggered some discussion and the results are - aut-num authorization will not be delayed because of this issue - coordination among registries is vital The RIPE NCC was asked to approach the other registries to discuss this item. Action 28.R1: Carol Orange, RIPE NCC Contact other RR on the topic of distributed authorization * Hierarchical Authorization revisited (Joachim Schmitz) The current state is that anybody may add route objects for any origin, except for control by aut-num authorization. A second hierarchy may be applied as well, based on IP prefixes like it exists for inetnum objects. This would mean that route objects of different origins for given IP address ranges could only be handled if properly authorized. However, authorization only makes sense if it is enforced. As a consequence, additional restrictions are imposed. The question now is whether these can be accepted. Cons: - Restrictions hinder current practice. Why should route objects be registered by anyone if the administrative effort is too high? Routers in real life do not depend on registration. Going this way leads to a weakened IRR. - Domains and IP address space (inetnum objects) are tied to ownership immediately calling for control. Yet, who "owns" routes? Pros: - Routing and filters may be built from registry data calling for a tighter control of route objects because invalid registry data directly impacts real world routing if router configs are generated from them. - Owning address space is worthless if it is not used. Usage is reflected in route objects making them important beyond mere technical operation. Unfortunately, even though there was some discussion on this topic, no real consensus was found. The general idea is that for the time being there is no demand to implement a hierarchical scheme based upon IP prefixes. E. Route Flap Dampening (Christian Panigl) Christian Panigl had sent out the paper from the task force on route flap dampening the week before. It had been read by many people. To summarize, he gave an overview of the current dampening parameters and recommendations - never start dampening before the 4th flap in a row - /24 will then be dampened for 1 hour - /22 and /23 : max: 45 min and min: 30 min - all else: max:30min, min: 10min - exceptions: 'golden networks': root dns He then added some related recommendations with regard to configurations of Cisco routers - no ip bgp fast-external-fallover - clear ip bgp soft He had some feedback on this first version of the paper. He then asked on how to proceed, especially on the idea to present this as a RIPE document. Daniel Karrenberg offered his editorial help, after the feedback received was incorporated in the paper. As a RIPE document it will be an official RIPE recommendation, and as such may lead to further development, e.g. to place it as an informational RFC. F. PAIR: Policy Analysis of Internet Routing (Jake Khuon) http://www.rsng.net/presentations/ripe28/pair/ PAIR consists of a series of web based tools to help understand and diagnose problems with IRR policy and announcements seen at the RSng Route Servers. It is built upon route servers, and users may see routing problems as they appear at the route servers. Other tools exist which partly have the functionality of PAIR. However, PAIR is more and comprises various functions in one shell providing a simple and uniform interface. Some of the functions include - compare announced route AS origins to register route objects - compare route announcements to registered routes - suggest route aggregation Routes are classified according to a color scheme - green: registered in the IRR and announced - red: registered but not announced - grey: announced but not registered Work has been in progress for 5 months now. Much of proposed functionality is not yet implemented but will be done in the near future. PAIR will be continuously developed. For further reference see Homepage: http://www.rsng.net/pair/ RSCV: http://www.rsng.net/rs-views/ G. Reports from other WGs There was no current input from other WGs. H. AOB Since there was no AOB the meeting was closed. Agenda ------ R I P E 2 8 A M S T E R D A M Routing Working Group Session 24-Sep-97 Draft Agenda A. Preliminaries (Joachim Schmitz) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 27 minutes - actions from earlier meetings B. Current Developments (Joachim Schmitz) - ietf - rpsl - rpsl transition session C. Report from the RIPE NCC (Daniel Karrenberg) D. Authorisation/Notification with Route Objects - implementations in database software (Carol Orange) - aut-num authorisation revisited (Joachim Schmitz) - hierarchical authorisation of route objects revisited (Joachim Schmitz) - discussion E. Route Flap Dampening Parameters (Christian Panigl) - report from the task force - the route flap dampening paper F. PAIR - Overview and Introduction (Jake Khuon) Y. General Input from Other WGs Z. AOB Summary of Actions ------------------ Action 26.R3: J. Schmitz To finalize the hierarchical authorization for route objects together with the Routing WG Action 27.R1: Carol Orange, RIPE NCC To implement cross notification in the RR with modifications as agreed at the meeting of the 27th RIPE Routing WG. Action 27.R2: Carol Orange, RIPE NCC To implement aut-num authorisation in the RR Action 27.R4: Task Force (Tony Barber, Sean Doran, Daniel Karrenberg and Christian Panigl). To write up the results on route flap dampening in a RIPE document Action 28.R1: Carol Orange, RIPE NCC Contact other RR on the topic of distributed authorization Julia Edwards, Joachim Schmitz, 01/18/98 ----

1 0

The Cidr Report
by Tony Bates 16 Jan '98

16 Jan '98

This is an auto-generated mail on Fri Jan 16 12:00:00 PST 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 16Jan98 0) General Status Table History ------------- Date Prefixes 090198 47514 100198 47408 110198 47661 120198 47816 130198 47654 140198 47809 150198 47905 160198 48136 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 98.6.10.0/24 from AS701 AS Summary ---------- Number of ASes in routing system: 3118 Number of ASes announcing only one prefix: 1448 (743 cidr, 705 classful) Largest number of cidr routes: 458 announced by AS3561 Largest number of classful routes: 991 announced by AS701 1) Gains by aggregating at the origin AS level --- 16Jan98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 696 390 306 44.0% iSTAR Internet, Inc. AS4293 417 205 212 50.8% IMCI AS174 880 675 205 23.3% Performance Systems International AS816 577 406 171 29.6% UUNET Canada (ASN-UUNETCA-AS4) AS3602 450 300 150 33.3% Sprint Canada Inc. AS3749 201 60 141 70.1% TECNET AS701 991 888 103 10.4% Alternet AS3751 122 46 76 62.3% SNET-AS AS721 352 278 74 21.0% DLA-ASNBLOCK-AS AS2048 162 90 72 44.4% LaNet AS5668 103 36 67 65.0% Century Telephone Inc. AS3804 203 141 62 30.5% Bell Solutions AS1 852 791 61 7.2% BBNPLANET AS549 217 162 55 25.3% ONet Backbone AS3464 120 65 55 45.8% Alabama Research and Education Ne AS271 111 56 55 49.5% BCnet Backbone AS7545 115 63 52 45.2% TPG Internet Pty Ltd AS1239 578 526 52 9.0% SprintLink Backbone AS72 84 36 48 57.1% Schlumberger Information Network AS4763 127 79 48 37.8% Telstra New Zealand AS719 502 457 45 9.0% LANLINK autonomous system AS1221 261 216 45 17.2% AARNET-AS AS4648 194 150 44 22.7% NZIX 2 AS684 84 42 42 50.0% Manitoba Regional Network Backbon AS3561 927 885 42 4.5% MCI AS3493 194 154 40 20.6% INTERLINK AS4740 331 292 39 11.8% ASN-OZEMAIL (Ozemail Pty Ltd) AS2711 93 54 39 41.9% SUNBELT-AS AS1691 161 123 38 23.6% BCTEL AS6332 81 44 37 45.7% TELNOR For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Your Search Engine Listing
by list＠LISTME.COM 15 Jan '98

15 Jan '98

To: routing-wg(a)ripe.net Is your site listed with the top search engines? ListMe will list you with 50 search engines and indexes for $90. Satisfaction guaranteed! Search engines are the only way most people have to find internet sites. But if your site is not listed, no one will find it. ListMe will submit your site for listing in the top 50 search engines for $90. Here's how it works: 1. Complete and return the form below. 2. We'll post your site to 50 search engines within two business days, and we'll send you a submission report when we're finished. 3. Pay nothing now. We'll send you an invoice after we've completed the posting. Your satisfaction is guaranteed! These are permanent listings. The $90 is a one-time fee. WHICH SEARCH ENGINES? Here's the list: Infoseek, Lycos, Excite, Alta Vista, Galaxy, HotBot, Magellan, Open Text Web Index, Web Crawler, BizWeb, New Riders WWW Yellow Pages, YelloWWWeb, True North, Northern Light, LinkMonster, The Weekly Bookmark, Seven Wonders, Jayde Online Directory, Starting Point, Web 100, Web Walker, New Page List, PeekABoo, One World Plaza, PageHost A-Z, Net-Announce, Project Cool, Where2Go, World Wide Business Yellow Pages, Sserv, Wow! Web Wonders!, WWW Worm, JumpCity, The Galactic Galaxy, TurnPike, Unlock:The Information Exchange, Your WebScout, Manufacturers Information Network, Net Happenings, Net Mall, Web World Internet Directory, InfoSpace, BC Internet, BizCardz Business Directory, Scrub The Web, WebVenture, Hotlist, What's New, WhatUSeek, JumpLink, Linkcentre Directory. ORDER FORM Hit the REPLY button on your e-mail program and fill out the following information. (This information will be posted to the search engines/indexes): Contact name: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: Contact e-mail address (in case we have questions about this order): URL: http:// Site Title: Description (250 characters): Key words (250 characters, in descending order of importance): If billing a different address, please complete the following: Addressee: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: TERMS Terms are net 15 days from date of invoice. ______________________________________________________________________ ListMe, Inc. 1127 High Ridge Road - Suite 184 Stamford CT 06905 Phone: (203) 326-8519 Fax: (203) 322-4505 E-mail: list(a)listme.com

1 0

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

15 Jan '98

Joachim suggested I send this off to the mailing list for discussion. I have written two draft proposals (one for RIPE-181 and the other for RPSL) on how to specifying 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

The Cidr Report
by Tony Bates 09 Jan '98

09 Jan '98

This is an auto-generated mail on Fri Jan 9 12:00:00 PST 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 09Jan98 0) General Status Table History ------------- Date Prefixes 020198 47531 030198 47597 040198 35241 050198 47479 060198 47617 070198 47694 080198 47566 090198 47514 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 3094 Number of ASes announcing only one prefix: 1455 (749 cidr, 706 classful) Largest number of cidr routes: 463 announced by AS3561 Largest number of classful routes: 985 announced by AS701 1) Gains by aggregating at the origin AS level --- 09Jan98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 668 376 292 43.7% iSTAR Internet, Inc. AS4293 414 202 212 51.2% IMCI AS174 890 681 209 23.5% Performance Systems International AS816 568 396 172 30.3% UUNET Canada (ASN-UUNETCA-AS4) AS3602 447 300 147 32.9% Sprint Canada Inc. AS3749 201 60 141 70.1% TECNET AS701 985 884 101 10.3% Alternet AS839 123 31 92 74.8% North West Territories Regional N AS3751 122 46 76 62.3% SNET-AS AS2048 164 92 72 43.9% LaNet AS5668 103 36 67 65.0% Century Telephone Inc. AS3804 203 139 64 31.5% Bell Solutions AS1 863 804 59 6.8% BBNPLANET AS3464 120 65 55 45.8% Alabama Research and Education Ne AS271 111 56 55 49.5% BCnet Backbone AS7545 115 63 52 45.2% TPG Internet Pty Ltd AS1239 581 529 52 9.0% SprintLink Backbone AS4763 127 76 51 40.2% Telstra New Zealand AS4648 196 146 50 25.5% NZIX 2 AS549 202 153 49 24.3% ONet Backbone AS72 84 36 48 57.1% Schlumberger Information Network AS719 506 460 46 9.1% LANLINK autonomous system AS1221 258 213 45 17.4% AARNET-AS AS3561 934 892 42 4.5% MCI AS684 83 43 40 48.2% Manitoba Regional Network Backbon AS4740 332 293 39 11.7% ASN-OZEMAIL (Ozemail Pty Ltd) AS2711 94 55 39 41.5% SUNBELT-AS AS1691 165 126 39 23.6% BCTEL AS6181 60 24 36 60.0% FUSE-NET AS1591 137 101 36 26.3% SAIC DISM For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

(no subject)
by ipopov 05 Jan '98

05 Jan '98

Dear sirs, chiefs of the enterprises! Our company "Talan" offers cooperation and services on conditions very favourable to you. The company "Talan" is engaged in the real estate (purshase, sale and rent of apartments, houses, offices, factories, shops etc.) in St.-Petersburg, Leningrad area, other regions of Russia. The firm "Talan" is large, stable and reliable real estate company of St.-Petersburg with the ramified network of branches, has high reputation at the clients, gives attention qualitative complex to service. The especial attention is given to marketing of the market of the real estate and effective advertising. The company has an opportunity decrement of legislative and tax policy, has experience of work in the international market of the real estate. The company "Talan" is situated at historical centre of St.-Petersburg, - first on beauty and in the second-largest city of Russia. Incorporated by Peter The Greate as "window in Europe", St.-Petersburg remains large cultural, scientific and technical, port and industrial, trade and business centre of Russia with the population more than 5 mln persons. Annually St.-Petersburg is visited by millions tourists and visitors from the whole world. We agree to carry sufficient expenses for search in our country of the buyer of your real estate. In case of fulfilment of the joint bargain the unit of the commission is made in a proportion 50/50%. In other cases the size of agency fee is stipulated in the contract. For operative communication and transfer of the information about the characteristics of objects, offered you, it is convenient to use channels of a network INTERNET. Vizit our site www.real.spb.ru/index_en.htm and answer us if you are interested in business in Russia. Yours faithfully General Director Kuzmin Serge Nik.

1 0

The Cidr Report
by Tony Bates 02 Jan '98

02 Jan '98

This is an auto-generated mail on Fri Jan 2 12:00:00 PST 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 02Jan98 0) General Status Table History ------------- Date Prefixes 261297 47433 271297 47424 281297 47380 291297 47497 301297 47601 311297 47560 010198 47266 020198 47531 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 3075 Number of ASes announcing only one prefix: 1452 (758 cidr, 694 classful) Largest number of cidr routes: 521 announced by AS3561 Largest number of classful routes: 973 announced by AS701 1) Gains by aggregating at the origin AS level --- 02Jan98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 698 391 307 44.0% iSTAR Internet, Inc. AS4293 417 199 218 52.3% IMCI AS174 882 675 207 23.5% Performance Systems International AS816 571 399 172 30.1% UUNET Canada (ASN-UUNETCA-AS4) AS3602 457 300 157 34.4% Sprint Canada Inc. AS3749 190 54 136 71.6% TECNET AS701 973 878 95 9.8% Alternet AS839 123 31 92 74.8% North West Territories Regional N AS3751 119 46 73 61.3% SNET-AS AS5668 102 37 65 63.7% Century Telephone Inc. AS2048 153 88 65 42.5% LaNet AS3804 202 140 62 30.7% Bell Solutions AS1 869 808 61 7.0% BBNPLANET AS549 218 161 57 26.1% ONet Backbone AS271 111 56 55 49.5% BCnet Backbone AS7545 115 63 52 45.2% TPG Internet Pty Ltd AS3464 119 67 52 43.7% Alabama Research and Education Ne AS1239 580 528 52 9.0% SprintLink Backbone AS4763 126 75 51 40.5% Telstra New Zealand AS4747 114 64 50 43.9% Taiwan Telecommunication Network AS4648 190 140 50 26.3% NZIX 2 AS72 84 36 48 57.1% Schlumberger Information Network AS719 505 460 45 8.9% LANLINK autonomous system AS3561 936 894 42 4.5% MCI AS1221 256 215 41 16.0% AARNET-AS AS684 82 43 39 47.6% Manitoba Regional Network Backbon AS6181 60 21 39 65.0% FUSE-NET AS4740 330 291 39 11.8% ASN-OZEMAIL (Ozemail Pty Ltd) AS2711 96 57 39 40.6% SUNBELT-AS AS1691 164 125 39 23.8% BCTEL For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

The Cidr Report
by Tony Bates 26 Dec '97

26 Dec '97

This is an auto-generated mail on Fri Dec 26 12:00:00 PST 1997 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 26Dec97 0) General Status Table History ------------- Date Prefixes 191297 46949 201297 46969 211297 46910 221297 46996 231297 47516 241297 47566 251297 47463 261297 47433 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 1662 Number of ASes announcing only one prefix: 778 (143 cidr, 635 classful) Largest number of cidr routes: 121 announced by AS3561 Largest number of classful routes: 583 announced by AS1 1) Gains by aggregating at the origin AS level --- 26Dec97 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS4293 201 102 99 49.3% IMCI AS72 84 36 48 57.1% Schlumberger Information Network AS719 505 460 45 8.9% LANLINK autonomous system AS174 298 258 40 13.4% Performance Systems International AS271 80 46 34 42.5% BCnet Backbone AS1 583 551 32 5.5% BBNPLANET AS1257 296 265 31 10.5% SWIPnet Swedish IP Network AS701 473 443 30 6.3% Alternet AS2493 97 73 24 24.7% iSTAR Internet, Inc. AS5381 58 36 22 37.9% PowerTech Information Systems AS AS8517 75 55 20 26.7% ULAKNET-ASN AS6822 37 19 18 48.6% SuperOnline autonomous system AS6663 35 17 18 51.4% InterComp Bucharest AS3663 25 7 18 72.0% NETNET-NET AS3563 59 41 18 30.5% Pilot Network Services, Inc. AS2048 45 28 17 37.8% LaNet AS2561 36 20 16 44.4% Egyptian Networks AS6897 32 17 15 46.9% Global-One Spain AS3564 29 15 14 48.3% Microserve Infromation Systems In AS2907 110 96 14 12.7% SINET AS1239 268 254 14 5.2% SprintLink Backbone AS6846 30 17 13 43.3% UKRPACK.NET AS1785 162 149 13 8.0% NYSERNet Backbone AS5666 35 23 12 34.3% Omnes - A Schlumberger and Cable AS4000 74 62 12 16.2% Global IP AS2752 38 26 12 31.6% THOMSONCA-AS AS549 93 82 11 11.8% ONet Backbone AS3577 30 19 11 36.7% PREPnet-WEST AS2686 46 35 11 23.9% Autonomous System number for IBM AS816 54 44 10 18.5% UUNET Canada (ASN-UUNETCA-AS4) For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

how to distinguish european routes from others
by Mart Norman 22 Dec '97

22 Dec '97

Hi! I'm not sure is this the right list for this question but what is the easiest way to distinguish european routes from others? Is anywhere a list of European AS-s? The reason I need this is that in nearest future we will have SAT channel to US and I would like to direct US traffic via SAT and European traffic via other channel. So I probably need to have as much as possible European routes in my box and point default to US. The problem is which nets are European and which are not. Thanks in advance, Mart =========================================================================== Mart Norman Technical Manager Esdata Ltd. Tel. +372 6 300 042 Akadeemia tee 21 GSM: +372 5 079 595 EE0026 Tallinn Fax +372 6 300 020 ESTONIA E-mail: mart(a)estnet.ee

2 1

(no subject)
by Thomas Groß 25 Nov '97

25 Nov '97

help

1 0