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

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/