--- 1/draft-ietf-opsec-routing-capabilities-00.txt 2007-02-26 23:13:12.000000000 +0100 +++ 2/draft-ietf-opsec-routing-capabilities-01.txt 2007-02-26 23:13:12.000000000 +0100 @@ -1,20 +1,20 @@ OPSEC Working Group Y. Zhao Internet-Draft F. Miao Intended status: Informational Huawei Technologies -Expires: April 13, 2007 R. Callon +Expires: August 29, 2007 R. Callon Juniper Networks - October 10, 2006 + February 25, 2007 Routing Control Plane Security Capabilities - draft-ietf-opsec-routing-capabilities-00.txt + draft-ietf-opsec-routing-capabilities-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -25,33 +25,34 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 13, 2007. + This Internet-Draft will expire on August 29, 2007. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). Abstract The document lists the security capabilities needed for the routing control plane of an IP infrastructure to support the practices defined in Operational Security Current Practices. In particular - this includes capabilities for route filtering and for authentication - of routing protocol packets. + this includes capabilities for route filtering, for authentication of + routing protocol packets, and for ensuring resource availability for + control functions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Threat model . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Format and Definition of Capabilities . . . . . . . . . . 3 1.3. Packet Filtering versus Route Filtering . . . . . . . . . 4 2. Route Filtering Capabilities . . . . . . . . . . . . . . . . . 5 2.1. General Route Filtering Capabilities . . . . . . . . . . . 5 2.1.1. Ability to Filter Inbound or Outbound Routes . . . . . 5 @@ -59,26 +60,26 @@ 2.2. Route Filtering of Exterior Gateway Protocol . . . . . . . 6 2.2.1. Ability to Filter Routes by Route Attributes . . . . . 6 2.2.2. Ability to Filter Routing Update by TTL . . . . . . . 7 2.2.3. Ability to Limit the Number of Routes from a Peer . . 8 2.2.4. Ability to Limit the Length of Prefixes . . . . . . . 9 2.2.5. Ability to Cooperate in Outbound Route Filtering . . . 9 2.3. Route Filtering of Interior Gateway Protocols . . . . . . 10 2.3.1. Route Filtering Within an IGP Area . . . . . . . . . . 10 2.3.2. Route Filtering Between IGP Areas . . . . . . . . . . 10 2.4. Route Filtering during Redistribution . . . . . . . . . . 11 - 3. Route Authentication Capabilities . . . . . . . . . . . . . . 12 + 3. Route Authentication Capabilities . . . . . . . . . . . . . . 11 3.1. Ability to configure an authentication mechanism . . . . . 12 3.2. Ability to support authentication key chains . . . . . . . 12 4. Ability to Damp Route Flap . . . . . . . . . . . . . . . . . . 13 - 5. Performance and Prioritization . . . . . . . . . . . . . . . . 14 - 5.1. Ensure Resources for Management Functions . . . . . . . . 14 + 5. Resource Availability for Router Control Functions . . . . . . 13 + 5.1. Ensure Resources for Management Functions . . . . . . . . 13 5.2. Ensure Resources for Routing Functions . . . . . . . . . . 15 5.3. Limit Resources used by IP Multicast . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 20 @@ -427,22 +428,21 @@ implementations support prefix-based ORF. Considerations. None. 2.3. Route Filtering of Interior Gateway Protocols This section describes route filtering as it may be applied to OSPF and IS-IS when used as the interior gateway protocol (Internal - Gateway Protocol or "IGP") used within a routing domain. Route - filtering with RIP is TBD. + Gateway Protocol or "IGP") used within a routing domain. 2.3.1. Route Filtering Within an IGP Area A critical design principle of OSPF and IS-IS is that each router within an area has the same view of the topology, thereby allowing consistent routes to be computed by all routers within the area. For this reason, all properly authenticated (if applicable) routing topology advertisements (Link State Advertisements or LSAs in OSPF, or Link State Packets or LSPs in IS-IS) are flooded unchanged throughout the area. Route filtering within an OSPF or IS-IS area is @@ -489,24 +488,24 @@ processes running in the single device. Supported Practices. Route redistribution bridges between different route domains and improves the flexibility of routing system. This allows for the transmission of reachable destinations learned in one protocol through another protocol. However, without careful consideration it may lead to looping or black holes as well. - Filters always needed when routes redistributing between IGP and - BGP. For example, it is unfeasible to inject all internet routes - from BGP to IGPs, since IGPs are not able to deal with such a - large number of routes. + Filters is always needed when routes redistributing between IGP + and BGP. For example, it is unfeasible to inject all internet + routes from BGP to IGPs, since IGPs are not able to deal with such + a large number of routes. Current Implementations. Most implementations allow applying a filter based on a prefix list to control redistribution. Considerations TBD. @@ -593,33 +592,35 @@ MAO [19] described a flaw of current BGP RFD standard RFC2439, which shows that route flap damping could suppress relatively stable routes and affect routing convergence. Since none of vendors has corrected his BGP implementation, RIPE378 [20] proposes that, with the current implementations of BGP flap damping, the application of flap damping in ISP networks is not recommended. -5. Performance and Prioritization +5. Resource Availability for Router Control Functions 5.1. Ensure Resources for Management Functions Capability. This capability specifies that device implementations ensure that at least a certain minimum sufficient level of resources are - available for management functions. This may include resources at - ingress to the device, on egress from the device, for internal - transmission, and processing. This may include at least protocols - used for configuration, monitoring, configuration backup, logging, - time synchronization, and authentication. + available for management functions. This may include such + resources as memory, processor cycle, data structure and/or + bandwidth at ingress to the device, on egress from the device, for + internal transmission and processing. This may include at least + protocols used for configuration, monitoring, configuration + backup, logging, time synchronization, authentication and + authorization. Supported Practices. Certain attacks (and normal operation) can cause resource saturation such as link congestion, memory exhaustion or CPU overload. In these cases it is important that resources be available for management functions in order to ensure that operators have the tools needed to recover from the attack. Current Implementations. @@ -650,25 +651,26 @@ (e.g., ingress, egress, internal transit, processing). To the extent that this is done across an entire network, the overall effect will be to ensure that the network remains manageable. 5.2. Ensure Resources for Routing Functions Capability. This capability specifies that a device implementation ensures at least a certain minimum sufficient level of resources are - available for routing protocol functions. This may include - resources at ingress to the device, on egress from the device, for - internal transmission, and processing. This may include at least - protocols used for routing protocol operation, including resources - used for routing HELLO packets for BGP, IS-IS, and OSPF. + available for routing protocol functions. This may include such + resources as memory, processor cycle, data structure and bandwidth + at ingress to the device, on egress from the device, for internal + transmission, and processing. This may include at least protocols + used for routing protocol operation, including resources used for + routing HELLO packets for BGP, IS-IS, and OSPF. Supported Practices. Certain attacks (and normal operation) can cause resource saturation such as link congestion, memory exhaustion or CPU overload. In these cases it is important that resources be available for the operation of routing protocols in order to ensure that the network continues to operate (for example, that routes can be computed in order to allow management traffic to be delivered). For many routing protocols the loss of HELLO packets @@ -681,26 +683,26 @@ How this is implemented depend upon the details of the device. There are a variety of ways that this may be ensured such as prioritizing routing functions in comparison with other functions performed by the device, providing separate queues for routing traffic, use of operating systems or other methods that partition resources between processes or functions, and so on. Consideration. - If routing HELLO packets are not prioritized, then it is possible - during DoS attacks or during severe network congestion for routing - protocols to drop HELLO packets, causing routing adjacencies to be - lost. This in turn can cause overall failure of a network. A DoS - attack against hosts can therefore become a DoS attack against the - network. + For example, if routing HELLO packets are not prioritized, then it + is possible during DoS attacks or during severe network congestion + for routing protocols to drop HELLO packets, causing routing + adjacencies to be lost. This in turn can cause overall failure of + a network. A DoS attack against hosts can therefore become a DoS + attack against the network. Guaranteeing resources within routers is not a panacea. Routing packets may not make it across a saturated link (thus for example it may also be desirable to prioritize routing packets for transmission across link layer devices such as Ethernet switches). This requirement simply says that the device should prioritize routing functions within its scope of control (e.g., ingress, egress, internal transit, processing). To the extent that this is done across an entire network, the overall effect will be to ensure that the network continues to operate. @@ -839,40 +841,39 @@ Shangdi Information Industry Base Haidian District, Beijing 100085 P. R. China Phone: +86 10 8288 2008 Email: miaofy@huawei.com Ross W. Callon Juniper Networks 10 Technology Park Drive - Shangdi Information Industry Base Westford, MA 01886 USA Email: rcallon@juniper.net Full Copyright Statement - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM 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 + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information