rfc2725.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,411 行 · 第 1/5 页

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

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 (1999).  All Rights Reserved.

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.














Villamizar, et al.          Standards Track                     [Page 1]

RFC 2725             Routing Policy System Security        December 1999


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




Villamizar, et al.          Standards Track                     [Page 2]

RFC 2725             Routing Policy System Security        December 1999


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.

      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.

   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.

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.





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.

   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.

   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.

   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.

   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.

   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


   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.

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.

   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.

   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.

   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

   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]