rfc2769.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,394 行 · 第 1/5 页
TXT
1,394 行
Network Working Group C. Villamizar
Request for Comments: 2769 Avici Systems
Category: Standards Track C. Alaettinoglu
R. Govindan
ISI
D. Meyer
Cisco
February 2000
Routing Policy System Replication
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.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Abstract
The RIPE database specifications and RPSL 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 use. The Routing Policy System Security RFC [3] addresses the
need to assure integrity of the data by proposing an authentication
and authorization model. This document addresses the need to
distribute data over multiple repositories and delegate authority for
data subsets to other repositories without compromising the
authorization model established in Routing Policy System Security
RFC.
Villamizar, et al. Standards Track [Page 1]
RFC 2769 Routing Policy System Replication February 2000
Table of Contents
1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Data Representation . . . . . . . . . . . . . . . . . . . . . 4
3 Authentication and Authorization . . . . . . . . . . . . . . . 5
4 Repository Hierarchy . . . . . . . . . . . . . . . . . . . . . 6
5 Additions to RPSL . . . . . . . . . . . . . . . . . . . . . . 6
5.1 repository object . . . . . . . . . . . . . . . . . . . . 7
5.2 delegated attribute . . . . . . . . . . . . . . . . . . . 9
5.3 integrity attribute . . . . . . . . . . . . . . . . . . . 10
6 Interactions with a Repository or Mirror . . . . . . . . . . . 11
6.1 Initial Transaction Submission . . . . . . . . . . . . . 12
6.2 Redistribution of Transactions . . . . . . . . . . . . . 12
6.3 Transaction Commit and Confirmation . . . . . . . . . . . 12
7 Data Format Summaries, Transaction Encapsulation and Processing 13
7.1 Transaction Submit and Confirm . . . . . . . . . . . . . 13
7.2 Redistribution of Transactions . . . . . . . . . . . . . 16
7.3 Redistribution Protocol Description . . . . . . . . . . . 16
7.3.1 Explicitly Requesting Transactions . . . . . . . . 21
7.3.2 Heartbeat Processing . . . . . . . . . . . . . . . 22
7.4 Transaction Commit . . . . . . . . . . . . . . . . . . . 23
7.5 Database Snapshot . . . . . . . . . . . . . . . . . . . . 24
7.6 Authenticating Operations . . . . . . . . . . . . . . . . 25
A Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.1 Initial Object Submission and Redistribution . . . . . . 27
A.2 Transaction Redistribution Encoding . . . . . . . . . . . 29
A.3 Transaction Protocol Encoding . . . . . . . . . . . . . . 31
A.4 Transaction Redistribution . . . . . . . . . . . . . . . 32
B Technical Discussion . . . . . . . . . . . . . . . . . . . . . 35
B.1 Server Processing . . . . . . . . . . . . . . . . . . . . 35
B.1.1 getting connected . . . . . . . . . . . . . . . . . 35
B.1.2 rolling transaction logs forward and back . . . . . 35
B.1.3 committing or disposing of transactions . . . . . . 36
B.1.4 dealing with concurrency . . . . . . . . . . . . . 36
B.2 Repository Mirroring for Redundancy . . . . . . . . . . . 36
B.3 Trust Relationships . . . . . . . . . . . . . . . . . . . 37
B.4 A Router as a Minimal Mirror . . . . . . . . . . . . . . 38
B.5 Dealing with Errors . . . . . . . . . . . . . . . . . . . 38
C Deployment Considerations . . . . . . . . . . . . . . . . . . 39
D Privacy of Contact Information . . . . . . . . . . . . . . . . 39
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Security Considerations . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 42
Villamizar, et al. Standards Track [Page 2]
RFC 2769 Routing Policy System Replication February 2000
1 Overview
A routing registry must maintain some degree of integrity to be of
any use. The IRR is increasingly used for purposes that have a
stronger requirement for data integrity and security. There is also
a desire to further decentralize the IRR. This document proposes a
means of decentralizing the routing registry in a way 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.
Two methods of authenticating the routing registry information have
been proposed.
authorization and authentication checks on transactions: The
integrity of the routing registry data is insured by repeating
authorization checks as transactions are processed. As
transactions are flooded each remote registry has the option to
repeat the authorization and authentication checks. This scales
with the total number of changes to the registry regardless of how
many registries exist. When querying, the integrity of the
repository must be such that it can be trusted. If an
organization is unwilling to trust any of the available
repositories or mirrors they have the option to run their own
mirror and repeat authorization checks at that mirror site.
Queries can then be directed to a mirror under their own
administration which presumably can be trusted.
signing routing registry objects: An alternate which appears on the
surface to be attractive is signing the objects themselves.
Closer examination reveals that the approach of signing objects by
itself is flawed and when used in addition to signing transactions
and rechecking authorizations as changes are made adds nothing.
In order for an insertion of critical objects such as inetnums and
routes to be valid, authorization checks must be made which allow
the insertion. The objects on which those authorization checks
are made may later change. In order to later repeat the
authorization checks the state of other objects, possibly in other
repositories would have to be known. If the repository were not
trusted then the change history on the object would have to be
traced back to the object's insertion. If the repository were not
trusted, the change history of any object that was depended upon
for authorization would also have to be rechecked. This trace
back would have to go back to the epoch or at least to a point
where only trusted objects were being relied upon for the
authorizations. If the depth of the search is at all limited,
authorization could be falsified simply by exceeding the search
depth with a chain of authorization references back to falsified
Villamizar, et al. Standards Track [Page 3]
RFC 2769 Routing Policy System Replication February 2000
objects. This would be grossly inefficient. Simply verifying
that an object is signed provides no assurance that addition of
the object addition was properly authorized.
A minor distinction is made between a repository and a mirror. A
repository has responsibility for the initial authorization and
authentication checks for transactions related to its local objects
which are then flooded to adjacent repositories. A mirror receives
flooded transactions from remote repositories but is not the
authoritative source for any objects. From a protocol standpoint,
repositories and mirrors appear identical in the flooding topology.
Either a repository or a mirror may recheck all or a subset of
transactions that are flooded to it. A repository or mirror may
elect not to recheck authorization and authentication on transactions
received from a trusted adjacency on the grounds that the adjacent
repository is trusted and would not have flooded the information
unless authorization and authentication checks had been made.
If it can be arranged that all adjacencies are trusted for a given
mirror, then there is no need to implement the code to check
authorization and authentication. There is only a need to be able to
check the signatures on the flooded transactions of the adjacent
repository. This is an important special case because it could allow
a router to act as a mirror. Only changes to the registry database
would be received through flooding, which is a very low volume. Only
the signature of the adjacent mirror or repository would have to be
checked.
2 Data Representation
RPSL provides a complete description of the contents of a routing
repository [1]. Many RPSL data objects remain unchanged from the
RIPE, 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. The integrity
of the distributed registry data requires the use of the
authorization and authentication additions to RPSL described in [3].
Some additions to RPSL are needed to locate all of the repositories
after having located one of them and to make certain parameters
selectable on a per repository basis readily available. These
additions are described in Section 5.
Some form of encapsulation must be used to exchange data. The de-
facto encapsulation has been that 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
Villamizar, et al. Standards Track [Page 4]
RFC 2769 Routing Policy System Replication February 2000
the mail headers. 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.
The exchange that occurs during flooding differs from the initial
submission. In order to repeat the authorization checks the state of
all repositories containing objects referenced by the authorization
checks needs to be known. To accomplish this a sequence number is
associated with each transaction in a repository and the flooded
transactions must contain the sequence number of each repository on
which authorization of the transaction depends.
In order to repeat authorization checks it must be possible to
retrieve back revisions of objects. How this is accomplished is a
matter local to the implementation. One method which is quite simple
is to keep the traversal data structures to all current objects even
if the state is deleted, keep the sequence number that the version of
the object became effective and keep back links to prior versions of
the objects. Finding a prior version of an object involves looking
back through the references until the sequence number of the version
of the object is less than or equal to the sequence number being
searched for.
The existing very simple forms of encapsulation are adequate for the
initial submission of a database transaction and should be retained
as long as needed for backward compatibility. A more robust
encapsulation and submission protocol, with optional confirmation is
defined in Section 6.1. An encapsulation suitable for exchange of
transaction between repositories is addressed in Section 6. Query
encapsulation and protocol is outside the scope of this document.
3 Authentication and Authorization
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 Authorization is the determination of whether a transaction
passing a specific authentication check is allowed to perform a
given operation.
A submitted transaction contains a claimed identity. Depending on
the type of transaction, the authorization will depend on related
objects.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?