RFC2725 日本語訳
2725 Routing Policy System Security. C. Villamizar, C. Alaettinoglu,D. Meyer, S. Murphy. December 1999. (Format: TXT=101649 bytes) (Updated by RFC4012) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Villamizar
Request for Comments: 2725 Avici
Category: Standards Track C. Alaettinoglu
ISI
D. Meyer
Cisco
S. Murphy
TIS
December 1999
Network Working Group C. Villamizar Request for Comments: 2725 Avici Category: Standards Track C. Alaettinoglu ISI D. Meyer Cisco S. Murphy TIS December 1999
Routing Policy System Security
Routing Policy System Security
Status of this Memo
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
Abstract
The RIPE database specifications and RPSL language define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model.
The RIPE database specifications and RPSL language define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model.
Villamizar, et al. Standards Track [Page 1] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 1] RFC 2725 Routing Policy System Security December 1999
Table of Contents
Table of Contents
1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Background . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Implicit Policy Assumptions . . . . . . . . . . . . . . . . 5
4 Scope of Security Coverage . . . . . . . . . . . . . . . . 5
5 Organization of this Document . . . . . . . . . . . . . . 6
6 Goals and Requirements . . . . . . . . . . . . . . . . . . 6
7 Data Representation . . . . . . . . . . . . . . . . . . . . 10
8 Authentication Model . . . . . . . . . . . . . . . . . . . 10
9 Authorization Model . . . . . . . . . . . . . . . . . . . . 12
9.1 Maintainer Objects . . . . . . . . . . . . . . . . . . 12
9.2 as-block and aut-num objects . . . . . . . . . . . . . 13
9.3 inetnum objects . . . . . . . . . . . . . . . . . . . 13
9.4 route objects . . . . . . . . . . . . . . . . . . . . 14
9.5 reclaim and no-reclaim attributes . . . . . . . . . . 14
9.6 Other Objects . . . . . . . . . . . . . . . . . . . . 15
9.7 Objects with AS Hierarchical Names . . . . . . . . . . 16
9.8 Query Processing . . . . . . . . . . . . . . . . . . . 16
9.9 Adding to the Database . . . . . . . . . . . . . . . . 17
9.10 Modifying or Deleting Database Objects . . . . . . . . 19
10 Data Format Summaries . . . . . . . . . . . . . . . . . . 20
10.1 Changes to the RIPE/RPSL Schema . . . . . . . . . . . 20
Appendicies
A Core and Non-Core Functionality . . . . . . . . . . . . . . 23
B Examples . . . . . . . . . . . . . . . . . . . . . . . . . 23
C Technical Discussion . . . . . . . . . . . . . . . . . . . 26
C.1 Relaxing requirements for ease of registry . . . . . 27
C.2 The address lending issue . . . . . . . . . . . . . . 28
C.3 Dealing with non-conformant or questionable older
data . . . . . . . . . . . . . . . . . . . . . . . . . 29
D Common Operational Cases . . . . . . . . . . . . . . . . . 30
D.1 simple hierarchical address allocation and route
allocation . . . . . . . . . . . . . . . . . . . . . . 31
D.2 aggregation and multihomed more specific routes . . . 32
D.3 provider independent addresses and multiple origin
AS . . . . . . . . . . . . . . . . . . . . . . . . . . 32
D.4 change in Internet service provider . . . . . . . . . 32
D.5 renumbering grace periods . . . . . . . . . . . . . . 32
E Deployment Considerations . . . . . . . . . . . . . . . . . 33
F Route Object Authorization Pseudocode . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property Notice . . . . . . . . . . . . . . . . . 38
References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Security Considerations . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . 41
1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Background . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Implicit Policy Assumptions . . . . . . . . . . . . . . . . 5 4 Scope of Security Coverage . . . . . . . . . . . . . . . . 5 5 Organization of this Document . . . . . . . . . . . . . . 6 6 Goals and Requirements . . . . . . . . . . . . . . . . . . 6 7 Data Representation . . . . . . . . . . . . . . . . . . . . 10 8 Authentication Model . . . . . . . . . . . . . . . . . . . 10 9 Authorization Model . . . . . . . . . . . . . . . . . . . . 12 9.1 Maintainer Objects . . . . . . . . . . . . . . . . . . 12 9.2 as-block and aut-num objects . . . . . . . . . . . . . 13 9.3 inetnum objects . . . . . . . . . . . . . . . . . . . 13 9.4 route objects . . . . . . . . . . . . . . . . . . . . 14 9.5 reclaim and no-reclaim attributes . . . . . . . . . . 14 9.6 Other Objects . . . . . . . . . . . . . . . . . . . . 15 9.7 Objects with AS Hierarchical Names . . . . . . . . . . 16 9.8 Query Processing . . . . . . . . . . . . . . . . . . . 16 9.9 Adding to the Database . . . . . . . . . . . . . . . . 17 9.10 Modifying or Deleting Database Objects . . . . . . . . 19 10 Data Format Summaries . . . . . . . . . . . . . . . . . . 20 10.1 Changes to the RIPE/RPSL Schema . . . . . . . . . . . 20 Appendicies A Core and Non-Core Functionality . . . . . . . . . . . . . . 23 B Examples . . . . . . . . . . . . . . . . . . . . . . . . . 23 C Technical Discussion . . . . . . . . . . . . . . . . . . . 26 C.1 Relaxing requirements for ease of registry . . . . . 27 C.2 The address lending issue . . . . . . . . . . . . . . 28 C.3 Dealing with non-conformant or questionable older data . . . . . . . . . . . . . . . . . . . . . . . . . 29 D Common Operational Cases . . . . . . . . . . . . . . . . . 30 D.1 simple hierarchical address allocation and route allocation . . . . . . . . . . . . . . . . . . . . . . 31 D.2 aggregation and multihomed more specific routes . . . 32 D.3 provider independent addresses and multiple origin AS . . . . . . . . . . . . . . . . . . . . . . . . . . 32 D.4 change in Internet service provider . . . . . . . . . 32 D.5 renumbering grace periods . . . . . . . . . . . . . . 32 E Deployment Considerations . . . . . . . . . . . . . . . . . 33 F Route Object Authorization Pseudocode . . . . . . . . . . . 35 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 Intellectual Property Notice . . . . . . . . . . . . . . . . . 38 References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Security Considerations . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40 Full Copyright Statement . . . . . . . . . . . . . . . . . . 41
Villamizar, et al. Standards Track [Page 2] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 2] RFC 2725 Routing Policy System Security December 1999
1 Overview
1 Overview
The Internet Routing Registry (IRR) has evolved to meet a need for Internet-wide coordination. This need was described in RFC-1787, an informational RFC prepared on behalf of the IAB [14]. The following summary appears in Section 7 of RFC-1787.
The Internet Routing Registry (IRR) has evolved to meet a need for Internet-wide coordination. This need was described in RFC-1787, an informational RFC prepared on behalf of the IAB [14]. The following summary appears in Section 7 of RFC-1787.
While ensuring Internet-wide coordination may be more and more
difficult, as the Internet continues to grow, stability and
consistency of the Internet-wide routing could significantly
benefit if the information about routing requirements of various
organizations could be shared across organizational boundaries.
Such information could be used in a wide variety of situations
ranging from troubleshooting to detecting and eliminating
conflicting routing requirements. The scale of the Internet
implies that the information should be distributed. Work is
currently underway to establish depositories of this information
(Routing Registries), as well as to develop tools that analyze, as
well as utilize this information.
While ensuring Internet-wide coordination may be more and more difficult, as the Internet continues to grow, stability and consistency of the Internet-wide routing could significantly benefit if the information about routing requirements of various organizations could be shared across organizational boundaries. Such information could be used in a wide variety of situations ranging from troubleshooting to detecting and eliminating conflicting routing requirements. The scale of the Internet implies that the information should be distributed. Work is currently underway to establish depositories of this information (Routing Registries), as well as to develop tools that analyze, as well as utilize this information.
A routing registry must maintain some degree of integrity to be of any use. The degree of integrity required depends on the usage of the routing policy system.
A routing registry must maintain some degree of integrity to be of any use. The degree of integrity required depends on the usage of the routing policy system.
An initial intended usage of routing policy systems such as the RIPE database had been in an advisory capacity, documenting the intended routing policies for the purpose of debugging. In this role a very weak form of authentication was deemed sufficient.
An initial intended usage of routing policy systems such as the RIPE database had been in an advisory capacity, documenting the intended routing policies for the purpose of debugging. In this role a very weak form of authentication was deemed sufficient.
The IRR is increasingly used for purposes that have a stronger requirement for data integrity and security. This document addresses issues of data integrity and security that is consistent with the usage of the IRR and which avoids compromising data integrity and security even if the IRR is distributed among less trusted repositories.
The IRR is increasingly used for purposes that have a stronger requirement for data integrity and security. This document addresses issues of data integrity and security that is consistent with the usage of the IRR and which avoids compromising data integrity and security even if the IRR is distributed among less trusted repositories.
2 Background
2 Background
An early routing policy system used in the NSFNET, the policy routing database (PRDB), provided a means of determining who was authorized to announce specific prefixes to the NSFNET backbone. The need for a policy database was recognized as far back as 1989 [6, 4]. By 1991 the database was in place [5]. Authentication was accomplished by requiring confirmation and was a manually intensive process. This solved the problem for the NSFNET, but was oriented toward holding the routing policy of a single organization.
An early routing policy system used in the NSFNET, the policy routing database (PRDB), provided a means of determining who was authorized to announce specific prefixes to the NSFNET backbone. The need for a policy database was recognized as far back as 1989 [6, 4]. By 1991 the database was in place [5]. Authentication was accomplished by requiring confirmation and was a manually intensive process. This solved the problem for the NSFNET, but was oriented toward holding the routing policy of a single organization.
Villamizar, et al. Standards Track [Page 3] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 3] RFC 2725 Routing Policy System Security December 1999
The problem since has become more difficult. New requirements have emerged.
The problem since has become more difficult. New requirements have emerged.
1. There is a need to represent the routing policies of many
organizations.
1. There is a need to represent the routing policies of many organizations.
2. CIDR and overlapping prefixes and the increasing complexity of
routing policies and the needs of aggregation have introduced new
requirements.
2. CIDR and overlapping prefixes and the increasing complexity of routing policies and the needs of aggregation have introduced new requirements.
3. There is a need to assure integrity of the data and delegate
authority for the data representing specifically allocated
resources to multiple persons or organizations.
3. There is a need to assure integrity of the data and delegate authority for the data representing specifically allocated resources to multiple persons or organizations.
4. There is a need to assure integrity of the data and distribute the
storage of data subsets to multiple repositories.
4. There is a need to assure integrity of the data and distribute the storage of data subsets to multiple repositories.
The RIPE effort specificly focused on the first issue and needs of the European community. Its predecessor, the PRDB, addressed the needs of a single organization, the NSF. The RIPE database formats as described in [2] were the basis of the original IRR.
The RIPE effort specificly focused on the first issue and needs of the European community. Its predecessor, the PRDB, addressed the needs of a single organization, the NSF. The RIPE database formats as described in [2] were the basis of the original IRR.
Routing protocols themselves provide no assurance that the origination of a route is legitimate and can actually reach the stated destination. The nature of CIDR allows more specific prefixes to override less specific prefixes [9, 15, 8]. Even with signed route origination, there is no way to determine if a more specific prefix is legitimate and should override a less specific route announcement without a means of determining who is authorized to announce specific prefixes. Failing to do so places no assurance of integrity of global routing information and leaves an opportunity for a very effective form of denial of service attack.
Routing protocols themselves provide no assurance that the origination of a route is legitimate and can actually reach the stated destination. The nature of CIDR allows more specific prefixes to override less specific prefixes [9, 15, 8]. Even with signed route origination, there is no way to determine if a more specific prefix is legitimate and should override a less specific route announcement without a means of determining who is authorized to announce specific prefixes. Failing to do so places no assurance of integrity of global routing information and leaves an opportunity for a very effective form of denial of service attack.
The Routing Policy System Language (RPSL) [1, 13] was a fairly substantial evolutionary step in the data representation which was largely targeted at addressing the second group of needs. The PRDB accommodated CIDR in 1993 [12] and the RIPE database accommodated the entry of CIDR prefixes from inception, but RPSL provides many needed improvements including explicit support for aggregation.
The Routing Policy System Language (RPSL) [1, 13] was a fairly substantial evolutionary step in the data representation which was largely targeted at addressing the second group of needs. The PRDB accommodated CIDR in 1993 [12] and the RIPE database accommodated the entry of CIDR prefixes from inception, but RPSL provides many needed improvements including explicit support for aggregation.
This document addresses the third group of needs identified above.
This document addresses the third group of needs identified above.
While the current implementation supporting weak authentication doesn't guarantee integrity of the data, it does provide extensive mechanisms to make sure that all involved parties get notified when a change is made to the database, whether the change was malicious or intended. This provides inadequate protection against additions. Since the software is increasingly used to configure the major parts
While the current implementation supporting weak authentication doesn't guarantee integrity of the data, it does provide extensive mechanisms to make sure that all involved parties get notified when a change is made to the database, whether the change was malicious or intended. This provides inadequate protection against additions. Since the software is increasingly used to configure the major parts
Villamizar, et al. Standards Track [Page 4] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 4] RFC 2725 Routing Policy System Security December 1999
of the Internet infrastructure, it is not considered to be adequate anymore to know about and have the ability roll back unintended changes. Therefore, more active security mechanisms need to be developed to prevent such problems before they happen.
of the Internet infrastructure, it is not considered to be adequate anymore to know about and have the ability roll back unintended changes. Therefore, more active security mechanisms need to be developed to prevent such problems before they happen.
A separate document will be needed to address the fourth group of needs.
A separate document will be needed to address the fourth group of needs.
3 Implicit Policy Assumptions
3 Implicit Policy Assumptions
The authorization model encodes certain policies for allocation of address numbers, AS numbers, and for the announcement of routes. Implicit to the authorization model is a very limited number of policy assumptions.
The authorization model encodes certain policies for allocation of address numbers, AS numbers, and for the announcement of routes. Implicit to the authorization model is a very limited number of policy assumptions.
1. Address numbers are allocated hierarchically. The IANA delegates
portions of the address space to the regional registries
(currently ARIN, APNIC and RIPE), which in turn delegate address
space to their members, who can assign addresses to their
customers.
1. Address numbers are allocated hierarchically. The IANA delegates portions of the address space to the regional registries (currently ARIN, APNIC and RIPE), which in turn delegate address space to their members, who can assign addresses to their customers.
2. AS numbers are allocated either singly or in small blocks by
registries. Registries are allocated blocks of AS numbers,
thereby making the allocation hierarchical.
2. AS numbers are allocated either singly or in small blocks by registries. Registries are allocated blocks of AS numbers, thereby making the allocation hierarchical.
3. Routes should only be announced with the consent of the holder of
the origin AS number of the announcement and with the consent of
the holder of the address space.
3. Routes should only be announced with the consent of the holder of the origin AS number of the announcement and with the consent of the holder of the address space.
4. AS numbers and IP address registries may be different entities
from routing registries.
4. AS numbers and IP address registries may be different entities from routing registries.
For subsets of any of these three allocation spaces, network addresses, AS numbers, and routes, these restrictions may be loosened or disabled by specifying a very weak authorization method or an authentication method of "none". However, even when no authentication mechanism is used, all involved parties can be notified about the changes that occurred through use of the existing "notify" attribute.
For subsets of any of these three allocation spaces, network addresses, AS numbers, and routes, these restrictions may be loosened or disabled by specifying a very weak authorization method or an authentication method of "none". However, even when no authentication mechanism is used, all involved parties can be notified about the changes that occurred through use of the existing "notify" attribute.
4 Scope of Security Coverage
4 Scope of Security Coverage
This document is intended only to provide an authentication and authorization model to insure the integrity of the policy data in a registry. Only authetication and authorization of additions, deletions, and changes to the database are within the scope of this document. Authentication and authorization of database queries is
This document is intended only to provide an authentication and authorization model to insure the integrity of the policy data in a registry. Only authetication and authorization of additions, deletions, and changes to the database are within the scope of this document. Authentication and authorization of database queries is
Villamizar, et al. Standards Track [Page 5] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 5] RFC 2725 Routing Policy System Security December 1999
explicitly out of scope. Mutual authentication of queries, that is authenticating both the origin of the query and the repository from which query results are obtained, is also out of scope.
explicitly out of scope. Mutual authentication of queries, that is authenticating both the origin of the query and the repository from which query results are obtained, is also out of scope.
5 Organization of this Document
5 Organization of this Document
Familiarity with RIPE-181 [2] and RPSL [1] is assumed throughout this document. Goals are described in Section 6. Section 7 through Section 9 provide descriptions of the changes and discussion. Section 10 provides a concise summary of data formats and semantics. Appendix C through Appendix E provide additional technical discussion, examples, and deployment considerations.
Familiarity with RIPE-181 [2] and RPSL [1] is assumed throughout this document. Goals are described in Section 6. Section 7 through Section 9 provide descriptions of the changes and discussion. Section 10 provides a concise summary of data formats and semantics. Appendix C through Appendix E provide additional technical discussion, examples, and deployment considerations.
Goals and Requirements Section 6 provides a more detailed
description of the issues and identifies specific problems that
need to be solved, some of which require a degree of cooperation
in the Internet community.
Goals and Requirements Section 6 provides a more detailed description of the issues and identifies specific problems that need to be solved, some of which require a degree of cooperation in the Internet community.
Data Representation Section 7 provides some characteristics of
RPSL and formats for external representations of information.
Data Representation Section 7 provides some characteristics of RPSL and formats for external representations of information.
Authentication Model Section 8 describes current practice,
proposes additional authentication methods, and describes the
extension mechanism if additional methods are needed in the
future.
Authentication Model Section 8 describes current practice, proposes additional authentication methods, and describes the extension mechanism if additional methods are needed in the future.
Authorization Model Section 9 describes the means of determining
whether a transaction contains the authorization needed to add,
modify, or delete specific data objects, based on stated
authentication requirements in related data objects.
Authorization Model Section 9 describes the means of determining whether a transaction contains the authorization needed to add, modify, or delete specific data objects, based on stated authentication requirements in related data objects.
Data Format Summaries Section 10 provides a concise reference to
the data formats and steps in transaction processing.
Data Format Summaries Section 10 provides a concise reference to the data formats and steps in transaction processing.
Technical Discussion Section C contains some discussion of
technical tradeoffs.
Technical Discussion Section C contains some discussion of technical tradeoffs.
Common Operational Cases Section D provides some examples drawn
from past operational experience with the IRR.
Common Operational Cases Section D provides some examples drawn from past operational experience with the IRR.
Deployment Considerations Section E describes some deployment
issues and discusses possible means of resolution.
Deployment Considerations Section E describes some deployment issues and discusses possible means of resolution.
6 Goals and Requirements
6 Goals and Requirements
The Internet is an open network. This openness and the large scale of the Internet can present operational problems. Technical weaknesses that allow misconfiguration or errant operation in part of
The Internet is an open network. This openness and the large scale of the Internet can present operational problems. Technical weaknesses that allow misconfiguration or errant operation in part of
Villamizar, et al. Standards Track [Page 6] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 6] RFC 2725 Routing Policy System Security December 1999
the network to propagate globally or which provide potentials for simple denial of service attacks should be eliminated to the extent that it is practical. The integrity of routing information is critical in assuring that traffic goes where it is supposed to.
the network to propagate globally or which provide potentials for simple denial of service attacks should be eliminated to the extent that it is practical. The integrity of routing information is critical in assuring that traffic goes where it is supposed to.
An accidental misconfiguration can direct traffic toward routers that cannot reach a destination for which they are advertising reachability. This is commonly caused by misconfigured static routes though there are numerous other potential causes. Static routes are often used to provide constant apparent reachability to single homed destinations. Some of the largest ISPs literally have thousands of static routes in their networks. These are often entered manually by operators. Mistyping can divert traffic from a completely unrelated destination to a router with no actual reachability to the advertised destination. This can happen and does happen somewhat regularly. In addition, implementation bugs or severe misconfigurations that result in the loss of BGP AS path information or alteration of prefix length can result in the advertisement of large sets of routes. Though considerably more rare, on a few occasions where this has occurred the results were catastrophic.
An accidental misconfiguration can direct traffic toward routers that cannot reach a destination for which they are advertising reachability. This is commonly caused by misconfigured static routes though there are numerous other potential causes. Static routes are often used to provide constant apparent reachability to single homed destinations. Some of the largest ISPs literally have thousands of static routes in their networks. These are often entered manually by operators. Mistyping can divert traffic from a completely unrelated destination to a router with no actual reachability to the advertised destination. This can happen and does happen somewhat regularly. In addition, implementation bugs or severe misconfigurations that result in the loss of BGP AS path information or alteration of prefix length can result in the advertisement of large sets of routes. Though considerably more rare, on a few occasions where this has occurred the results were catastrophic.
Where there is the potential for an accidental misconfiguration in a remote part of the Internet affecting the global Internet there is also the potential for malice. For example, it has been demonstrated by accident that multiple hour outages at a major institution can be caused by a laptop and a dial account if proper precautions are not taken. The dial account need not be with the same provider used by the major institution.
Where there is the potential for an accidental misconfiguration in a remote part of the Internet affecting the global Internet there is also the potential for malice. For example, it has been demonstrated by accident that multiple hour outages at a major institution can be caused by a laptop and a dial account if proper precautions are not taken. The dial account need not be with the same provider used by the major institution.
The potential for error is increased by the CIDR preference for more specific routes [8]. If an institution advertises a single route of a given length and a distant router advertises a more specific route covering critical hosts, the more specific route, if accepted at all, is preferred regardless of administrative weighting or any routing protocol attributes.
The potential for error is increased by the CIDR preference for more specific routes [8]. If an institution advertises a single route of a given length and a distant router advertises a more specific route covering critical hosts, the more specific route, if accepted at all, is preferred regardless of administrative weighting or any routing protocol attributes.
There is a need to provide some form of checks on whether a route advertisement is valid. Today checks are typically made against the border AS advertising the route. This prevents accepting routes from the set of border AS that could not legitimately advertise the route. Theses checks rely on the use of information registered in the IRR to generate lists of prefixes that could be advertised by a specific border AS. Checks can also be made against the origin AS. If policy information were sufficiently populated, checks could be made against the entire AS path, but this is not yet feasible.
There is a need to provide some form of checks on whether a route advertisement is valid. Today checks are typically made against the border AS advertising the route. This prevents accepting routes from the set of border AS that could not legitimately advertise the route. Theses checks rely on the use of information registered in the IRR to generate lists of prefixes that could be advertised by a specific border AS. Checks can also be made against the origin AS. If policy information were sufficiently populated, checks could be made against the entire AS path, but this is not yet feasible.
Villamizar, et al. Standards Track [Page 7] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 7] RFC 2725 Routing Policy System Security December 1999
The use of a routing registry can also make it more difficult for prefixes to be used without authorization such as unallocated prefixes or prefixes allocated to another party.
The use of a routing registry can also make it more difficult for prefixes to be used without authorization such as unallocated prefixes or prefixes allocated to another party.
In summary, some of the problems being addressed are:
In summary, some of the problems being addressed are:
o Localizing the impact of accidental misconfiguration made by
Internet Providers to that provider's networks only.
o Localizing the impact of accidental misconfiguration made by Internet Providers to that provider's networks only.
o Eliminating the potential for an Internet provider's customer to
use malicious misconfiguration of routing as a denial of service
attack if the provider route filters their customers. Localizing
the denial of service to that Internet provider only if the
immediate Internet service provider does not route filter their
customers but other providers route filter the route exchange at
the interprovider peering.
o Eliminating the potential for an Internet provider's customer to use malicious misconfiguration of routing as a denial of service attack if the provider route filters their customers. Localizing the denial of service to that Internet provider only if the immediate Internet service provider does not route filter their customers but other providers route filter the route exchange at the interprovider peering.
o Eliminating the unauthorized use of address space.
o Eliminating the unauthorized use of address space.
If the data within a routing registry is critical, then the ability to change the data must be controlled. Centralized authorities can provide control but centralization can lead to scaling problems (and is politically distasteful).
If the data within a routing registry is critical, then the ability to change the data must be controlled. Centralized authorities can provide control but centralization can lead to scaling problems (and is politically distasteful).
Address allocation and name allocation is already delegated. Since delegation can be to outside registries it is at least somewhat distributed [11]. Autonomous System (AS) numbers are allocated by the same authorities. It makes sense to delegate the routing number space in a manner similar to the address allocation and AS number allocation. The need for this delegation of authority to numerous registries increases the difficulty of maintaining the integrity of the body of information as a whole.
Address allocation and name allocation is already delegated. Since delegation can be to outside registries it is at least somewhat distributed [11]. Autonomous System (AS) numbers are allocated by the same authorities. It makes sense to delegate the routing number space in a manner similar to the address allocation and AS number allocation. The need for this delegation of authority to numerous registries increases the difficulty of maintaining the integrity of the body of information as a whole.
As a first step, the database can be somewhat centrally administered with authority granted to many parties to change the information. This is the case with the current IRR. There are a very small number of well trusted repositories and a very large number of parties authorized to make changes. Control must be exercised over who can make changes and what changes they can make. The distinction of who vs what separates authentication from authorization.
As a first step, the database can be somewhat centrally administered with authority granted to many parties to change the information. This is the case with the current IRR. There are a very small number of well trusted repositories and a very large number of parties authorized to make changes. Control must be exercised over who can make changes and what changes they can make. The distinction of who vs what separates authentication from authorization.
o Authentication is the means to determine who is attempting to make
a change.
o Authentication is the means to determine who is attempting to make a change.
o Authorization is the determination of whether a transaction
passing a specific authentication check is allowed to perform a
given operation.
o Authorization is the determination of whether a transaction passing a specific authentication check is allowed to perform a given operation.
Villamizar, et al. Standards Track [Page 8] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 8] RFC 2725 Routing Policy System Security December 1999
Different portions of the database will require different methods of authentication. Some applications will require authentication based on strong encryption. In other cases software supporting strong encryption may not be necessary or may not be legally available. For this reason multiple authentication methods must be supported, selected on a per object basis through the specification of authentication methods in the maintainer object "auth" attribute. The authentication methods may range from very weak data integrity checks to cryptographicly strong signatures. The authorization model must sure that the use of weak integrity checks in parts of the database does not compromise the overall integrity of the database.
Different portions of the database will require different methods of authentication. Some applications will require authentication based on strong encryption. In other cases software supporting strong encryption may not be necessary or may not be legally available. For this reason multiple authentication methods must be supported, selected on a per object basis through the specification of authentication methods in the maintainer object "auth" attribute. The authentication methods may range from very weak data integrity checks to cryptographicly strong signatures. The authorization model must sure that the use of weak integrity checks in parts of the database does not compromise the overall integrity of the database.
Additional requirements are placed on the authorization model if the database is widely distributed with delegations made to parties that may not be trustworthy or whose security practices may be lacking. This problem must be addressed in the authorization model in order to enable later evolution to a more distributed routing registry.
Additional requirements are placed on the authorization model if the database is widely distributed with delegations made to parties that may not be trustworthy or whose security practices may be lacking. This problem must be addressed in the authorization model in order to enable later evolution to a more distributed routing registry.
Autonomous system numbers can be delegated in blocks and subdelegated as needed and then individual AS numbers assigned. Address allocation is a simple numeric hierarchy. Route allocation is somewhat more complicated. The key attributes in a route object (key with regard to making it unique) contain both an address prefix and an AS number, known as the origin AS. The addition of a route object must be validated against the authorization criteria for both the AS and the address prefix. Route objects may exist for the same prefix with multiple origin AS values due to a common multihoming practice that does not require a unique origin AS. There is often no correlation between the origin AS of a prefix and the origin AS of overlapping more specific prefixes.
Autonomous system numbers can be delegated in blocks and subdelegated as needed and then individual AS numbers assigned. Address allocation is a simple numeric hierarchy. Route allocation is somewhat more complicated. The key attributes in a route object (key with regard to making it unique) contain both an address prefix and an AS number, known as the origin AS. The addition of a route object must be validated against the authorization criteria for both the AS and the address prefix. Route objects may exist for the same prefix with multiple origin AS values due to a common multihoming practice that does not require a unique origin AS. There is often no correlation between the origin AS of a prefix and the origin AS of overlapping more specific prefixes.
There are numerous operational cases that must be accommodated. Some of the more common are listed below. These are explored in greater detail in Appendix D with discussion of technical tradeoffs in Appendix C.
There are numerous operational cases that must be accommodated. Some of the more common are listed below. These are explored in greater detail in Appendix D with discussion of technical tradeoffs in Appendix C.
o simple hierarchical address allocation and route allocation
o simple hierarchical address allocation and route allocation
o aggregation and multihomed more specific routes
o aggregation and multihomed more specific routes
o provider independent addresses and multiple origin AS
o provider independent addresses and multiple origin AS
o changing Internet service providers
o changing Internet service providers
o renumbering grace periods
o renumbering grace periods
Villamizar, et al. Standards Track [Page 9] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 9] RFC 2725 Routing Policy System Security December 1999
The authorization model must accommodate a variety of policies regarding the allocation of address space and cannot mandate the use of any one model. There is no standardization of address allocation policies though guidelines do exist [11, 16]. Whether authorization allows the recovery of address space must be selectable on a per object basis and may differ in parts of the database. This issue is discussed further in Appendix C.
The authorization model must accommodate a variety of policies regarding the allocation of address space and cannot mandate the use of any one model. There is no standardization of address allocation policies though guidelines do exist [11, 16]. Whether authorization allows the recovery of address space must be selectable on a per object basis and may differ in parts of the database. This issue is discussed further in Appendix C.
7 Data Representation
7 Data Representation
RPSL provides a complete description of the contents of a routing repository [1]. Many RPSL data objects remain unchanged from the RIPE specifications and RPSL references the RIPE-181 specification as recorded in RFC-1786 [2]. RPSL provides external data representation. Data may be stored differently internal to a routing registry.
RPSL provides a complete description of the contents of a routing repository [1]. Many RPSL data objects remain unchanged from the RIPE specifications and RPSL references the RIPE-181 specification as recorded in RFC-1786 [2]. RPSL provides external data representation. Data may be stored differently internal to a routing registry.
Some database object types or database attributes must be added to RPSL to record the delegation of authority and to improve the authentication and authorization mechanisms. These additions are very few and are described in Section 8 and Section 9.
Some database object types or database attributes must be added to RPSL to record the delegation of authority and to improve the authentication and authorization mechanisms. These additions are very few and are described in Section 8 and Section 9.
Some form of encapsulation must be used to exchange data. The defacto encapsulation has been the one which the RIPE tools accept, a plain text file or plain text in the body of an RFC-822 formatted mail message with information needed for authentication derived from the mail headers or the body of the message. Merit has slightly modified this using the PGP signed portion of a plain text file or PGP signed portion of the body of a mail message. These very simple forms of encapsulation are suitable for the initial submission of a database transaction.
Some form of encapsulation must be used to exchange data. The defacto encapsulation has been the one which the RIPE tools accept, a plain text file or plain text in the body of an RFC-822 formatted mail message with information needed for authentication derived from the mail headers or the body of the message. Merit has slightly modified this using the PGP signed portion of a plain text file or PGP signed portion of the body of a mail message. These very simple forms of encapsulation are suitable for the initial submission of a database transaction.
The encapsulation of registry transaction submissions, registry queries and registry responses and exchanges between registries is outside the scope of this document. The encapsulation of registry transaction submissions and exchanges between registries is outside the scope of this document.
The encapsulation of registry transaction submissions, registry queries and registry responses and exchanges between registries is outside the scope of this document. The encapsulation of registry transaction submissions and exchanges between registries is outside the scope of this document.
8 Authentication Model
8 Authentication Model
The maintainer objects serve as a container to hold authentication filters. A reference to a maintainer within another object defines authorization to perform operations on the object or on a set of related objects. The maintainer is typically referenced by name in mnt-by attributes of objects. Further details on the use of maintainers are provided in Section 9.1.
The maintainer objects serve as a container to hold authentication filters. A reference to a maintainer within another object defines authorization to perform operations on the object or on a set of related objects. The maintainer is typically referenced by name in mnt-by attributes of objects. Further details on the use of maintainers are provided in Section 9.1.
Villamizar, et al. Standards Track [Page 10] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 10] RFC 2725 Routing Policy System Security December 1999
The maintainer contains one or more "auth" attributes. Each "auth" attribute begins with a keyword identifying the authentication method followed by the authentication information needed to enforce that method. The PGPKEY method is slightly syntactically different in that the method PGPKEY is a substring.
The maintainer contains one or more "auth" attributes. Each "auth" attribute begins with a keyword identifying the authentication method followed by the authentication information needed to enforce that method. The PGPKEY method is slightly syntactically different in that the method PGPKEY is a substring.
Authentication methods currently supported include the following. Note that pgp-from is being replaced by the pgpkey (see Section 10 and [18]).
Authentication methods currently supported include the following. Note that pgp-from is being replaced by the pgpkey (see Section 10 and [18]).
mail-from This is a very weak authentication check and is
discouraged. The authentication information is a regular
expression over ASCII characters. The maintainer is authenticated
if the from or reply-to fields in RFC-822 mail headers are matched
by this regular expression. Since mail forgery is quite easy,
this is a very weak form of authentication.
mail-from This is a very weak authentication check and is discouraged. The authentication information is a regular expression over ASCII characters. The maintainer is authenticated if the from or reply-to fields in RFC-822 mail headers are matched by this regular expression. Since mail forgery is quite easy, this is a very weak form of authentication.
crypt-pw This is another weak form of authentication. The
authentication information is a fixed encrypted password in UNIX
crypt format. The maintainer is authenticated if the transaction
contains the clear text password of the maintainer. Since the
password is in clear text in transactions, it can be captured by
snooping. Since the encrypted form of the password is exposed, it
is subject to password guessing attacks.
crypt-pw This is another weak form of authentication. The authentication information is a fixed encrypted password in UNIX crypt format. The maintainer is authenticated if the transaction contains the clear text password of the maintainer. Since the password is in clear text in transactions, it can be captured by snooping. Since the encrypted form of the password is exposed, it is subject to password guessing attacks.
pgp-from This format is being replaced by the "pgpkey" so that the
public key certificate will be available to remote repositories.
This is Merit's PGP extension. The authentication information is
a signature identity pointing to an external public key ring. The
maintainer is authenticated if the transaction (currently PGP
signed portion of a mail message) is signed by the corresponding
private key.
pgp-from This format is being replaced by the "pgpkey" so that the public key certificate will be available to remote repositories. This is Merit's PGP extension. The authentication information is a signature identity pointing to an external public key ring. The maintainer is authenticated if the transaction (currently PGP signed portion of a mail message) is signed by the corresponding private key.
pgpkey This keyword takes the form "PGPKEY-hhhhhhhh", where
"hhhhhhhh" is the hex representation of the four byte id of the
PGP public key used for authentication. The public key
certificate is stored in a separate object as described in [18].
pgpkey This keyword takes the form "PGPKEY-hhhhhhhh", where "hhhhhhhh" is the hex representation of the four byte id of the PGP public key used for authentication. The public key certificate is stored in a separate object as described in [18].
Repositories may elect to disallow the addition of "auth" attributes specifying weaker forms of authentication and/or disallow their use in local transaction submissions. Repositories are encouraged to disallow the addition of "auth" attributes with the deprecated "pgp- from" method.
Repositories may elect to disallow the addition of "auth" attributes specifying weaker forms of authentication and/or disallow their use in local transaction submissions. Repositories are encouraged to disallow the addition of "auth" attributes with the deprecated "pgp- from" method.
Any digital signature technique can in principle be used for authentication. Transactions should be signed using multiple digital signature techniques to allow repositories or mirrors that only use a
Any digital signature technique can in principle be used for authentication. Transactions should be signed using multiple digital signature techniques to allow repositories or mirrors that only use a
Villamizar, et al. Standards Track [Page 11] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 11] RFC 2725 Routing Policy System Security December 1999
subset of the techniques to verify at least one of the signatures. The selection of digital signature techniques is not within the scope of this document.
subset of the techniques to verify at least one of the signatures. The selection of digital signature techniques is not within the scope of this document.
9 Authorization Model
9 Authorization Model
The authorization model must accommodate the requirements outlined in Section 6. A key feature of the authorization model is the recognition that authorization for the addition of certain types of data objects must be derived from related data objects.
The authorization model must accommodate the requirements outlined in Section 6. A key feature of the authorization model is the recognition that authorization for the addition of certain types of data objects must be derived from related data objects.
With multiple repositories, objects not found in RPSL are needed to control AS delegations and new attributes are needed in existing objects to control subdelegation. The definition of RPSL objects used to implement a distrubuted routing registry system is not within the scope of this document.
With multiple repositories, objects not found in RPSL are needed to control AS delegations and new attributes are needed in existing objects to control subdelegation. The definition of RPSL objects used to implement a distrubuted routing registry system is not within the scope of this document.
9.1 Maintainer Objects
9.1 Maintainer Objects
The maintainer objects serve as a container to hold authentication filters. The authentication methods are described in Section 8. The maintainer can be referenced by name in other objects, most notably in the mnt-by attributes of those objects.
The maintainer objects serve as a container to hold authentication filters. The authentication methods are described in Section 8. The maintainer can be referenced by name in other objects, most notably in the mnt-by attributes of those objects.
Maintainers themselves contain mnt-by attributes. In some cases the mnt-by in a maintainer will reference the maintainer itself. In this case, authorization to modify the maintainer is provided to a (usually very limited) set of identities. A good practice is to create a maintainer containing a long list of identities authorized to make specific types of changes but have the maintainer's mnt-by attribute reference a far more restrictive maintainer more tightly controlling changes to the maintainer object itself.
Maintainers themselves contain mnt-by attributes. In some cases the mnt-by in a maintainer will reference the maintainer itself. In this case, authorization to modify the maintainer is provided to a (usually very limited) set of identities. A good practice is to create a maintainer containing a long list of identities authorized to make specific types of changes but have the maintainer's mnt-by attribute reference a far more restrictive maintainer more tightly controlling changes to the maintainer object itself.
The mnt-by attribute is mandatory in all objects. Some data already exists without mnt-by attributes. A missing mnt-by attribute is interpreted as the absence of any control over changes. This is highly inadvisable and most repositories will no longer allow this.
The mnt-by attribute is mandatory in all objects. Some data already exists without mnt-by attributes. A missing mnt-by attribute is interpreted as the absence of any control over changes. This is highly inadvisable and most repositories will no longer allow this.
An additional maintainer reference can occur through a new attribute, "mnt-routes", and is used in aut-num, inetnum and route objects. The "mnt-routes" attribute is an extension to RPSL and is described in detail in Section 10.
An additional maintainer reference can occur through a new attribute, "mnt-routes", and is used in aut-num, inetnum and route objects. The "mnt-routes" attribute is an extension to RPSL and is described in detail in Section 10.
A mnt-routes attribute in an aut-num object allows addition of route objects with that AS number as the origin to the maintainers listed. A mnt-routes attribute in an inetnum object allows addition of route objects with exact matching or more specific prefixes. A mnt-routes attribute in a route object allows addition of route objects with
A mnt-routes attribute in an aut-num object allows addition of route objects with that AS number as the origin to the maintainers listed. A mnt-routes attribute in an inetnum object allows addition of route objects with exact matching or more specific prefixes. A mnt-routes attribute in a route object allows addition of route objects with
Villamizar, et al. Standards Track [Page 12] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 12] RFC 2725 Routing Policy System Security December 1999
exact matching or more specific prefixes. A mnt-routes attribute does not allow changes to the aut-num, inetnum, or route object where it appears. A mnt-routes may optionally be constrained to only apply to a subset of more specific routes.
exact matching or more specific prefixes. A mnt-routes attribute does not allow changes to the aut-num, inetnum, or route object where it appears. A mnt-routes may optionally be constrained to only apply to a subset of more specific routes.
Where "mnt-routes" or "mnt-lower" are applicable, any maintainer referenced in the "mnt-by" still apply. The set of applicable maintainers for whatever check is being made is the union of the "mnt-routes" or "mnt-lower" and the "mnt-by". For example, when authorizing a route object software would look at "mnt-routes", if it does not exist, look at "mnt-lower", if that does not exist look at "mnt-by".
Where "mnt-routes" or "mnt-lower" are applicable, any maintainer referenced in the "mnt-by" still apply. The set of applicable maintainers for whatever check is being made is the union of the "mnt-routes" or "mnt-lower" and the "mnt-by". For example, when authorizing a route object software would look at "mnt-routes", if it does not exist, look at "mnt-lower", if that does not exist look at "mnt-by".
9.2 as-block and aut-num objects
9.2 as-block and aut-num objects
An "as-block" object is needed to delegate a range of AS numbers to a given repository. This is needed for authorization and it is needed to avoid having to make an exhaustive search of all repositories to find a specific AS. This search would not be an issue now but would be if a more distributed routing repository is used. Distributed registry issues are not within the scope of this document.
An "as-block" object is needed to delegate a range of AS numbers to a given repository. This is needed for authorization and it is needed to avoid having to make an exhaustive search of all repositories to find a specific AS. This search would not be an issue now but would be if a more distributed routing repository is used. Distributed registry issues are not within the scope of this document.
The "as-block" object also makes it possible to separate AS number allocation from registration of AS routing policy.
The "as-block" object also makes it possible to separate AS number allocation from registration of AS routing policy.
as-block: AS1321 - AS1335
as-block: AS1321 - AS1335
The "aut-num" describes the routing policy for an AS and is critical for router configuration of that AS and for analysis performed by another AS. For the purpose of this document it is sufficient to consider the aut-num solely as a place holder identifying the existence of an AS and providing a means to associate authorization with that AS when adding "route" objects.
The "aut-num" describes the routing policy for an AS and is critical for router configuration of that AS and for analysis performed by another AS. For the purpose of this document it is sufficient to consider the aut-num solely as a place holder identifying the existence of an AS and providing a means to associate authorization with that AS when adding "route" objects.
The "as-block" object is proposed here solely as a means of recording the delegation of blocks of AS numbers to alternate registries and in doing so providing a means to direct queries and a means to support hierarchical authorization across multiple repositories.
The "as-block" object is proposed here solely as a means of recording the delegation of blocks of AS numbers to alternate registries and in doing so providing a means to direct queries and a means to support hierarchical authorization across multiple repositories.
9.3 inetnum objects
9.3 inetnum objects
The "inetnum" exists to support address allocation. For external number registries, such as those using "[r]whoisd[++]" the "inet-num" can serve as a secondary record that is added when an address allocation is made in the authoritative database. Such records could be added by a address registry such as ARIN as a courtesy to the corresponding routing registry.
The "inetnum" exists to support address allocation. For external number registries, such as those using "[r]whoisd[++]" the "inet-num" can serve as a secondary record that is added when an address allocation is made in the authoritative database. Such records could be added by a address registry such as ARIN as a courtesy to the corresponding routing registry.
Villamizar, et al. Standards Track [Page 13] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 13] RFC 2725 Routing Policy System Security December 1999
inetnum: 193.0.0.0 - 193.0.0.255
source: IANA
inetnum: 193.0.0.0 - 193.0.0.255 source: IANA
9.4 route objects
9.4 route objects
Currently there are a quite few route objects in more than one registry. Quite a few are registered with an origin AS for which they have never been announced. There is a legitimate reason to be in more than one origin AS.
Currently there are a quite few route objects in more than one registry. Quite a few are registered with an origin AS for which they have never been announced. There is a legitimate reason to be in more than one origin AS.
The "route" object is used to record routes which may appear in the global routing table. Explicit support for aggregation is provided. Route objects exist both for the configuration of routing information filters used to isolate incidents of erroneous route announcements (Section 6) and to support network problem diagnosis.
The "route" object is used to record routes which may appear in the global routing table. Explicit support for aggregation is provided. Route objects exist both for the configuration of routing information filters used to isolate incidents of erroneous route announcements (Section 6) and to support network problem diagnosis.
9.5 reclaim and no-reclaim attributes
9.5 reclaim and no-reclaim attributes
A reclaim attribute is needed in as-block, inetnum and route objects. The reclaim attribute allows a control to be retained over more specific AS, IP address or route space by allowing modify and delete privileges regardless of the mnt-by in the object itself.
A reclaim attribute is needed in as-block, inetnum and route objects. The reclaim attribute allows a control to be retained over more specific AS, IP address or route space by allowing modify and delete privileges regardless of the mnt-by in the object itself.
The reclaim attribute provides the means to enforce address lending. It allows cleanup in cases where entities cease to exist or as a last presort means to correct errors such as parties locking themselves out of access to their own objects. To specify all more specific objects the reclaim attribute value should be "ALL". To allow finer control a set of prefixes can be specified.
The reclaim attribute provides the means to enforce address lending. It allows cleanup in cases where entities cease to exist or as a last presort means to correct errors such as parties locking themselves out of access to their own objects. To specify all more specific objects the reclaim attribute value should be "ALL". To allow finer control a set of prefixes can be specified.
A no-reclaim attribute can be used to provide explicit exceptions. A reclaim attribute can only be added to an existing object if the addition of the reclaim attribute does not remove autonomy of existing more specific objects that are covered by the new reclaim attribute.
A no-reclaim attribute can be used to provide explicit exceptions. A reclaim attribute can only be added to an existing object if the addition of the reclaim attribute does not remove autonomy of existing more specific objects that are covered by the new reclaim attribute.
1. A reclaim attribute can be added to an existing object if there
are no existing exact matches or more specific objects overlapped
by the new reclaim attribute, or
1. A reclaim attribute can be added to an existing object if there are no existing exact matches or more specific objects overlapped by the new reclaim attribute, or
2. if the submitter is listed in the maintainer pointed to by the
mnt-by of the objects which are overlapped, or
2. if the submitter is listed in the maintainer pointed to by the mnt-by of the objects which are overlapped, or
3. if any overlapped object is listed in a no-reclaim attribute in
the object where the reclaim is being added.
3. if any overlapped object is listed in a no-reclaim attribute in the object where the reclaim is being added.
Villamizar, et al. Standards Track [Page 14] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 14] RFC 2725 Routing Policy System Security December 1999
Similarly, a submitter may delete a no-reclaim attribute from an object only when that submitter is the only maintainer listed in the mnt-by attributes of any overlapped objects. If the submitter is not listed in any of the maintainers pointed to by the mnt-by attributes for one or more overlapped object, then the submitter is not permitted to delete the no-reclaim attribute.
Similarly, a submitter may delete a no-reclaim attribute from an object only when that submitter is the only maintainer listed in the mnt-by attributes of any overlapped objects. If the submitter is not listed in any of the maintainers pointed to by the mnt-by attributes for one or more overlapped object, then the submitter is not permitted to delete the no-reclaim attribute.
If neither a reclaim or no-reclaim attribute is present, then more specific objects of a given object cannot be modified by the maintainer of the less specified object unless the maintainer is also listed as a maintainer in the more specific object. However, the addition of a new route or inetnum object must pass authentication of the largest less specific prefix as part of the authentication check described in Section 9.9.
If neither a reclaim or no-reclaim attribute is present, then more specific objects of a given object cannot be modified by the maintainer of the less specified object unless the maintainer is also listed as a maintainer in the more specific object. However, the addition of a new route or inetnum object must pass authentication of the largest less specific prefix as part of the authentication check described in Section 9.9.
See Section 10 for a full description of the reclaim and no-reclaim attributes.
See Section 10 for a full description of the reclaim and no-reclaim attributes.
9.6 Other Objects
9.6 Other Objects
Many of the RPSL ancillary objects have no natural hierarchy the way AS numbers, Internet addresses and routes do have a numeric hierarchy. Some examples are "maintainers", "people" and "role" objects. For these objects, lack of any hierarchy leads to two problems.
Many of the RPSL ancillary objects have no natural hierarchy the way AS numbers, Internet addresses and routes do have a numeric hierarchy. Some examples are "maintainers", "people" and "role" objects. For these objects, lack of any hierarchy leads to two problems.
1. There is no hierarchy that can be exploited to direct queries to
alternate registries. At some point the query strategy of
searching all known registries becomes impractical.
1. There is no hierarchy that can be exploited to direct queries to alternate registries. At some point the query strategy of searching all known registries becomes impractical.
2. There is no hierarchy on which authorizations of additions can be
based.
2. There is no hierarchy on which authorizations of additions can be based.
The first problem can be addressed by considering the name space for each of the ancillary objects to be unique only within the local database and to use explicit references to an external repository where needed. To specify an external repository reference, the object key is preceded by the name of the repository and the delimiter "::". For example a NIC handle may take the form "RIPE::CO19". Currently there is a desire to keep NIC handles unique so the naming convention of appending a dash and the repository name is used. Prepending the repository name provides the unique name space since an object in the RIPE database referencing "CO19" would be interpreted as "RIPE::CO19" by default, but it would still be possible to query or reference "IANA::CO19". There is no possibility of accidentally forgetting to adhere to the conventions when making an addition and the existing objects are accommodated, including cases where name conflicts have already occurred.
The first problem can be addressed by considering the name space for each of the ancillary objects to be unique only within the local database and to use explicit references to an external repository where needed. To specify an external repository reference, the object key is preceded by the name of the repository and the delimiter "::". For example a NIC handle may take the form "RIPE::CO19". Currently there is a desire to keep NIC handles unique so the naming convention of appending a dash and the repository name is used. Prepending the repository name provides the unique name space since an object in the RIPE database referencing "CO19" would be interpreted as "RIPE::CO19" by default, but it would still be possible to query or reference "IANA::CO19". There is no possibility of accidentally forgetting to adhere to the conventions when making an addition and the existing objects are accommodated, including cases where name conflicts have already occurred.
Villamizar, et al. Standards Track [Page 15] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 15] RFC 2725 Routing Policy System Security December 1999
The second problem can be partially addressed by using a referral system for the addition of maintainers and requiring that any other object be submitted by a registered maintainer or by IANA. The referral system would allow any existing maintainer to add another maintainer. This can be used in parallel with the addition of other object types to support the maintenance of those objects. For example, when adding a subdomain to the "domain" hierarchy (in the RIPE repository where domains are also handled), even when adding a new domain to a relatively flat domain such as "com", there is already a maintainer for the existing domain. The existing maintainer can add the maintainer that will be needed for the new domain in addition to adding the new domain and giving the new maintainer the right to modify it.
The second problem can be partially addressed by using a referral system for the addition of maintainers and requiring that any other object be submitted by a registered maintainer or by IANA. The referral system would allow any existing maintainer to add another maintainer. This can be used in parallel with the addition of other object types to support the maintenance of those objects. For example, when adding a subdomain to the "domain" hierarchy (in the RIPE repository where domains are also handled), even when adding a new domain to a relatively flat domain such as "com", there is already a maintainer for the existing domain. The existing maintainer can add the maintainer that will be needed for the new domain in addition to adding the new domain and giving the new maintainer the right to modify it.
An organization gaining a presence on the Internet for the first time would be given a maintainer. This maintainer may list a small number of very trusted employees that are authorized to modify the maintainer itself. The organization itself can then add another maintainer listing a larger set of employees but listing the more restrictive maintainer in the mnt-by attributes of the maintainers themselves. The organization can then add people and role objects as needed and any other objects as needed and as authorization permits.
An organization gaining a presence on the Internet for the first time would be given a maintainer. This maintainer may list a small number of very trusted employees that are authorized to modify the maintainer itself. The organization itself can then add another maintainer listing a larger set of employees but listing the more restrictive maintainer in the mnt-by attributes of the maintainers themselves. The organization can then add people and role objects as needed and any other objects as needed and as authorization permits.
9.7 Objects with AS Hierarchical Names
9.7 Objects with AS Hierarchical Names
Many RPSL objects do not have a natural hierarchy of their own but allow hierarchical names. Some examples are the object types "as- set" and "route-set". An as-set may have a name corresponding to no naming hierarchy such as "AS-Foo" or it may have a hierarchical name of the form "AS1:AS-Bar".
Many RPSL objects do not have a natural hierarchy of their own but allow hierarchical names. Some examples are the object types "as- set" and "route-set". An as-set may have a name corresponding to no naming hierarchy such as "AS-Foo" or it may have a hierarchical name of the form "AS1:AS-Bar".
When a hierarchical name is not used, authorization for objects such as "as-set" and "route-set" correspond to the rules for objects with no hierarchy described in Section 9.6.
When a hierarchical name is not used, authorization for objects such as "as-set" and "route-set" correspond to the rules for objects with no hierarchy described in Section 9.6.
If hierarchical names are used, then the addition of an object must be authorized by the aut-num whose key is named by everything to the left of the rightmost colon in the name of the object being added. Authorization is determined by first using the mnt-lower maintainer reference, or if absent, using the mnt-by reference.
If hierarchical names are used, then the addition of an object must be authorized by the aut-num whose key is named by everything to the left of the rightmost colon in the name of the object being added. Authorization is determined by first using the mnt-lower maintainer reference, or if absent, using the mnt-by reference.
9.8 Query Processing
9.8 Query Processing
A query may have to span multiple repositories. All queries should be directed toward a local repository which may mirror the root repository and others. Currently each IRR repository mirrors all other repositories. In this way, the query may be answered by the local repository but draw data from others.
A query may have to span multiple repositories. All queries should be directed toward a local repository which may mirror the root repository and others. Currently each IRR repository mirrors all other repositories. In this way, the query may be answered by the local repository but draw data from others.
Villamizar, et al. Standards Track [Page 16] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 16] RFC 2725 Routing Policy System Security December 1999
The mechanism below when applied to multiple repositories assumes the existence of an attribute for traversal of the repositories. The definition of this attribute is considered a distributed registry issue and is out of scope of this document.
The mechanism below when applied to multiple repositories assumes the existence of an attribute for traversal of the repositories. The definition of this attribute is considered a distributed registry issue and is out of scope of this document.
For object types that have a natural hierarchy, such as aut-num, inet-num, and route, the search begins at the root database and follows the hierarchy. For objects types that have no natural hierarchy, such as maintainer, person, and role objects, the search is confined to a default database unless a database is specified. The default database is the same database as an object from which a reference is made if the query is launched through the need to follow a reference. Otherwise the default is generally the local database or a default set by the repository. The default can be specified in the query itself as described in Section 9.7.
For object types that have a natural hierarchy, such as aut-num, inet-num, and route, the search begins at the root database and follows the hierarchy. For objects types that have no natural hierarchy, such as maintainer, person, and role objects, the search is confined to a default database unless a database is specified. The default database is the same database as an object from which a reference is made if the query is launched through the need to follow a reference. Otherwise the default is generally the local database or a default set by the repository. The default can be specified in the query itself as described in Section 9.7.
In the absense of attributes to traverse multiple registries a search of all repositories is needed. With such attributes the search would proceed as follows. In searching for an AS, the delegation attribute in AS blocks can be consulted, moving the search to data from other repositories. Eventually the AS is either found or the search fails. The search for an inetnum is similar. Less specific inetnums may refer the search to other databases. Eventually the most specific inetnum is found and its status (assigned or not assigned) can be determined. The definition of attributes for traversal of repositories is considered a distrbiuted registry issue and is not within the scope of this document.
In the absense of attributes to traverse multiple registries a search of all repositories is needed. With such attributes the search would proceed as follows. In searching for an AS, the delegation attribute in AS blocks can be consulted, moving the search to data from other repositories. Eventually the AS is either found or the search fails. The search for an inetnum is similar. Less specific inetnums may refer the search to other databases. Eventually the most specific inetnum is found and its status (assigned or not assigned) can be determined. The definition of attributes for traversal of repositories is considered a distrbiuted registry issue and is not within the scope of this document.
The search for a route in the presence of attributes for the traversal of multiple registries is similar except the search may branch to more than one repository. The most specific route in one repository may be more specific than the most specific in another. In looking for a route object it makes sense to return the most specific route that is not more specific than the query requests regardless of which repository that route is in rather than return one route from each repository that contains a less specific overlap.
The search for a route in the presence of attributes for the traversal of multiple registries is similar except the search may branch to more than one repository. The most specific route in one repository may be more specific than the most specific in another. In looking for a route object it makes sense to return the most specific route that is not more specific than the query requests regardless of which repository that route is in rather than return one route from each repository that contains a less specific overlap.
9.9 Adding to the Database
9.9 Adding to the Database
The mechanism below when applied to multiple repositories assumes the existence of an attribute for traversal of the repositories. The definition of this attribute is considered a distributed registry issue and is out of scope of this document.
The mechanism below when applied to multiple repositories assumes the existence of an attribute for traversal of the repositories. The definition of this attribute is considered a distributed registry issue and is out of scope of this document.
The root repository must be initially populated at some epoch with a few entries. An initial maintainer is needed to add more maintainers. The referral-by attribute can be set to refer to itself in this special case (Section 10 describes the referral-by). When
The root repository must be initially populated at some epoch with a few entries. An initial maintainer is needed to add more maintainers. The referral-by attribute can be set to refer to itself in this special case (Section 10 describes the referral-by). When
Villamizar, et al. Standards Track [Page 17] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 17] RFC 2725 Routing Policy System Security December 1999
adding an inetnum or a route object an existing exact match or a less specific overlap must exist. A route object may be added based on an exact match or a less specific inetnum. The root repository must be initially populated with the allocation of an inetnum covering the prefix 0/0, indicating that some address allocation authority exists. Similarly an initial as-block is needed covering the full AS number range.
adding an inetnum or a route object an existing exact match or a less specific overlap must exist. A route object may be added based on an exact match or a less specific inetnum. The root repository must be initially populated with the allocation of an inetnum covering the prefix 0/0, indicating that some address allocation authority exists. Similarly an initial as-block is needed covering the full AS number range.
When adding an object with no natural hierarchy, the search for an existing object follows the procedure outlined in Section 9.8.
When adding an object with no natural hierarchy, the search for an existing object follows the procedure outlined in Section 9.8.
When adding an aut-num (an AS), the same procedure used in a query is used to determine the appropriate repository for the addition and to determine which maintainer applies. The sequence of AS-block objects and repository delegations is followed. If the aut-num does not exist, then the submission must match the authentication specified in the maintainer for the most specific AS-block in order to be added.
When adding an aut-num (an AS), the same procedure used in a query is used to determine the appropriate repository for the addition and to determine which maintainer applies. The sequence of AS-block objects and repository delegations is followed. If the aut-num does not exist, then the submission must match the authentication specified in the maintainer for the most specific AS-block in order to be added.
The procedure for adding an inetnum is similar. The sequence of inet-num blocks is followed until the most specific is found. The submission must match the authentication specified in the maintainer for the most specific inetnum overlapping the addition.
The procedure for adding an inetnum is similar. The sequence of inet-num blocks is followed until the most specific is found. The submission must match the authentication specified in the maintainer for the most specific inetnum overlapping the addition.
Adding a route object is somewhat more complicated. 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.
Adding a route object is somewhat more complicated. 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.
An addition is submitted with an AS number and prefix as its key. If the object already exists, then the submission is treated as a modify (see Section 9.10). If the aut-num does not exist on a route add, then the addition is rejected (see Section C for further discussion of tradeoffs). If the aut-num exists then the submission is checked against the applicable maintainer. A search is then done for the prefix first looking for an exact match. If the search for an exact match fails, a search is made for the longest prefix match that is less specific than the prefix specified. If this search succeeds it will return one or more route objects. The submission must match an applicable maintainer in at least one of these route objects for the addition to succeed. If the search for a route object 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 match the maintainer.
An addition is submitted with an AS number and prefix as its key. If the object already exists, then the submission is treated as a modify (see Section 9.10). If the aut-num does not exist on a route add, then the addition is rejected (see Section C for further discussion of tradeoffs). If the aut-num exists then the submission is checked against the applicable maintainer. A search is then done for the prefix first looking for an exact match. If the search for an exact match fails, a search is made for the longest prefix match that is less specific than the prefix specified. If this search succeeds it will return one or more route objects. The submission must match an applicable maintainer in at least one of these route objects for the addition to succeed. If the search for a route object 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 match the maintainer.
Villamizar, et al. Standards Track [Page 18] RFC 2725 Routing Policy System Security December 1999
Villamizar, et al. Standards Track [Page 18] RFC 2725 Routing Policy System Security December 1999
Having found the AS and either a route object or inetnum, the authorization is taken from these two objects. The applicable maintainer object is any referenced by the mnt-routes attributes. If one or more mnt-routes attributes are present in an object, the mnt- by attributes are not considered. In the absence of a mnt-routes attribute in a given object, the mnt-by attributes are used for that object. The authentication must match one of the authorizations in each of the two objects.
Having found the AS and either a route object or inetnum, the authorization is taken from these two objects. The applicable maintainer object is any referenced by the mnt-routes attributes. If one or more mnt-routes attributes are present in an object, the mnt- by attributes are not considered. In the absence of a mnt-routes attribute in a given object, the mnt-by attributes are used for that object. The authentication must match one of the authorizations in each of the two objects.
If the addition of a route object or inetnum contains a reclaim attribute, then any more specific objects of the same type must be examined. The reclaim attribute can only be added if there are no more specific overlaps or if the authentication on the addition is present in the authorization of a less specific object that already has a reclaim attribute covering the prefix range, or if the authentication on the addition is authorized for the modification of all existing more specific prefixes covered by the addition.
If the addition of a route object or inetnum contains a reclaim attribute, then any more specific objects of the same type must be examined. The reclaim attribute can only be added if there are no more specific overlaps or if the authentication on the addition is present in the authorization of a less specific object that already has a reclaim attribute covering the prefix range, or if the authentication on the addition is authorized for the modification of all existing more specific prefixes covered by the addition.
9.10 Modifying or Deleting Database Objects
9.10 Modifying or Deleting Database Objects
When modifying or deleting any existing object a search for the object is performed as described in Section 9.8. If the submission matches an applicable maintainer for the object, then the operation can proceed. An applicable maintainer for a modification is any maintainer referenced by the mnt-by attribute in the object. For route and inet-num objects an applicable maintainer may be listed in a less specific object with a reclaim attribute.
When modifying or deleting any existing object a search for the object is performed as described in Section 9.8. If the submission matches an applicable maintainer for the object, then the operation can proceed. An applicable maintainer for a modification is any maintainer referenced by the mnt-by attribute in the object. For route and inet-num objects an applicable maintainer may be listed in a less specific object with a reclaim attribute.
If the submission is for a route object, a search is done for all less specific route objects and inetnums. If the submission is for an inetnum, a search is done for all less specific inetnums. If the submission fails the authorization in the object itself but matches the reclaim attribute in any of the less specific objects, then the operation can proceed. Section C contains discussion of the rationale behind the use of the reclaim attribute.
If the submission is for a route object, a search is done for all less specific route objects and inetnums. If the submission is for an inetnum, a search is done for all less specific inetnums. If the submission fails the authorization in the object itself but matches the reclaim attribute in any of the less specific objects, then the operation can proceed. Section C contains discussion of the rationale behind the use of the reclaim attribute.
A modification to an inetnum object that adds a reclaim attribute or removes a no-reclaim attribute must be checked against all existing inetnums that are more specific. The same check of the reclaim attribute that is made during addition must be made when a reclaim attribute is added by a modification (see Section 9.9).
aが属性を取り戻すと言い足すか、または取り外されるinetnumオブジェクトにaは属性を取り戻しません。変更、すべての、より特定の既存のinetnumsに対してチェックしなければなりません。 同じくらいがチェックする、追加の間、人工であることが、作られていて、aがいつ属性を取り戻すかが変更で加えられるという(セクション9.9を見てください)ことであるに違いないということである属性を取り戻してください。
A deletion is considered a special case of the modify operation. The deleted object may remain in the database with a "deleted" attribute in which case the mnt-by can still be consulted to remove the "deleted" attribute.
削除が特別なケースであると考えられる、操作を変更してください。 削除されたオブジェクトはデータベースに「削除された」属性で残るかもしれません、その場合、「削除された」属性を取り除くためにまだmntしているのに相談できます。
Villamizar, et al. Standards Track [Page 19] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[19ページ]。
10 Data Format Summaries
10 データの形式概要
RIPE-181 [2] and RPSL [1] data is represented externally as ASCII text. Objects consist of a set of attributes. Attributes are name value pairs. A single attribute is represented as a single line with the name followed by a colon followed by whitespace characters (space, tab, or line continuation) and followed by the value. Within a value all whitespace is equivalent to a single space. Line continuation is supported by a backslash at the end of a line or the following line beginning with whitespace. When transferred, externally attributes are generally broken into shorter lines using line continuation though this is not a requirement. An object is externally represented as a series of attributes. Objects are separated by blank lines.
RIPE-181[2]とRPSL[1]データはASCIIテキストとして外部的に表されます。 オブジェクトは1セットの属性から成ります。 属性は名前値の組です。 ただ一つの属性を空白キャラクタ(スペース、タブ、または系列継続)でコロンが名前のあとに続いている単線が従ったので表されて、値はあとに続いています。 値の中では、すべての空白がシングルスペースに同等です。 線継続は線の端か空白で始まる以下の系列でバックスラッシュで後押しされています。 移すと、外部的に、一般に、これが要件ではありませんが、系列継続を使用することで、より短い系列を属性に細かく分けます。 オブジェクトは一連の属性として外部的に表されます。 オブジェクトは空白行によって分離されます。
There are about 80 attribute types in the current RIPE schema and about 15 object types. Some of the attributes are mandatory in certain objects. Some attributes may appear multiple times. One or more attributes may form a key. Some attributes or sets of attributes may be required to be unique across all repositories. Some of the attributes may reference a key field in an object type and may be required to be a valid reference. Some attributes may be used in inverse lookups.
現在のRIPE図式とおよそ15人のオブジェクト・タイプにはおよそ80人の属性タイプがいます。 属性のいくつかが、あるオブジェクトで義務的です。 いくつかの属性が複数の回現れるかもしれません。 1つ以上の属性がキーを形成するかもしれません。 数属性かセットの属性が、すべての倉庫の向こう側に特有になるのに必要であるかもしれません。 属性のいくつかが、オブジェクト・タイプでキーフィールドに参照をつけて、有効な参照になるのに必要であるかもしれません。 いくつかの属性が逆さのルックアップに使用されるかもしれません。
A review of the entire RIPE or RPSL schema would be too lengthy to include here. Only the differences in the schema are described.
全体のRIPEかRPSL図式のレビューはここに含むことができないくらい長いでしょう。 図式の違いだけが説明されます。
10.1 Changes to the RIPE/RPSL Schema
10.1 熟している/RPSL図式への変化
One new object type and several attributes are added to the RIPE/RPSL schema. There are significant changes to the rules which determine if the addition of an object is authorized.
1人の新しいオブジェクト・タイプといくつかの属性がRIPE/RPSL図式に追加されます。 オブジェクトの追加が認可されているかどうか決定する規則への著しい変化があります。
The new object type is listed below. The first attribute listed is the key attribute and also serves as the name of the object type.
新しいオブジェクト・タイプは以下に記載されています。 記載された最初の属性は、主要な属性であり、また、オブジェクト・タイプの名前として機能します。
as-block key mandatory single unique descr optional multiple remarks optional multiple admin-c mandatory multiple tech-c mandatory multiple notify optional multiple mnt-by mandatory multiple changed mandatory multiple source mandatory single
ブロックとしての主要な義務的なただ一つのユニークなdescr任意の倍数は任意の複数の科学技術のc義務的な倍数に通知するのが義務的な複数のアドミンc任意のソース義務的な近く倍数が義務的な倍数を変えたのが義務的な複数のmntシングルを述べさせます。
Villamizar, et al. Standards Track [Page 20] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[20ページ]。
In the above object type only the key attribute "as-block" is new:
キーだけが結果と考える上のオブジェクト・タイプで、「ブロック」は新しいです:
as-block This attribute provides the AS number range for an "as-
block" object. The format is two AS numbers including the sub-
string "AS" separated by a "-" delimiter and optional whitespace
before and after the delimiter.
ブロックとしてのThis属性がAS数の範囲を提供する、「-、」 オブジェクトを妨げてください。 形式はデリミタの前後に「-」デリミタと任意の空白によって切り離されたサブストリング“AS"を含む2つのAS番号です。
In order to support stronger authentication, the following keywords are added to the "auth" attribute:
より強い認証をサポートするために、以下のキーワードは"auth"属性に加えられます:
pgp-from The remainder of the attribute gives the string identifying
a PGP identity whose public key is held in an external keyring.
The use of this method is deprecated in favor of the "pgpkey"
method.
pgp、-、属性の残りは公開鍵が外部のkeyringで保持されるPGPのアイデンティティを特定するストリングを与えます。 このメソッドの使用は"pgpkey"メソッドを支持して推奨しないです。
pgpkey See [18].
pgpkey See[18]。
In order to disable authentication and give permission to anyone, the authentication method "none" is added. It has no arguments.
認証を無効にして、だれにも許可するために、認証方法「なにも」は加えられます。 それには、議論が全くありません。
An additional change is the "auth" attribute is allowed to exist in a "person" or "role" object. The "auth" method "role" or "person" can be used to refer to a role or person object and take the "auth" fields from those objects. Care must be taken in implementations to detect circular references and terminate expansion or the references already visited.
付加的な変化は"auth"属性が「人」か「役割」オブジェクトに存在できるということです。 役割か人のオブジェクトについて言及して、それらのオブジェクトから"auth"グラウンドに出るのに"auth"メソッド「役割」か「人」を使用できます。 循環参照を検出して、既に訪問された拡張か参照を終えるために実装で注意しなければなりません。
A few attributes are added to the schema. These are:
いくつかの属性が図式に追加されます。 これらは以下の通りです。
mnt-routes The mnt-routes attribute may appear in an aut-num, inet-
num, or route object. This attribute references a maintainer
object which is used in determining authorization for the addition
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-ルートが結果と考えるmnt-ルートはaut-num、inet- num、またはルートオブジェクトに現れるかもしれません。 この属性はルートオブジェクトの追加のために承認を決定する際に使用される維持装置オブジェクトに参照をつけます。 維持装置の参照の、あとに巻き毛の内部が強化する接頭語範囲(RPSLで定義されるように)の任意のリストか「少しも」というキーワードについて行くかもしれません。 デフォルトであり、どんな追加セットの品目もいつ指定されないかは、「少しも」かすべて多くの詳細です。 mnt-ルート属性は、任意であって、複数です。 セクション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
より多くの下のmnt下側の属性がinetnumで見えるかもしれないmnt、ブロックとしてのルートまたはaut-numが反対します。 この属性は維持装置オブジェクトに参照をつけます。 inetnumかルートオブジェクトで使用されると、効果は、「mnt-ルート」と同じですが、それが含まれているオブジェクトの接頭語より特定の接頭語だけに適用されます。 中、塊状物として、より多くの下のmntが塊状物として、より特定の追加を許容するか、またはaut-numは反対します。 aut-numで
Villamizar, et al. Standards Track [Page 21] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[21ページ]。
object the mnt-lower attribute specifies a maintainer that can be
used to add objects with hierarchical names as described in
Section 9.7.
mnt下側が結果と考えるオブジェクトはセクション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.
属性を取り戻してください。開墾、aut-num、inet-num、またはルートが、ブロックとして中に現れるかもしれないのを反対します。 aを含むオブジェクトの維持装置による変更されているかもしれないか、または削除された階層構造における以下の同じタイプのどんなオブジェクトも属性を取り戻します。 属性の値は、RPSLで定義されるようにセットか範囲の構文がそうである同じタイプのオブジェクトのセットか範囲です。 付加の制限のためのセクション9.5が属性を取り戻すのを見てください。
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.
開墾でない、使用される属性を取り戻さないでください、属性を取り戻してください。 属性はいずれも否定します。どんな開墾、もそれが重ね合わせる属性を取り戻さないでください。 いいえを削除するときの制限のためのセクション9.5が属性を取り戻すのを見てください。
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.
近くThisが結果と考える紹介が維持装置オブジェクトで必要です。 それは維持装置の追加の後に決して変更されないかもしれません。 この属性はこの維持装置を作成した維持装置について言及します。 1つ以上の署名がオブジェクトを作成しながらトランザクションに現れたなら、複数であるかもしれません。
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.
近く紹介で記載された維持装置によって提出されたトランザクションは、auth-オーバーライドAn auth-オーバーライド属性を加えるか、削除するか、または変えることができます。 その維持装置が先の60日間不活発である場合にだけ、auth-オーバーライドを維持装置に加えることができます。 auth-オーバーライド属性自体は属性が維持装置を変更するために承認が既にない場合現在の期日から少なくとも60日間でなければならない効果に入る日付だけを含んでいます。 auth-オーバーライドにおける日付に達した後に、維持装置によって近く紹介で特定されたものは維持装置を変更する承認を持っています。 この属性は、維持装置の所有者が無反応になるなら掃除する手段として存在していて、その維持装置が変化の上に現れる自動通知に対応してauth-オーバーライドを取り除かない場合にだけ、実施できます。
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.
既存の「近くmnt」属性は「維持装置」オブジェクト・タイプに参照をつけます。 「近くmnt」属性は現在、すべてのオブジェクト・タイプで義務的です。 新しい維持装置はどんな既存の維持装置によっても加えられるかもしれません。 「近く紹介」属性を現在、「維持装置」オブジェクトでどの維持装置に関する記録が追加をした生活費に義務的であり、決して変えることができません。 それらがほかの場所で「近く紹介」属性によって参照をつけられる限り、維持装置を削除できません。
Villamizar, et al. Standards Track [Page 22] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[22ページ]。
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.
「auth-オーバーライド」属性は倉庫データが何らかの方法で再配付される環境における回復を容易にする便利です。
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.
「近くreferal」属性は「コア」の特徴です。 個々の登録は、自己に参照をつけた維持装置、「近くreferal」がitslefを示すものを作成することによって、sutonomyを急送するかもしれません。 他の登録がケースバイケースでaを決めることができる、基礎、そのようなエントリーが有効であると考えるのであるかどうか 「近くreferal」は登録で登録のコントロールの下における特定の維持装置を示すことができるだけであるかもしれません。 このさらなる制限は純粋に登録にローカルであることの問題です。
B Examples
Bの例
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.
以下の例はオブジェクトの使用を例証するのに必要でないいくつかの必要な属性と本書では説明された属性を省きます。 なくなるのは、アドミンc、科学技術のcの、そして、変えられたソースです。 また、なくなるのは、使用が良い習慣ですが、厳密に必要でないmnt-nfyなどの属性です。
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.
とにかく何にでも維持装置をするのが必要です。 aが維持装置を選抜するいつかの時代に、ある倉庫とそのmaintianerが近くreferalにそれ自体に指させる居住されたコネがあります。 すべての他のもの近くreferal参照をその維持装置にたどって戻すことができます。 また、時代に、ブロックとしてのAS0- AS65535とinetnum0.0.0.0-255.255.255.255を割り当てます。 また、他のancilliaryオブジェクトが独力で進むのが必要であるかもしれません。
mntner: ROOT-MAINTAINER
auth: pgpkey-12345678
mntner: ROOT-MAINTAINER auth: pgpkey-12345678
mnt-by: ROOT-MAINTAINER
referal-by: ROOT-MAINTAINER
近くmnt: 近くROOT-MAINTAINER referal: 根維持装置
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
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[23ページ]。
mntner: WIZARDS
descr: High level Technical Folks
auth: pgpkey-23456789
auth: pgpkey-3456789a
mnt-by: WIZARDS
referal-by: ROOT-MAINTAINER
mntner: ウィザーズdescr: 高レベルTechnical Folks auth: pgpkey-23456789 auth: 近くpgpkey-3456789a mnt: ウィザーズはreferalされます: 根維持装置
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
mntner: MORTALS descr: 日々に操作authを維持してください: pgpkey-456789ab auth: pgpkey-56789abc auth: 近くpgpkey-6789abcd mnt: ウィザーズはreferalされます: ウィザード
Note that the WIZARDS can change their own maintainer object and the MORTALS maintainer object but MORTALS cannot.
ウィザースがそれら自身の維持装置オブジェクトとMORTALS維持装置オブジェクトを変えることができますが、MORTALSが変えることができないことに注意してください。
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
ブロックとして: 近くAS65500-AS65510 mnt: SOME-REGISTRY mnt下側: ウィザード
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は加えられます。 輸入と輸出がaut-numに通常必要ですが、ここに示されないことに注意してください。
aut-num: AS65501
mnt-by: WIZARDS
mnt-lower: MORTALS
aut-num: 近くAS65501 mnt: より多くの下のウィザーズmnt: 死すべき者
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.
ウィザースの上のaut-numでは、維持装置はaut-num自身を変更できます。 MORTALS維持装置は、また、彼らにそれほど特定でないルートかinetnumのIP数のスペースへの承認があるなら発生源としてこのASを使用することでルートオブジェクトを加えることができます。
Villamizar, et al. Standards Track [Page 24] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[24ページ]。
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配分を必要とします。 この例では、完全に異なった組織にinetnumを割り当てます。 再び、通常、inetnumで必要である属性はomitedされます。
inetnum: 192.168.144.0-192.168.151.255
mnt-by: SOME-REGISTRY
mnt-lower: ISP
reclaim: ALL
inetnum: 192.168.144.0-192.168 .255がmntする.151: SOME-REGISTRY mnt下側: ISPは以下を開墾します。 すべて
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.
維持装置ISPはこのアドレス空間で、より特定のinetnumsかルートを加えることができます。 登録がアドレス空間を取り戻す彼らの能力を宣言したことに注意してください。
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).
ISPであるなら、彼らの配分にもかかわらず、何らかの細分割当てが抵抗したすべてを開墾することが願われていて、私たちはそれらが配分の上半分だけを取り戻す以下のように何かを得るかもしれません(ことによると未使用のままで残っているなら)。
inetnum: 192.168.144.0-192.168.147.255
mnt-by: ISP
mnt-lower: EBG-COM
reclaim: 192.168.146/23+
inetnum: 192.168.144.0-192.168 .255がmntする.147: より多くの下のISP mnt: EBG-COMは以下を開墾します。 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.
私たちが、維持装置EBG-COMと維持装置MORTALSがルートオブジェクトを加えたがっていると思うなら、それをする1つの方法は双方が署名することです。 EBG-COMがある理由で集めることができない、ただ一つのトップ平らなルート(最近、許しがたい)を割り当てたか、または何れの当事者が追加を作るもう片方の許可を与えることができた服従のときに連判アプローチを避けるために、a好みがある理由でありました。 mnt-ルートをaut-numに加えることができましたか、またはより多くの下のmntをinetnumに加えることができました。
aut-num: AS65501
mnt-by: WIZARDS
mnt-lower: MORTALS
mnt-routes: EBG-COM {192.168.144/23}
aut-num: 近くAS65501 mnt: より多くの下のウィザーズmnt: MORTALS mnt-ルート: 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.
aut-numへのこの変化で、維持装置EBG-COMは発生源AS65501にもかかわらず、限られたアドレスの範囲だけがあるルートを加えることができました。
route: 192.168.144/24
origin: AS65501
descr: These boneheads don't aggregate
mnt-by: EBG-COM
mnt-by: FICTION::MORTALS
以下を発送してください。 192.168.144/24発生源: AS65501 descr: これらのまぬけは近くmntに集めません: 近くEBG-COM mnt: フィクション:、:死すべき者
Note that while the maintainer EBG-COM added the object they allowed the maintainer MORTALS the ability to modify it.
維持装置EBG-COMがオブジェクトを加えましたが、彼らがそれを変更する能力を維持装置MORTALSに許したことに注意してください。
Villamizar, et al. Standards Track [Page 25] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[25ページ]。
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.
オブジェクトが別の倉庫で終わるなら、まだ単一の維持装置を使用できるでしょうに。 記法FICTIONを超えた例で:、:MORTALSが、ルートオブジェクトが異なった倉庫にあるのを示して、むしろ、維持装置をコピーするよりMORTALSオブジェクトが住んでいる倉庫を参照します。
In the example below, a pair of route-sets are added and hierarchical names are used.
以下の例では、1組のルートセットは加えられます、そして、階層的な名前は使用されています。
route-set: AS65501:Customers
mnt-by: WIZARDS
mnt-lower: MORTALS
ルートセット: AS65501: 顧客はmntします: より多くの下のウィザーズmnt: 死すべき者
route-set: AS65501:Customers:EBG-COM
mnt-by: MORTALS
mnt-lower: EBG-COM
ルートセット: AS65501: 顧客: 近くEBG-COM mnt: MORTALS mnt下側: 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.
192.168.144/24オブジェクトで上では、EBG-COM維持装置だけが記載されていると仮定してください。 EBG-COMが、破産するようになって、もうアドレス空間を必要としないで、応じるのを止めるなら、このオブジェクトを削除するのは難しいかもしれません。 EBG-COM近く紹介属性で記載された維持装置に連絡できました。 彼らはauth-オーバーライド属性をEBG-COMオブジェクトに加えるかもしれません。 その後、それらは、EBG-COMと共に近くmntでEBG-COMオブジェクトを変更して、次に、どんなオブジェクトも変更できました。
mntner: EBG-COM
mnt-by: EBG-COM
auth-override: 19990401
mntner: 近くEBG-COM mnt: EBG-COM auth-オーバーライド: 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
C技術面の協議
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.
1. 情報を登録するのに容認の側で間違えて、承認コントロールを弱めますか、バリアを建設する可能性を危険にさらしますか?
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.
2. enforcibleアドレスの貸すことをサポートするか、より小さく提供するか、そして、それらが使用している接頭語の登録の究極のコントロールのエンドユーザ。
Villamizar, et al. Standards Track [Page 26] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[26ページ]。
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.
3. より古いオブジェクトでそんなにのどちらかべきことは、最小の承認、認証、および責任に関する、より新しい要件に従わないか、または疑わしい正当性のものです。
C.1 Relaxing requirements for ease of registry
登録の容易さのためのC.1の寛げる要件
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.
aut-numが存在しているという要件が弛緩するなら、だれでも割り当てられなかったAS番号を利用するか、またはaut-numに入られていない割り当てられたAS番号を利用するのが、可能です。 aut-numのエントリーに要件を置くと、インターネット・アドレス配分権威の協力は推定されます(ルーティング登録から別々であるなら)。 アドレス配分権威はパーティーから骸骨のaut-numsに居住するという配分がされた分野要求に望んでいるに違いありません。 これらのaut-numは維持装置の指示するものを含まなければなりません。 したがって、アドレス配分権威への要求は既存の維持装置の指示するものを含まなければなりません。
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.
また、ルートオブジェクトを加える能力はそれほど特定でないルートオブジェクトかinetnumsの存在に結ばれます。また、インターネット・アドレス配分権威(ルーティング登録から別々であるなら)は、パーティーへのinetnum記録が既にアドレス空間を割り当てたと言い足すという要求をさばいても構わないと思っているに違いありません。
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.
また、インターネット・アドレス配分権威は新しい配分のためにinetnumsとaut-numsを加えるべきです。 そうするために、維持装置は存在しなければなりません。 パーティーがインターネットに接続するなら、彼らは彼らが接続するインターネット接続サービス業者への要求をするのによる維持装置にそうさせることができます。 一度、彼らはアドレス空間を求める要求かAS番号をすることができる維持装置を持っています。 それが適切であると登録パーティーによって考えられるなら、維持装置は、暗号的に強い承認メソッドのための公開鍵を含むことができるか、「地下室キー」を含んでいるか、または許可検査に「郵送するかもしれません」。 その上、アドレス配分権威は、AS番号かアドレス空間を求める要求が維持装置で承認評価基準に合っていることを確かめるべきです。
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
現在の、登録自体だけが維持装置を加えるかもしれません。 これは登録と、特に公開鍵について確かめる際に問題になります。 既存の維持装置が維持装置を加えるのを許容することによって、この要件はリラックスします。 残念ながら、責任道は既存の維持装置のために存在していません。 次に、要件は既存の維持装置が残ることができるように、リラックスするべきですが、「近く紹介」属性を持っている既存の維持装置だけが維持装置を加えることができます。 「近く紹介」を変更できません。 この要件は、わずかに「近く紹介」を維持装置に加えることができるようにリラックスできます。
Villamizar, et al. Standards Track [Page 27] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[27ページ]。
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.
パーティーが彼らが初期の追加にいると主張する人であることを確かめるのは、現在AS番号とアドレス登録を攻撃する問題の1つです。 既存の維持装置が維持装置を加えるのを許容することによって、この問題は減少します。 これで、実際に維持装置をより手に入れやすくてしたがって、登録するのは、より簡単であるかもしれません。 数の権威は、ASかアドレス空間が実際に要求をしているパーティーによって必要とされることをまだ確かめなければなりません。
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.
強くASオブジェクトとinetnumsについて言及するルートオブジェクトの追加の間にされた許可検査はインターネット・アドレス配分当局の協力に依存します。 AS番号かアドレス空間がaut-nums、またはinetnumsですが、割り当てて、必須がブロックとして登録する数当局。 数の部分集合だけであるなら、当局は協力して、次に、その数の権威からアドレスを得るinetnumかブロックとしての登録が割り当てるスペースをカバーしながら作成できる、本質的には必要なヌル配分(例えば、パスワードがオブジェクトかその維持装置の所見で与えられている「地下室-pw」認証)か人のどちらかがルーティング登録に登録するのに苦労するでしょう。 承認モデルはオプションをサポートします、数当局が協力して、問題が実際には決して表面化しないなら、望ましいでしょうにが。
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
アドレスの貸すのが発行するC.2
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.
貸す契約がenforcibleであるべきであるかどうかに関する問題はだれが結局アドレス空間の配分にコントロールを及ぼすことができるべきであるかに関する問題です。 ルーティング登録は、できるだけ第三者の間の論争に関して中立のままであるために賢明でしょう。 そして、「開墾」、「どんな開墾、も」 それほど特定でないinetnumかルートオブジェクトの所有者が登録でコントロールを細分割当てに及ぼすことができるかどうかに関してどちらの結果も決定に許容するために、設計されていません。 ルーティング登録自体は、自分たちでコントロールを保有するかどうか決めなければなりません、そして、そうだとすれば、非常に明確に、登録にどんな条件のもとで介入するかを述べるべきです。 登録は法廷で論争を解決して、裁判所命令を発行した後にだけ彼らがそのような論争を干渉すると述べる極端に行くことさえできました。
Villamizar, et al. Standards Track [Page 28] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[28ページ]。
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.
登録が登録で配分をするときそれほど特定でないオブジェクトに「開墾」属性を保って、a強硬な政策声明をそれにするべきである、下の非常に明確に定義された特別番組が事情であるつもりであった(まさしくその最小限で裁判所命令を含んでいる)なら特権を取り戻してください。 または、配分がさらに細分されるなら配分を細分するパーティーと細分割当てを受け入れるパーティーが、それほど特定でない配分の所有者がa「開墾」を保つことができるかどうか決めなければならない、「いいえ加えられた移すのが、より特定の所有者へのコントロールであったなら」 必須を再生利用してください。 登録はその決定にかかわりません。 第三者の異なった組は法的な契約の形に登録の外に表されて、激しい論争の場合、結局法廷によって決議されている「開墾」に関する異なった決定と使用のどんな契約上の制限にも達するかもしれません。
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.
「開墾保有」権利で、登録は裁判所命令を守る能力を保有します。 これが本当に、登録がほかの場所で行われた取引の承認を再確認する分散登録環境における問題になるだけであり、aであるなら別の登録が正常な承認をくつがえすのによる裁判所命令で登録コンテンツを変えるのをとどまる試みを処理しないかもしれない、開墾、提示しません。
C.3 Dealing with non-conformant or questionable older data
非conformantの、または、疑わしいより古いデータに対処するC.3
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.
多くのルート物が、どれが維持装置が全くないか、そして、物がどのinetnumとASに関して存在しないように存在しているか。 或るものは近くmntよりむしろ現在時代遅れにされた保護者属性を含んでいます。
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.
無条件に維持装置を持っていないか、または認可階層構造に従わない古いデータを掃除するのは実用的ではありません。 新しい要件に従うために新しい追加を必要としなければなりません(さもなければ、要件は無意味です)。 変更が新しい要件に従うのを必要とすることによって、新しい要件を段階的に導入することができます。
Villamizar, et al. Standards Track [Page 29] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[29ページ]。
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).
既存のデータの有効な問い合わせ先を必要とするのは無理ではありません。 多くのデータが未使用であるように見えます、発表が全く何カ月も何年間も見られていないルート物などのように。 続く維持装置責任道が全くなければ、試みは、そして、維持装置近く紹介チェーンの上に1つがあれば1つがあれば記載が物、維持装置で連絡する接触に作られていて、数の登録か起源AS問い合わせ先を使用するべきです。 経験は、今までのところ、ルート憂鬱に対して登録された接頭語を比較することによって特定されたかなりの大多数の削除が明確に確認されるか(削除を許して)、または無効の問い合わせ先(多くの場合 nsfnet-admin@merit.edu へのIRR問い合わせ先ポイント)による応答が全くないのを示します。
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.
変更する許容するのによる登録、(削除、)、維持装置責任道から外されるどんな物、クリーンアップを可能にすることができます(メールヘッダ鍛造物には、同じ効果が多くの場合あるかもしれませんが、登録自体がクリーンアップを作ったという事実を記録するのは望ましいです)。 同様に、すべての接触が維持装置のための無反応になったなら、メカニズムが、将来、近く紹介における維持装置が参照された維持装置で維持装置特権を無視するのを許容するのに必要であるかもしれません。 近く紹介維持装置は添加の時間から60日以内に"auth"として使用可能になる「auth-オーバーライド」属性を加えることができます。 維持装置、自分たち、変化について通知されて、有効になる前に「auth-オーバーライド」属性を取り除いて、それが加えられた理由に関して問い合わせて、存在したどんな問題も修正できました。 必要であるなら、これをすぐに、支持するか、または後で加えることができます。
D Common Operational Cases
D一般的な操作上のケース
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:
原則として、アドレス配分とルート配分は物理的なトポロジーに対応する階層構造で階層的であるべきです。 実際には、多数の理由でこれはしばしばそうであるというわけではありません。 第一の理由はトポロジーによる厳密に、構造化された木とトポロジーが変化できるということでないということです。 以上は特定です:
Villamizar, et al. Standards Track [Page 30] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[30ページ]。
1. The Internet topology is not strictly tree structured.
1. インターネットトポロジーは厳密に構造化されていた状態で木に登らないことです。
o At the top level the network more closely resembles a
moderately dense mesh.
o ネットワークはトップレベルでは、より密接に適度に濃いメッシュに類似しています。
o Near the bottom level many attachments to the Internet are
multi-homed to more than one Internet provider.
o 下部レベルにおいて、インターネットへの多くの付属がそうである、マルチ、家へ帰り、1つ以上のプロバイダに。
2. The Internet topology can and does change.
2. インターネットトポロジーは、変化して、変化できます。
o Many attachments switch providers to obtain better service or
terms.
o 多くの付属が、より良いサービスか用語を得るためにプロバイダーを切り換えます。
o Service providers may modify adjacencies to obtain better
transit service or terms.
o サービスプロバイダーは、より良いトランジットサービスか用語を得るように隣接番組を変更するかもしれません。
o Service providers may disappear completely scattering
attachments or they may merge.
o サービスプロバイダーが付属を完全に点在させながら、見えなくなるかもしれませんか、またはそれらは合併するかもしれません。
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.
番号を付け替えることは厳しい数値階層構造[16]を維持する実用的な手段として見なされます。 また、IPv4ネットワークに番号を付け替えさせるのが難しい場合があると[16、3、17]認められます。 私たちは最初に、階層構造がまだ存在している簡単なケースを調べます。 そして、私たちは初期のトポロジーがそうでない木が構造化した操作上のケースかトポロジーが変化するケースを調べます。
D.1 simple hierarchical address allocation and route allocation
D.1の簡単な階層的なアドレス配分とルート配分
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).
これは最も簡単なそうです。 inetnumsの広い範囲は、登録を記述するために割り当てられます。 または、これらの登録がダイレクト使用のために順番により小さい範囲を割り当てる、位相的である、トポロジーに従った配分が情報が必要としたルーティングの量を減少させることができる(より良いルート集合を促進してください)大きい実体。
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.
トポロジーが追加AS[10]の必要性を書き取るとき、AS物を割り当てます。 認可がASとアドレス所有者によって与えられているものはルート物を登録できます。 これはASの維持装置とinetnumが同じでない問題です。 彼らが異なるか、プロバイダーがそれらのASのためにルート物を加える許可を与えることができるか、またはパーティーがアドレス空間を割り当てたところに、それらのアドレス空間のためにルート物を加えるプロバイダー許可を与えることができるか、または双方は取引にサインできます。 維持装置属性に加えることによって、許可を提供します。
Villamizar, et al. Standards Track [Page 31] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[31ページ]。
D.2 aggregation and multihomed more specific routes
D.2集合と「マルチ-家へ帰」っているより特定のルート
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.
プロバイダーであるなら、集合は潜在的に問題であるか1セットのプロバイダーが、ブロックとして明らかにそれらのプロバイダーに決して割り当てませんでしたが、むしろアドレス登録の配分のままで残っているアドレス空間に集めるのを計画しています。 これらの大きい集合に珍しいと予想されますが、比較的容易に対処できます。 また、隣接しているアドレス配分を引き起こすために管理されて、一般に、タイプが形成されるこのSuperaggregatesがそうした実体を位相的に閉じます。 事実上、登録はinetnumのmnt-ルートでそうする許可を与えるか、または相手と共に服従にサインすることによってそのような「スーパー-集合」を形成する許可を与えなければなりません。
D.3 provider independent addresses and multiple origin AS
D.3のプロバイダーの独立しているアドレスと複数の起源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.
プロバイダーの独立しているアドレスと複数の起源ASを使用するマルチホーミングアレンジメントが同様の問題をマルチホーミングに提示します。 アドレス空間の維持装置とASの維持装置は同じではありません。 mnt-ルートを使用するのを許可に与えることができますか、または複数の署名が服従のときに現れることができます。
D.4 change in Internet service provider
D.4はインターネット接続サービス業者で変化します。
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.
インターネット接続サービス業者における変化はマルチホーミングと同様です。 小異は、より特定のルートへのASが「マルチ-家へ帰」っている顧客のASよりむしろ新しいプロバイダーのASになるということです。 mnt-ルートを使用するのを許可に与えることができますか、または複数の署名が服従のときに現れることができます。
D.5 renumbering grace periods
据置期間に番号を付け替えさせるD.5
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
据置期間に番号を付け替えさせて、番号を付け替えるのが完成していた後にだれが別のプロバイダーに行くのを選んだ顧客がそれらのネットワークに徐々に番号を付け替えさせるのを許容するために完全にアドレス配分を保ちたがっているか、そして、その時が返すプロバイダーにアドレス空間を許容してください。 即座の番号を付け替えることを必要とするか、または据置期間を番号を付け替えるのに提供して、それらがどれくらい長いはずであるか、そして、またはそれらが無期であるべきであるかどうかに関する問題は激しい論争の話題です。 据置期間に番号を付け替えさせない有限番号を付け替えることを認可モデルは支持できます。
Villamizar, et al. Standards Track [Page 32] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[32ページ]。
grace period, or an indefinite renumbering grace period. The "reclaim" attribute described in Section 9.1 provides a means to end the grace period.
据置期間、または無期番号を付け替える据置期間。 セクション9.1で説明された「開墾」属性は据置期間を終わらせる手段を提供します。
E Deployment Considerations
E展開問題
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.
ルーティング登録の使用はまだ一般に受け入れられていません。 まだ、正確なルーティング情報の加えられた保証を提供するどんな理由もセクション6で説明されていないのを見るプロバイダが残っています。 より正確に、これらの利益は費用を正当化するためには不十分であるとして見なされます。 最近までの非常に一流のルータ業者が接頭語基礎あたりのaに関するルーティング方針を指定するのに必要であるサイズの接頭語リストを扱うことができないことはこれに大幅に引き起こされました。
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.
明確に、ルーティング登録の使用に関して臨界質量問題があります。 プロバイダーの少数が接頭語基礎あたりのaで既存のIRRをフィルタに使用します。 接続性問題が報告されるまで、プロバイダーの別の少数派は、IRRを支持して、一般に、必ず接頭語を登録します。 プロバイダーの大部分が、接頭語を登録しますが、厳しい接頭語フィルタリングを実行しません。
Deploying new authentication mechanisms has no adverse consequences. This has been proven with Merit's deployment of PGP.
新しい認証機構を配備するのにおいて、どんな不利な結果もありません。 これはMeritの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.
新しい認可メカニズムを配備する際に、主要な問題は非常に疑わしい起源に関する既存のデータに対処しています。 非常に多くのルート物が何年間も発表されていない接頭語を示します。 他のルート物はもう彼らが登録される起源ASと共に発表されない接頭語を示します(或るものは不当にまず第一に登録されました)。 この多くの原因があります。
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".
1. NSFNET PRDBからRADBまでの変遷の間、多くの接頭語がNSFNETが一度ルート発表を聞いたことがあった境界ASに対応する起源ASに登録されました。 PRDBが起源ASを支持しなかったので、境界ASは使用されました。 これらのルートの多くが、もう当時、使用中でなく、submitterが「nsfnet admin@merit.edu 」として記載されている状態で、現在、発送されます。
Villamizar, et al. Standards Track [Page 33] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[33ページ]。
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.
2. CIDRが配備されたとき、以前に別々に取り替えられた集合は、より特定の接頭語を発表しました。 より特定の接頭語のためのルート物はルーティング登録から決して引っ込められませんでした。
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.
3. いくつかの接頭語はもう絶対に使用中ではありません。 番号を付け替えられたネットワークもありました。 何らかのネットワークはもう存在していません。 しばしば、ルーティング登録情報はよそよそしいというわけではありません。
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.
4. プロバイダーAS隣接番組が変化して、末端顧客がしばしばプロバイダーを切り換えたとき、実際の起源ASは変化しました。 これはルーティング登録の変化によってしばしば反映されたというわけではありません。
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.
誤りは、1番目を除いた、上記の理由のため起こり続けるでしょう。 階層的な認可は、よりすばらしい責任を提供します。 特定の物に関する接触が無反応になる場合、認可階層構造への縦断は、前の提供された認可を持っているパーティーを特定するのを助けるべきです。 これらの接触には、必要なクリーンアップを実行できるくらいの認可がまだあるかもしれません。 セクション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.
多くの情報が現在、IRRでなくなっています。 かなり多くのASには、aut-numが全くありません。 かなり多くのデータで、維持装置がなくてかなりの大多数の維持装置使用は認証方法が最も苦手であるだけでありなります。 登録でほとんどして、これを修正することがないことができます。 認可に必要であるなくなった物のケースにおけるデフォルトは認証を全く全くチェックにしてはいけないことです。
The transition can be staged as follows:
以下の通り変遷を上演できます:
1. Add and make use of stronger authorization models.
1. より強い認可モデルを加えて、利用してください。
2. Make schema modifications necessary to support delegations.
2. 図式変更を代表団を支持するのに必要にしてください。
3. Add delegation attributes needed for query traversal.
4. Base query traversal on delegations rather than a search of all
known registries.
3. 質問縦断に必要である代表団属性を加えてください。 4. 質問縦断をすべての知られている登録の検索よりむしろ代表団に基礎づけてください。
5. Obtain the cooperation of the address registries for the purpose
of populating the "inetnum" entries on an ongoing basis.
5. 進行中ベースで"inetnum"エントリーに居住する目的にアドレス登録の協力を得てください。
6. Add hierarchical authorization support for critical object types,
"aut-num", "inetnum" and "route".
6. 重要なオブジェクト・タイプ、"aut-num"、"inetnum"、および「ルート」の階層的な認可サポートを加えてください。
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.
7. データベース物には、使用中であるか、または有効な問い合わせ先があって、登録で質問をするなら物がそれであるなら目的に役立つのを示す接触からの応答が使用が何であるかが明確でないという要件を加えてください。
Villamizar, et al. Standards Track [Page 34] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[34ページ]。
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.
8. 接触から明確に使用中でなく、また有効な問い合わせ先がない応答が全くないデータを掃除し始めてください。
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.
現在の、ほとんどの登録リターンが、知られている倉庫のすべてからそれらの映されたコピーを使用することで結果について質問します。 交差している登録承認はまだ実行されていません。 認可階層構造がある物を代表として派遣する能力を支持して、最小量の図式変更が他の倉庫の質問と参照を支持すると行われなければなりません。 AS代表団、「ブロック」としての唯一縦断の目的のために作成されるべき必要性の場合で。
F Route Object Authorization Pseudocode
Fルート物の認可擬似コード
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.
1. ルート物の提案は2つの認証評価基準を満たさなければなりません。 それはaut- numで指定された認証に合わなければなりません、そして、ルート物かそれとも次に、どんな適切なルート物も見つけられないかどうかで認証は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.
2. 接頭語認可がないかどうかチェックするとき、正確なルート物の接頭語マッチは最初にがないかどうかチェックされます。 完全な一致がなければ、接頭語ほど特定でない最も長い接頭語マッチは捜し求められます。 ルート前方一致検索が失敗するなら、検索はまさに接頭語に合っているinetnumかルート物の提案ほど特定でない最も特定のinetnumのために実行されます。
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
inetnumの検索は決して失敗するべきではありませんが、それは「非-割り当て」られたか予約された範囲を返すかもしれません。 inetnum状態は「割り当てられなければなりません」、そして、服従はそれの維持装置を渡さなければなりません。
Villamizar, et al. Standards Track [Page 35] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[35ページ]。
authorization in order to get authorization from an inetnum. So
an unallocated or reserved range inetnum will cause the route
object submission to fail.
認可、inetnumから、認可を得てください。 それで、「非-割り当て」られたか予約された範囲inetnumはルート物の提案に失敗されるでしょう。
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.
3. ルート物は参照をつけられたaut-num物とルートかinetnum物の両方から認可を通過しなければなりません。 認可は、最初に「mntルート」属性で参照をつけられた維持装置を使用することでテストされるものとします。 そのチェックが失敗するなら、「mnt下側」の属性はチェックされます。 そのチェックが失敗するなら、「近くmnt」属性は許可検査に使用されます。
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.
4. 「開墾」属性は、ルートと塊状物としてのinetnumに現れることができて、アドレスの貸すことを支持する手段を提供します。 「開墾」は物の「近くmnt」にかかわらずより特定の物の上に認可を与えます。 「開墾」属性の値は、よりよい粒コントロールを提供するためには物のリストかセットであるかもしれません。
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).
#1、をケースに入れてください。 ルート物は加えます(ie、正確な接頭語/起源マッチは全く存在していません)。
/* first check the aut-num authorization */
/*は最初に、aut-num認可*/をチェックします。
if ( the referenced aut-num object does not exist or
the aut-num authorization fails )
authorization fails
(参照をつけられたaut-num物が存在していないか、またはaut-num認可は失敗します)認可が失敗するなら
/* 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
(最も長い接頭語があるそれほど特定でないルートは見つけられます)、[(認可は少なくとも認可が失敗するそれほど特定でないルート(s) )の1つに適用しません。
/* now check for a "reclaim" attr */
/*は現在、「開墾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
(物は、aが属性を「開墾すること」を持っています)、[(どんなより多くの詳細も存在していない、認可を通過して、aが属性を「開墾すること」を持っているORのaより少ない詳細が、存在しています。
Villamizar, et al. Standards Track [Page 36] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[36ページ]。
OR all more specifics routess pass modify authorization )
authorization passes
else
authorization fails
] else
authorization passes
]
すべての、より多くの詳細routessが通過するORが認可) 認可のやり損ないほかの] 認可がほかの渡す認可パスを変更する、]
/* there are no less specific routes to check for prefix
authentication, so we need to try and get authorization from an
inetnum object */
*そこの/がおまけに、接頭語認証がないかどうかチェックする特定のルートであるので、私たちは、inetnum物*/から認可を得てみる必要があります。
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
(維持装置がinetnumで参照をつけた(完全な一致ORがそれほど特定でなく、状態が「割り当てられる」ということであるということであるinetnumは見つけられます)ANDは認可を通過します)認可が成功するなら
/* if there is no inetnum or route object then then
authorization fails. This should never happen if
the DB is initialized properly. */
*そこであるなら、その時、/は、inetnumでなくて、またまたはルート物でもなく、次に、認可は失敗します。 DBが適切に初期化されるなら、これは決して起こるべきではありません。 */
authorization fails.
認可は失敗します。
Case #2. Route object modify/delete
(ie, exact prefix/origin match exists).
#2、をケースに入れてください。 物が変更するか、または削除する(ie、正確な接頭語/起源マッチは存在しています)ルート。
if ( the mnt-by passes authorization )
authorization succeeds
(mntしているのは認可を通過します)認可が成功するなら
/* 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
(それほど特定でないルートかinetnum物で、認可を通過して、「開墾」属性は変更されるべき物に適切になります)認可がほかに成功するなら、認可は失敗します。
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.
このドキュメントはIETFルート設定Policy System Work GroupとRIPEルート設定Work Groupの頻繁な議論と貢献から考えを得ます。 このドキュメントの以前の草稿はキャロルOrangeについて共同作者に記載しました。 RIPEにある間、キャロルOrangeはこのドキュメントへの貢献をしました。
Villamizar, et al. Standards Track [Page 37] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[37ページ]。
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.
ジェラードWintersはスーザン・ハリスがコメントと頻繁な編集上の訂正を供給した付録F.で見つけられた擬似コードの基礎であったRIPE dbsecメーリングリストにメールメッセージの擬似コードを提供しました。
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.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
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.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
References
参照
[1] Alaettinoglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer,
D., Terpstra M. and C. Villamizar, "Routing Policy
Specification Language (RPSL)", RFC 2280, January 1998.
[1] Alaettinoglu(C.)は和らげます、T.、Gerich、E.、Karrenberg、D.、マイヤー、テルプストラM.とC.Villamizar、D.、「方針仕様言語(RPSL)を発送し」て、RFC2280、1998年1月。
[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++)", RFC 1786,
March 1995.
[2] ベイツとT.とGerichとE.とJoncherayとL.、JouanigotとJ-M.とKarrenbergとD.とテルプストラとM.とJ.ユー、「ルート設定登録(熟している81++)のIPルート設定方針の表現」RFC1786(1995年3月)。
[3] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January
1997.
[3] バーコウィッツ、H.、「ガイドに番号を付け替えさせるルータ」、RFC2072、1997年1月。
[4] Braun, H-W., "Models of policy based routing", RFC 1104, June
1989.
[4] ブラウン、H-W.、「方針のモデルはルーティングを基礎づけた」RFC1104、1989年6月。
[5] Braun, H-W. and Y. Rekhter, "Advancing the NSFNET routing
architecture", RFC 1222, May 1991.
[5] ブラウンとH-W.とY.Rekhter、「NSFNETルーティング構造を唱えます」、RFC1222、1991年5月。
Villamizar, et al. Standards Track [Page 38] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[38ページ]。
[6] Clark, D., "Policy routing in Internet protocols", RFC 1102,
May 1989.
[6] クラーク、D.、「インターネットプロトコルでの方針ルーティング」、RFC1102、1989年5月。
[7] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982.
[7] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[8] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC 1519, September 1993.
[8] フラーとV.と李とT.とユーとJ.とK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日
[9] Internet Engineering Steering Group and R. Hinden,
"Applicability Statement for the Implementation of Classless
Inter-Domain Routing (CIDR)", RFC 1517, September 1993.
[9] インターネット工学運営グループとR.Hinden、「階級のない相互ドメインルート設定(CIDR)の実現のための適用性証明」、RFC1517、1993年9月。
[10] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)", RFC
1930, March 1996.
[10]Hawkinson、J.とT.ベイツ、「Autonomous System(AS)の創造、選択、および登録のためのガイドライン」RFC1930(1996年3月)。
[11] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J.
Postel, "Internet Registry IP Allocation Guidelines", BCP 12,
RFC 2050, November 1996.
[11] ハバードとK.とKostersとM.とコンラッドとD.とKarrenbergとD.とJ.ポステル、「インターネット登録IP配分ガイドライン」、BCP12、RFC2050、1996年11月。
[12] Knopper, M. and S. Richardson, "Aggregation Support in the
NSFNET Policy-Based Routing Database", RFC 1482, June 1993.
[12]KnopperとM.とS.リチャードソン、「NSFNETの方針ベースのルート設定データベースにおける集合サポート」、RFC1482、1993年6月。
[13] Meyer, D., Prior, M., Alaettinoglu, C., Schmitz, J. and Carol
Orange, "Using RPSL in Practice", RFC 2650, August 1999.
1999年8月の[13]先のマイヤーとD.とM.とAlaettinogluとC.とシュミッツとJ.とキャロルOrange、「実際には使用RPSL」RFC2650。
[14] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787,
April 1995.
[14]Rekhter、Y.、「マルチプロバイダーインターネットのルート設定」、RFC1787、1995年4月。
[15] Rekhter Y. and T. Li, "An Architecture for IP Address
Allocation with CIDR", RFC 1518, September 1993.
[15]Rekhter Y.とT.李、「CIDRとのIPアドレス配分のための構造」、RFC1518、1993年9月。
[16] Rekhter Y. and T. Li, "Implications of Various Address
Allocation Policies for Internet Routing", RFC 2008, October
1996.
[16]Rekhter Y.とT.李、「インターネットルート設定のための様々なアドレス配分方針の含意」、RFC2008、1996年10月。
[17] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S. and J.
Postel, "An IPv6 Provider-Based Unicast Address Format", RFC
2073, January 1997.
[17]RekhterとY.とLothbergとP.とHindenとR.とデアリングとS.とJ.ポステル、「IPv6のプロバイダーベースのユニキャストアドレス形式」、RFC2073、1997年1月。
[18] Zsako, J., "PGP Authentication for RIPE Database Updates", RFC
2726, December 1999.
[18]Zsako、J.、「熟しているデータベース更新のためのPGP認証」、RFC2726、1999年12月。
Villamizar, et al. Standards Track [Page 39] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[39ページ]。
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.
このドキュメントは主として追加、削除、およびルーティングへの変更を方針情報倉庫にするための承認規則を扱います。 強い暗号の手段によるこれらのトランザクションの認証は[18]によって扱われて、参照をつけられたthorughoutはこのドキュメントです。 承認規則は、規則が固く守られるのを保障するために倉庫を映すどんなパーティーも独自にどんなトランザクションの保全についても確かめることができるように、設計されています。 これを達成するために、鏡は適切に認可されるのが既に知られていたデータを含まなければなりません。 言い換えれば、鏡は終了しているに違いなくて、整然とした状態で倉庫への変化をrecievedして、処理するとき絶え間なく認証と許可検査をしなければなりません。
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
カーティスVillamizar Avici Systemsはメールされます: curtis@avici.com
Cengiz Alaettinoglu ISI EMail: cengiz@ISI.EDU
Cengiz Alaettinoglu ISIはメールします: cengiz@ISI.EDU
David M. Meyer Cisco EMail: dmm@cisco.com
デヴィッドM.マイヤーコクチマスメール: dmm@cisco.com
Sandy Murphy Trusted Information Systems EMail: sandy@tis.com
砂地のマーフィーは情報システムメールを信じました: sandy@tis.com
Villamizar, et al. Standards Track [Page 40] RFC 2725 Routing Policy System Security December 1999
Villamizar、他 規格はルート設定方針システムセキュリティ1999年12月にRFC2725を追跡します[40ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Villamizar, et al. Standards Track [Page 41]
Villamizar、他 標準化過程[41ページ]
一覧
スポンサーリンク
