📄 rfc2725.txt
字号:
curly braces or the keyword "ANY" may follow. The default, when no additional set items are specified is "ANY" or all more specifics. The mnt-routes attribute is optional and multiple. See usage details in Section 9.1. mnt-lower The mnt-lower attribute may appear in an inetnum, route, as-block or aut-num object. This attribute references a maintainer object. When used in an inetnum or route object the effect is the same as a "mnt-routes" but applies only to prefixes more specific than the prefix of the object in which it is contained. In an as block object, mnt-lower allows addition of more specific as-block objects or aut-num objects. In an aut-numVillamizar, et al. Standards Track [Page 21] RFC 2725 Routing Policy System Security December 1999 object the mnt-lower attribute specifies a maintainer that can be used to add objects with hierarchical names as described in Section 9.7. reclaim The reclaim attribute may appear in as-block, aut-num, inet-num, or route objects. Any object of the same type below in the hierarchy may be modified or deleted by the maintainer of the object containing a reclaim attribute. The value of the attribute is a set or range of objects of the same type where the syntax of the set or range is as defined in RPSL. See Section 9.5 for restrictions on adding reclaim attributes. no-reclaim The no-reclaim attribute is used with the reclaim attribute. The no-reclaim attribute negates any reclaim attribute it overlaps. See Section 9.5 for restrictions on deleting no- reclaim attributes. referral-by This attribute is required in the maintainer object. It may never be altered after the addition of the maintainer. This attribute refers to the maintainer that created this maintainer. It may be multiple if more than one signature appeared on the transaction creating the object. auth-override An auth-override attribute can be added, deleted, or changed by a transaction submitted by maintainer listed in the referral-by. An auth-override can only be added to a maintainer if that maintainer has been inactive for the prior 60 days. The auth-override attribute itself contains only the date when the attribute will go into effect which must be at least 60 days from the current date unless there is already authorization to modify the maintainer. After the date in the auth-override is reached, those identified by the maintainer in the referral-by have authorization to modify the maintainer. This attribute exists as a means to clean up should the holder of a maintainer become unresponsive and can only take effect if that maintainer does not remove the auth-override in response to the automatic notification that occurs on changes. The existing "mnt-by" attribute references the "maintainer" object type. The "mnt-by" attribute is now mandatory in all object types. A new maintainer may be added by any existing maintainer. The "referral-by" attribute is now mandatory in the "maintainer" object to keep a record of which maintainer made the addition and can never be changed. Maintainers cannot be deleted as long as they are referenced by a "referral-by" attribute elsewhere.Villamizar, et al. Standards Track [Page 22] RFC 2725 Routing Policy System Security December 1999A Core and Non-Core Functionality Most of the objects and attributes described in this document are essential to the authorization framework. These are referred to as being part of the "core" functionality. A few attributes listed here are considered "non-core". The "reclaim" and "no-reclaim" attributes are a convenience to support flexibility in the implementation of address lending. The "auth-override" attribute is a convenience to facilitate recovery in an environment where repository data is redistributed in any way. The "referal-by" attribute is a "core" feature. An individual registry may express its sutonomy by creating a self-referencing maintainer, one whose "referal-by" points to itslef. Other registries can decide on a case by case basis whether to consider such an entry valid. A registry may only allow the "referal-by" to refer to a specific maintainer under the control of the registry. This further restriction is an issue that is purely local to the registry.B Examples The examples below leave out some required attributes that are not needed to illustrate the use of the objects and attributes described in this document. Missing are admin-c, tech-c, changed, source. Also missing are attributes such as mnt-nfy, whose use are a good practice but are not strictly required. To do anything at all a maintainer is needed. At some epoch a a single maintainer is populated in one repository and that maintianer has a referal-by pointing to itself. All others referal-by references can be traced back to that maintainer. At the epoch the as-block AS0- AS65535 and the inetnum 0.0.0.0-255.255.255.255 are also allocated. Other ancilliary object may also be needed to bootstrap. mntner: ROOT-MAINTAINER auth: pgpkey-12345678 mnt-by: ROOT-MAINTAINER referal-by: ROOT-MAINTAINER This root maintainer might add a top level maintainer for some organization.Villamizar, et al. Standards Track [Page 23] RFC 2725 Routing Policy System Security December 1999 mntner: WIZARDS descr: High level Technical Folks auth: pgpkey-23456789 auth: pgpkey-3456789a mnt-by: WIZARDS referal-by: ROOT-MAINTAINER That maintainer might add another who have more limited capabilities. mntner: MORTALS descr: Maintain day to day operations auth: pgpkey-456789ab auth: pgpkey-56789abc auth: pgpkey-6789abcd mnt-by: WIZARDS referal-by: WIZARDS Note that the WIZARDS can change their own maintainer object and the MORTALS maintainer object but MORTALS cannot. At some point an as-block is allocated and broken down. In the example below, private number space is used. as-block: AS65500-AS65510 mnt-by: SOME-REGISTRY mnt-lower: WIZARDS Note that a registry has control over the object that they have created representing the allocation, but have given the party to which the allocation was made the ability to create more specific objects. Below this as-block, an aut-num is added. Note that import and export are normally required for a aut-num but are not shown here. aut-num: AS65501 mnt-by: WIZARDS mnt-lower: MORTALS In aut-num above the WIZARDS maintainer can modify the aut-num itself. The MORTALS maintainer can add route objects using this AS as the origin if they also have authorization for the IP number space in a less specific route or inetnum.Villamizar, et al. Standards Track [Page 24] RFC 2725 Routing Policy System Security December 1999 We also need an inetnum allocation. In this example the inetnum is allocated to a completely different organization. Again attributes are omited which would normally be needed in an inetnum. inetnum: 192.168.144.0-192.168.151.255 mnt-by: SOME-REGISTRY mnt-lower: ISP reclaim: ALL The maintainer ISP can add more specific inetnums or routes with this address space. Note that the registry has declared their ability to reclaim the address space. If ISP wished to reclaim all allocations but some suballocation of theirs resisted, we might get something like the following in which they will reclaim only the top half of an allocation (possibly if it remains unused). inetnum: 192.168.144.0-192.168.147.255 mnt-by: ISP mnt-lower: EBG-COM reclaim: 192.168.146/23+ If we assume that the maintainer EBG-COM and the maintainer MORTALS want to add a route object, one way to do it is for both parties to sign. If EBG-COM for some reason couldn't aggregate an allocate a single top level route (which is inexcusable these days) or there was a preference for some reason to avoid the joint signature approach on a submission either party could give the other permission to make the addition. A mnt-routes could be added to the aut-num or a mnt-lower could be added to an inetnum. aut-num: AS65501 mnt-by: WIZARDS mnt-lower: MORTALS mnt-routes: EBG-COM {192.168.144/23} With this change to the aut-num the maintainer EBG-COM could add a route with origin AS65501, but only with a limited address range. route: 192.168.144/24 origin: AS65501 descr: These boneheads don't aggregate mnt-by: EBG-COM mnt-by: FICTION::MORTALS Note that while the maintainer EBG-COM added the object they allowed the maintainer MORTALS the ability to modify it.Villamizar, et al. Standards Track [Page 25] RFC 2725 Routing Policy System Security December 1999 If an object ended up in another repository, a single maintainer could still be used. In the example above the notation FICTION::MORTALS indicates that the route object is in a different repository and rather than duplicate the maintainer, a reference is made to the repository in which the MORTALS object resides. In the example below, a pair of route-sets are added and hierarchical names are used. route-set: AS65501:Customers mnt-by: WIZARDS mnt-lower: MORTALS route-set: AS65501:Customers:EBG-COM mnt-by: MORTALS mnt-lower: EBG-COM Suppose in the 192.168.144/24 object above, only the EBG-COM maintainer is listed. If EBG-COM goes bankrupt, no longer needs address space, and stops responding, it could be difficult to delete this object. The maintainer listed in the EBG-COM referral-by attribute could be contacted. They could add a auth-override attribute to the EBG-COM object. Later they could modify the EBG-COM object and then any objects with EBG-COM in the mnt-by. mntner: EBG-COM mnt-by: EBG-COM auth-override: 19990401 The examples above stray significantly from realism. They do provide simple illustrations of the usage of the objects type and attributes described in this document and hopefully in doing some are of some value.C Technical Discussion A few design tradeoffs exist. Some of these tradeoffs, the selected solution, and the alternatives are discussed here. Some of the issues are listed below. 1. Whether to err on the side of permissiveness and weaken authorization controls or risk the possibility of erecting ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -