From Tony.Bates at ripe.net Mon May 2 14:26:11 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Mon, 02 May 1994 14:26:11 +0200 Subject: as-out metrics In-Reply-To: Your message of Thu, 28 Apr 1994 23:01:12 MDT. <9404282101.AA19611@mellow.ripe.net> Message-ID: <9405021226.AA17951@mature.ripe.net> Trying to wade through all the mails from Friday. Not around sorry - this one definately catches my eye. DFK is correct here. What you have to be careful of with a general representation (which is what this is) is not to map too much current directly into the syntax. The fact is the peer can interperate this metric (what metric by the way ? MED, Local Pref, BGP passes two - just adding a little confusion to the clarity bag) as it wishes. The source has no control on it. It is an idication of policy but an indication potentially only available in some protocols and the granularity of intention is different per protocol. However, I do see that it may be useful to have "optional" indicative protocol metrics if it helps to clearly descride what pllicy is being set (this may need to map on a per peer basis in some cases so the semantics of the attribute needs the association to peer as well). Again, tools may have a hard time with this but..... --Tony. P.S. If this is all discussed later then apologies, Daniel Karrenberg writes: * * > Laurent Joncheray writes: * > * > > Is its use defined by the protocol? * > > My first impulse is to register this as * > > bgp-metric: ... * > > since it is protocol specific and needs a specific value configured * > > rhather than a relative cost. * > > Is this acceptable? * > * > Why changing everything? ALC handle this metric * > correctly, i don't see any need to create another attribute. * * Why? For clarity! * * The cost in as-in is relative. The absolute numbers do not have any meaning * . * It defines a static preference independent of protocol. * * The bgp-metric is something different, applicable only to BGP and its * use by the peer is not predicatble. So to my mind it should go somewhere * else. * * But I'll sleep over it. * * Daniel -------- Logged at Mon May 2 14:26:46 MET DST 1994 --------- From Tony.Bates at ripe.net Mon May 2 14:26:33 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Mon, 02 May 1994 14:26:33 +0200 Subject: rr-disc@rrdb.merit.edu In-Reply-To: Your message of Thu, 28 Apr 1994 23:08:12 MDT. <9404282108.AA19627@mellow.ripe.net> Message-ID: <9405021226.AA17963@mature.ripe.net> And me as well if I'm not already. --Tony. Daniel Karrenberg writes: * * > "Dale S. Johnson" writes: * > Daniel, Tony, Marten, * > * > I just bcc'd you on one message on rr-disc. Could I add you to that * list * * You can add me. Just don't expect a commitment to participate. If I am busy * it might get refiled or /dev/nulled without being read. * * daniel -------- Logged at Mon May 2 22:10:48 MET DST 1994 --------- From ala at merit.edu Mon May 2 22:10:45 1994 From: ala at merit.edu (Andrew Adams) Date: Mon, 2 May 1994 16:10:45 -0400 Subject: rash & passwd Message-ID: <199405022010.QAA19280@merit.edu> Hi. I was wondering if you guys had perhaps responded to dsj's question of last week concerning rash and passwd and I just didn't see it. We were wondering how you handle letting users set their own passwds with a chrooted shell. (The problem being that even if you give them their own copy of passwd under the "new" root, the _real_ /etc/passwd file can't be updated and thus telnet can't make use of the new passwd.) Did you guys write your own copy of passwd? (Dale's on vacation until Wednesday so we can't ask him if he got a reply. :-) ) Thanks. Andy -------- Logged at Tue May 3 00:09:24 MET DST 1994 --------- From GeertJan.deGroot at ripe.net Tue May 3 00:09:17 1994 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Tue, 03 May 1994 00:09:17 +0200 Subject: rash & passwd In-Reply-To: Your message of "Mon, 02 May 1994 16:10:45 EDT." <199405022010.QAA19280@merit.edu> Message-ID: <9405022209.AA02419@belegen.ripe.net> On Mon, 2 May 1994 16:10:45 -0400 Andrew Adams wrote: > Hi. I was wondering if you guys had perhaps responded to dsj's question > of last week concerning rash and passwd and I just didn't see it. We were > wondering how you handle letting users set their own passwds with a > chrooted shell. (The problem being that even if you give them their own > copy of passwd under the "new" root, the _real_ /etc/passwd file can't > be updated and thus telnet can't make use of the new passwd.) > > Did you guys write your own copy of passwd? That one is on my plate. I didn't have time to look at it yet (and I'm on vacation now...). At this time, the password is not settable by a rash user; they send in a UNIX-encrypted password or get a (random word) password assigned. Password is a dangerous program, both because it changes behaviour pending on argv[0] and command line arguments, and because it currently runs as root. I intend to make a second password-file (owned by a pseudo-user), from which *only* the password-entry is copied to the Master Password file (say, once a day). The rest of the entries (e.g. the dangerous shell field) are kept in another file OUTSIDE the rash environment. Please note that rash is still pretty dangerous; write a perl script in your guardian file, execute it, and put the 'real' guardian file back. We have not made this public.. I *don't* want a setiud root program in there if I can avoid it. Second, the guardian box is not integrated with the rest of the network, thus if it's broken, it doesn't mean the end of your network. I intend to work on the merge thing next week. Is this sufficient? Geert Jan > > (Dale's on vacation until Wednesday so we can't ask him if he got a reply. :- ) ) > > Thanks. > > Andy -------- Logged at Wed Apr 6 23:03:27 MET DST 1994 --------- From farrache at ccpnxt5.in2p3.fr Tue May 24 18:41:26 1994 From: farrache at ccpnxt5.in2p3.fr (Gilles Farrache) Date: Tue, 24 May 94 18:41:26 MET DST Subject: here's as far we have got. Message-ID: <9405241641.AA02412@ccpnxt5.in2p3.fr.> Tony, I still do not understand the goal of "component". This component lead to a very complicated mechanism of guardians. Why is it no simplier to have multiple route objects ? Let's take the example given in the document : >inetnum: 192.87.45.0 >netname: RIPE-NCC >descr: RIPE Network Coordination Centre >descr: Amsterdam, Netherlands >country: NL >admin-c: Daniel Karrenberg >tech-c: Marten Terpstra >connect: RIPE NSF WCW >aut-sys: AS3333 >comm-list: SURFNET >ias-int: 192.87.45.80 AS1104 >ias-int: 192.87.45.6 AS2122 >ias-int: 192.87.45.254 AS2600 >rev-srv: ns.ripe.net >rev-srv: ns.eu.net >notify: ops at ripe.net >changed: tony at ripe.net 940110 >source: RIPE >will be distributed over two objects: >inetnum: 192.87.45.0 >netname: RIPE-NCC >descr: RIPE Network Coordination Centre >descr: Amsterdam, Netherlands >country: NL >admin-c: Daniel Karrenberg >tech-c: Marten Terpstra >rev-srv: ns.ripe.net >rev-srv: ns.eu.net >notify: ops at ripe.net >changed: tony at ripe.net 940110 >source: RIPE >route: 192.87.45.0/24 >descr: RIPE Network Coordination Centre >origin: AS3333 >comm-list: SURFNET >component: 192.87.45.80/32 AS1104 >component: 192.87.45.6/32 AS2122 >component: 192.87.45.254/32 AS2600 >changed: dfk at ripe.net 940427 >source: RIPE The inetnum object can be split in four object : inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops at ripe.net changed: tony at ripe.net 940110 source: RIPE route: 192.87.45.0/24 descr: RIPE Network Coordination Centre origin: AS3333 comm-list: SURFNET changed: dfk at ripe.net 940427 source: RIPE route: 192.87.45.80/32 descr: RIPE Network Coordination Centre origin: AS1104 changed: dfk at ripe.net 940427 source: RIPE route: 192.87.45.6/24 descr: RIPE Network Coordination Centre origin: AS2122 changed: dfk at ripe.net 940427 source: RIPE route: 192.87.45.254/24 descr: RIPE Network Coordination Centre origin: AS2600 changed: dfk at ripe.net 940427 source: RIPE The sofware (whois or anything else ) will describe very easily the components of the route. It also allow easy cross-check as describe in page 17 for route object update procedure. In this case we have no problems of community added on components. The only problem remainig is the "HOLE" problem. Why not add an attribute on the route object called hole. In this case my proposal for the route object will be : Appendix D - Syntax for the "route" object. There is a summary of the tags associated with community object itself and their status. The first column specifies the attribute, the second column whether this attribute is mandatory in the commun- ity object, and the third column whether this specific attribute can occur only once per object [single], or more than once [multiple]. When specifying multiple lines per attribute, the attribute name must be repeated. See [6] the example for the descr: attribute. route: [mandatory] [single] descr: [mandatory] [multiple] origin: [mandatory] [single] hole: [optional] [multiple] comm-list: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] maintainer: [optional] [single] changed: [mandatory] [multiple] source: [mandatory] [single] Each attribute has the following syntax: route: Route being announced. Format: Classless representation of a route with the RIPE database known as the "prefix length" representation. See [10] for more details on classless representations. Examples: route: 192.87.45.0/24 This represents addressable bits 192.87.45.0 to 192.87.45.255. route: 192.1.128.0/17 This represents addressable bits 192.1.128.0 to 192.1.255.255. Status: mandatory, only one line allowed origin: The autonomous system announcing this route. Format: See appendix A for syntax. Example: origin: AS1104 Status: mandatory, only one line allowed hole: A route that is more specific than the one described and that is unreachable via the less specific route. (my english is poor) Format: Example: origin: 193.48.85/24 Status: optional, multiple line allowed comm-list: List of one or more communities this route is part of. Format: ... See Appendix B for definition. Example: comm-list: HEP LEP Status: optional, multiple lines allowed remarks: Remarks/comments, to be used only for clarification. Format: free text Example: remarks: Multihomed AS talking to AS1755 and AS786 remarks: Will soon connect to AS1104 also. Status: optional, multiple lines allowed notify: The notify attribute contains an email address to which notifi- cations of changes to this object should be send. See also [11]. Format: The should be in RFC822 domain syntax wherever possible. Example: notify: Marten.Terpstra at ripe.net Status: optional, multiple lines allowed maintainer: The maintainer attribute contains a registered maintainer name. See also [11]. Format: Example: maintainer: RIPE-DBM Status: optional, multiple lines allowed changed: Who changed this object last, and when was this change made. Format: YYMMDD should be the address of the person who made the last change. YYMMDD denotes the date this change was made. Example: changed: johndoe at terabit-labs.nn 900401 Status: mandatory, multiple lines allowed source: Source of the information. This is used to separate information from different sources kept by the same database software. For RIPE database entries the value is fixed to RIPE. Format: RIPE Status: mandatory, only one line allowed Gilles -------- Logged at Tue May 24 21:38:39 MET DST 1994 --------- From Marten.Terpstra at ripe.net Tue May 24 21:38:36 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 24 May 1994 21:38:36 +0200 Subject: here's as far we have got. In-Reply-To: Your message of Tue, 24 May 1994 18:41:26 +0700. <9405241641.AA02412@ccpnxt5.in2p3.fr.> Message-ID: <9405241938.AA09914@rijp.ripe.net> farrache at ccpnxt5.in2p3.fr (Gilles Farrache) writes * Tony, * * I still do not understand the goal of "component". This component * lead to a very complicated mechanism of guardians. Why is it no * simplier to have multiple route objects ? Gilles, I agree with you in some sense that this would be easier to read. However, as soon as you do this, you basically imply that you are inserting host routes, which you do not do. How do I distinguish a "route" object that is routed, from one that is not? That is very confusing. The whole idea about the component is to show parts of a route that have different information but are not routed as such. For prtraceroute for instance, with the route objects for all the interfaces as you described I would follow the host route as the correct route according to the routing registry. However, I am supposed to follow the DMZ since that is the only one really routed. There is a clear distinction in this that routes are routed, components are not, but simply provide extra information for the tools and troubleshooters. -Marten -------- Logged at Tue May 24 22:02:03 MET DST 1994 --------- From Tony.Bates at ripe.net Tue May 24 22:01:59 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Tue, 24 May 1994 22:01:59 +0200 Subject: here's as far we have got. In-Reply-To: Your message of Tue, 24 May 1994 21:38:36 MDT. <9405241938.AA09914@rijp.ripe.net> Message-ID: <9405242002.AA13172@mature.ripe.net> Marten Terpstra writes: * * farrache at ccpnxt5.in2p3.fr (Gilles Farrache) writes * * Tony, * * * * I still do not understand the goal of "component". This component * * lead to a very complicated mechanism of guardians. Why is it no * * simplier to have multiple route objects ? * * Gilles, * * I agree with you in some sense that this would be easier to read. * However, as soon as you do this, you basically imply that you are * inserting host routes, which you do not do. How do I distinguish a * "route" object that is routed, from one that is not? That is very * confusing. The whole idea about the component is to show parts of a * route that have different information but are not routed as such. * * For prtraceroute for instance, with the route objects for all the * interfaces as you described I would follow the host route as the * correct route according to the routing registry. However, I am * supposed to follow the DMZ since that is the only one really routed. * * There is a clear distinction in this that routes are routed, * components are not, but simply provide extra information for the tools * and troubleshooters. * Well yes and this paragraph is the important bit. Not the host route part as in practivce there would not be so many. But the important part of the component infomration is what is used to make up a route (the only thing used in actual routing). Remember a route is a route seen somewhere in the Internet. A component is not. * -Marten --Tony. -------- Logged at Tue May 24 22:06:20 MET DST 1994 --------- From farrache at ccpnxt5.in2p3.fr Tue May 24 22:06:15 1994 From: farrache at ccpnxt5.in2p3.fr (Gilles Farrache) Date: Tue, 24 May 94 22:06:15 MET DST Subject: here's as far we have got. Message-ID: <9405242006.AA02510@ccpnxt5.in2p3.fr.> >I agree with you in some sense that this would be easier to read. >However, as soon as you do this, you basically imply that you are >inserting host routes, which you do not do. How do I distinguish a >"route" object that is routed, from one that is not? That is very >confusing. The whole idea about the component is to show parts of a >route that have different information but are not routed as such. Clear there is no way to distinguish a route that is routed from one that is not routed. But It must also be clear that we are going to leave in a world with route declared and not announced (that is already the case in the NSFnet database because you do not destroy the subset at the same time that you create the superset). So if you want to clearly distinguish between was is routed and what is not why not creating an object that can be called "fortools" for example and with the same philosophy of a route except that this fortools will never be introduced in the routing mesh. Because you propose to have a very complicated guardians mechanism just for tools. Gilles -------- Logged at Tue May 24 23:58:43 MET DST 1994 --------- From lpj at merit.edu Tue May 24 23:58:36 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Tue, 24 May 94 17:58:36 EDT Subject: here's as far we have got. In-Reply-To: <9405242006.AA02510@ccpnxt5.in2p3.fr.>; from "Gilles Farrache" at May 24, 94 10:06 pm Message-ID: <199405242158.RAA26957@merit.edu> I think you should have something between RIPE and Gilles'proposals: The component syntax should only include the originator's AS and (of course) the IP address: component: |HOLE If someone wants to add a community or whatever he should create a route object and add the community in this object. As for the 'routed or not routed' thread, i cannot figure out an example where the route is routed and the components are not (except the holes :-) Does 'routed' means "announced with a E/BGP by someone" or "present in some configuration file" or "connected to the Internet"? It is kind of a pointless discussion IMHO. Laurent > >I agree with you in some sense that this would be easier to read. > >However, as soon as you do this, you basically imply that you are > >inserting host routes, which you do not do. How do I distinguish a > >"route" object that is routed, from one that is not? That is very > >confusing. The whole idea about the component is to show parts of a > >route that have different information but are not routed as such. > > Clear there is no way to distinguish a route that is routed from > one that is not routed. But It must also be clear that we are > going to leave in a world with route declared and not announced > (that is already the case in the NSFnet database because you > do not destroy the subset at the same time that you create the > superset). > > So if you want to clearly distinguish between was is routed and > what is not why not creating an object that can be called "fortools" > for example and with the same philosophy of a route except that > this fortools will never be introduced in the routing mesh. > > Because you propose to have a very complicated guardians > > mechanism just for tools. > > Gilles > -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Wed May 25 08:24:55 MET DST 1994 --------- From farrache at ccpnxt5.in2p3.fr Wed May 25 08:24:48 1994 From: farrache at ccpnxt5.in2p3.fr (Gilles Farrache) Date: Wed, 25 May 94 08:24:48 MET DST Subject: here's as far we have got. Message-ID: <9405250624.AA02717@ccpnxt5.in2p3.fr.> Laurent, Let's take the postulate : - A route is something that is present in the routing table of a router, belonging to an AS define in the routing registery, somewhere in the Internet. and let's try to demonstrate the following proposition : - You never need to define a component on a route object if you have the hole attribute. (considering that we are not dealing with the "host" definition used for prtraceroute or any other tools, this point will be looked at after). 1) In case of homogenous aggregation this is trivial. You are neither loosing any information in aggregating nor beeing able to add information that is the principle of the homogenous aggregation as define in page 13. 2) In case of heterogenous aggregation In the document (page 14) it is stated that teh community SPECIAL may not be relevant to routing, from my point of view that is nonsense. We are now dealing with a routing registery not with a global registery, so a community defined in a routing registrery must be relevant to routing !!!! And if this community is relevant to routing the route entry with community SPECIAL must be kept in the registery. So for the example given : route: 193.0.8.0/24 descr: Enterprise 2 origin: AS2 and route: 193.0.9.0/24 descr: Enterprise 2 origin: AS2 comm-list: SPECIAL the entries remaining in the routing registery will be in case of aggregation : route: 193.0.0.0/20 origin: AS2 hole: 193.0.0.0/24 hole: 193.0.2.0/23 hole: 193.0.4.0/22 hole: 193.0.10.0/23 hole: 193.0.12.0/22 and route: 193.0.9.0/24 descr: Enterprise 2 origin: AS2 comm-list: SPECIAL 3) Proxy aggregation Let's take the example of AS2 making proxy aggregation for AS1. AS1 has to be registred in the routing registery in order to be able to define its routing policy with AS2. AS1 is not able to aggregate and ask AS2 to do it for it. AS1 has still to declare all the routes that have to be announced in order to allow AS2 to build access-list or whatever. So the entries for AS1 in the routing registery will be : route: 193.0.8.0/24 origin: AS1 route: 193.0.9.0/24 origin: AS1 Now in order to aggregate AS2 will generate the following entry: route: 193.0.8.0/23 origin: AS2 descr: Proxy aggragate for AS1 but the entries of AS1 must not be deleted because they are used between AS1 and AS2. So no component is needded. CQFD. Conclusion : Components are never needed with the following condition that seems to be evident , a community defined in the routing registery is relevant for routing. (Just a point of detail, in the tool that will show the content of an aggregat hole will take precedence on route. I mean by that that if an aggregat is defined with hole, even if a route equivalent to the hole is present in the registery the hole will be shown) So now let's take the old attribute ias-int that is used for differents tools. Putting it as a component on a route is not the best solution. In fact it may happend that an interconnect net have not any connectivity outside an AS. An example is easy to find from AS789 to go to AS2156 you cross AS1717, all the interconnections nets on the road are local to AS1717 so they are not registred in the routing registry so all the tools are "broken"..... So to conclude my proposals are the following : 1) Define the community in the routing registry as related to routing. 2) Define the route object as I propose yesterday 3) Define a new object called dmzhost (or something like that) with the following definition : dmzhost: [mandatory] [single] origin: [mandatory] [single] gardian: [mandatory] [single] . . . This object will be a guarded object and will be used to define interfaces IP number as the old ias-int attribute of the inetnum object. dmzhost: IP number of an interface of a router in a DMZ Format: Ip number in "prefix form" Example: dmzhost: 192.10.10.10/32 origin: The autonomous number to which belongs the router with this IP address. Format: . . . . Comments .......... Gilles -------- Logged at Wed May 25 09:48:54 MET DST 1994 --------- From Marten.Terpstra at ripe.net Wed May 25 09:48:52 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 25 May 1994 09:48:52 +0200 Subject: here's as far we have got. In-Reply-To: Your message of Tue, 24 May 1994 17:58:36 EDT. <199405242158.RAA26957@merit.edu> Message-ID: <9405250748.AA10519@rijp.ripe.net> Laurent Joncheray writes * I think you should have something between RIPE and Gilles'proposals: * The component syntax should only include the originator's AS and * (of course) the IP address: * * component: |HOLE * * If someone wants to add a community or whatever he should create * a route object and add the community in this object. * As for the 'routed or not routed' thread, i cannot figure out an example * where the route is routed and the components are not (except the holes :-) Well, the simple case of proxy aggregation over multiple ASes in the text is one of these examples. * Does 'routed' means "announced with a E/BGP by someone" or * "present in some configuration file" or "connected to the Internet"? * It is kind of a pointless discussion IMHO. Routed means someone has it in their configuration, ie someone needs this info to be in the routing registry to configure their box. -Marten -------- Logged at Wed May 25 10:14:54 MET DST 1994 --------- From Marten.Terpstra at ripe.net Wed May 25 10:14:51 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 25 May 1994 10:14:51 +0200 Subject: here's as far we have got. In-Reply-To: Your message of Wed, 25 May 1994 08:24:48 +0700. <9405250624.AA02717@ccpnxt5.in2p3.fr.> Message-ID: <9405250814.AA10556@rijp.ripe.net> farrache at ccpnxt5.in2p3.fr (Gilles Farrache) writes * 2) In case of heterogenous aggregation * * In the document (page 14) it is stated that teh community SPECIAL may * not be relevant to routing, from my point of view that is nonsense. We It does not say it is not relevant to routing, it says it is an advisory tag. It cannot be anything else. It has the same status as as-exclude. * are now dealing with a routing registery not with a global registery, * so a community defined in a routing registrery must be relevant to * routing !!!! And if this community is relevant to routing the route * entry with community SPECIAL must be kept in the registery. * * route: 193.0.0.0/20 * origin: AS2 * hole: 193.0.0.0/24 * hole: 193.0.2.0/23 * hole: 193.0.4.0/22 * hole: 193.0.10.0/23 * hole: 193.0.12.0/22 * * and * * * route: 193.0.9.0/24 * descr: Enterprise 2 * origin: AS2 * comm-list: SPECIAL But Gilles, how do I know what routes are actually being used and what not? According to the two route objects above, I would expect to see 193.0.9.0/24 in my routing table, where the whole idea is that only 193.0.0.0/20 is routed ... * 3) Proxy aggregation * * Let's take the example of AS2 making proxy aggregation for AS1. AS1 * has to be registred in the routing registery in order to be able to * define its routing policy with AS2. AS1 is not able to aggregate and * ask AS2 to do it for it. AS1 has still to declare all the routes that * have to be announced in order to allow AS2 to build access-list or * whatever. So the entries for AS1 in the routing registery will be : * * route: 193.0.8.0/24 * origin: AS1 * * route: 193.0.9.0/24 * origin: AS1 * * Now in order to aggregate AS2 will generate the following entry: * * route: 193.0.8.0/23 * origin: AS2 * descr: Proxy aggragate for AS1 * * but the entries of AS1 must not be deleted because they are used * between AS1 and AS2. So no component is needded. CQFD. Again the problem is here that if AS1 has other (non-aggretable) routes there is no way to specify that the two more specifics are only relevant to the AS1 and AS2 and are not seen anywhere else. With components you can tell that these two are not seen specifically, but are used to make up the aggregate. I agree that components could be used in the config between AS1 and AS2 to derive the aggregate. * * Conclusion : * * Components are never needed with the following condition that seems * to be evident , a community defined in the routing registery is * * relevant for routing. * * (Just a point of detail, in the tool that will show the content * of an aggregat hole will take precedence on route. I mean by that * that if an aggregat is defined with hole, even if a route equivalent * to the hole is present in the registery the hole will be shown) * * So now let's take the old attribute ias-int that is used for * differents tools. Putting it as a component on a route is not the * best solution. In fact it may happend that an interconnect net * have not any connectivity outside an AS. An example is easy to * find from AS789 to go to AS2156 you cross AS1717, all the * interconnections nets on the road are local to AS1717 so * * they are not registred in the routing registry so all the * tools are "broken"..... Well that is obvious. If an dmz is not routed there is no way to get to it, so any tool will not work, even ping or traceroute ... That is not something specific to a routing registry. -Marten -------- Logged at Wed May 25 10:39:49 MET DST 1994 --------- From farrache at ccpnxt5.in2p3.fr Wed May 25 10:39:43 1994 From: farrache at ccpnxt5.in2p3.fr (Gilles Farrache) Date: Wed, 25 May 94 10:39:43 MET DST Subject: here's as far we have got. Message-ID: <9405250839.AA02850@ccpnxt5.in2p3.fr.> Marten , you write : > * route: 193.0.0.0/20 > * origin: AS2 > * hole: 193.0.0.0/24 > * hole: 193.0.2.0/23 > * hole: 193.0.4.0/22 > * hole: 193.0.10.0/23 > * hole: 193.0.12.0/22 > * > * and > * > * > * route: 193.0.9.0/24 > * descr: Enterprise 2 > * origin: AS2 > * comm-list: SPECIAL > >But Gilles, how do I know what routes are actually being used and what >not? According to the two route objects above, I would expect to see >193.0.9.0/24 in my routing table, where the whole idea is that only >193.0.0.0/20 is routed ... I just wen to remind you the postulate : - A route is something that is present in the routing table of a router, belonging to an AS define in the routing registery, somewhere in the Internet. --------- Somewhere does not mean in your router that mean for example in AS1 router. That has been clealy said by Tony in a previous mail : Tony Message : *Well yes and this paragraph is the important bit. Not the host route part *as in practivce there would not be so many. But the important part of the *component infomration is what is used to make up a route (the only thing *used in actual routing). Remember a route is a route seen somewhere *in the Internet. A component is not. --------- I know that the goal is to generate as big aggregat as we can but for example as 193.0.0.0 has been granted to Europe does that mean that the day when Europe will announce 193.0.0.0/8 to US all subset of 193.0.0.0/8 will vanished from the routing registery ? I cannot believe that. Then you write : >Again the problem is here that if AS1 has other (non-aggretable) >routes there is no way to specify that the two more specifics are only >relevant to the AS1 and AS2 and are not seen anywhere else. With >components you can tell that these two are not seen specifically, but >are used to make up the aggregate. I agree that components could be >used in the config between AS1 and AS2 to derive the aggregate. Again you are forgetting the postulate. And to tell the truth I will not be in favor to generate config depending on an attribut so difficult to manage. Gilles -------- Logged at Wed May 25 17:21:34 MET DST 1994 --------- From lpj at merit.edu Wed May 25 17:21:20 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Wed, 25 May 94 11:21:20 EDT Subject: more comments... Message-ID: <199405251521.LAA27586@merit.edu> > * As for the 'routed or not routed' thread, i cannot figure out an example > * where the route is routed and the components are not (except the holes :-) > > Well, the simple case of proxy aggregation over multiple ASes in the > text is one of these examples. Could you be more explicit? For me everything is routed. Some other points: - in the documment 'time to converge' the syntax for interas-out is In ripe-81++ this becomes: to announce Where is the preference? We need it. - in the documment 'time to converge' you refer to 'as-transit' and the db selector stuff. Those references disapear in ripe-81++. why? Laurent -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Wed May 25 17:28:42 MET DST 1994 --------- From Tony.Bates at ripe.net Wed May 25 17:28:33 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Wed, 25 May 1994 17:28:33 +0200 Subject: more comments... In-Reply-To: Your message of Wed, 25 May 1994 11:21:20 EDT. <199405251521.LAA27586@merit.edu> Message-ID: <9405251528.AA17346@mature.ripe.net> Laurent Joncheray writes: * Some other points: * - in the documment 'time to converge' the syntax for interas-out is * * In ripe-81++ this becomes: * to announce * Where is the preference? We need it. * Well this is only in the interas-out syntax where we agreed pref made no sense for outbound announcements. Too protocol specific. The "time to converge" shouldn't be taken as a proposal. * - in the documment 'time to converge' you refer to 'as-transit' and * the db selector stuff. Those references disapear in ripe-81++. why? * It was agreed these would be left to the experimental state stuff and I understood these would be written as seperate docs from ripe-81++. --Tony -------- Logged at Wed May 25 17:33:15 MET DST 1994 --------- From lpj at merit.edu Wed May 25 17:33:10 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Wed, 25 May 94 11:33:10 EDT Subject: more comments... In-Reply-To: <9405251528.AA17346@mature.ripe.net>; from "Tony Bates" at May 25, 94 5:28 pm Message-ID: <199405251533.LAA28975@merit.edu> > Well this is only in the interas-out syntax where we agreed pref made > no sense for outbound announcements. Too protocol specific. > The "time to converge" shouldn't be taken as a proposal. We agreed on as-out. Not interas-out. > * - in the documment 'time to converge' you refer to 'as-transit' and > * the db selector stuff. Those references disapear in ripe-81++. why? > * > It was agreed these would be left to the experimental state stuff and > I understood these would be written as seperate docs from ripe-81++. ^^^ "Tony Bates" i suppose? Definitly not me (lpj). Laurent -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Wed May 25 17:45:09 MET DST 1994 --------- From Tony.Bates at ripe.net Wed May 25 17:45:06 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Wed, 25 May 1994 17:45:06 +0200 Subject: more comments... In-Reply-To: Your message of Wed, 25 May 1994 11:33:10 EDT. <199405251533.LAA28975@merit.edu> Message-ID: <9405251545.AA17427@mature.ripe.net> Laurent Joncheray writes: * > Well this is only in the interas-out syntax where we agreed pref made * > no sense for outbound announcements. Too protocol specific. * > The "time to converge" shouldn't be taken as a proposal. * * We agreed on as-out. Not interas-out. * Well then fine - say why we need it. * > * - in the documment 'time to converge' you refer to 'as-transit' and * > * the db selector stuff. Those references disapear in ripe-81++. why? * > * * > It was agreed these would be left to the experimental state stuff and * > I understood these would be written as seperate docs from ripe-81++. * * ^^^ "Tony Bates" i suppose? Definitly not me (lpj). * Well I (yes that means Tony Bates) thought this was the consensus at least. In any case we would not write this part. Please realiase what we have done so far is exactly that - "so far". Now I (yeah that means Tony Bates again) would hope you could suggest how this should be worked into to the document and do the relavent honours with the text. --I -------- Logged at Thu May 26 10:44:17 MET DST 1994 --------- From farrache at ccpnxt5.in2p3.fr Thu May 26 10:44:04 1994 From: farrache at ccpnxt5.in2p3.fr (Gilles Farrache) Date: Thu, 26 May 94 10:44:04 MET DST Subject: Some more comments on components Message-ID: <9405260844.AA03407@ccpnxt5.in2p3.fr.> Hi Marten, Here comes a new day and some more comment on the component management. Let's assume the following configuration : ---AS2-----------AS1 ! ---AS3------------! AS1 is connected to AS2 and AS3 and cannot be used for transit trafic. At a first stage the routes entries for AS1 are : route: 193.0.8.0/24 origin: AS1 component: 193.0.8.1/32 AS2 component: 193.0.8.2/32 AS3 route: 193.0.9.0/24 origin: AS1 Then AS2 and AS3 start to agregate and that gives two entries : route: 193.0.0.0/20 origin: AS2 component: 193.0.0.0/23 HOLE component: 193.0.8.0/23 AS1 component: 193.0.12.0/22 HOLE and route: 193.0.0.0/20 origin: AS3 component: 193.0.2.0/23 HOLE component: 193.0.4.0/22 HOLE component: 193.0.8.0/23 AS1 component: 193.0.10.0/23 HOLE but on which entry are we going to put the old component stuff (the interace IP address) ? On the first ? On the second ? On both ? And from step to step we are going to end with objects completly unmanageable. In the case of a dmzhost object this will not occur. Gilles -------- Logged at Thu May 26 18:02:41 MET DST 1994 --------- From jyy at merit.edu Thu May 26 18:02:31 1994 From: jyy at merit.edu (Jessica Yu) Date: Thu, 26 May 1994 12:02:31 -0400 Subject: more comments... In-Reply-To: Your message of "Wed, 25 May 1994 17:45:06 +0200." <9405251545.AA17427@mature.ripe.net> Message-ID: <199405261602.MAA05545@merit.edu> >>Laurent Joncheray writes: >* > Well this is only in the interas-out syntax where we agreed pref made >* > no sense for outbound announcements. Too protocol specific. >* > The "time to converge" shouldn't be taken as a proposal. >* >* We agreed on as-out. Not interas-out. >* >Well then fine - say why we need it. Tony, Why we need it? Think about the following example: AS1 and AS2 interconnects at two different locations at connection point c1 and c2. AS2 likes to have AS1 send traffic to x via c1 as primary c2 as secondary. It can either grab the phone and call AS1 asking: 'please put in your interas-in statement to accept x at c1 with prefernce 1 and c2 with prefernce 2' or just put in its own interas-out statement using the to specify that. Now the point of express policy and register it is to avoid phone calles to communicate policies. Adding metric/pref in interas-out (or as a matter of fact as-out) is a win. In the NSFNet environment, we have many ASs interconnects with AS690 with multiple locations and using the same AS number now. Currently they use NCAR to express the preference policy, it is equivenlunt to express their as-out (interas-out) policy. In short, we really need the metric/pref be added in at least interas-out. --Jessica -------- Logged at Fri May 27 10:02:28 MET DST 1994 --------- From Marten.Terpstra at ripe.net Fri May 27 10:02:25 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Fri, 27 May 1994 10:02:25 +0200 Subject: more comments... In-Reply-To: Your message of Thu, 26 May 1994 12:02:31 EDT. <199405261602.MAA05545@merit.edu> Message-ID: <9405270802.AA13303@rijp.ripe.net> Jessica Yu writes * >>Laurent Joncheray writes: * >* > Well this is only in the interas-out syntax where we agreed pref made * * >* > no sense for outbound announcements. Too protocol specific. * >* > The "time to converge" shouldn't be taken as a proposal. * >* * >* We agreed on as-out. Not interas-out. * >* * >Well then fine - say why we need it. * * Tony, * * Why we need it? Think about the following example: * * AS1 and AS2 interconnects at two different locations at connection point c1 * and c2. * AS2 likes to have AS1 send traffic to x via c1 as primary c2 as secondary. * It can * either grab the phone and call AS1 asking: 'please put in your interas-in s * tatement * to accept x at c1 with prefernce 1 and c2 with prefernce 2' or just put in i * ts * own interas-out statement using the to specify that. Now the point o * f * express policy and register it is to avoid phone calles to communicate polic * ies. * Adding metric/pref in interas-out (or as a matter of fact as-out) is a win. Our main argument against preferences on outgoing policies has always been that this is the ONLY bit of policy information in the whole object that you CANNOT control. You can specify whatever you want, it completely depends on your neighbor to do the right thing. You have no control, your neighbor has. Besides that, the metric is *very* protocol dependent. In the case of BGP-4, there should be at least two metrics. Which is the one specified here? The definition in my mind is too vague, AND it is the only bit of policy that you actually cannot enforce. * In the NSFNet environment, we have many ASs interconnects with AS690 with mu * ltiple * locations and using the same AS number now. Currently they use NCAR to expr * ess * the preference policy, it is equivenlunt to express their as-out (interas-ou * t) * policy. I do not agree. The NACR does not specify their as-out, it specifies AS690's as-in. In any peer-peer agreement you have to communicate the desired policy to get it to work. AS690 enforces the ordering of announcements, not the regional. This is the whole point. * In short, we really need the metric/pref be added in at least interas-out. As you see, I do not agree. As far as I see, this metric is only needed because the gated config supports something like this. I however would prefer to keep a consistent model (ie I can enforce everything I register) than bending consistency to accomodate one type of router configuration. For the same reason, people using BGP-4 on cisco's may want two metrics. As proposed before, I much rather put all this (non-enforcable and very protocol dependent) information in a completely seperate place that clearly defines what they are and in what context. Something like a "bgpmetrics" attribute or something in that style. This can be clearly marked as local information, non-enforcable and as the name shows, protocol dependent. -Marten -------- Logged at Fri May 27 23:07:52 MET DST 1994 --------- From jyy at merit.edu Fri May 27 23:07:45 1994 From: jyy at merit.edu (Jessica Yu) Date: Fri, 27 May 1994 17:07:45 -0400 Subject: more comments... In-Reply-To: Your message of "Fri, 27 May 1994 10:02:25 +0200." <9405270802.AA13303@rijp.ripe.net> Message-ID: <199405272107.RAA09213@merit.edu> >Our main argument against preferences on outgoing policies has always >been that this is the ONLY bit of policy information in the whole >object that you CANNOT control. You can specify whatever you want, it >completely depends on your neighbor to do the right thing. You have no >control, your neighbor has. Besides that, the metric is *very* >protocol dependent. In the case of BGP-4, there should be at least two >metrics. Which is the one specified here? The definition in my mind is >too vague, AND it is the only bit of policy that you actually cannot >enforce. There are cases that people do not config a preference when accepting certain routes and rather they use the MED (Multi Exit Distriminator) information passed along with the routes. So the sending AS actually really specify the preference not the receiving AS. Let interas-out to specify its MED is to inform the receiving AS the policy it has and how the traffic will flow. There is no other way except a phone call to let the receiving AS know. One of the purpose of routing registry is to reduce the need to have phone such calls. The MED is not just bgp specific. IDRP has allow to specify that too. So it is not just for BGP. >I do not agree. The NACR does not specify their as-out, it specifies >AS690's as-in. In any peer-peer agreement you have to communicate the >desired policy to get it to work. AS690 enforces the ordering of >announcements, not the regional. This is the whole point. I am AS237, I want NSFNet to accept net 35 at router-eastcost as primary and router-westcoast as secondary. What do I do if I want to use this new syntax? I will say: interas-out: to AS690 1 announce {35} interas-out: to AS690 2 announce {35} How do I express that if I can not specify MED. I do not suppose I can write as-in for AS690. So as you can see, there are usage of being allow to specify MED in interas-out especially interas-out/interas-in is really for the policy exchange between the neighbor ASs. I was not in the meeting of various discussion at Amesterdam but this is how it relayed to me. --Jessica -------- Logged at Sat May 28 20:19:21 MET DST 1994 --------- From Marten.Terpstra at ripe.net Sat May 28 20:19:17 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Sat, 28 May 1994 20:19:17 +0200 Subject: more comments... In-Reply-To: Your message of Fri, 27 May 1994 17:07:45 EDT. <199405272107.RAA09213@merit.edu> Message-ID: <9405281819.AA14207@rijp.ripe.net> Jessica, Jessica Yu writes * * There are cases that people do not config a preference when accepting certai * n routes * and rather they use the MED (Multi Exit Distriminator) information passed al * ong with * the routes. So the sending AS actually really specify the preference not th * e * receiving AS. Let interas-out to specify its MED is to inform the receiving * AS * the policy it has and how the traffic will flow. There is no other way exce * pt a * phone call to let the receiving AS know. One of the purpose of routing regi * stry * is to reduce the need to have phone such calls. Well, again I do not agree. If I was to configure my router, I would NEVER base my configuration on my neighbours as-out lines (or interas-out for that matter). This is not so much a matter of translation into configuration or direct mapping into protocols, but about control. My neighbour can specify whatever he wants in his as-out, I make the decision (of course after discussing with my neighbour) HOW I want to receive his announcements. If you accept MED, you basically say you do not care how your neighbour sends his routes over multiple links. He can pick and choose whatever he wants, and by accepting MED you loose control over what he announces where. I strongly believe that you should only specify what you can enforce. * The MED is not just bgp specific. IDRP has allow to specify that * too. So it is not just for BGP. Not a fair argument. We all know that IDRP will be the logical successor of BGP-4 and is often referred to as BGP-5. Besides, IDRP can have many more attributes defined (see section 5.2.3 in draft-hares-idrp-05.txt). Do we include all of these? If not, can someone pick and choose which of the attributes the one specified in interas-out is? There is no way you can generate a complete router configuration without local information. You will always need this. I believe outgoing metrics is local/advisory information (again for the control argument). * How do I express that if I can not specify MED. I do not suppose I can writ * e * as-in for AS690. Noop you cannot. In the same way that you cannot specify that AS690 should accept MEDs on your connections. AS690 has control, not the neighbour. It is again enforcable versus advisory information. Mixing the two will give information you cannot base any tools on. -Marten -------- Logged at Mon May 30 11:18:18 MET DST 1994 --------- From jimi at dxcoms.cern.ch Mon May 30 11:18:08 1994 From: jimi at dxcoms.cern.ch (Jean-Michel Jouanigot) Date: Mon, 30 May 1994 11:18:08 +0200 (MET DST) Subject: here's as far we have got. In-Reply-To: <9405250814.AA10556@rijp.ripe.net> from "Marten Terpstra" at May 25, 94 10:14:51 am Message-ID: <9405300918.AA00457@dxcoms.cern.ch> Folks, I should say that what Gilles pointed out is sound, and, except for the description of the 'holes', I do like the idea to simplify the registry. I do not agree with Marten and Tony when you say that a component is never routed, or we have to change the definition of 'component'. Components (except for holes) bring nothing in case of simple aggregation, and in case of proxy, the components HAVE to be routed. Could anybody provides an example (except holes once again), where a component is really needed i.e. where the component shouldn't be registered as a route ? I don't see any (but I may be wrong :-) The big pro if this proposal is simplicity. We just have to find a way to represent holes, but this can be a new field. Concerning Jessica's concern on the interas-out metric, I do understand Merit's point of view, and it cannot really be implemented as a local field since it's something the tools will need when tracing inside 690... However, I'm not still convince it fits very well with the current scheme... I'm puzzled. The point is that we HAVE to find a solution! -- Jean-Michel -------- Logged at Mon May 30 12:08:05 MET DST 1994 --------- From farrache at ccpnxt5.in2p3.fr Mon May 30 12:07:59 1994 From: farrache at ccpnxt5.in2p3.fr (Gilles Farrache) Date: Mon, 30 May 94 12:07:59 MET DST Subject: here's as far we have got. Message-ID: <9405301007.AA05267@ccpnxt5.in2p3.fr.> In reading Jean Michel's mail I realize that there is a typo error on the definition I gave on the attribute hole. Th correct version is : hole: A route that is more specific than the one described and that is unreachable via the less specific route. (my english is poor) Format: Example: --------> hole: 193.48.85/24 and not origin: 193.48.85/24 Status: optional, multiple line allowed gilles -------- Logged at Tue May 31 17:41:57 MET DST 1994 --------- From jyy at merit.edu Tue May 31 17:41:53 1994 From: jyy at merit.edu (Jessica Yu) Date: Tue, 31 May 1994 11:41:53 -0400 Subject: more comments... Message-ID: <199405311541.LAA00335@merit.edu> Marten, * There are cases that people do not config a preference when accepting certai * n routes * and rather they use the MED (Multi Exit Distriminator) information passed al * ong with * the routes. So the sending AS actually really specify the preference not th * e * receiving AS. Let interas-out to specify its MED is to inform the receiving * AS * the policy it has and how the traffic will flow. There is no other way exce * pt a * phone call to let the receiving AS know. One of the purpose of routing regi * stry * is to reduce the need to have phone such calls. >Well, again I do not agree. If I was to configure my router, I would >NEVER base my configuration on my neighbours as-out lines (or >interas-out for that matter). This is not so much a matter of >translation into configuration or direct mapping into protocols, but >about control. My neighbour can specify whatever he wants in his >as-out, I make the decision (of course after discussing with my >neighbour) HOW I want to receive his announcements. If you accept MED, >you basically say you do not care how your neighbour sends his routes >over multiple links. He can pick and choose whatever he wants, and by >accepting MED you loose control over what he announces where. I >strongly believe that you should only specify what you can enforce. Actually, AS690's as-in is exactly specified by its neighbor ASs. The format of that is to use NCAR. So there is practice that AS configure their routers based neighbor's specification and it works well for all these years. * The MED is not just bgp specific. IDRP has allow to specify that * too. So it is not just for BGP. >Not a fair argument. We all know that IDRP will be the logical >successor of BGP-4 and is often referred to as BGP-5. Besides, IDRP >can have many more attributes defined (see section 5.2.3 in >draft-hares-idrp-05.txt). Do we include all of these? If not, can >someone pick and choose which of the attributes the one specified in >interas-out is? Would you tell me that routing protocols people are using and register with you currently? EGP and BGP right? Even EGP has outbound announcement metric which could be used by its neighbor. Would you tell me what inter-domain routing protocols people will use in the next 3 years? Again EGP, BGP and IDRP. In terms of metrics used by IDRP, MED like BGP. Other point: I feel puzzled that why it was decided to have both as-in/as-out and interas-in/ interas-out. The latter is somesort a superset of the former. Why define a system which has redundant attributes. I was told that interas-in/interas-out could be used to allow the neighbors to exchange more routing exchange information including the gateways,etc. If that is the case, then it REALLY MAKES SENSE to allow people to specify pref/metric in interas-out. --Jessica -------- Logged at Tue May 31 17:49:09 MET DST 1994 --------- From jyy at merit.edu Tue May 31 17:48:59 1994 From: jyy at merit.edu (Jessica Yu) Date: Tue, 31 May 1994 11:48:59 -0400 Subject: here's as far we have got. In-Reply-To: Your message of "Mon, 30 May 1994 11:18:08 +0200." <9405300918.AA00457@dxcoms.cern.ch> Message-ID: <199405311549.LAA00680@merit.edu> Concerning Jessica's concern on the interas-out metric, I do understand Merit's point of view, and it cannot really be implemented as a local field since it's something the tools will need when tracing inside 690... However, I'm not still convince it fits very well with the current scheme... I'm puzzled. The point is that we HAVE to find a solution! Jean-Michel: Actually, it fits quite well to the current scheme. interas-in/interas-out is for neighbors to communicate more routing exchange information between them. It seems natraul to allow ASs to specify pref/metric in interas-out. Thanks! --Jessica -------- Logged at Thu Jun 2 15:17:47 MET DST 1994 --------- From ala at merit.edu Tue May 3 14:39:13 1994 From: ala at merit.edu (Andrew Adams) Date: Tue, 03 May 1994 08:39:13 -0400 Subject: rash & passwd In-Reply-To: Your message of "Tue, 03 May 1994 00:09:17 +0200." <9405022209.AA02419@belegen.ripe.net> Message-ID: <199405031239.IAA28742@merit.edu> Yep, this answers my question. (Sorry to drag you away from your vacation :-( ). >Second, the guardian box is not integrated with the rest of the >network, thus if it's broken, it doesn't mean the end of your >network. I don't understand the above statement, though. Thanks. -Andy >On Mon, 2 May 1994 16:10:45 -0400 Andrew Adams wrote: >> Hi. I was wondering if you guys had perhaps responded to dsj's question >> of last week concerning rash and passwd and I just didn't see it. We were >> wondering how you handle letting users set their own passwds with a >> chrooted shell. (The problem being that even if you give them their own >> copy of passwd under the "new" root, the _real_ /etc/passwd file can't >> be updated and thus telnet can't make use of the new passwd.) >> >> Did you guys write your own copy of passwd? > >That one is on my plate. I didn't have time to look at it yet >(and I'm on vacation now...). At this time, the password is >not settable by a rash user; they send in a UNIX-encrypted >password or get a (random word) password assigned. > >Password is a dangerous program, both because it changes behaviour >pending on argv[0] and command line arguments, and because it >currently runs as root. I intend to make a second password-file >(owned by a pseudo-user), from which *only* the password-entry >is copied to the Master Password file (say, once a day). >The rest of the entries (e.g. the dangerous shell field) >are kept in another file OUTSIDE the rash environment. > >Please note that rash is still pretty dangerous; write a perl >script in your guardian file, execute it, and put the 'real' >guardian file back. We have not made this public.. >I *don't* want a setiud root program in there if I can avoid it. > >Second, the guardian box is not integrated with the rest of the >network, thus if it's broken, it doesn't mean the end of your >network. > >I intend to work on the merge thing next week. >Is this sufficient? > >Geert Jan > > > >> > > >> (Dale's on vacation until Wednesday so we can't ask him if he got a reply. : - >) ) >> >> Thanks. >> >> Andy -------- Logged at Tue May 3 14:50:52 MET DST 1994 --------- From Tony.Bates at ripe.net Tue May 3 14:50:33 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Tue, 03 May 1994 14:50:33 +0200 Subject: rash & passwd In-Reply-To: Your message of Tue, 03 May 1994 08:39:13 EDT. <199405031239.IAA28742@merit.edu> Message-ID: <9405031250.AA21777@mature.ripe.net> Andrew Adams writes: * * Yep, this answers my question. (Sorry to drag you away from your vacation : * -( ). * * >Second, the guardian box is not integrated with the rest of the * >network, thus if it's broken, it doesn't mean the end of your * >network. * * I don't understand the above statement, though. * Not sure I do either but I'll leave that to Geert Jan. However, One other thing about rash. I told Dale I'd wrap up some script we use. Here they are in a small shar. If not clear what they do and are interested please ask me (offline of list I guess ;-)). --Tony. #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh enab <<'END_OF_enab' X#!/local/bin/perl X# X# TB X# X# A well commented script. X$LOG="/nccfs3/dbase/newguard/log/enabled"; X$DATE=`date '+%y%m%d %T'`; Xchop($DATE); X$H="/home/guarded/home"; X$G="/nccfs3/dbase/guarded/as"; Xif($#ARGV ) { X print "usage: $0 account\n"; X exit 1; X} Xprintf STDOUT "Enabling the Guarded account $ARGV[0]\n"; Xsystem("passwd $ARGV[0]"); Xunlink "$H/$ARGV[0]/.autogen"; X$em = &getemail($ARGV[0]); Xprint "Enter new .forward address [$em] > "; Xwhile() { X $ans = $_; X last if /$/; X} Xchop($ans); Xif($ans eq "") { X $ans = $em; X} Xsystem ("echo \"$ans\" > $H/$ARGV[0]/.forward"); Xopen (L,">$LOG") || warn "can't open logfile $!"; Xprint L "$DATE $ARGV[0]"; Xclose(L); Xsymlink("$H/$ARGV[0]/$ARGV[0]", "$G/$ARGV[0]"); Xprint STDOUT "The account is now enabled\n"; X Xsub getemail { X local($as) = @_; X open (WHOIS, "/local/bin/whois -r -F $as |"); X while () { X if(/(^\*gd:\ )(.*$)/) { X return $2; X } X next; X } X return ""; X} END_OF_enab if test 921 -ne `wc -c genfiles <<'END_OF_genfiles' X#!/local/bin/perl X# X# This builds the guarded files automagically X# X# TB X# Xrequire "getopts.pl"; X X&Getopts('v'); X$home = "/home/guarded/home/"; # The home extra / needed X$file = ".autogen"; # Needs to see this file X$magicdir = "/nccfs1/local/spool/ftppublic/ripe/as/router/asdir"; X$date = `date '+%y%m%d'`; chop($date); X X# X# Loop the loop !! X# Xopen (LS, "cd $home; /bin/ls |"); Xwhile() { X chop; X $cur = $_; X next if (!-e "$home$cur/$file"); X if($opt_v) { X print "processing $cur\n"; X } X open (TMP, ">$home$cur/$cur.new") || warn "cant open $cur $!"; X rename("$home$cur/$cur", "$home$cur/$cur.old"); X chown((getpwnam($cur))[2], 30, "$home$cur/$cur.old"); X chmod (0644, "$home$cur/$cur.old"); X print TMP "#\n# File : $cur\n#\n"; X print TMP "#\n# This file was auto-generated for you on $date\n"; X print TMP "# by the RIPE Guarded Field File Generator\n#\n"; X $as = $cur; X #$as =~ s/as/AS/; X open(TMP2, "$magicdir/$as"); X while () { X chop; X $in = $_; X printf TMP "$in\n"; X } X close(TMP2); X close(TMP); X rename("$home$cur/$cur.new", "$home$cur/$cur"); X chown ((getpwnam($cur))[2], 30, "$home$cur/$cur"); X chmod (0644, "$home$cur/$cur"); X} X END_OF_genfiles if test 1158 -ne `wc -c genguard <<'END_OF_genguard' X#!/local/bin/perl X# X# This is the account builder. X# This will build an account that needs (or may need to be guarded at least). X# X# It is a perl script that builds and finally execs a shell script. X# X# This can be run in two modes every by reading a config or by passing a X# single (use -s arg) argument of "ASblah:GCOS" X# X# TB X# Xrequire "getopts.pl"; X# X$first = 14000; # This is the starting UID X # only needed for first gen X$commstart = 13000; X$asmacstart = 12000; X$first += 0; X$commstart + 0; X$asmacstart += 0; X$group = 30; # This is the GID X$home = "/home/guarded/./home/"; # The home extra / needed X$sh = "/local/bin/rash"; # The key to it all X$passwd = "/nccfs3/dbase/newguard/tmp/passwd.$$"; X$tmp = "/nccfs3/dbase/newguard/tmp/shell.$$"; X$profile = "/nccfs3/dbase/newguard/etc/profile"; X$forward = "/nccfs3/dbase/newguard/etc/forward"; X X X&Getopts('hvcms:'); X Xif ($opt_h) { X print STDOUT "Usage: genguard [-v] [-h] [config | -s \"ASnnn:GCOS\"]\n". X "Optional: [-m] for AS-macro\n". X " [-c] for community\n"; X exit 0; X} Xif ($opt_m && $opt_c) { X print STDOUT "Sorry - cant do an as-macro and community at the same time\n"; X exit 1; X} X$start = &getuid; Xif (!$start) { X if ($opt_m) { X $start = $asmacstart; X } elsif ($opt_c) { X $start = $commstart; X } else { X $start = $first; X } X} Xif ($opt_s) { X if ($opt_v) { X print STDOUT "Creating a single entry using \"$opt_s\"\n"; X } X open (FD, ">$passwd") || die "Can't open $passwd $!"; X if ($opt_m) { X if ($opt_s !~ /^[aA][sS]\-.*$/) { X print STDOUT "single entry has an error - exiting ! X\n"; X exit 1; X } X } elsif ($opt_c) { X if ($opt_s =~ /^[aA][sS].*$/) { X print STDOUT "single entry has an error - exiting ! X\n"; X exit 1; X } X } else { X if ($opt_s !~ /^[aA][sS]\d+:.*$/) { X print STDOUT "single entry has an error - exiting ! \n"; X exit 1; X } X } X if ($opt_v) { X print STDOUT "Creating password entry in $passwd\n"; X } X $line[0] =~ tr/a-z/A-Z/; X @line = split(/:/, $opt_s); X printf FD "%s:PASSWORD:%s:%s:%s:%s%s:%s\n", X $line[0], ++$start, $group, X $line[1], $home, $line[0], $sh; X $as{$line[0]} = 1; X} else { X if($#ARGV ) { X print STDOUT "No configfile given, assuming stdin\n"; X } X open (FD, ">$passwd") || die "Can't open $passwd $!"; X if ($opt_v) { X print STDOUT "Creating password entries in $passwd\n"; X } X while () { X chop; X next if (/^#/); # Allow comments in the config; X if (/^[aA][sS]/) { X @line = split(/:/, $_); X $line[0] =~ tr/a-z/A-Z/; X printf FD "%s:PASSWORD:%s:%s:%s:%s%s:%s\n", X $line[0], ++$start, $group, X $line[1], $home, $line[0], $sh; X $as{$line[0]} = 1; X } X } X} Xprintf STDOUT "Password entr%s created in $passwd\n", $opt_s ? "y" : "ies"; Xif ($opt_v) { X print STDOUT "Creating script in $tmp\n"; X} X Xopen (SHELL, ">$tmp") || die "can't open shell script $tmp $!"; X printf SHELL "#!/bin/sh\n"; X if ($opt_v) { X printf SHELL "set -x\n\t# you asked for -v\n"; X } X Xforeach $j (keys %as) { X printf SHELL "mkdir $home$j\n"; X printf SHELL "chmod 755 $home$j\n"; X printf SHELL "cp $profile $home$j/.profile\n"; X printf SHELL "cp $forward $home$j/.forward\n"; X printf SHELL "chmod 600 $home$j/.forward\n"; X printf SHELL "chown $j $home$j/.forward\n"; X printf SHELL "touch $home$j/$j\n"; X printf SHELL "chown $j $home$j/$j\n"; X} Xif ($opt_v) { X print STDOUT "$tmp creation done\n"; X} Xprint STDOUT "Shell script created in $tmp\n"; Xprint STDOUT <<"E_O_F"; X** Now all you do is the following:- X** Edit the passwd file and include $passwd X** at the end of the file like... Xvipw X:\$r $passwd X:x X** Then run script $tmp like.... Xsh $tmp X** them remove the files... Xrm -i $tmp $passwd XE_O_F X Xsub getuid { X local(@line) = ""; X local(@uid) = ""; X open (PASS, "/etc/passwd") || die "can't open password file $!"; X while () { X @line = split (/:/, $_); X next if ($line[3] != 30); X $line[2] += 0; X if($opt_c) { X if($line[2] >= $commstart && $line[2] < $first ) { X @uid = (@uid, $line[2]) ; X } X } elsif ($opt_m) { X if($line[2] >= $asmacstart && $line[2] < $commstart ) { X @uid = (@uid, $line[2]) ; X } X } X else { X @uid = (@uid, $line[2]); X } X } X return (sort num @uid)[$#uid]; X} Xsub num { $a <=> $b; } X END_OF_genguard if test 4431 -ne `wc -c Message-ID: <9405031852.AA02727@ncc.ripe.net> On Tue, 03 May 1994 08:39:13 -0400 Andrew Adams wrote: > >Second, the guardian box is not integrated with the rest of the > >network, thus if it's broken, it doesn't mean the end of your > >network. > I don't understand the above statement, though. That should teach me not to answer at late hours :-) The guardian box does not NFS-mount from other machines; neither does it have .rhosts or other funnies on other machines. If it is broken into (via a guardian account or not), it doesn't mean that the rest of our network is successfully broken into as well. Geert Jan -------- Logged at Tue May 17 16:11:10 MET DST 1994 --------- From ala at merit.edu Tue May 17 16:10:58 1994 From: ala at merit.edu (Andrew Adams) Date: Tue, 17 May 1994 10:10:58 -0400 Subject: DB User Intf Proposal Message-ID: <199405171410.KAA04723@merit.edu> Hi all. I've been playing with a couple of ideas and wanted to run them past you all. We are all concerned with having users update and maintain their own information in various databases; routing registry dbs, contact dbs, etc. Along with this desire comes the issue of authentication. Below are some thoughts on using HTML and a WWW browser such as NCSA Mosaic as a user interface to databases. The users are probably better off in the long run if we agree on the same approach and tools. I've been investigating the possibility of using HTML+ and an HTML browser such as XMosaic as a front end for our routing registry database. For those of you who don't know about World Wide Web stuff, here's a quick glossary. HTML stands for HyperText Markup Language. HTML is a page description language which allows you to define how pages look; for example, define sections that should be in bold or italics, etc. In addition, it also allows you to create hypertext links between pages. HTML+ is the follow-on to HTML. A superset of HTML, it also defines (among other things)_input_forms_. On a unix workstation running XMosaic, these forms appear as Motif scrolled lists, text widgets, push buttons, etc. Using a well defined application programming interface, data entered into a form can be passed off to any application you write, turned into a database query (or anything else for that matter), and then the results handed back to the user in the form of a new hypertext page. HTTP is the HyperText Transfer Protocol, the application level protocol used to serve up HTML(+) docs. Httpd is the daemon which serves documents on a given machine. It's important to understand the HTML(+) & Mosaic are information _browsing_ _tools_ and not database technologies. The database technology that sits behind HTML(+)/Mosaic is independant from HTML(+)/Mosaic. Ok, having said all that, I was thinking that it might be neat to let users enter and/or browse registry info using HTML(+) and Mosaic. For example, a user could start up XMosaic and load the "Registry Info Browser" page which would prompt them for a name and password. (See paragraphs on authentication below). The name could then be used to determine the ASs for which the user is the contact, and a screen displayed which would allow them to view their AS's current policy and submit changes if necessary. To test the feasability of this approach a bit, I cobbled together a little application to basically do the operation described in the paragraph above. To run the demo you need to have a Web browser like Mosaic running on your machine. (Note that MacMosaic won't work 'cause it doesn't yet handle the 'forms' stuff.) Fire up XMosaic and click "Open..." button at the bottom of the "Document View" window. In the pop-up dialog that appears, enter http://shockwave.merit.edu/ala_htdocs/pass.html A page with "This is a test" at the top, and 'Name' and 'Password' input fields should appear. In the 'Name' field enter 'bmanning'. In the 'Passwd' field enter 'xyzman'. Then click the 'Submit Query' button. A new page should appear which begins 'Access Granted to Bill Manning'. This page should also have a list widget full of the ASs for which Bill Manning has authority. This list is the result of sending off an SQL query to our Informix AS Contacts database. Select an AS to modify, say AS 114, and then click 'Submit Query.' A new page should appear for which the heading reads "Policy for AS114". The policy for AS 114 appears below the heading in an editable text widget. The policy is simply the output of a "whois -r rrdb.merit.edu AS114" command. Here now you could change the policy, click 'Submit Query' and have the changes made to the database. So authentication is definitely an issue here. I'm still learning about this stuff but from what I understand so far, a couple of different levels of authentication are possible. The authentiation used in my little prototype above is the simplest and thus, least secure. The password and user name are sent, over the net, to an authentication program I wrote. The name is looked up in a local password file and the supplied passwd is compared with the stored, encrypted password. This is arguably as secure as telnet. (Assume for a second that putting a Web deamon, httpd, on your machine isn't a big security hole in itself. I don't know how secure httpd is.) Actually, it is arguably slightly more secure than telnet because, if I read the doc correctly, the passwd string sent from a password widget is uuencoded. Thus, anyone running a sniffer would have to explicity look for and decode this. For stricter authentication, it appears that the HTTP protocol has constructs built in which allow for Kerberos, PGP and PEM. I don't yet know exaclty how to implement a system using these facilities, having only quickly browsed the documentation. Reasons for using WWW, HTML+ and Mosaic for browse and update registry info. (1) Ease of use .... for some operations. For occasional users and for operations which don't require a lot of hand editing, a point and click interface might be easier to use. ftp'ing a large file of network numbers might still be the easiest way to do, say, network additions. (2) Software Exists Now on Multiple Platforms HTML is an IETF standard (pretty sure about this) and HTML+ is in IETF Draft form. NCSA has Mosaic clients that run on nearly all Unix workstations. (The Mac client which supports HTML+ forms is rumored to be forthcoming, as is a Window's version.) This means we need not distribute client code to handle the user interface. Thoughts? -Andy -------- Logged at Tue May 17 17:40:48 MET DST 1994 --------- From markk at internic.net Tue May 17 17:32:40 1994 From: markk at internic.net (Mark Kosters) Date: Tue, 17 May 1994 11:32:40 -0400 (EDT) Subject: DB User Intf Proposal In-Reply-To: <199405171410.KAA04723@merit.edu> from "Andrew Adams" at May 17, 94 10:10:58 am Message-ID: <199405171532.LAA03077@slam.internic.net> This is an excellent idea. Scott and I have talked about this about using this as front-end to RWhois. RWhois then would be a navigation tool for a WWW browser. I don't believe that exists yet - or am I wrong? I'd be happy to help on this. Thanks, Mark > > > Hi all. I've been playing with a couple of ideas and wanted to run them past > you all. > > We are all concerned with having users update and maintain their own > information in various databases; routing registry dbs, contact dbs, etc. > Along with this desire comes the issue of authentication. Below are some > thoughts on using HTML and a WWW browser such as NCSA Mosaic as a user > interface to databases. The users are probably better off in the long run > if we agree on the same approach and tools. > > I've been investigating the possibility of using HTML+ and an HTML browser > such as XMosaic as a front end for our routing registry database. > > For those of you who don't know about World Wide Web stuff, here's a quick > glossary. > > HTML stands for HyperText Markup Language. HTML is a page description > language which allows you to define how pages look; for example, define > sections that should be in bold or italics, etc. In addition, it also > allows you to create hypertext links between pages. > > HTML+ is the follow-on to HTML. A superset of HTML, it also defines > (among other things)_input_forms_. On a unix workstation running XMosaic, > these forms appear as Motif scrolled lists, text widgets, push buttons, > etc. Using a well defined application programming interface, data entered > into a form can be passed off to any application you write, turned into a > database query (or anything else for that matter), and then the results > handed back to the user in the form of a new hypertext page. > > HTTP is the HyperText Transfer Protocol, the application level protocol > used to serve up HTML(+) docs. > > Httpd is the daemon which serves documents on a given machine. > > It's important to understand the HTML(+) & Mosaic are information _browsing_ > _tools_ and not database technologies. The database technology that sits > behind HTML(+)/Mosaic is independant from HTML(+)/Mosaic. > > Ok, having said all that, I was thinking that it might be neat to let users > enter and/or browse registry info using HTML(+) and Mosaic. For example, a > user could start up XMosaic and load the "Registry Info Browser" page which > would prompt them for a name and password. (See paragraphs on authentication > below). The name could then be used to determine the ASs for which the user > is the contact, and a screen displayed which would allow them to view their > AS's current policy and submit changes if necessary. > > To test the feasability of this approach a bit, I cobbled together a little > application to basically do the operation described in the paragraph above. > To run the demo you need to have a Web browser like Mosaic running on your > machine. (Note that MacMosaic won't work 'cause it doesn't yet handle the > 'forms' stuff.) Fire up XMosaic and click "Open..." button at the bottom > of the "Document View" window. In the pop-up dialog that appears, enter > > http://shockwave.merit.edu/ala_htdocs/pass.html > > A page with "This is a test" at the top, and 'Name' and 'Password' input > fields should appear. In the 'Name' field enter 'bmanning'. In the > 'Passwd' field enter 'xyzman'. Then click the 'Submit Query' button. > > A new page should appear which begins 'Access Granted to Bill Manning'. This > page should also have a list widget full of the ASs for which Bill Manning has > authority. This list is the result of sending off an SQL query to our Informix > AS Contacts database. Select an AS to modify, say AS 114, and then click > 'Submit Query.' > > A new page should appear for which the heading reads "Policy for AS114". The > policy for AS 114 appears below the heading in an editable text widget. > The policy is simply the output of a "whois -r rrdb.merit.edu AS114" command. > Here now you could change the policy, click 'Submit Query' and have the changes > made to the database. > > So authentication is definitely an issue here. I'm still learning about this > stuff but from what I understand so far, a couple of different levels of > authentication are possible. The authentiation used in my little prototype > above is the simplest and thus, least secure. The password and user name are > sent, over the net, to an authentication program I wrote. The name is looked > up in a local password file and the supplied passwd is compared with the > stored, encrypted password. This is arguably as secure as telnet. (Assume > for a second that putting a Web deamon, httpd, on your machine isn't a big > security hole in itself. I don't know how secure httpd is.) Actually, it > is arguably slightly more secure than telnet because, if I read the doc > correctly, the passwd string sent from a password widget is uuencoded. Thus, > anyone running a sniffer would have to explicity look for and decode this. > > For stricter authentication, it appears that the HTTP protocol has constructs > built in which allow for Kerberos, PGP and PEM. I don't yet know exaclty how > to implement a system using these facilities, having only quickly browsed > the documentation. > > Reasons for using WWW, HTML+ and Mosaic for browse and update registry info. > > (1) Ease of use .... for some operations. For occasional users and for > operations which don't require a lot of hand editing, a point and click > interface might be easier to use. ftp'ing a large file of network numbers > might still be the easiest way to do, say, network additions. > > (2) Software Exists Now on Multiple Platforms > HTML is an IETF standard (pretty sure about this) and HTML+ is in IETF > Draft form. NCSA has Mosaic clients that run on nearly all Unix > workstations. (The Mac client which supports HTML+ forms is rumored to > be forthcoming, as is a Window's version.) This means we need not > distribute client code to handle the user interface. > > > Thoughts? > > > -Andy > -- Mark Kosters markk at internic.net +1 703 742 4795 Software Engineer InterNIC Registration Services -------- Logged at Wed May 18 15:56:52 MET DST 1994 --------- From Marten.Terpstra at ripe.net Wed May 18 15:56:45 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 18 May 1994 15:56:45 +0200 Subject: DB User Intf Proposal In-Reply-To: Your message of Tue, 17 May 1994 10:10:58 EDT. <199405171410.KAA04723@merit.edu> Message-ID: <9405181356.AA01608@rijp.ripe.net> Andrew, I had a quick look and it looks nice. There's a few things that need sorting out: - this is not very good for people who maintain lots of data. I would in such cases prefer to just send it in using email or something else. I prefer my own editor over Mosaic. - how many people would have to have authorisation? You may end up with *many* people who need authorisation. It's basically a scaling issue, which we will have whatever we do with large amounts of data maintained by different organisations. I am basically stating what you say in your last paragraph, we should realize in what cases this is useful and in what cases there may be other ways that may be easier. -Marten -------- Logged at Wed May 18 16:06:06 MET DST 1994 --------- From ala at merit.edu Wed May 18 16:05:58 1994 From: ala at merit.edu (Andrew Adams) Date: Wed, 18 May 1994 10:05:58 -0400 Subject: DB User Intf Proposal In-Reply-To: Your message of "Wed, 18 May 1994 15:56:45 +0200." <9405181356.AA01608@rijp.ripe.net> Message-ID: <199405181405.KAA10797@merit.edu> > >Andrew, > >I had a quick look and it looks nice. There's a few things that need >sorting out: > >- this is not very good for people who maintain lots of data. I would >in such cases prefer to just send it in using email or something else. >I prefer my own editor over Mosaic. Agreed. It seems like it might be good for short editing operations like editing a short AS object, or one or two network objects. But if one wants to make wholescale changes, being able to use sed/awk/parsing programs/ ftp/etc is probably easier. > >- how many people would have to have authorisation? You may end up >with *many* people who need authorisation. It's basically a scaling >issue, which we will have whatever we do with large amounts of data >maintained by different organisations. I'd been thinking that you'd need as many authorizations as you have guardians. But I think I understand what you're saying. You're saying that right now, not all objects are guarded and therefore people can make changes to certain objects without having accounts. And you're wondering if I'm proposing that for anyone to be able to change data in the database, would they have to have a userid and passwd, yes? > >I am basically stating what you say in your last paragraph, we should >realize in what cases this is useful and in what cases there may be >other ways that may be easier. > Agreed. >-Marten -Andy -------- Logged at Wed May 18 20:55:55 MET DST 1994 --------- From Marten.Terpstra at ripe.net Wed May 18 20:55:44 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 18 May 1994 20:55:44 +0200 Subject: DB User Intf Proposal In-Reply-To: Your message of Wed, 18 May 1994 10:05:58 EDT. <199405181405.KAA10797@merit.edu> Message-ID: <9405181855.AA01860@rijp.ripe.net> * >- how many people would have to have authorisation? You may end up * >with *many* people who need authorisation. It's basically a scaling * >issue, which we will have whatever we do with large amounts of data * >maintained by different organisations. * * I'd been thinking that you'd need as many authorizations as you have * guardians. But I think I understand what you're saying. You're saying * that right now, not all objects are guarded and therefore people can make * changes to certain objects without having accounts. And you're wondering * if I'm proposing that for anyone to be able to change data in the database, * would they have to have a userid and passwd, yes? Yes. WHere does it stop? I am in the middle of a brainstorm session on the whole guarded attribute/object procedure, because I think it can and has to be done different. Expect some ideas tomorrow or Friday. I want to get some feel on what the right direction for the implementation for the principle of guarded information should be. Cheers, -Marten -------- Logged at Wed May 18 23:08:25 MET DST 1994 --------- From dsj at merit.edu Wed May 18 23:08:21 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 18 May 1994 17:08:21 -0400 Subject: DB User Intf Proposal Message-ID: <199405182108.RAA15632@merit.edu> Marten, 'Just some thoughts for your brainstorm (in case any of these are non- obvious): 1) The ability to use the whole Unix environment to support your guardian file is really wonderful (vi, emacs, diff, perl, ftp, RCS, ..., ... ) 2) Login access is troublesome; rash access eliminates a lot of the advantages of having a Unix environment. 3) The ability to support full-screen interfaces for new or infrequent users is good. (20% of our NACRs come through the full-screen Auto-NACR, and the quality of those is *much* higher than the stuff that is emailed. But then again we haven't implemented automatic email parsing and bouncing yet, which the RIPE software has.) 4) Free, ubiquitous, standard clients are great. (e.g. whois, mosaic). 5) There is a ned for authentication. This is a well-studied problem. It would be good to support a range of authentication methods, especially including new ones as they develop. (local passwords, .rhost-like restrictions, pem, kerberos, soft-key, etc). Possibly each object's owner could select which security level he wanted for the object (thought that's kind of extreme). Users need to be able to maintain their own authentication registrations (e.g. passwd; adding new registered users to the account; etc.) The more of this that comes for free by piggybacking on some existing client, the better. (Too many options are a real problem, too, of course, besides being a pain to maintain). We were tossing around one model after thinking about Rwhois: suppose there was an option for the guardian file to be a pointer to an anonymous ftp file on the user's machine? Or to a user's rwhois client? The Registry would then go grab this file once per night or once per use or some such (and default to the previous night's copy if the new one was unavailable). The user would have total control and total use of his native environment. Are guardian files retrievable by whois? (Could/should they be?) If there was a good, authenticated, standard, way to send a single named file to a named machine, that would nearly give us what we need. Users would maintain their data on their own machines, and then type: pr_update_guardian AS237 my_as237_guardian_file that would submit it to the database. Underneath, this would use mail or rcp or ftp or pem, with the right authentications, etc. The world really needs a version of rcp/rexec that specifies an exact list of commands that would be accepted, to keep the security hole small. Uucp used to have this, I think. Just some thoughts for the hopper... This is a great discussion to have. -Dale > I am in the middle of a brainstorm session on the whole guarded > attribute/object procedure, because I think it can and has to be done > different. Expect some ideas tomorrow or Friday. I want to get some > feel on what the right direction for the implementation for the > principle of guarded information should be. > > Cheers, > > -Marten -------- Logged at Thu May 19 13:48:26 MET DST 1994 --------- From Marten.Terpstra at ripe.net Thu May 19 13:48:22 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 19 May 1994 13:48:22 +0200 Subject: Brainstorm on guarded information Message-ID: <9405191148.AA02896@rijp.ripe.net> Folks, As said yesterday, I have written up some ideas on how to implement the idea of guarded information. I have worked out the current procedure in more detail than others below, simply because we have some experience with it. You will also see this could be the most complicated in a new ripe-81++ type scheme. We feel most for option 3 in the text below. Let's have some discussion. -Marten These are some ideas on how the principle of guarded attributes and objects can be implemented. All of this is in light of the ripe-81++ proposal for the route and autonomous system number. It deals mainly with the interface the guardian will have to the database, and how guarded information will be included in the database. These are very rough ideas. The first thing I want to get a feel of is what direction to go to. Details about implementation are not yet an issue, altough of course we have to keep in mind that whatever procedure we choose it can be implemented ;-) Some general remarks: - up till now, there has been a distinction between guarded attributes and guarded objects. If at all possible we should look for one method that can implemenent both. - we will have to find a balance between what is reasonably easy to implement, operate and usable for guardians. 1- The guarded file method This is basically the method as we have things now. Guarded attributes and objects are dealt with in different ways. Guarded attributes through the once a day examination of the files, guarded objects by means of the authorisation. I can currently see a few disadvantages: - guarded attributes are added only once a day - guarded attributes that change will be removed from normal updates - scaling issues with respect to guardian accounts - guarded objects have to be dealt with differently With the introduction of the route object, some more disadvantages can be found: - in the current inetnum object, the "aut-sys" attribute is optional. That means that whenever an object is send in with an aut-sys different than the current value it can be reset or ignored. Specifically in the case of new entries, the aut-sys will be removed. In the route object however, the "origin" attribute is mandatory. That means that for a new route object the origin cannot be ignored because that would invalidate the object. There is of course a way around that. One way would be to leave the once a day update mechanism and move to an on-the-fly guardian check. That means whenever an object is send in, the referenced guardian file is checked to see if it is allowed, and accepted if OK, bounced if NOK. Then another problem arises, because this means you will have to synchronize the updating of guardian files and the updating of route objects. The file must be updated first before a route object can be added. Some people I spoke with saw this as a problem. Solution for this would be to put the update request on hold if NOK, through some requeing mechanism, and bounce if after a day it still fails. Another solution mentioned was to accept the objects, but keep them hidden, and still do a nightly run to find all these objects and "unhide" them. I am not too fond of either of these solutions, although the requeueing is the best of the two. The complexity for the old but updated guarded file solution could get out of hand quite quickly I would think. 2- Modified guarded files Another solution that keeps the guardian account principle could be to change the format of the guardian file. Why should the guardian file only contain pointers to objects and not the objects themselves. So, in stead of guardians sending in objects and then check the files, they simply keep a file with all their objects on the database machine. On the database machine a daemon would scan around all guardian files every X minutes to find files that have been changed and update the information in that file. There can of course some refinements in the way the file is handled but that does not change the general principle. Advantages in my view are abvious: - definately guarded - no one a night procedure - no difficult checking for the database software - can be refined in many ways - the difference between guarded objects and attributes dissapears Disadvantages: - updates will not be immediate but can take X minutes There may be some other disadvantages, but many of them I can can be resolved by adding refinements to the file(s) the guardian keeps and the way the file is handled for updates. 3- Authentication in updates The perhaps most obvious solution is to do authentication on the updates people send in. In our case there would be some authentication in the mails people send there updates in, or even as far as per object. This could be implemented as simple as a magic string per mail where the string identified the guardian, or more complicated things like PEM or what have you. My vote would be to keep this as light but secure as possible. Obvious advantages: - no need for guardian accounts and files - no special procedures for guardians, they simply send in updates as they always would, just include some magic - less complexity and administration for database maintainer - the difference between guarded attributes and objects dissapears -------- Logged at Tue May 24 12:26:27 MET DST 1994 --------- From farrache at ccpnxt5.in2p3.fr Tue May 24 12:26:22 1994 From: farrache at ccpnxt5.in2p3.fr (Gilles Farrache) Date: Tue, 24 May 94 12:26:22 MET DST Subject: Brainstorm on guarded information Message-ID: <9405241026.AA01942@ccpnxt5.in2p3.fr.> Marten, There a few things I do not understand in your second point : >2- Modified guarded files How to deal with garded attributes ? I perfectly understand that this solution will be fine for handling things as the route object. But how can the gardian of an attribute (like the community list) will be able to tag a route ? Will the gardian of the route include the community in his file or will the gardian of the community include a route object in his file (in any case that is not the goal of the game) ? Why not a mix of two solutions : 1) Update via mail with a pass for guarded objects 2) Guarded files for guarded attribute (perhaps with more frequent updates) Gilles -------- Logged at Tue May 24 17:25:38 MET DST 1994 --------- From Tony.Bates at ripe.net Tue May 24 17:25:22 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Tue, 24 May 1994 17:25:22 +0200 Subject: here's as far we have got. Message-ID: <9405241525.AA12858@mature.ripe.net> Find below the latest draft of RIPE-81++. This trys to incorperate the changes mentioned and also proposes the interas-in and interas-out syntax we suggested with some explainatory text. Other changes are more general with a big tidy of syntax and all additions as per "time to converge" paper. The one caveat to this is the components part has only minor changes which we hope make it more readable now without having to do a major re-write. For our part we are now going to stand back from it for a few days and take in all the comments. These will then be edited in for sending out to the RIPE list as agreed. Please also note that whilst the ascii version is fine for annotating and comments the postscript version may be more readable especially for the syntax formats as they now look. The postscript version is available from ftp.ripe.net:ripe/drafts/ripe-81++.ps Regards, --Tony. Representation of IP Routing Policies in a Routing Registry (ripe-81++) DRAFT DRAFT DRAFT Tony Bates Elise Gerich Laurent Joncheray Jean-Michel Jouanigot Daniel Karrenberg Marten Terpstra Jessica Yu Document-ID: ripe-1nn Obsoletes: ripe-81 May, 1994 ABSTRACT This document is an update to the original `ripe- 81'[1] proposal for representing and storing routing polices within the RIPE database. It incorporates several extensions proposed by Merit Inc.[2] and gives details of a generalised IP routing policy representa- tion to be used by all Internet routing registries. It acts as both tutorial and provides details of database objects and attributes that use and make up a routing registry. ripe-1nn.txt May, 1994 - 2 - Table of Contents 1 Introduction ................................................ ? 2 Organisation of this Document ............................... ? 3 General Representation of Policy Information ................ ? 4 The Routing Registry and the RIPE Database .................. ? 5 The Route Object ............................................ ? 6 The Autonomous System Object ................................ ? 7 The AS Macro Object ......................................... ? 8 The Community Object ........................................ ? 9 Representation of Routing Policies .......................... ? 10 References ................................................. ? 11 Authors Addresses .......................................... ? Appendix A - Syntax for the "aut-num" object .................. ? Appendix B - Syntax for the "community" object ................ ? Appendix C - Syntax for the "as-macro" object ................. ? Appendix D - Syntax for the "route" object .................... ? Appendix E - Motivations for RIPE-81++ ........................ ? Appendix F - Transition strategy from RIPE-81 to RIPE-81++ .... ? ripe-1nn.txt May, 1994 - 3 - 1. Introduction This document is a much revised version of the RIPE routing registry document known as ripe-81[1]. Since its inception in February, 1993 and the establishment of the RIPE routing registry, several addi- tions and clarifications have come to light which can be better presented in a single updated document rather than separate addenda. Some of the text remains the same the as the original ripe-81 docu- ment keeping its tutorial style mixed with details of the RIPE data- base objects relating to routing policy representation. However this document does not repeat the background and historical remarks in ripe-81. For these please refer to the original document. It should be noted that whilst this document specifically references the RIPE database and the RIPE routing registry one can easily read "Regional routing registry" in place of RIPE as this representation is certainly general and flexible enough to be used outside of the RIPE community incorporating many ideas and features from other routing registries in this update. As you can see this document has a new RIPE document identification number but can also be referred to as ripe-81++. Appendix E summar- ises the changes from ripe-81 plus the motivation for these changes. We would like to acknowledge many people for help with this docu- ment. Specifically, Peter Lothberg who was a co-author of the ori- ginal ripe-81 document for his many ideas and Gilles Farrache. We would also like to thank the RIPE routing working group for their review and comment. Finally, we like to thank Merit Inc. for many constructive comments and ideas and making the routing registry a worldwide Internet service. We would also like to acknowledge the funding provided by the PRIDE project run in conjunction with the RARE Technical Program, RIPE and the RIPE NCC without which this paper would not have been possible. 2. Organisation of this Paper This paper acts as both a basic tutorial for understanding routing policy and provides details of objects and attributes used within an Internet routing registry to store routing policies. Section 3 describes general issues about IP routing policies and their representation in routing registries. Experienced readers may wish to skip this section. Section 4 provides an overview of the RIPE database, its basic concepts, schema and objects which make up the database itself. It highlights the way in which the RIPE database splits routing information from allocation information. Sections 5, 6, 7 and 8 detail all the objects associated with routing policy representation. Section 9 gives a fairly extensive "walk through" of how these objects are used for expressing routing policy and the general principles behind their use. Section 10 provides a list of references used throughout this document. Appendix A, B, C and D document the formal syntax for the database objects and attributes. Appendix E details the main changes from ripe-81 and motivations for these changes. Appendix F tackles the issues of transition from ripe-1nn.txt May, 1994 - 4 - ripe-81 to ripe-81++. ripe-1nn.txt May, 1994 - 5 - 3. General Representation of Policy Information Networks, Network Operators and Autonomous Systems Throughout this document an effort is made to be consistent with terms so as not to confuse the reader. When we talk about "networks" we mean physical networks which have a unique classless IP network number: Layer 3 entities. We do not mean organisations. We call the organisations operating networks "network operators". For the sake of the examples we divide network operators into two categories: "service providers" and "customers". A "service pro- vider" is a network operator who operates a network to provide Internet services to different organisations, its "customers". The distinction between service providers and customers is not clear cut. A national research networking organisation frequently acts as a service provider to Universities and other academic organisations, but in most cases it buys international connectivity from another service provider. A University networking department is a customer of the research networking organisation but in turn may regard University departments as its customers. An Autonomous System (AS) is a group of IP networks having a single clearly defined routing policy which is run by one or more network operators. Inside ASes IP packets are routed using one or more Inte- rior Routing Protocols (IGPs). In most cases interior routing deci- sions are based on metrics derived from technical parameters like topology, link speeds and load(1). ASes exchange routing information with other ASes using Exterior Routing Protocols (EGPs). Exterior routing decisions are frequently based on policy based rules rather than purely on technical parame- ters. Tools are needed to configure complex policies and to commun- icate those policies between ASes while still ensuring proper opera- tion of the Internet as a whole. Some EGPs like BGP-3 [8] and BGP-4 [9] provide tools to filter routing information according to policy rules and more. None of them provides a mechanism to publish or com- municate the policies themselves. Yet this is critical for opera- tional coordination and fault isolation among network operators and thus for the operation of the global Internet as a whole. This document describes a "Routing Registry" providing this functional- ity. _________________________ (1) The entity we refer to as an AS is frequently and more generally called a routing domain with the AS just being an implementation vehicle. We have decided to use the term AS exclusively because it relates more direct- ly with the database objects and routing tools. By us- ing only one term we hope to reduce the number of con- cepts and to avoid confusion. The academically inclined reader may forgive us. ripe-1nn.txt May, 1994 - 6 - Routing Policies The exchange of routing information between ASes is subject to rout- ing policies. Consider the case of two ASes, X and Y exchanging routing information: NET1 ...... ASX <---> ASY ....... NET2 ASX knows how to reach a network called NET1. It does not matter whether NET1 is belonging to ASX or some other AS which exchanges routing information with ASX either directly or indirectly; we just assume that ASX knows how to direct packets towards NET1. Likewise ASY knows how to reach NET2. In order for traffic from NET2 to NET1 to flow between ASX and ASY, ASX has to announce NET1 to ASY using an external routing protocol. This states that ASX is willing to accept traffic directed to NET1 from ASY. Policy thus comes into play first in the decision of ASX to announce NET1 to ASY. In addition ASY has to accept this routing information and use it. It is ASY's privilege to either use or disregard the information that ASX is willing to accept traffic for NET1. ASY might decide not to use this information if it does not want to send traffic to NET1 at all or if it considers another route more appropriate to reach NET1. So in order for traffic in the direction of NET1 to flow between ASX and ASY, ASX must announce it to ASY and ASY must accept it from ASX: resulting packet flow towards NET1 <<=================================== | | announce NET1 | accept NET1 --------------> + -------------> | AS X | AS Y | <------------- + <-------------- accept NET2 | announce NET2 | | resulting packet flow towards NET2 ===================================>> Ideally, and seldom practically, the announcement and acceptance policies of ASX and ASY are identical. ripe-1nn.txt May, 1994 - 7 - In order for traffic towards NET2 to flow, announcement and accep- tance of NET2 must be in place the other way round. For almost all applications connectivity in just one direction is not useful at all. It is important to realise that with current destination based for- warding technology routing policies must eventually be expressed in these terms. It is relatively easy to formulate reasonable policies in very general terms which CANNOT be expressed in terms of announc- ing and accepting networks. With current technology such policies are almost always impossible to implement. Usually policies are not configured for each network separately but for groups of networks. In practise these groups are almost always defined by the networks forming one or more ASes. Routing Policy limitations The generic example of a reasonable but un-implementable routing is a split of already joined packet streams based on something other than destination address. Once traffic for the same destination network passes the same router, or the same AS at our level of abstraction, it will take exactly the same route to the destina- tion(2). In a concrete example AS Z might be connected to the outside world by two links. AS Z wishes to reserve these links for different kinds of traffic, let's call them black and white traffic. For this purpose the management of AS Z keeps two lists of ASes, the black and the white list. Together these lists comprise all ASes in the world reachable from AS Z. "W" <---> ... AS Z .... NET 3 <---> "B" It is quite possible to implement the policy for traffic originating in AS Z: AS Z will only accept announcements for networks in white ASes on the white link and will only accept announcements for net- works in black ASes on the black link. This causes traffic from networks within AS Z towards white ASes to use the white link and likewise traffic for black ASes to use the black link. Note that this way of implementing things makes it necessary to decide on the colour of each new AS which appears before traffic can be sent to it from AS Z. A way around this would be to accept only _________________________ (2) Disregarding special cases like "type of service" routing, load sharing and routing instabilities. ripe-1nn.txt May, 1994 - 8 - white announcements via the white link and to accept all but white announcements on the black link. That way traffic from new ASes would automatically be sent down the black link and AS Z management would only need to keep the list of white ASes rather than two lists. Now for the unimplementable part of the policy. This concerns traffic towards AS Z. Consider the following topology: B AS ---) "W" W AS ---) ---> B AS ---)>> AS A ---> ... AS Z .... NET 3 B AS ---) ---> W AS ---) "B" As seen from AS Z there are both black and white ASes "behind" AS A. Since ASes can make routing decisions based on destination only, AS A and all ASes between AS A and the two links connecting AS Z can only make the same decision for traffic directed at a network in AS Z, say NET 3. This means that traffic from both black and white ASes towards NET 3 will follow the same route once it passes through AS A. This will either be the black or the white route depending on the routing policies of AS A and all ASes between it and AS Z. The important thing to note is that unless routing and forwarding decisions can be made based on both source and destination addresses, policies like the "black and white" example cannot be implemented in general because "once joined means joined forever". Access Policies Access policies contrary to routing policies are not necessarily defined in terms of ASes. The very simplest type of access policy is to block packets from a specific network S from being forwarded to another network D. A common example is when some inappropriate use of resources on network D has been made from network S and the prob- lem has not been resolved yet. Other examples of access policies might be resources only accessible to networks belonging to a par- ticular disciplinary group or community of interest. While most of these policies are better implemented at the host or application level, network level access policies do exist and are a source of connectivity problems which are sometimes hard to diagnose. There- fore they should also be documented in the routing registry accord- ing to similar requirements as outlined above. Routing v Allocation information The RIPE database contains both routing registry and address space allocation registry information. In the past the database schema combined this information. Because RIPE was tasked with running both an allocation and routing registry it seemed natural to initially ripe-1nn.txt May, 1994 - 9 - combine these functions. However, experience has shown that a clear separation of routing information from allocation is desirable. Often the maintainer of the routing information is not the same as the maintainer of the allocation information. Also, in other parts of the world there are different registries for each kind of infor- mation. Whilst the actual routing policy objects will be introduced in the next section it is worthy of note that a transition from the current objects will be required. This is described with in Appendix F. This split in information represents a significant change in the representational model of the RIPE database. Appendix E expands on the reasons for this a little more. Tools The network operators will need a series of tools for policy rout- ing. Some tools are already available to perform some of the tasks. Most notably, the PRIDE tools [3] from the PRIDE project started in September 1993 as well as others produced by Merit Inc [4] and CERN [5]. These tools will enable them to use the routing policy stored in the RIPE routing registry to perform such tasks as check actual routing against policies defined, ensure consistency of policies set by dif- ferent operators, and simulate the effects of policy changes. Work continues on producing more useful tools to service the Inter- net community. ripe-1nn.txt May, 1994 - 10 - 4. The Routing Registry and the RIPE Database One of the activities of RIPE is to maintain a database of Euro- pean IP networks, DNS domains and their contact persons along with various other kinds of network management information. The database content is public and can be queried using the whois protocol as well as retrieved as a whole. This supports NICs/NOCs all over Europe and beyond to perform their respective tasks. The RIPE database combines both allocation registry and routing registry functions. The RIPE allocation registry contains data about address space allocated to specific enterprises and/or delegated to local registries as well as data about the domain name space. The allocation registry is described in separate documents [6,7] and outside the scope of this document. Database Objects Each object in the database describes a single entity in the real world. This basic principle means that information about that entity should only be represented in the corresponding data- base object and not be repeated in other objects. The whois ser- vice can automatically display referenced objects where appropriate. The types of objects stored in the RIPE database are summarised in the table below: R Object Describes References ____________________________________________________________________ B person contact persons A inetnum IP address space person A domain DNS domain person R aut-num autonomous system person (aut-num,community) R as-macro a group of autonomous systems person, aut-num R community community person R route a route being announced aut-num, community R clns CLNS address space and routing person The first column indicates whether the object is part of the alloca- tion registry (A), the routing registry (R) or both (B). The last column indicates the types of objects referenced by the particular type of object. It can be seen that almost all objects reference contact persons. Objects are described by attributes value pairs, one per line. Objects are separated by empty lines. An attribute that consists ripe-1nn.txt May, 1994 - 11 - of multiple lines should have the attribute name repeated on consecutive lines. The information stored about network 192.87.45.0 consists of three objects, one network object and two person objects and looks like this: inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops at ripe.net changed: tony at ripe.net 940110 source: RIPE person: Daniel Karrenberg address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: dfk at ripe.net nic-hdl: DK58 changed: ripe-dbm at ripe.net 920826 source: RIPE person: Marten Terpstra address: RIPE Network Coordination Centre (NCC) address: PRIDE Project address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5064 fax-no: +31 20 592 5090 e-mail: Marten.Terpstra at ripe.net nic-hdl: MT2 notify: marten at ripe.net changed: marten at ripe.net 931230 source: RIPE Objects are stored and retrieved in this tag/value format. The RIPE NCC does not provide differently formatted reports because any desired format can easily be produced from this generic one. ripe-1nn.txt May, 1994 - 12 - Routing Registry Objects The main objects comprising the routing registry are "aut-num" and "route", describing an autonomous system and a route respectively. It should be noted that routes not described in the routing registry should never be routed in the Internet itself. The autonomous system (aut-num) object provides contact information for the AS and describes the routing policy of that AS. The routing policy is described by enumerating all neighbouring ASes with which routing information is exchanged. For each neighbour the routing policy is described in terms of exactly what is being sent (announced) and allowed in (accepted). It is important to note that this is exactly the part of the global policy over which an AS has direct control. Thus each aut-num object describes what can indeed be implemented and enforced locally by the AS concerned. Combined together all the aut-num objects provide the global routing graph and permit to deduce the exact routing policy between any two ASes. While the aut-num objects describe how routing information is pro- pagated, the route object describes a single route injected into the external routing mesh. The route object references the AS injecting (originating) the route and thereby indirectly provides contact information for the originating AS. This reference also provides the primary way of grouping routes into larger collections. This is necessary because describing routing policy on the level of single routes would be awkward to impractical given the number of routes in the Internet which is about 20,000 at the time of this writing. Thus routing policy is most often defined for groups of routes by originating AS. This method of grouping is well supported by current exterior routing protocols. The route object also refer- ences community objects described below to provide another method of grouping routes. Modification of aut-num object itself and the referencing by route objects is strictly protected to provide net- work operators control over the routing policy description and the routes originated by their ASes. Sometimes even keeping track of groups of routes at the AS level is cumbersome. Consider the case of policies described at the transit provider level which apply transitively to all customers of the transit provider. Therefore another level of grouping is provided by the as-macro object which provides groups of ASes which can be referenced in routing policies just like single ASes. Membership of as-macro groups is also strictly controlled. Sometimes there is a need to group routes on different criteria than ASes for purposes like statistics or local access policies. This is provided by the community object. A community object is much like an AS but without a routing policy. It just describes a group of routes. This is not supported at all by exterior routing protocols and depending on aggregation of routes may not be generally usable to define routing policies. It is suitable for local policies and non-routing related purposes. ripe-1nn.txt May, 1994 - 13 - These routing related objects will be described in detail in the sections below. ripe-1nn.txt May, 1994 - 14 - 5. The Route Object As stated in the previous chapter routing and address space alloca- tion information are now clearly separated. This is performed with the introduction of the route object. The route object will contain all the information regarding a routing announcement. All routing related attributes are removed from the inetnum object. Some old attributes are obsoleted: connect, routpr-l, bdryg-l, nsf- in, nsf-out, gateway). The currently useful routing attributes are moved to the route object: aut-sys becomes origin, ias-int is encoded in the component attribute and comm-list simply moves. See [6] for detail of the "inetnum" object definition. The information in the old inetnum object inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra connect: RIPE NSF WCW aut-sys: AS3333 comm-list: SURFNET ias-int: 192.87.45.80 AS1104 ias-int: 192.87.45.6 AS2122 ias-int: 192.87.45.254 AS2600 rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops at ripe.net changed: tony at ripe.net 940110 source: RIPE will be distributed over two objects: ripe-1nn.txt May, 1994 - 15 - inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops at ripe.net changed: tony at ripe.net 940110 source: RIPE route: 192.87.45.0/24 descr: RIPE Network Coordination Centre origin: AS3333 comm-list: SURFNET component: 192.87.45.80/32 AS1104 component: 192.87.45.6/32 AS2122 component: 192.87.45.254/32 AS2600 changed: dfk at ripe.net 940427 source: RIPE The route object is used to represent a single route originated into the Internet routing mesh. The actual syntax is given in Appendix D. However, there are several important aspects of the attributes worthy of note. The value of the route attribute will be a classless address. It represents the exact route being injected into the routing mesh. The representation of classless addresses is described in [10]. The value of the origin attribute will be an AS reference of the form AS1234 referring to an aut-num object. It represents the AS injecting this route into the routing mesh. The "aut-num" object (see below) thus referenced provides all the contact information for this route. Special cases: There can only be a single originating AS in each route object. However in todays Internet sometimes a route is injected by more than one AS. In the routing registry this is represented by multiple route objects. This situation is poten- tially dangerous as it can create conflicting routing policies for that route and requires coordination between the originating ASes. This is a departure from the one route (net), one AS principle of the ripe-81 routing registry. The consequences for the different tools based in the routing registry need to be evaluated and ripe-1nn.txt May, 1994 - 16 - possibly additional consistency checking of the database is needed. The component attributes describe components of an aggregate route which go to make up the aggregate route itself. The component attri- bute is not used for routing itself as an advisory for routing information. See the examples below for a more detailed explana- tion. The examples below will illustrate the usage of the route object further. Suppose three chunks of address space of 2 different enterprises. represented by the following inetnum objects: Examples inetnum: 193.0.1.0 netname: ENT-1 descr: Enterprise 1 ... inetnum: 193.0.8.0 netname: ENT-2 descr: Enterprise 2 ... inetnum: 193.0.9.0 netname: ENT-2-SPEC descr: Enterprise 2 ... Supposing that the Enterprises have their own AS numbers straight application of routing without aggregation would yield: route: 193.0.1.0/24 descr: Enterprise 1 origin: AS1 ... route: 193.0.8.0/24 descr: Enterprise 2 origin: AS2 ... route: 193.0.9.0/24 descr: Enterprise 2 origin: AS2 ... NB: This representation can be achieved by straight translation from ripe-1nn.txt May, 1994 - 17 - the ripe-81 representation. See Appendix F for more details. Homogeneous Aggregation The two chunks of address space of Enterprise 2 can be represented by one aggregate route turning two route objects into one and poten- tially saving routing table space for one route. route: 193.0.8.0/2 descr: Enterprise 2 origin: AS2 ... Note that AS2 can also decide to originate all routes mentioned so far, two 24-bit prefixes and one 23-bit prefix. This case would be represented by storing all three route objects in the database. In this particular example the additional routes will not add any func- tionality however and only increase the amount of routes announced unnecessarily. Heterogeneous Aggregation Consider the following case however: route: 193.0.8.0/24 descr: Enterprise 2 origin: AS2 ... route: 193.0.9.0/24 descr: Enterprise 2 / Special origin: AS2 comm-list: SPECIAL ... Now the prefix 193.0.9.0/24 belongs to community SPECIAL (this com- munity may well not be relevant to routing) and the other prefix originated by AS2 does not. If AS2 aggregates these prefixes into the 193.0.8.0/23 prefix, routing policies based on the community value SPECIAL cannot be implemented in general, because there is no way to distinguish between the special and the not-so-special parts of AS2. If another AS has the policy to accept only routes to members of community SPECIAL it cannot implement it, because accept- ing the route to 193.0.8.0/23 would also route to 193.0.8.0/24 and not accepting this route would lose connectivity to the special part 193.0.9.0/24. We call aggregate routes consisting of components belonging to different communities or even different ASes "hetero- geneous aggregates". ripe-1nn.txt May, 1994 - 18 - In many instances the problems introduced by heterogeneous aggre- gates are not relevant because they break no routing policies. In our example it might be that no-one cares that part of AS2 is spe- cial after all. However AS2 cannot know this before making the deci- sion without examining all routing policies in the routing registry. And even if AS2 did this some other AS later on may want to use the fact that AS2 is special. So there has to be a way for AS2 to docu- ment this even if it does not originate the route to 193.0.9.0/24 any more. This can be done with the "component" attribute of the route object. The aggregate route to 193.0.8.0/23 could now be registered as: route: 193.0.8.0/23 descr: Enterprise 2 origin: AS2 component: 193.0.8.0/24 AS2 component: 193.0.9.0/24 AS2 SPECIAL ... The component attribute lists in order the prefix of the component, the autonomous system and the list of communities. Components which belong to the same AS and communities as the route itself need not be generally listed as this information is redundant. With the help of the component attributes other ASes can find out if their routing policies are implementable. Also consistency checks of the routing registry can be done. Components referencing prefixes which are described by either route or inetnum objects in the registries should be avoided. Again, it should be noted that components them- selves are not used for routing. Proxy Aggregation The next step of aggregation are aggregates consisting of more than one AS. This generally means one AS is aggregating on behalf of another. It is called proxy aggregation. Proxy aggregation should be done with great care and always coordinators with other providers announcing the same route. Consider the following: route: 193.0.0.0/20 descr: All routes known by AS1 in a single package origin: AS1 component: 193.0.1.0/24 AS1 component: 193.0.8.0/24 AS2 component: 193.0.9.0/24 AS2 SPECIAL ... If AS1 announced no other routes to a single homed neighbouring AS, ripe-1nn.txt May, 1994 - 19 - that neighbour can in general either take that route or leave it but not differentiate between AS1 and AS2. Note: If the neighbor was previously configured to accept routes originating in AS2 but not in AS1 they lose connectivity to AS2 as well. This means that proxy aggregation has to be done carefully and in a well coordinated fashion. The component information in the route object can help to achieve that. Aggregates with Holes If we assume that the world of our example still consists of only three chunks of address space the aggregate above contains what are called holes, parts of an aggregate that are not reachable via the originator of the route. From the routing information itself one cannot tell whether these are holes and what part of the route falls inside one. The only way to tell is to send a packet there and see whether it gets to the destination, or an ICMP message is received back, or there is silence. On the other hand announcing aggregates with holes is quite legitimate. Consider a 16-bit aggregate with only one 24-bit prefix unreachable. The savings in routing table size by far outweigh the hole problem. For operational reasons however it is very useful to register these holes in the routing registry. Consider the case where a remote net- work operator experiences connectivity problems to addresses inside an aggregate route. If the packets are getting to the AS announcing the aggregate and there are no more specific routes, the normal cause of action is to get in touch with the originating AS of the aggregate route and ask them to fix the problem. If the address falls into a hole this is futile. Therefore problem diagnosis can be sped up and unnecessary calls prevented by registering the holes in the routing registry. In our example the representation would be: route: 193.0.0.0/20 descr: All routes known by AS1 origin: AS1 component: 193.0.0.0/24 HOLE component: 193.0.2.0/23 HOLE component: 193.0.4.0/22 HOLE component: 193.0.8.0/24 AS2 component: 193.0.9.0/24 AS2 SPECIAL component: 193.0.10.0/23 HOLE component: 193.0.12.0/22 HOLE ... Multiple Proxy Aggregation Finally suppose that AS2 decides to announce the same aggregate, they would add the following route object to the registry: ripe-1nn.txt May, 1994 - 20 - route: 193.0.0.0/20 descr: All routes known by AS2 origin: AS2 component: 193.0.0.0/24 HOLE component: 193.0.2.0/23 HOLE component: 193.0.4.0/22 HOLE component: 193.0.9.0/24 AS2 SPECIAL component: 193.0.10.0/23 HOLE component: 193.0.12.0/22 HOLE ... AS per the update procedures below both AS1 and AS2 will be notified that there already is a route to the same prefix in the registry. This multiple proxy aggregation is very dangerous to do if the com- ponents of the route are not the same. It is still dangerous when the components are consistent but connectivity to the components varies widely between the originators. Route object update procedures Adding a route object will be guarded by use of the AS guardian files[12]. The actual implementation of this is outside the scope of this document. A route object will only be added if the class- less address value of the route attribute will appear in the guar- dian file of the origin AS mentioned. This guarantees that an AS guardian has full control over the registration of the routes it announces. Any AS added or deleted from the components of a route object will be notified of the event by e-mail to the AS guardian. This guaran- tees that ASes are notified if some of their address space gets aggregated somewhere. Any community added or deleted from the components of a route object will be notified of the event by e-mail to the community guardian. It should be noted that adding community information to component attributes should be done with some caution. One should check with the community guardian before doing this. What is an Inter-AS network ? An inter-AS network(3) exists for the purpose of passing traffic and routing information between different autonomous systems. The most _________________________ (3) Inter-AS IP networks are those networks are currently called FIXes, IXFs, DMZs, NAPs, GIX and many other acronyms. ripe-1nn.txt May, 1994 - 21 - simple example of an inter-AS network is a point-to-point link, con- necting exactly two ASes. Each end of such a link is connected to an interface of router belonging to each of the autonomous systems. More complex examples are broadcast type networks with multiple interfaces connecting multiple ASes with the possibility of more than one connection per AS. Consider the following example of three routers 1, 2 and 3 with interfaces a through f connected by two inter-AS networks X and Y: Consider the following example of three routers 1, 2 and 3 with interfaces a through f connected by two inter-AS networks X and Y: X Y a1b --- c2d --- e3f Suppose that network X is registered in the routing registry as part of AS1 and net Y as part of AS3. If traffic passes from left to right prtraceroute will report the following sequence of interfaces and ASes: a in AS1 c in AS1 e in AS3 The traceroute algorithm enumerates only the receiving interfaces on the way to the destination. In the example this leads to the pas- sage of AS2 going unnoticed. This is confusing to the user and will also generate exceptions when the path found is checked against the routing registry. For operational monitoring tools such as prtraceroute it is neces- sary to know which interface on an inter-AS network belongs to which AS. If AS information is not known about interfaces on an inter-AS network, tools like prtraceroute cannot determine correctly which ASes are being traversed. ripe-1nn.txt May, 1994 - 22 - Format All interfaces on inter-AS networks will be described in the com- ponent part of the route object. This is done by specifying a 32 bit prefix (host address). For example: route: 192.87.45.0/24 descr: RIPE Network Coordination Centre origin: AS3333 component: 192.87.45.80/32 AS1104 component: 192.87.45.6/32 AS2122 component: 192.87.45.254/32 AS2600 changed: dfk at ripe.net 940427 source: RIPE describes a route to a DMZ network which lives in AS3333. There are three interfaces in different ASes. ripe-1nn.txt May, 1994 - 23 - 6. The Autonomous System Object Autonomous Systems An Autonomous System (AS) is a group of IP networks run by one or more network operators which has a single and clearly defined rout- ing policy. An AS has a unique number associated with it which is used both in exchange of exterior routing information and as an identifier of the AS itself. Exterior routing protocols such as BGP and EGP are used to exchange routing information between ASes. In routing terms an AS will normally use one or more interior gate- way protocols (IGPs) in conjunction with some sort of common agreed metrics when exchanging network information within its own AS. The term AS is often confused or even misused as a convenient way of grouping together a set of networks which belong under the same administrative umbrella even if within that group of networks there are various different routing policies. We provide the "community" concept for such use. ASes can strictly have only one single rout- ing policy. The creation of an AS should be done in a conscious and well coordi- nated manner to avoid creating ASes for the sake of it, perhaps resulting in the worst case scenario of one AS per routing announce- ment. It should be noted that there is a limited number of AS numbers available. Also creating an AS may well increase the number of AS paths modern EGPs will have to keep track of. This aggravates what is known as "the routing table growth problem". This may mean that by applying the general rules for the creation and allocation of an AS below, some re-engineering may well be needed. However, this may be the only way to actually implement the desired routing policy anyway. The creation and allocation of an AS should be done with the following recommendations in mind: o Creation of an AS is only required when exchanging routing information with other ASes. Some router implementations make use of an AS number as a form of tagging to identify the rout- ing process. However, it should be noted that this tag does not need to be unique unless routing information is indeed exchanged with other ASes. o For a simple case of customer networks connected to a single service provider, the IP network should normally be a member of the service providers AS. In terms of routing policy the IP network has exactly the same policy as the service provider and there is no need to make any distinction in routing informa- tion. This idea may at first seem slightly alien to some, but it highlights the clear distinction in the use of the AS number ripe-1nn.txt May, 1994 - 24 - as a representation of routing policy as opposed to some form of administrative use. o If a network operator connects to more than one AS with dif- ferent routing policies then they need to create their own AS. In the case of multi-homed customer networks connected to two service providers there are at least two different routing pol- icies to a given customer network. At this point the customer networks will be part of a single AS and this AS would be dis- tinct from either of the service providers ASes. This allows the customer the ability of having a different representation of policy and preference to the different service providers. This is the ONLY case where a network operator should create its own AS number. o As a general rule one should always try to populate the AS with as many routes as possible, providing all routes conform to the same routing policy. Each AS is represented in the RIPE database by both an AS object and the route objects representing the routes originated by the AS. The AS object stores descriptive, administrative and contact information about the AS as well as the routing policies of the AS in relation to all neighbouring ASes. The origin attributes of the route objects define the set of routes originated by the AS. Each route object can have exactly one origin attribute. Route objects can only be created and updated by the "guardian" of the AS and not by those immediately responsible for the particular routes referenced therein. This ensures that opera- tors, especially service providers, remain in control of AS routing announcements. The AS object itself is used to represent a description of adminis- trative details and the routing policies of the AS itself. The AS object definition is depicted as follows. ripe-1nn.txt May, 1994 - 25 - Example: aut-num: AS1104 descr: NIKHEF-H Autonomous system as-in: from AS1213 100 accept AS1213 as-in: from AS1913 100 accept AS1913 as-in: from AS1755 150 accept ANY as-out: to AS1213 announce ANY as-out: to AS1913 announce ANY as-out: to AS1755 announce AS1104 AS1913 AS1213 tech-c: Rob Blokzijl admin-c: Eric Wassenaar guardian: as-guardian at nikhef.nl changed: ripe-dbm at ripe.net 920910 source: RIPE See Appendix A for a complete syntax definition of the "aut-num" object. It should be noted that this representation provides two things: o a set of routes. o a description of administrative details and routing policies. The set of routes can be used to generate network list based confi- guration information as well as configuration information for exte- rior routing protocols knowing about ASes. This means an AS can be defined and is useful even if it does not use routing protocols which know about the AS concept! ripe-1nn.txt May, 1994 - 26 - Preferences on Inter-AS connections - "interas-in/interas-out". Often two ASes will have more than one physical connection between them. In practice certain local policies my be placed on these inter-AS connections as agreed by the two ASes. If we look at the simple example below. Example: LINK1 +----------+ |a b| AS1------AS2 AS3-----AS4 |c d| +----------+ LINK2 It may be that AS2 prefers to get to AS3 on LINK1 (a and b being the interface addresses of this link) and to AS4 on LINK2 (c and d being the interface addresses of this link) with LINK2 as a backup for AS3. Whilst this is purely of local information and at the AS level will have no significance per se to any other ASes except AS2 and AS3 this may be useful to represent. The way this is done is by using the attributes "interas-in" and "interas-out". The exact syn- tax is given in Appendix A. However, if we follow this example through in terms of AS2 we would represent this policy as follows: Example: aut-num: AS2 as-in: from AS3 10 accept AS3 AS4 as-out: to AS3 announce AS1 AS2 interas-in: from AS3 a b 5 accept AS3 interas-in: from AS3 a b 15 accept AS4 interas-in: from AS3 c d 10 accept AS4 ... Here we see additional local link based information in terms of the IP addresses of the link (in this example represented by a and b and c and d respectively). It should be noted that the preference on interas-in attributes is only of relevance to other interas-in lines and not to as-in lines. Of course this type on inter-AS policy should always be bilaterally-laterally agreed to avoid asymmetry and in practice there may need to be corresponding interas-in attributes in the policy representation of AS3. It should also be noted that there are no interas-out attributes defined. In this case the gen- eral policy is assumed. The key difference between interas-in/interas-out and as-in/as-in attributes is the former describes a local inter-AS policy and the ripe-1nn.txt May, 1994 - 27 - latter the general inter-AS policy as seen by other ASes. The gen- eral policy should always be defined. The local inter-AS policy should only be defined when such a policy really exists and the implications of setting such policies is fully understood. ripe-1nn.txt May, 1994 - 28 - How to describe the exclusion policy of a certain AS - "as-exclude" Some ASes have a routing policy based on the exclusion of certain routes if for whatever reason a certain AS is used as transit. Whilst, this is in general not good practice as it makes implicit assumptions on topology with asymmetry a possible outcome if not coordinated, this case needs to be accommodated within the routing policy representation. The way this is achieved is by making use of the "as-exclude" attri- bute. The precise syntax of this attribute can be found in Appendix A along with the rest of the defined syntax for the "aut-num" object. However, some explanation of the use of this attribute is useful. If we have the following example topology. Example: AS4--------AS3 | | | | | | AS1--------AS2--------AS5 With a simple corresponding policy like so: Example: aut-num: AS1 as-in: from AS2 100 accept ANY as-out: to AS2 announce AS1 as-exclude: exclude AS4 to ANY .... We see an interesting policy. What this says in simple terms is AS1 doesn't want to reach anything if it transit AS4. This can be a per- fectly valid policy. However, it should be realised that for what- ever reason AS2 decides to route to AS3 via AS4 then immediately AS1 has no connectivity to AS3 or if AS1 is running default to AS2 pack- ets from AS1 will still flow via AS4. The important point about this is that whilst AS1 can advise its neighbours of its policy it has no direct control on how it can enforce this policy to neighbours upstream. Another interesting scenario to highlight the unexpected result of using such an "as-exclude" policy. If we assume in the above example AS2 preferred AS4 to reach AS3 and AS1 did not use default routing then as stated AS1 would have no connectivity to AS3. Now lets sup- pose that for example the link between AS2 and AS4 went down for some reason. Like so: ripe-1nn.txt May, 1994 - 29 - Example: AS4--------AS3 | | AS1--------AS2--------AS5 Suddenly AS1 now has connectivity to AS3. This unexpected behavior should be considered when created policies based on the "as-exclude" attribute. The second problem with this type of policy is the potential of asymmetry. In the original example we saw the correct policy from AS1's point of view but if ASes with connectivity through AS4 do not use a similar policy you have asymmetric traffic and policy. If an AS uses such a policy they must be aware of the consequences of its use. Namely that the specified routes which transit the AS (i.e. routing announcements with this AS in the AS path information) in question will be excluded. If not coordinated this can easily cause asymmetry or even worse loss of connectivity to unknown ASes behind (or in front for that matter) the transit AS in question. With this in mind this attribute can only be viewed as a form of advisory to other service providers. However, this does not preclude its use with policy based tools if the attribute exists. By having the ability to specify a route keyword based on any of the four notations given in the syntax it allows the receiving AS to specify what routes it wishes to exclude through a given transit AS to a network granularity. ripe-1nn.txt May, 1994 - 30 - 7. AS Macros It may be difficult to keep track of each and every new AS that is represented in the routing registry. A convenient way around this is to define an `AS Macro' which essentially is a convenient way to group ASes. This is done so that each and every AS guardian does not have to add a new AS to it's routing policy as described by the as- in and as-out attributes of it's AS object. However, it should be noted that this creates an implicit trust on the guardian of the AS-Macro. An AS-Macro can be used in for the "as-in" and "as-out" attributes in the aut-num object. The AS-Macro object is then used to derive the list or group of ASes. A simple example would be something like: Example: aut-num: AS786 as-in: from AS1755 100 accept AS-EBONE AND NOT AS1104 as-in: from AS1755 100 accept AS-EBONE AND NOT AS1104 as-out to AS1755 announce AS786 ..... Where the as-macro object for AS-EBONE is as follows: as-macro: AS-EBONE descr: ASes routed by EBONE as-list: AS2121 AS1104 AS2600 AS2122 as-list: AS1103 AS1755 AS2043 guardian: guardian at ebone.net ...... So the policy would be evaluated to: aut-num: AS786 as-in: from AS1755 100 accept (AS2121 OR AS1104 OR AS2600 OR AS2122 as-in: from AS1755 100 accept AS1103 OR AS1755 OR AS2043) AND NOT AS1104 ...... See Appendix C for a definition on the AS-Macro syntax. ripe-1nn.txt May, 1994 - 31 - 8. The Community Object A community is a group of routes that cannot be represented by an AS or a group of ASes. It is in some circumstances useful to define a group of routes that have something in common. This could be a spe- cial access policy to a supercomputer centre, a group of routes used for a specific mission, or a disciplinary group that is scattered among several autonomous systems. Also these communities could be useful to group routes for the purpose of network statistics. Communities do not exchange routing information, since they do not represent an autonomous system. More specifically, communities do not define routing policies, but access or usage policies. However, they can de used as in conjunction with an ASes routing policy to define a set of routes the AS sets routing policy for. Communities should be defined in a strict manner, to avoid creating as many communities as there are routes, or even worse. Communities should be defined following the two rules below; o Communities must have a global meaning. Communities that have no global meaning, are used only in a local environment and should be avoided. o Communities must not be defined to express non-local policies. It should be avoided that a community is created because some other organisation forces a policy upon your organisation. Communities must only be defined to express a policy defined by your organisation. Community examples There are some clear examples of communities: BACKBONE - all customers of a given backbone service provider even though they can have various different routing policies and hence belong to different ASes. This would be extremely useful for statistics collection. HEPNET - the High Energy Physics community partly shares infrastructure with other organisations, and the institutes it consists of are scattered all over Europe, often being part of a non HEPNET autonomous system. To allow statistics, access or part of a routing policy , a community HEPNET, consisting of all routes that are part of HEPNET, conveniently groups all these routes. ripe-1nn.txt May, 1994 - 32 - NSFNET - the National Science Foundation Network imposes an acceptable use policy on routes that wish to make use of it. A community NSFNET could imply the set of routes that comply with this pol- icy. MULTI - a large multinational corporation that does not have its own internal infrastructure, but connects to the various parts of its organisations by using local service providers that connect them all together, may decide to define a community to restrict access to their networks, only by networks that are part of this community. This way a corporate network could be defined on shared infrastructure. Also, this community could be used by any of the service providers to do statistics for the whole of the corporation, for instance to do topology or bandwidth plan- ning. Similar to Autonomous systems, each community is represented in the RIPE database by both a community object and community tags on the route objects representing the routes belonging to the community. The community object stores descriptive, administrative and contact information about the community. The community tags on the route objects define the set of routes belonging to a community. A route can have multiple community tags. The community tags can only be created and updated by the "guardian" of the community and not by those directly responsible for the par- ticular network. This ensures that guardians remain in control of community membership. Here's an example of how this might be represented in terms of the community tags within the network object. We have an example where the route 192.16.199.0/24 has a single routing policy (i.e. that of AS 1104), but is part of several different communities of interest. We use the tag "comm-list" to represent the list of communities associated with this route. NIKHEF-H uses the service provider SURFNET (a service provider with customers with more than one rout- ing policy), is also part of the High Energy Physics community as well as having the ability to access the Supercomputer at CERN(4). _________________________ (4) The community `CERN-SUPER', is somewhat national, but is intended as an example of a possible use of an access policy constraint. ripe-1nn.txt May, 1994 - 33 - Example: route: 192.16.199.0/24 descr: Local Ethernet descr: NIKHEF section H origin: AS1104 comm-list: HEPNET CERN-SUPER SURFNET changed: ripe-dbm at ripe.net 920604 source: RIPE In the above examples some communities have been defined. The com- munity object itself will take the following format: Example: community: SURFNET descr: Dutch academic research network authority: SURFnet B.V. guardian: comm-guardian at surfnet.nl admin-c: Erik-Jan Bos tech-c: Erik-Jan Bos changed: ripe-dbm at ripe.net 920604 source: RIPE For a complete explanation of the syntax please refer to Appendix B. ripe-1nn.txt May, 1994 - 34 - 9. Representation of Routing Policies Routing policies of an AS are represented in the autonomous system object. Initially we show some examples, so the reader is familiar with the concept of how routing information is represented, used and derived. Refer to Appendix A, for the full syntax of the "aut-num" object. The topology of routing exchanges is represented by listing how routing information is exchanged with each neighbouring AS. This is done separately for both incoming and outgoing routing information. In order to provide backup and back door paths a relative cost is associated with incoming routing information. Example 1: AS1------AS2 This specifies a simple routing exchange of two presumably isolated ASes. Even if either of them has routing information about routes in ASes other than AS1 and AS2, none of that will be announced to the other. aut-num: AS1 as-out: to AS2 announce AS1 as-in: from AS2 100 accept AS2 aut-num: AS2 as-out: to AS1 announce AS2 as-in: from AS1 100 accept AS1 The number 100 in the in-bound specifications is a relative cost, which is used for backup and back door routes. The absolute value is of no significance. The relation between different values within the same AS object is. A lower value means a lower cost. This is cons- ciously similar to the cost based preference scheme used with DNS MX RRs. Example 2: Now suppose that AS2 is connected to one more AS, besides AS1, and let's call that AS3: AS1------AS2------AS3 ripe-1nn.txt May, 1994 - 35 - In this case there are two reasonable routing policies: a) AS2 just wants to exchange traffic with both AS1 and AS3 itself without passing traffic between AS1 and AS3. b) AS2 is willing to pass traffic between AS3 and AS1, thus acting as a transit AS Example 2a: In the first case AS1's representation in the routing registry will remain unchanged as will be the part of AS2's representation describing the routing exchange with AS1. A description of the addi- tional routing exchange with AS3 will be added to AS2's representa- tion: aut-num: AS1 as-out: to AS2 announce AS1 as-in: from AS2 100 accept AS2 aut-num: AS2 as-out: to AS1 announce AS2 as-in: from AS1 100 accept AS1 as-out: to AS3 announce AS2 as-in: from AS3 100 accept AS3 aut-num: AS3 as-out: to AS2 announce AS3 as-in: from AS2 100 accept AS2 Note that in this example, AS2 keeps full control over its resources. Even if AS3 and AS1 were to allow each others routes in from AS2, the routing information would not flow because AS2 is not announcing it(5). Example 2b: If contrary to the previous case, AS1 and AS3 are supposed to have connectivity to each other via AS2, all AS objects have to change: _________________________ (5) Of course AS1 and AS3 could just send traffic to each other to AS2 even without AS2 announcing the routes, hoping that AS2 will forward it correctly. Such questionable practices however are beyond the scope of this document. ripe-1nn.txt May, 1994 - 36 - aut-num: AS1 as-out: to AS2 announce AS1 as-in: from AS2 100 accept AS2 AS3 aut-num: AS2 as-out: to AS1 announce AS2 AS3 as-in: from AS1 100 accept AS1 as-out: to AS3 announce AS2 AS1 as-in: from AS3 100 accept AS3 aut-num: AS3 as-out: to AS2 announce AS3 as-in: from AS2 100 accept AS1 AS2 Note that the amount of routing information exchanged with a neigh- bour AS is defined in terms of routes belonging to ASes. In BGP terms this is the AS where the routing information originates and the originating AS information carried in BGP could be used to implement the desired policy. However, using BGP or the BGP AS-path information is not required to implement the policies thus speci- fied. Configurations based on route lists can easily be generated from the database. The AS path information, provided by BGP can then be used as an additional checking tool as desired. The specification understands one special expression and this can be expressed as a boolean expressions: ANY - means any routing information known. For output this means that all routes an AS knows about are announced. For input it means that anything is accepted from the neighbour AS. ripe-1nn.txt May, 1994 - 37 - Example 3: AS4 is a stub customer AS, which only talks to service provider AS123. | | -----AS123------AS4 | | aut-num: AS4 as-out: to AS123 announce AS4 as-in: from AS123 100 accept ANY aut-num: AS123 as-in: from AS4 100 accept AS4 as-out: to AS4 announce ANY Since AS4 has no other way to reach the outside world than AS123 it is not strictly necessary for AS123 to send routing information to AS4. AS4 can simply send all traffic for which it has no explicit routing information to AS123 by default. This strategy is called default routing. It is expressed in the routing registry by adding one or more default tags to the autonomous system which uses this strategy. In the example above this would look like: aut-num: AS4 as-out: to AS123 announce AS4 default: AS123 100 aut-num: AS123 as-in: from AS4 100 accept AS4 ripe-1nn.txt May, 1994 - 38 - Example 4: AS4 now connects to a different operator, AS5. AS5 uses AS123 for outside connectivity but has itself no direct connection to AS123. AS5 traffic to and from AS123 thus has to pass AS4. AS4 agrees to act as a transit AS for this traffic. | | -----AS123------AS4-------AS5 | | aut-num: AS4 as-out: to AS123 announce AS4 AS5 as-in: from AS123 100 accept ANY as-out: to AS5 announce ANY as-in: from AS5 50 accept AS5 aut-num: AS5 as-in: from AS4 100 accept ANY as-out: to AS4 announce AS5 aut-num: AS123 as-in: from AS4 100 accept AS4 AS5 as-out: to AS4 announce ANY Now AS4 has two sources of external routing information. AS5 which provides only information about its own routes and AS123 which pro- vides information about the external world. Note that AS4 accepts information about AS5 from both AS123 and AS5 although AS5 informa- tion cannot come from AS123 since AS5 is connected only via AS4 itself. The lower cost of 50 for the announcement from AS5 itself compared to 100 from AS123 ensures that AS5 is still believed even in case AS123 will unexpectedly announce AS5. In this example too, default routing can be used by AS5 much like in the previous example. AS4 can also use default routing towards AS123: ripe-1nn.txt May, 1994 - 39 - aut-num: AS4 as-out: to AS123 announce AS4 AS5 default: AS123 11 as-in: from AS5 50 accept AS5 Note no announcements to AS5, they default to us. aut-num: AS5 as-out: to AS4 announce AS5 default: AS4 100 aut-num: AS123 as-in: from AS4 100 announce AS4 AS5 Note that the relative cost associated with default routing is totally separate from the relative cost associated with in-bound announcements. The default route will never be taken if an explicit route is known to the destination. Thus an explicit route can never have a higher cost than the default route. The relative cost asso- ciated with the default route is only useful in those cases where one wants to configure multiple default routes for redundancy. Note also that in this example the configuration using default routes has a subtly different behavior than the one with explicit routes: In case the AS4-AS5 link fails AS4 will send traffic to AS5 to AS123 when using the default configuration. Normally this makes not much difference as there will be no answer and thus little traffic. With certain datagram applications which do not require acknowledgments however, significant amounts of traffic may be use- lessly directed at AS123. Similarly default routing should not be used if there are stringent security policies which proscribe any traffic intended for AS5 to ever touch AS123. Generally it can be said that default routing should only be used in very simple topologies. Once the situation gets more complex using default routes can lead to unexpected results or even defeat the routing policies established when links fail. As an example consider how Example 5a) below could be implemented using default routing. ripe-1nn.txt May, 1994 - 40 - Example 5: In a different example AS4 has a private connection to AS6 which in turn is connected to the service provider AS123: | | -----AS123------AS4 | | | | | | AS6 ---------+ There are a number of policies worth examining in this case: a) AS4 and AS6 wish to exchange traffic between themselves exclusively via the private link between themselves; such traffic should never pass through the backbone (AS123). The link should never be used for transit traffic, i.e. traffic not both originating in and destined for AS4 and AS6. b) AS4 and AS6 wish to exchange traffic between themselves via the private link between themselves. Should the link fail, traffic between AS4 and AS6 should be routed via AS123. The link should never be used for transit traffic. c) AS4 and AS6 wish to exchange traffic between themselves via the private link between themselves. Should the link fail, traffic between AS4 and AS6 should be routed via AS123. Should the connection between AS4 and AS123 fail, traffic from AS4 to des- tinations behind AS123 can pass through the private link and AS6's connection to AS123. d) AS4 and AS6 wish to exchange traffic between themselves via the private link between themselves. Should the link fail, traffic between AS4 and AS6 should be routed via AS123. Should the backbone connection of either AS4 or AS6 fail, the traffic of the disconnected AS should flow via the other AS's backbone connection. ripe-1nn.txt May, 1994 - 41 - Example 5a: aut-num: AS4 as-in: from AS123 100 accept NOT AS6 as-out: to AS123 announce AS4 as-in: from AS6 50 accept AS6 as-out: to AS6 announce AS4 aut-num: AS123 as-in: from AS4 100 accept AS4 as-out: to AS4 announce ANY as-in: from AS6 100 accept AS6 as-out: to AS6 announce ANY aut-num: AS6 as-in: from AS123 100 accept NOT AS4 as-out: to AS123 announce AS6 as-in: from AS4 50 accept AS4 as-out: to AS4 announce AS6 Note that here the configuration is slightly inconsistent. AS123 will announce AS6 to AS4 and AS4 to AS6. These announcements will be filtered out on the receiving end. This will implement the desired policy. Consistency checking tools might flag these cases however. ripe-1nn.txt May, 1994 - 42 - Example 5b: aut-num: AS4 as-in: from AS123 100 accept ANY as-out: to AS123 announce AS4 as-in: from AS6 50 accept AS6 as-out: AS6 AS4 aut-num: AS123 as-in: AS4 100 AS4 as-out: AS4 ANY as-in: AS6 100 AS6 as-out: AS6 ANY aut-num: AS6 as-in: from AS123 100 accept ANY as-out: to AS123 announce AS6 as-in: from AS4 50 accept AS4 as-out: to AS4 announce AS6 The thing to note here is that in the ideal operational case, `all links working' AS4 will receive announcements for AS6 from both AS123 and AS6 itself. In this case the announcement from AS6 will be preferred because of its lower cost and thus the private link will be used as desired. AS6 is configured as a mirror image. ripe-1nn.txt May, 1994 - 43 - Example 5c: The new feature here is that should the connection between AS4 and AS123 fail, traffic from AS4 to destinations behind AS123 can pass through the private link and AS6's connection to AS123. aut-num: AS4 as-in: from AS123 100 accept ANY as-out: to AS123 announce AS4 as-in: from AS6 50 accept AS6 as-in: from AS6 110 accept ANY as-out: to AS6 AS4 aut-num: AS123 as-in: from AS4 1 accept AS4 as-out: to AS4 announce ANY as-in: from AS6 1 accept AS6 as-in: from AS6 2 accept AS4 as-out: to AS6 announce ANY aut-num: AS6 as-in: from AS123 100 accept ANY as-out: to AS123 AS6 announce AS4 as-in: from AS4 50 accept AS4 as-out: to AS4 announce ANY Note that it is important to make sure to propagate routing informa- tion for both directions in backup situations like this. Connec- tivity in just one direction is not useful at all for almost all applications. Note also that in case the AS6-AS123 connection breaks, AS6 will only be able to talk to AS4. The symmetrical case (5d) is left as an exercise to the reader. ripe-1nn.txt May, 1994 - 44 - 10. References [1] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P., Terpstra, M., "Representation of IP Routing Policies in the RIPE Database", RIPE-81, February 1993. [2] Merit Network Inc.,"Representation of Complex Routing Policies of an Autonomous System", DRAFT, March, 1994. [3] PRIDE Tools Release 1. See ftp.ripe.net:pride/tools/pride-tools-1.tar.Z. [4] Merit Inc. RRDB Tools. See rrdb.merit.edu:pub/meritrr/* [5] The Network List Compiler. See dxcoms.cern.ch:pub/ripe-routing-wg/nlc-2.2d.tar [6] Lord, A., Terpstra, M., "RIPE Database Template for Networks and Persons", DRAFT, May 1994. [7] Karrenberg, D., "RIPE Database Template for Domains", RIPE-49, April 1992. [8] Lougheed, K., Rekhter, Y., "A Border Gateway Protocol 3 (BGP- 3)", RFC1267, October 1991. [9] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", INTERNET-DRAFT, draft-ietf-bgp-bgp4-10.txt, May 1994. [10] Bates, T., Karrenberg, D., Terpstra, M., "Support for Classless Internet Addresses in the RIPE Database", DRAFT, May 1994. [11] Karrenberg, D., "Authorisation and Notification of Changes in the RIPE Database", RIPE-96, October 1993. [12] Bates, T., "Support of Guarded fields within the RIPE Data- base", ripe-108, February 1994. ripe-1nn.txt May, 1994 - 45 - 11. Author's Addresses Tony Bates RARE/PRIDE Project c/o RIPE Network Coordination Centre Kruislaan 409 NL-1098 SJ Amsterdam The Netherlands +31 20 592 5064 T.Bates at ripe.net Elise Gerich The University of Michigan Merit Computer Network 1075 Beal Avenue Ann Arbor, MI 48109 USA +1 313 936 2120 epg at merit.edu Laurent Joncheray The University of Michigan Merit Computer Network 1075 Beal Avenue Ann Arbor, MI 48109 USA +1 313 936 2065 lpj at merit.edu Jean-Michel Jouanigot CERN, European Laboratory for Particle Physics CH-1211 Geneva 23 Switzerland +41 22 767 4417 Jean-Michel.Jouanigot at cern.ch Daniel Karrenberg RIPE Network Coordination Centre Kruislaan 409 NL-1098 SJ Amsterdam The Netherlands +31 20 592 5065 D.Karrenberg at ripe.net ripe-1nn.txt May, 1994 - 46 - Marten Terpstra PRIDE Project c/o RIPE Network Coordination Centre Kruislaan 409 NL-1098 SJ Amsterdam The Netherlands +31 20 592 5064 M.Terpstra at ripe.net Jessica Yu The University of Michigan Merit Computer Network 1075 Beal Avenue Ann Arbor, MI 48109 USA +1 313 936 2655 jyy at merit.edu ripe-1nn.txt May, 1994 - 47 - Appendix A - Syntax for the aut-num object. Here is a summary of the tags associated with aut-num object itself and their status. The first column specifies the attribute, the second column whether this attribute is mandatory in the aut-num object, and the third column whether this specific attribute can occur only once per object [single], or more than once [multiple]. When specifying multiple lines per attribute, the attribute name must be repeated. See [6] the example for the descr: attribute. aut-num: [mandatory] [single] descr: [mandatory] [multiple] as-in: [optional] [multiple] as-out: [optional] [multiple] interas-in: [optional] [multiple] interas-out: [optional] [multiple] as-exclude: [optional] [multiple] default: [optional] [multiple] tech-c: [mandatory] [multiple] admin-c: [mandatory] [multiple] guardian: [mandatory] [single] remarks: [optional] [multiple] notify: [optional] [multiple] maintainer: [optional] [single] changed: [mandatory] [multiple] source: [mandatory] [single] Each attribute has the following syntax: aut-num: The autonomous system number. This must be a uniquely allo- cated autonomous system number from an AS registry (i.e. the RIPE NCC, the Inter-NIC, etc). Format: AS Example: aut-num: AS1104 Status: mandatory, only one line allowed descr: A short description of the Autonomous System. Format: free text Status: mandatory, multiple lines allowed as-in: ripe-1nn.txt May, 1994 - 48 - Example: descr: NIKHEF section H descr: Science Park Watergraafsmeer descr: Amsterdam A description of accepted routing information between AS peers. Format: from accept The keywords from and accept are optional and can be omit- ted. refers to your AS neighbour. is a positive integer used to express a relative cost of routes learned. The lower the cost the more pre- ferred the route. can take the following for- mats. 1. A list of one or more ASes, AS Macros, Communities or Network Lists. A Network List is a list of network numbers in prefix length format, separated by commas, and surrounded by curly brackets. Examples: as-in: from AS1103 100 accept AS1103 as-in: from AS786 105 accept AS1103 as-in: from AS786 10 accept AS786 HEPNET as-in: from AS1755 110 accept AS1103 AS786 as-in: from AS3333 100 accept {192.87.45.0/16, 128.141.0.0/16} 2. A set of KEYWORDS. The following KEYWORD is currently defined: ANY this means anything the neighbour AS knows. 3. A logical expression of either 1 or 2 above The current logical operators are defined as: AND OR NOT ripe-1nn.txt May, 1994 - 49 - NOTE: if no logical operator is given between ASes, AS-macros, Communities, Network Lists and KEYWORDS it is implicitly evaluated as an `OR' operation. The OR can be left out for conciseness. Rules are grouped together using parenthesis i.e "(" and ")". Example: as-in: from AS1755 100 accept ANY AND NOT (AS1234 OR AS513) as-in: from AS1755 150 accept AS1234 OR {35.0.0.0/8} A rule can be wrapped over lines providing the associated , values and from and accept keywords are repeated and occur on con- secutive lines. Example: as-in: from AS1755 100 accept ANY AND NOT (AS1234 AS513) and as-in: from AS1755 100 accept ANY AND NOT ( as-in: from AS1755 100 accept AS1234 AS513) are evaluated to the same result. Please note that the ordering of these continuing lines matters. Status: optional, multiple lines allowed as-out: A description of generated routing information sent to other AS peers. Format: to announce refers to your AS neighbour. is explained in the as-in attribute definition above. Example: as-out: to AS1104 announce AS978 as-out: to AS1755 announce ANY as-out: to AS786 announce ANY AND NOT (AS978) Status: optional, multiple lines allowed ripe-1nn.txt May, 1994 - 50 - interas-in: Describes incoming local preferences on an inter AS connection. Format: from accept The keywords from and accept are optional and can be omit- ted. is an autonomous system as defined in as-in. contains the IP address of the local border router, followed by a space, followed by the IP address of the remote border router. IP addresses must be in prefix length format. is a preference as defined in as-in. Preferences are only relevant to other interas-in attributes, not to as-in attributes. is an expression as defined in as-in above. Examples: interas-in: from AS1104 192.87.45.254/32 192.87.45.80/32 10 accept AS786 interas-in: from AS1104 192.87.45.254/32 192.87.45.79/32 20 accept AS987 Status: optional, multiple lines allowed interas-out: Describes outgoing local preferences on an inter AS connection. Format: to announce The keywords to and announce are optional and can be omit- ted. The definitions of , , and are identical to those defined in interas-in. Examples: interas-out: to AS1104 192.87.45.254/32 192.87.45.80/32 announce AS23 interas-out: to AS1104 192.87.45.254/32 192.87.45.79/32 announce AS10 Status: optional, multiple lines allowed as-exclude: A list of transit ASes to ignore all routes from. ripe-1nn.txt May, 1994 - 51 - Format: exclude to Keywords exclude and to are optional and can again be omitted. refers to the transit AS in question. an can be ONE of the following. 1. 2. AS macro 3. Community 4. ANY Examples: as-exclude: exclude AS690 to HEPNET This means exclude any HEPNET routes which have a route via AS690. as-exclude: exclude AS1800 to AS-EUNET This means exclude any AS-EUNET routes which have a route via AS1800. as-exclude: exclude AS1755 to AS1104 This means exclude any AS1104 route which have a route via AS1755. as-exclude: exclude AS1104 to ANY This means exclude all routes which have a route via AS1104. Status: optional, multiple lines allowed default: An indication of how default routing is done. Format: where is the AS peer you will default route to, and is the relative cost is a positive integer used to express a preference for default. There is no relationship to the cost used in the as-in tag. The AS peer with the lowest cost is used for default over ones ripe-1nn.txt May, 1994 - 52 - with higher costs. is optional and provides information on how a default route is selected. It can take the fol- lowing formats: 1. static. This indicates that a default is statically configured to this AS peer. 2. A network list with the syntax as described in the as-in attribute. This indicates that this list of routes is used to generate a default route. A special but valid value in this is the special route used by some routing protocols to indicate default: 0.0.0.0/0 3. default. This is the same as {0.0.0.0/0}. This means that the routing protocol between these two peers generates a true default. Examples: default: AS1755 10 default: AS786 5 {140.222.0.0/16, 192.87.45.0/24} default: AS2043 15 default Status: optional, multiple lines allowed tech-c: Full name or uniquely assigned NIC-handle of a technical con- tact person. This is someone to be contacted for technical problems such as misconfiguration. Format: or Example: tech-c: John E Doe tech-c: JED31 Status: mandatory, multiple lines allowed admin-c: Full name or uniquely assigned NIC-handle of an administrative contact person. In many cases this would be the name of the guardian. Format: or Example: admin-c: Joe T Bloggs admin-c: JTB1 ripe-1nn.txt May, 1994 - 53 - Status: mandatory, multiple lines allowed guardian: Mailbox of the guardian of the Autonomous system. Format: The should be in RFC822 domain format wherever possible. Example: guardian: as1104-guardian at nikhef.nl Status: mandatory, only one line and e-mail address allowed remarks: Remarks/comments, to be used only for clarification. Format: free text Example: remarks: Multihomed AS talking to AS1755 and AS786 remarks: Will soon connect to AS1104 also. Status: optional, multiple lines allowed notify: The notify attribute contains an email address to which notifi- cations of changes to this object should be sent. See also [11]. Format: The should be in RFC822 domain syntax wherever possible. Example: notify: Marten.Terpstra at ripe.net Status: optional, multiple lines allowed maintainer: The maintainer attribute contains a registered maintainer name. See also [11]. Format: ripe-1nn.txt May, 1994 - 54 - Example: maintainer: RIPE-DBM Status: optional, multiple lines allowed changed: Who changed this object last, and when was this change made. Format: YYMMDD should be the address of the person who made the last change. YYMMDD denotes the date this change was made. Example: changed: johndoe at terabit-labs.nn 900401 Status: mandatory, multiple lines allowed source: Source of the information. This is used to separate information from different sources kept by the same database software. For RIPE database entries the value is fixed to RIPE. Format: RIPE Status: mandatory, only one line allowed ripe-1nn.txt May, 1994 - 55 - Appendix B - Syntax details for the community object. Here is a summary of the tags associated with community object itself and their status. The first column specifies the attribute, the second column whether this attribute is mandatory in the commun- ity object, and the third column whether this specific attribute can occur only once per object [single], or more than once [multiple]. When specifying multiple lines per attribute, the attribute name must be repeated. See [6] the example for the descr: attribute. community: [mandatory] [single] descr: [mandatory] [multiple] authority: [mandatory] [single] guardian: [mandatory] [single] tech-c: [mandatory] [multiple] admin-c: [mandatory] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] maintainer: [optional] [single] changed: [mandatory] [multiple] source: [mandatory] [single] Each attribute has the following syntax: community: Name of the community. The name of the community should be descriptive of the community it describes. Format: Upper case text string which cannot start with "AS" or any of the KEYWORDS. See Appendix A. Example: community: WCW Status: mandatory, only one line allowed descr: A short description of the community represented. Format: free text Example: descr: Science Park Watergraafsmeer descr: Amsterdam Status: mandatory, multiple lines allowed ripe-1nn.txt May, 1994 - 56 - authority: The formal authority for this community. This could be an organisation, institute, committee, etc. Format: free text Example: authority: WCW LAN Committee Status: mandatory, only one line allowed guardian: Mailbox of the guardian of the community. Format: The should be in RFC822 domain format wherever possible. Example: guardian: wcw-guardian at nikhef.nl Status: mandatory, only one line and email address allowed tech-c: Full name or uniquely assigned NIC-handle of an technical con- tact person for this community. Format: or Example: tech-c: John E Doe tech-c: JED31 Status: mandatory, multiple lines allowed admin-c: Full name or uniquely assigned NIC-handle of an administrative contact person. In many cases this would be the name of the guardian. Format: or Example: admin-c: Joe T Bloggs admin-c: JTB1 ripe-1nn.txt May, 1994 - 57 - Status: mandatory, multiple lines allowed remarks: Remarks/comments, to be used only for clarification. Format: free text Example: remarks: Temporary community remarks: Will be removed after split into ASes Status: optional, multiple lines allowed notify: The notify attribute contains an email address to which notifi- cations of changes to this object should be send. See also [11]. Format: The should be in RFC822 domain syntax wherever possible. Example: notify: Marten.Terpstra at ripe.net Status: optional, multiple lines allowed maintainer: The maintainer attribute contains a registered maintainer name. See also [11]. Format: Example: maintainer: RIPE-DBM Status: optional, multiple lines allowed changed: Who changed this object last, and when was this change made. Format: YYMMDD should be the address of the person who made the last change. YYMMDD denotes the date this change was made. ripe-1nn.txt May, 1994 - 58 - Example: changed: johndoe at terabit-labs.nn 900401 Status: mandatory, multiple lines allowed source: Source of the information. This is used to separate information from different sources kept by the same database software. For RIPE database entries the value is fixed to RIPE. Format: RIPE Status: mandatory, only one line allowed ripe-1nn.txt May, 1994 - 59 - Appendix C - AS Macros syntax definition. Here is a summary of the tags associated with as-macro object itself and their status. The first column specifies the attribute, the second column whether this attribute is mandatory in the as-macro object, and the third column whether this specific attribute can occur only once per object [single], or more than once [multiple]. When specifying multiple lines per attribute, the attribute name must be repeated. See [6] the example for the descr: attribute. as-macro: [mandatory] [single] descr: [mandatory] [multiple] as-list: [mandatory] [multiple] guardian: [mandatory] [single] tech-c: [mandatory] [multiple] admin-c: [mandatory] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] maintainer: [optional] [single] changed: [mandatory] [multiple] source: [mandatory] [single] Each attribute has the following syntax: as-macro: The name of a macro containing at least two Autonomous Systems grouped together for ease of administration. Format: AS- The should be in upper case and not contain any special characters. Example: as-macro: AS-EBONE Status: mandatory, only one line allowed descr: A short description of the Autonomous System Macro. Format: free text Example: descr: Macro for EBONE connected ASes Status: mandatory, multiple lines allowed ripe-1nn.txt May, 1994 - 60 - as-list: The list of ASes that make up this macro. Format: ... See Appendix A for definition. Example: as-list: AS786 AS513 AS1104 Status: mandatory, multiple lines allowed guardian: Mailbox of the guardian of this AS macro. Format: The should be in RFC822 domain format wherever possible. Example: guardian: as-ebone-guardian at ebone.net Status: mandatory, only one line and e-mail address allowed tech-c: Full name or uniquely assigned NIC-handle of a technical con- tact person for this macro. This is someone to be contacted for technical problems such as misconfiguration. Format: or Examples: tech-c: John E Doe tech-c: JED31 Status: mandatory, multiple lines allowed admin-c: Full name or uniquely assigned NIC-handle of an administrative contact person. In many cases this would be the name of the guardian. Format: or Examples: ripe-1nn.txt May, 1994 - 61 - admin-c: Joe T Bloggs admin-c: JTB1 Status: mandatory, multiple lines allowed remarks: Remarks/comments, to be used only for clarification. Format: free text Example: remarks: AS321 will be removed from this Macro shortly Status: optional, multiple lines allowed notify: The notify attribute contains an email address to which notifi- cations of changes to this object should be send. See also [11]. Format: The should be in RFC822 domain syntax wherever possible. Example: notify: Marten.Terpstra at ripe.net Status: optional, multiple lines allowed maintainer: The maintainer attribute contains a registered maintainer name. See also [11]. Format: Example: maintainer: RIPE-DBM Status: optional, multiple lines allowed changed: Who changed this object last, and when was this change made. Format: YYMMDD ripe-1nn.txt May, 1994 - 62 - should be the address of the person who made the last change. YYMMDD denotes the date this change was made. Example: changed: johndoe at terabit-labs.nn 900401 Status: mandatory, multiple lines allowed source: Source of the information. This is used to separate information from different sources kept by the same database software. For RIPE database entries the value is fixed to RIPE. Format: RIPE Status: mandatory, only one line allowed ripe-1nn.txt May, 1994 - 63 - Appendix D - Syntax for the "route" object. There is a summary of the tags associated with community object itself and their status. The first column specifies the attribute, the second column whether this attribute is mandatory in the commun- ity object, and the third column whether this specific attribute can occur only once per object [single], or more than once [multiple]. When specifying multiple lines per attribute, the attribute name must be repeated. See [6] the example for the descr: attribute. route: [mandatory] [single] descr: [mandatory] [multiple] origin: [mandatory] [single] component: [optional] [multiple] comm-list: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] maintainer: [optional] [single] changed: [mandatory] [multiple] source: [mandatory] [single] Each attribute has the following syntax: route: Route being announced. Format: Classless representation of a route with the RIPE database known as the "prefix length" representation. See [10] for more details on classless representations. Examples: route: 192.87.45.0/24 This represents addressable bits 192.87.45.0 to 192.87.45.255. route: 192.1.128.0/17 This represents addressable bits 192.1.128.0 to 192.1.255.255. Status: mandatory, only one line allowed origin: The autonomous system announcing this route. Format: ripe-1nn.txt May, 1994 - 64 - See appendix A for syntax. Example: origin: AS1104 Status: mandatory, only one line allowed component: Represents the components which make up the route. Components in the same AS and in the same communities.need not be listed. Note components do not need to appear as their own route objects if there are no more specific routes to them originated anywhere. Format: is a more specific component route. can take the following formats: 1. ... where the list of communities can be empty. 2. HOLE Example: component: 193.0.2.0/24 AS1111 component: 193.0.3.0/24 AS2222 HEP EUNET component: 193.0.4.0/24 HOLE Status: mandatory, multiple lines allowed comm-list: List of one or more communities this route is part of. Format: ... See Appendix B for definition. Example: comm-list: HEP LEP Status: optional, multiple lines allowed remarks: Remarks/comments, to be used only for clarification. Format: ripe-1nn.txt May, 1994 - 65 - free text Example: remarks: Multihomed AS talking to AS1755 and AS786 remarks: Will soon connect to AS1104 also. Status: optional, multiple lines allowed notify: The notify attribute contains an email address to which notifi- cations of changes to this object should be send. See also [11]. Format: The should be in RFC822 domain syntax wherever possible. Example: notify: Marten.Terpstra at ripe.net Status: optional, multiple lines allowed maintainer: The maintainer attribute contains a registered maintainer name. See also [11]. Format: Example: maintainer: RIPE-DBM Status: optional, multiple lines allowed changed: Who changed this object last, and when was this change made. Format: YYMMDD should be the address of the person who made the last change. YYMMDD denotes the date this change was made. Example: changed: johndoe at terabit-labs.nn 900401 Status: mandatory, multiple lines allowed ripe-1nn.txt May, 1994 - 66 - source: Source of the information. This is used to separate information from different sources kept by the same database software. For RIPE database entries the value is fixed to RIPE. Format: RIPE Status: mandatory, only one line allowed ripe-1nn.txt May, 1994 - 67 - Appendix E - Motivations for RIPE-81++ This appendix gives motivations for the major changes in this propo- sal from ripe-81. (It is not complete yet). The main goals of the routing registry rework are: SPLIT Separate the allocation and routing registry functions into different database objects. This will facilitate data manage- ment if the Internet registry and routing registry functions are separated (like in other parts of the world). It will also make more clear what is part of the routing registry and who has authority to change allocation vs. routing data. CIDR Add the possibility to specify classless routes in the routing registry. Classless routes are being used in Internet produc- tion now. Aggregation information in the routing registry is necessary for network layer troubleshooting. It is also neces- sary because aggregation influences routing policies directly. CALLOC Add the possibility to allocate address space on classless boundaries in the allocation registry. This is a way to preserve address space. CLEAN To clean up some of the obsolete and unused parts of the rout- ing registry. The major changes are now discussed in turn: Introduce Classless Addresses CIDR, CALLOC Introduce route object. SPLIT, CIDR and CALLOC. Delete obsolete attributes from inetnum. CLEAN. ripe-1nn.txt May, 1994 - 68 - Delete RIPE-DB and LOCAL from routing policy expressions. CLEAN Allow multiple ASes to originate the same route Because it is being done. CIDR. Made possible by SPLIT. ripe-1nn.txt May, 1994 - 69 - Appendix F - Transition strategy from RIPE-81 to RIPE-81++ Transition from the routing registry described by ripe-81 to the routing registry described in this document is a straightforward process once the new registry functions have been implemented in the database software and are understood by the most commonly used registry tools. The routing related attributes in the classful inet- num objects of ripe-81 can be directly translated into new routing objects. Then these attributes can be deleted from the inetnum object making that object conform to the new schema. Proposed transition steps: 1) Implement classless addresses and new object definition in the database software. 2) Make common tools understand the new schema and prefer it if both old and new are present. 3) Invite everyone to convert their data to the new format. This can be encouraged by doing conversions automatically and pro- posing them to maintainers. 4) At a flag day remove all remaining routing information from the inetnum objects. Before the flag day all usage of obsoleted inetnum attributes has to cease and all other routing registry functions have to be taken over by the new objects and attri- butes. The current estimate is that point three can be reached in the Sum- mer 1994 if the draft is accepted by mid-June. The flag day should be scheduled 3-4 months after this point. ripe-1nn.txt May, 1994 -------- Logged at Thu Jun 23 20:42:55 MET DST 1994 ---------