of route objects. After the reference to the maintainer, an
optional list of prefix ranges (as defined in RPSL) inside of
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-num
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.
A 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.
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.
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.
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
barriers to registering information.
2. Whether to support enforcible address lending or provide the
smaller or end user with ultimate control over the registration of
the prefixes they are using.
3. What to do with older objects that either don't conform to newer
requirements regarding minimum authorization, authentication, and
accountability, or are of questionable validity.
C.1 Relaxing requirements for ease of registry
If the requirement that an aut-num exists is relaxed, then it is
possible for anyone to make use of an unassigned AS number or make
use of an assigned AS number for which the aut-num has not been
entered. Placing requirements on the entry of aut-num presumes
cooperation of the Internet address allocation authority (if separate
from the routing registry). The address allocation authority must be
willing to field requests to populate skeleton aut-nums from the
party for which the allocation has been made. These aut-num must
include a reference to a maintainer. A request to the address
allocation authority must therefore include a reference to an
existing maintainer.
The ability to add route objects is also tied to the existence of
less specific route objects or inetnums. The Internet address
allocation authority (if separate from the routing registry) must
also be willing to field requests to add inetnum records for the
party already allocated the address space.
The Internet address allocation authority should also add inetnums
and aut-nums for new allocations. In order to do so, a maintainer
must exist. If a party is going to connect to the Internet, they can
get a maintainer by making a request to the Internet service provider
they will be connecting to. Once they have a maintainer they can
make a request for address space or an AS number. The maintainer can
contain a public key for a cryptographicly strong authorization
method or could contain a "crypt-key" or "mail-to" authorization
check if that is considered adequate by the registering party.
Furthermore an address allocation authority should verify that the
request for an AS number or for address space matches the
authorization criteria in the maintainer.
Currently only the registries themselves may add maintainers. This
becomes a problem for the registry, particularly in verifying public
keys. This requirement is relaxed by allowing existing maintainers
to add maintainers. Unfortunately the accountability trail does not
exist for existing maintainers. The requirement then should be
relaxed such that existing maintainers may remain but only existing
maintainers that have a "referral-by" attribute can add maintainers.
The "referral-by" cannot be modified. This requirement can be
relaxed slightly so that a "referral-by" can be added to a maintainer
by an existing maintainer with a "referral-by". This will allow the
accountability trail to be added to existing maintainers and these
maintainers can then add new maintainers.
Verifying that a party is who they claim to be on initial addition,
is one of the problems that currently falls upon the AS number and
address registry. This problem is reduced by allowing existing
maintainers to add maintainers. This may actually make it easier to
get maintainers and therefore easier to register. The number
authority still must verify that the AS or address space is actually
needed by the party making a request.
Authorization checks made during the addition of route objects that
refer to AS objects and inetnums strongly rely on the cooperation of
the Internet address allocation authorities. The number authorities
must register as-blocks, aut-nums, or inetnums as AS numbers or
address space is allocated. If only a subset of the number
authorities cooperate, then either an inetnum or as-block can be
created covering the space that registry allocates and essentially
requiring null allocation (for example a "crypt-pw" authentication
where the password is given in the remarks in the object or its
maintainer) or those obtaining addresses from that number authority
will have trouble registering in the routing registry. The
authorization model supports either option, though it would be
preferable if the number authorities cooperated and the issue never
surfaced in practice.
The maintainer requirements can be relaxed slightly for existing
maintainers making it easier to register. Relaxing requirements on
other objects may defeat the authorization model, hence is not an
option.
C.2 The address lending issue
The issue of whether lending contracts should be enforcible is an
issue of who should ultimately be able to exercise control over
allocations of address space. The routing registry would be wise to
stay as neutral as possible with regard to disputes between third
parties. The "reclaim" and "no-reclaim" are designed to allow either
outcome to the decision as to whether the holder of a less specific
inetnum or route object can exercise control over suballocations in
the registry. The routing registry itself must decide whether to
retain control themselves and if so, should very clearly state under
what conditions the registry would intervene. A registry could even
go to the extreme of stating that they will intervene in such a
dispute only after the dispute has been resolved in court and a court
order has been issued.
When an allocation is made by a registry, the registry should keep a
"reclaim" attribute in the less specific object and make a strong
policy statement that the reclaim privilege will not be used except
under very clearly defined special circumstances (which at the very
minimum would include a court order). If the allocation is further
subdivided the party subdividing the allocation and the party
accepting the suballocation must decide whether a "reclaim" can be
kept by the holder of the less specific allocation or whether a "no-
reclaim" must be added transferring control to the holder of the more
specific. The registry is not involved in that decision. Different
pairs of third parties may reach different decisions regarding the
"reclaim" and any contractual restrictions on its use that may be
expressed outside of the registry in the form of a legal contract and
ultimately resolved by the courts in the event of a bitter dispute.
By retaining "reclaim" rights the registry retains the ability to
abide by a court order. This may only truly become an issue in a
distributed registry environment where registries will be rechecking
the authorization of transactions made elsewhere and may fail to
process the attempt of another registry to abide by a court order by
overriding normal authorization to change the registry contents if a
reclaim is not present.
C.3 Dealing with non-conformant or questionable older data
Some of the newer requirements include requiring that all objects
reference a maintainer object responsible for the integrity of the
object and requiring accountability for the creation of maintainers
to be recorded in the maintainer objects so that accountability can
be traced back from an unresponsive maintainer. In the event that
contact information is absent or incorrect from objects and there is
any question regarding the validity of the objects, the maintainer
can be contacted. If the maintainer is unresponsive, the maintainer
that authorized the addition of that maintainer can be contacted to
either update the contact information on the maintainer or confirm
that the entity no longer exists or is no longer actively using the
Internet or the registry.
Many route objects exist for which there are no maintainers and for
which inetnum and AS objects do not exist. Some contain the now
obsoleted guardian attribute rather than a mnt-by.
It is not practical to unconditionally purge old data that does not
have maintainers or does not conform to the authorization hierarchy.
New additions must be required to conform to the new requirements
(otherwise the requirements are meaningless). New requirements can
be phased in by requiring modifications to conform to the new
requirements.
A great deal of questionable data exists in the current registry.
The requirement that all objects have maintainers and the
requirements for improved accountability in the maintainers
themselves may make it easier to determine contact information even
where the objects are not updated to reflect contact information
changes.
It is not unreasonable to require valid contact information on
existing data. A great deal of data appears to be unused, such as
route objects for which no announcement has been seen in many months
or years. An attempt should be made to contact the listed contacts
in the object, in the maintainer if there is one, then up the
maintainer referral-by chain if there is one, and using the number
registry or origin AS contact information if there is no maintainer
accountability trail to follow. Experience so far indicates that the
vast majority of deletions identified by comparing registered
prefixes against route dumps will be positively confirmed (allowing
the deletion) or there will be no response due to invalid contact
information (in many cases the IRR contact information points to
nsfnet-admin@merit.edu).
By allowing the registry to modify (or delete) any objects which are
disconnected from the maintainer accountability trail, cleanup can be
made possible (though mail header forging could in many cases have
the same effect it is preferable to record the fact that the registry
itself made the cleanup). Similarly, a mechanism may be needed in
the future to allow the maintainer in the referral-by to override
maintainer privileges in a referred maintainer if all contacts have
become unresponsive for a maintainer. The referral-by maintainer is
allowed to add an "auth-override" attribute which becomes usable as
an "auth" within 60 days from the time of addition. The maintainer
themselves would be notified of the change and could remove the
"auth-override" attribute before it becomes effective and inquire as
to why it was added and correct whatever problem existed. This can
be supported immediately or added later if needed.
D Common Operational Cases
In principle, address allocation and route allocation should be
hierarchical with the hierarchy corresponding to the physical
topology. In practice, this is often not the case for numerous
reasons. The primary reasons are the topology is not strictly tree
structured and the topology can change. More specificly:
1. The Internet topology is not strictly tree structured.
o At the top level the network more closely resembles a
moderately dense mesh.
o Near the bottom level many attachments to the Internet are
multi-homed to more than one Internet provider.
2. The Internet topology can and does change.
o Many attachments switch providers to obtain better service or
terms.
o Service providers may modify adjacencies to obtain better
transit service or terms.
o Service providers may disappear completely scattering
attachments or they may merge.
Renumbering is viewed as a practical means to maintain a strict
numeric hierarchy [16]. It is also acknowledged that renumbering
IPv4 networks can be difficult [16, 3, 17]. We examine first the
simple case where hierarchy still exists. We then examine the
operational cases where either initial topology is not tree
structured or cases where topology changes.
D.1 simple hierarchical address allocation and route allocation
This is the simplest case. Large ranges of inetnums are assigned to
address registries. These registries in turn assign smaller ranges
for direct use or to topologically large entities where allocations
according to topology can reduce the amount of routing information
needed (promote better route aggregation).
AS objects are allocated as topology dictates the need for additional
AS [10]. Route objects can be registered by those with authorization
given by the AS and by the address owner. This is never an issue
where the maintainer of the AS and the inetnum are the same. Where
they differ, either the provider can give permission to add route
objects for their AS, or the party allocated the address space can
give the provider permission to add route objects for their address
space, or both parties can sign the transaction. Permission is
provided by adding to maintainer attributes.
D.2 aggregation and multihomed more specific routes
Aggregation is normally not a problem if a provider is aggregating
address space allocated to the provider and then suballocated
internally and/or to customers. In fact, the provider would be
expected to do so. This is not a problem even if the route object
for the aggregation is added after the more specific route objects
since only less specific objects are considered.
Aggregation is potentially a problem if a provider or a set of
providers plan to aggregate address space that was never explicitly
allocated as a block to those providers but rather remains the
allocation of a address registry. These large aggregations can be
expected to be uncommon, but relatively easily dealt with.
Superaggregates of this type will generally be formed by
topologically close entities who have also managed to draw adjacent
address allocations. In effect, the registry must give permission to
form such a superaggregate by either giving permission to do so in
the mnt-routes of an inetnum or by signing the submission along with
the other parties.
D.3 provider independent addresses and multiple origin AS
Provider independent addresses and multihoming arrangement using
multiple origin AS present a similar problem to multihoming. The
maintainer of the address space and the maintainer of the AS is not
the same. Permission can be granted using mnt-routes or multiple
signatures can appear on the submission.
D.4 change in Internet service provider
A change in Internet service providers is similar to multihoming. A
minor difference is that the AS for the more specific route will be
the AS of the new provider rather than the AS of the multihomed
customer. Permission can be granted using mnt-routes or multiple
signatures can appear on the submission.
D.5 renumbering grace periods
Renumbering grace periods allow a provider who wants to keep an
address allocation intact to allow a customer who has chosen to go to
another provider to renumber their network gradually and then return
the address space after renumbering is completed. The issue of
whether to require immediate renumbering or offer renumbering grace
periods and how long they should be or whether they should be
indefinite has been topic of bitter disputes. The authorization
model can support no renumbering grace period, a finite renumbering
grace period, or an indefinite renumbering grace period. The
"reclaim" attribute described in Section 9.1 provides a means to end
the grace period.
E Deployment Considerations
This section describes deployment considerations. The intention is
to raise issues and discuss approaches rather than to provide a
deployment plan.
The use of routing registries is not yet universally accepted. There
still remain Internet providers who see no reason to provide the
added assurance of accurate routing information described in Section
6. More accurately, these benefits are viewed as being insufficient
to justify the cost. This has been largely caused an inability of a
very major router vendor up until recently to handle prefix lists of
the size needed to specify routing policy on a per prefix basis.
Another reason cited is that filtering on a prefix basis in an
environment where routing registry information is incomplete or
inaccurate can interfere with connectivity.
There clearly is a critical mass issue with regard to the use of
routing registries. A minority of providers use the existing IRR to
filter on a per prefix basis. Another minority of providers do not
support the IRR and generally fail to register prefixes until
connectivity problems are reported. The majority of providers
register prefixes but do not implement strict prefix filtering.
Deploying new authentication mechanisms has no adverse consequences.
This has been proven with Merit's deployment of PGP.
In deploying new authorization mechanisms, a major issue is dealing
with existing data of very questionable origin. A very large number
of route objects refer to prefixes that have not been announced for
many years. Other route objects refer to prefixes that are no longer
announced with the origin AS that they are registered with (some were
incorrectly registered to start with). There are many causes for
this.
1. During the transition from the NSFNET PRDB to the RADB a large
number of prefixes were registered with an origin AS corresponding
to the border AS at which the NSFNET had once heard the route
announcements. The PRDB did not support origin AS, so border AS
was used. Many of these routes were no longer in use at the time
and are now routed with a submitter listed as "nsfnet-
admin@merit.edu".
2. As CIDR was deployed, aggregates replaced previously separately
announced more specific prefixes. The route objects for the more
specific prefixes were never withdrawn from the routing
registries.
3. Some prefixes are simply no longer in use. Some networks have
been renumbered. Some network no longer exist. Often the routing
registry information is not withdrawn.
4. As provider AS adjacencies changed and as end customers switched
providers often the actual origin AS changed. This was often not
reflected by a change in the routing registry.
Inaccuracies will continue to occur due to the reasons above, except
the first. The hierarchical authorization provides greater
accountability. In the event that the contacts for specific objects
become unresponsive traversal up the authorization hierarchy should
help identify the parties having previous provided authorization.
These contacts may still have sufficient authorization to perform the
necessary cleanup. This issue is discussed in Section C.
A great deal of information is currently missing in the IRR. Quite a
few AS have no aut-num. Quite a lot of data has no maintainer and
the vast majority of maintainers use only the weakest of
authentication methods. Very little can be done by the registries to
correct this. The defaults in the cases of missing objects needed
for authorization has to be to make no authentication checks at all.
The transition can be staged as follows:
1. Add and make use of stronger authorization models.
2. Make schema modifications necessary to support delegations.
3. Add delegation attributes needed for query traversal.
4. Base query traversal on delegations rather than a search of all
known registries.
5. Obtain the cooperation of the address registries for the purpose
of populating the "inetnum" entries on an ongoing basis.
6. Add hierarchical authorization support for critical object types,
"aut-num", "inetnum" and "route".
7. Add the requirement that database object either be in use or have
valid contact information and if queries are made by the registry
a response from a contact indicating that the object serves a
purpose if it is not clear what its use is.
8. Begin to purge data which is clearly not in use and for which
there is no valid contact information or no response from the
contacts.
Deployment of hierarchical authorization requires cooperation among
the existing routing registries. New code will have to be deployed.
In some cases minimal development resources are available and
substantial inertia exists due to the reliance on the current
repository and the need to avoid disruption.
If hierarchical authorization of route objects depends on the
existence of address registration information, minimal cooperation of
the currently separate address registries is required. The extent of
the cooperation amounts to sending cryptographically signed
transactions from the address registry to the number registry as
address allocations are made or providing equivalent access to new
address allocations.
Currently most registries return query results from all of the known
repositories using their mirrored copies. Cross registry
authorizations are not yet implemented. Minimal schema changes have
to be made to support the ability to delegate objects for which there
is an authorization hierarchy and to support queries and references
to other repositories. In the case of AS delegations, "as-block"
need to be created solely for the purpose of traversal.
F Route Object Authorization Pseudocode
The following list provides a brief review of basic concepts.
1. The route object submission must satisfy two authentication
criteria. It must match the authentication specified in the aut-
num and the authentication specified in either a route object or
if no applicable route object is found, then an inetnum.
2. When checking for prefix authorization, an exact route object
prefix match is checked for first. If there is not an exact match
then a longest prefix match that is less specific than the prefix
is searched for. If the route prefix search fails, then a search
is performed for an inetnum that exactly matches the prefix or for
the most specific inetnum that is less specific than the route
object submission.
The search for an inetnum should never fail but it may return an
unallocated or reserved range. The inetnum status must be
"allocated" and the submission must pass it's maintainer
authorization in order to get authorization from an inetnum. So
an unallocated or reserved range inetnum will cause the route
object submission to fail.
3. A route object must pass authorization from both the referenced
aut-num object and the route or inetnum object. Authorization
shall be tested using the maintainer(s) referenced in the "mnt-
routes" attribute(s) first. If that check fails, the "mnt-lower"
attributes are checked. If that check fails the "mnt-by"
attributes are used for the authorization check.
4. The "reclaim" attribute can appear in inetnum, route and as-block
objects and provides a means to support address lending. "reclaim"
gives authorization over more specific objects, regardless of the
"mnt-by" in the object. The value of a "reclaim" attribute can be
a list or set of objects to provide finer grain control.
The "reclaim" attribute is important to this discussion since it
affects prefix/origin authentication when a new route object is
submitted.
The "no-reclaim" attribute is used to provide explicit exceptions.
The following pseudocode outlines the algorithm used to check for
proper authorization of a route object submission.
Case #1. Route object add
(ie, no exact prefix/origin match exists).
/* first check the aut-num authorization */
if ( the referenced aut-num object does not exist or
the aut-num authorization fails )
authorization fails
/* next we check for prefix authorization */
if ( a less specific route(s) with the longest prefix is found ) [
if ( authorization does not pass for at least one of the less
specific route(s) )
authorization fails
/* now check for a "reclaim" attr */
if ( the object has a "reclaim" attribute ) [
if ( no more-specifics exist
OR a less specific exists which passes
authorization and has a "reclaim" attribute
OR all more specifics routess pass modify authorization )
authorization passes
else
authorization fails
] else
authorization passes
]
/* there are no less specific routes to check for prefix
authentication, so we need to try and get authorization from an
inetnum object */
if ( ( an inetnum is found that is an exact match
OR is less specific and it's status is "allocated" )
AND a maintainer referenced by the inetnum
passes authorization )
authorization succeeds
/* if there is no inetnum or route object then then
authorization fails. This should never happen if
the DB is initialized properly. */
authorization fails.
Case #2. Route object modify/delete
(ie, exact prefix/origin match exists).
if ( the mnt-by passes authorization )
authorization succeeds
/* if the authorization did not pass from the matched object,
we can still get authorization from a less specific route if it
has a "reclaim" attribute and we pass authorization */
if ( a less specific route or inetnum object passes authorization
AND has a "reclaim" attribute applicable to
the object to be modified )
authorization succeeds
else
authorization fails
Acknowledgments
This document draws ideas from numerous discussions and contributions
of the IETF Routing Policy System Work Group and RIPE Routing Work
Group. Earlier drafts of this document listed Carol Orange as a co-
author. Carol Orange made contributions to this document while at
RIPE.
Gerald Winters provided the pseudocode in an email message to the
RIPE dbsec mailing list that was the basis of the pseudocode found in
appendix F. Susan Harris provided comments and numerous editorial
corrections.
Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
References
[1] Alaettinoglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer,
D., Terpstra M. and C. Villamizar, "Routing Policy
Specification Language (RPSL)", RFC2280, January 1998.
[2] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M.,
Karrenberg, D., Terpstra, M. and J. Yu, "Representation of IP
Routing Policies in a Routing Registry (ripe-81++)", RFC1786,
March 1995.
[3] Berkowitz, H., "Router Renumbering Guide", RFC2072, January
1997.
[4] Braun, H-W., "Models of policy based routing", RFC1104, June
1989.
[5] Braun, H-W. and Y. Rekhter, "Advancing the NSFNET routing
architecture", RFC1222, May 1991.
[6] Clark, D., "Policy routing in Internet protocols", RFC1102,
May 1989.
[7] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC822, August 1982.
[8] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC1519, September 1993.
[9] Internet Engineering Steering Group and R. Hinden,
"Applicability Statement for the Implementation of Classless
Inter-Domain Routing (CIDR)", RFC1517, September 1993.
[10] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)", RFC
1930, March 1996.
[11] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J.
Postel, "Internet Registry IP Allocation Guidelines", BCP 12,
RFC2050, November 1996.
[12] Knopper, M. and S. Richardson, "Aggregation Support in the
NSFNET Policy-Based Routing Database", RFC1482, June 1993.
[13] Meyer, D., Prior, M., Alaettinoglu, C., Schmitz, J. and Carol
Orange, "Using RPSL in Practice", RFC2650, August 1999.
[14] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787,
April 1995.
[15] Rekhter Y. and T. Li, "An Architecture for IP Address
Allocation with CIDR", RFC1518, September 1993.
[16] Rekhter Y. and T. Li, "Implications of Various Address
Allocation Policies for Internet Routing", RFC2008, October
1996.
[17] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S. and J.
Postel, "An IPv6 Provider-Based Unicast Address Format", RFC
2073, January 1997.
[18] Zsako, J., "PGP Authentication for RIPE Database Updates", RFC
2726, December 1999.
Security Considerations
This document primarily addresses authorization rules for making
additions, deletions, and changes to routing policy information
repositories. The authentication of these transactions through
strong cryptographic means are addressed by [18], referenced
thorughout this document. The authorization rules are designed such
that the integrity of any transaction can be verified independently
by any party mirroring a repository to insure that rules are adhered
to. To accomplish this the mirror must contain data already known to
be properly authorized. In other words, the mirror must be complete
and authentication and authorization checks must be made continuously
as changes to the repository are recieved and processed in order.
Authentication alone does not provide a complete security model.
Current practice specifies authorization for deletions and changes
only, not for additions. The authorization rules provide here
complete the security model for additions, deletions, and changes by
very explicitly defining rules for addition and clarifying procedures
for handling exception cases such as organizations which have ceased
to exist and therefore become entirely unresponsive.
Authentication and authorization of queries is explicitly stated to
be out of scope of this document.
Authors' Addresses
Curtis Villamizar
Avici Systems
EMail: curtis@avici.com
Cengiz Alaettinoglu
ISI
EMail: cengiz@ISI.EDU
David M. Meyer
Cisco
EMail: dmm@cisco.com
Sandy Murphy
Trusted Information Systems
EMail: sandy@tis.com
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.