draft-ietf-opsec-routing-capabilities-01.txt   draft-ietf-opsec-routing-capabilities-02.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: Best Current Huawei Technologies
Expires: August 29, 2007 R. Callon Practice R. Callon
Juniper Networks Expires: October 7, 2007 Juniper Networks
February 25, 2007 April 5, 2007
Routing Control Plane Security Capabilities Routing Control Plane Security Capabilities
draft-ietf-opsec-routing-capabilities-01.txt draft-ietf-opsec-routing-capabilities-02.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 August 29, 2007. This Internet-Draft will expire on October 7, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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, for authentication of this includes capabilities for route filtering, for authentication of
routing protocol packets, and for ensuring resource availability for routing protocol packets, and for ensuring resource availability for
control functions. 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 . . . . . . . . . 3
2. Route Filtering Capabilities . . . . . . . . . . . . . . . . . 5 2. Route Filtering Capabilities . . . . . . . . . . . . . . . . . 4
2.1. General Route Filtering Capabilities . . . . . . . . . . . 5 2.1. General Route Filtering Capabilities . . . . . . . . . . . 4
2.1.1. Ability to Filter Inbound or Outbound Routes . . . . . 5 2.1.1. Ability to Filter Inbound or Outbound Routes . . . . . 4
2.1.2. Ability to Filter Routes by Prefix . . . . . . . . . . 6 2.1.2. Ability to Filter Routes by Prefix . . . . . . . . . . 5
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 . . . . . . . . . . . . . . 11 3. Route Authentication Capabilities . . . . . . . . . . . . . . 11
3.1. Ability to configure an authentication mechanism . . . . . 12 3.1. Ability to configure an authentication mechanism . . . . . 11
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 . . . . . . . . . . . . . . . . . . 12
5. Resource Availability for Router Control Functions . . . . . . 13 5. Resource Availability for Router Control Functions . . . . . . 13
5.1. Ensure Resources for Management Functions . . . . . . . . 13 5.1. Ensure Resources for Management Functions . . . . . . . . 13
5.2. Ensure Resources for Routing Functions . . . . . . . . . . 15 5.2. Ensure Resources for Routing Functions . . . . . . . . . . 14
5.3. Limit Resources used by IP Multicast . . . . . . . . . . . 16 5.3. Limit Resources used by IP Multicast . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
This document is defined in the context of Operation Security This document is defined in the context of [I-D.ietf-opsec-framework]
Framework [12] and Operation Security Current Practice [13]. and [RFC4778].
The Framework for Operation Security Framework outlines the effort of
the IETF OPSEC working group. This includes producing a series of
drafts to codify knowledge gained through operational experience
about capabilities that are needed to securely deploy and operate
managed network elements providing transit services at the data link
and network layers.
This document lists the security capabilities needed for the routing This document lists the security capabilities needed for the routing
control plane of IP infrastructure to support the practices defined control plane of IP infrastructure to support the practices defined
in Operational Security Current Practices. In particular this in [I-D.ietf-opsec-framework]. In particular this includes
includes capabilities for route filtering and for authentication of capabilities for route filtering and for authentication of routing
routing protocol packets. protocol packets.
Note that this document lists capabilities that can reasonably be Note that this document lists capabilities that can reasonably be
expected to be currently deployed in the context of existing expected to be currently deployed in the context of existing
standards. Extensions to existing protocol standards and development standards. Extensions to existing protocol standards and development
of new protocol standards are outside of the scope of this effort. of new protocol standards are outside of the scope of this effort.
The preferred capabilities needed for securing the routing The preferred capabilities needed for securing the routing
infrastructure may evolve over time. infrastructure may evolve over time.
There will be other capabilities which are needed to fully secure a There will be other capabilities which are needed to fully secure a
router infrastructure. For example, network management of devices router infrastructure. [RFC4778] defines the goals, motivation,
must be secured in order to prevent unauthorized access to or denial
of service to the device Network Management Access Security
Capabilities [15]. The reader should refer to Operation Security
Framework for a more complete list of documents describing
operational capabilities for network and link layer devices
supporting IP Network Infrastructure.
Operational Security Current Practices defines the goals, motivation,
scope, definitions, intended audience, threat model, potential scope, definitions, intended audience, threat model, potential
attacks and give justifications for each of the practices. attacks and give justifications for each of the practices.
1.1. Threat model 1.1. Threat model
The capabilities listed in this document are intended to aid in The capabilities listed in this document are intended to aid in
preventing or mitigating the threats outlined in Operation Security preventing or mitigating the threats outlined in
Framework and Current Practices. [I-D.ietf-opsec-framework].
1.2. Format and Definition of Capabilities 1.2. Format and Definition of Capabilities
Each individual capability will be defined using the four elements, Each individual capability will be defined using the four elements,
"Capability", "Supported Practices", "Current Implementations", and "Capability", "Supported Practices", "Current Implementations", and
"Considerations", as explained in section 1.7 of Operation Security "Considerations", as explained in section 1.7 of
Framework. [I-D.ietf-opsec-framework].
1.3. Packet Filtering versus Route Filtering 1.3. Packet Filtering versus Route Filtering
It is useful to make a distinction between Packet Filtering versus It is useful to make a distinction between Packet Filtering versus
Route Filtering. Route Filtering.
The term "packet filter" is used to refer to the filter that a router The term "packet filter" is used to refer to the filter that a router
applies to network layer packets passing through or destined to it. applies to network layer packets passing through or destined to it.
In general packet filters are based on contents of the network (IP) In general packet filters are based on contents of the network (IP)
and transport (TCP,UDP) layers, and are mostly stateless, in the and transport (TCP,UDP) layers, and are mostly stateless, in the
skipping to change at page 4, line 35 skipping to change at page 4, line 20
the filter). the filter).
Because of the simplicity and stateless nature of packet filters, Because of the simplicity and stateless nature of packet filters,
they can typically be implemented with very high performance. It is they can typically be implemented with very high performance. It is
not unusual for them to be implemented on line cards and to perform not unusual for them to be implemented on line cards and to perform
at or near full line rate. For this reason they are very useful to at or near full line rate. For this reason they are very useful to
counter very high bandwidth attacks, such as large DDoS attacks. counter very high bandwidth attacks, such as large DDoS attacks.
Packet filtering capabilities are outside of the scope of this Packet filtering capabilities are outside of the scope of this
document. A detailed description of packet filtering capabilities document. A detailed description of packet filtering capabilities
can be found in "Filtering Capabilities for IP Network can be found in [I-D.ietf-opsec-filter-caps].
Infrastructure" [14].
The Term "route filter" is used to refer to filters that routers The Term "route filter" is used to refer to filters that routers
apply to the content of routing protocol packets that they are either apply to the content of routing protocol packets that they are either
sending or receiving. Typically these therefore occur at the sending or receiving. Typically these therefore occur at the
application layer (although which route filters are applied to a application layer (although which route filters are applied to a
particular packet may be a function of network layer information, particular packet may be a function of network layer information,
such as what interface the packet is received on, or the source such as what interface the packet is received on, or the source
address for the packet -- indicating the system that transmitted the address for the packet -- indicating the system that transmitted the
packet). packet).
skipping to change at page 5, line 17 skipping to change at page 4, line 48
2. Route Filtering Capabilities 2. Route Filtering Capabilities
2.1. General Route Filtering Capabilities 2.1. General Route Filtering Capabilities
2.1.1. Ability to Filter Inbound or Outbound Routes 2.1.1. Ability to Filter Inbound or Outbound Routes
Capability. Capability.
The device provides the ability to filter which routes may be The device provides the ability to filter which routes may be
received in routing protocols (with BGP [10], and with RIP [7] and received with [RFC4271], as well as the ability to filter which
other distance vector routing protocols), as well as the ability routes are announced into each routing protocol.
to filter which routes are announced into each routing protocol.
Supported Practices. Supported Practices.
See section 2.4.2 of Current Practices. See section 2.4.2 of [RFC4778].
It is a beneficial practice to configure routing filters in both It is a beneficial practice to configure routing filters in both
directions, which will counter potential misconfiguration in each directions, which will counter potential misconfiguration in
side of peers. Also, incoming route filters will prevent a either peer. Also, incoming route filters will prevent a
deliberate attacker to inject invalid routing information. deliberate attacker from injecting invalid routing information.
Current Implementations. Current Implementations.
The unicast routing protocols used with IP can be classified into The unicast routing protocols used with IP can be classified into
path vector routing protocols (such as BGP), distance vector path vector routing protocols (such as BGP), distance vector
protocols (such as RIP) and link state protocols (such as OSPF [4] protocols (such as [RFC2453]) and link state protocols (such as
and IS-IS [1]). Because of difference of protocol mechanism, [RFC2328] and [RFC1195]). Because of differences in the
route filters will affect them in different ways. protocols, route filters will affect them in different ways.
Take BGP for example, an implementation may check a received route Take BGP for example, an implementation may check a received route
against inbound filters to determine whether to install it into against inbound filters to determine whether to install it into
the overall route table or not. Also, it will restrict the routes the overall route table or not. Also, it will restrict the routes
which will go out to neighbors against outbound route filters. which will go out to neighbors against outbound route filters.
However, as to link state protocols, such as OSPF, a router However, as to link state protocols, such as OSPF, a router
maintains a topology database and exchanges link state information maintains a topology database and exchanges link state information
with neighbors. Since route filters do not influence the link with neighbors. Since route filters do not influence the link
state database, route filters will only affect which routes are state database, route filters will only affect which routes are
skipping to change at page 6, line 18 skipping to change at page 5, line 50
None. None.
2.1.2. Ability to Filter Routes by Prefix 2.1.2. Ability to Filter Routes by Prefix
Capability. Capability.
The device supports filtering routes based on prefix. The device supports filtering routes based on prefix.
Supported Practices. Supported Practices.
See section 2.4.2 of Current Practices. See section 2.4.2 of [RFC4778].
Current Implementations. Current Implementations.
The filter may include a list of specific prefixes to be accepted The filter may include a list of specific prefixes to be accepted
or rejected. The filter may alternately include a list of or rejected. The filter may alternately include a list of
prefixes, such that more specific (longer) prefixes which are prefixes, such that more specific (longer) prefixes, which are
included in the more inclusive (shorter) prefix are accepted, included in the more inclusive (shorter) prefix, are accepted,
rejected, or summarized into the shorter prefix. rejected, or summarized into the shorter prefix.
Considerations. Considerations.
Operators may wish to ignore advertisements for routes to Operators may wish to ignore advertisements for routes to specific
specially used addresses, such as private addresses, reserved addresses, such as private addresses, reserved addresses and
addresses and multicast addresses, etc. The up-to-date allocation multicast addresses, etc. The up-to-date allocation of IPv4
of IPv4 address space can be found in INTERNET PROTOCOL V4 ADDRESS address space can be found in [IANA].
SPACE [18].
2.2. Route Filtering of Exterior Gateway Protocol 2.2. Route Filtering of Exterior Gateway Protocol
An exterior gateway protocol is used to exchange external routing An exterior gateway protocol is used to exchange external routing
information between different autonomous systems. Since BGP is the information between different autonomous systems. Since BGP is the
actual standard, this section mainly depicts special routing filter most widely used protocol, this section mainly depicts special
capabilities of BGP. routing filter capabilities of BGP.
2.2.1. Ability to Filter Routes by Route Attributes 2.2.1. Ability to Filter Routes by Route Attributes
Capability. Capability.
The device supports filtering routing updates by route attributes. The device supports filtering routing updates by route attributes.
Supported Practices. Supported Practices.
See RFC3013 [8] and section 3.2 of RFC2196 [3] and section 2.4.2 See [RFC3013] , section 3.2 of[RFC2196] and section 2.4.2 of
of Current Practices. [RFC4778].
Current Implementations. Current Implementations.
In comparison with other routing protocol, BGP defines various In comparison with other routing protocols, BGP defines various
path attributes to describe characteristics of routes. Besides path attributes to describe characteristics of routes. Besides
filtering by specific prefixes, BGP could also use some path filtering by specific prefixes, BGP also provides capability to
attributes to precisely filter routes to determine whether a route use some path attributes to precisely filter routes to determine
is accepted from or sent to a neighboring router. whether a route is accepted from or sent to a neighboring router.
These filters may be based upon any combination of route These filters may be based upon any combination of route
attributes, such as: attributes, such as:
* Restrictions on the Content of AS_PATH. Restrictions on the * Restrictions on the Content of AS_PATH. Restrictions on the
contents of the AS PATH are frequently used: for example, the contents of the AS PATH are frequently used: for example, the
received AS_PATH may be checked to ensure the sending AS is received AS_PATH may be checked to ensure the sending AS is
actually contained in the received AS_PATH. actually contained in the received AS_PATH.
* Restrictions on Communities. Implementations could filter * Restrictions on Communities. Implementations could filter
received routes based on the set of communities RFC1997 [2] or received routes based on the set of communities [RFC1997] or
extended communities RFC4360 [11]. extended communities [RFC4360].
Considerations. Considerations.
None. None.
2.2.2. Ability to Filter Routing Update by TTL 2.2.2. Ability to Filter Routing Update by TTL
Capability. Capability.
The device should provide a means to filter route packets based on The device should provide a means to filter route packets based on
the value of the TTL field in the IPv4 header or the Hop-Limit the value of the TTL field in the IPv4 header or the Hop-Limit
field in the IPv6 header. field in the IPv6 header.
Note that "Filtering Capabilities for IP Network Infrastructure" Note that [I-D.ietf-opsec-filter-caps] specifies:
Filtering Capabilities specifies:
Capability. Capability.
The filtering mechanism supports filtering based on the The filtering mechanism supports filtering based on the
value(s) of any portion of the protocol headers for IP, ICMP, value(s) of any portion of the protocol headers for IP, ICMP,
UDP and TCP. UDP and TCP.
The ability to filter based on TTL is therefore a packet filtering The ability to filter based on TTL is therefore a packet filtering
capability which is already implicitly covered by the capabilities capability which is already implicitly covered by the capabilities
listed in Filtering Capabilities. Since this capability is listed in Filtering Capabilities. Since this capability is
particularly important for BGP, we felt that it is worth particularly important for BGP, we felt that it is worth
mentioning here. mentioning here.
Supported Practices. Supported Practices.
See Current Practices section 2.4.2 and RFC3682 [9]. See [RFC4778] section 2.4.2 and [RFC3682].
Current Implementations. Current Implementations.
Most current BGP implementations support this capability to Most current BGP implementations support this capability to
protect BGP sessions. protect BGP sessions.
Considerations. Considerations.
There will be situations in which the distance to the neighboring There will be situations in which the distance to the neighboring
router is more than one hop away. This for example is common for router is more than one hop away. This for example is common for
skipping to change at page 8, line 32 skipping to change at page 8, line 16
Capability. Capability.
The device should provide a means to configure the maximum number The device should provide a means to configure the maximum number
of routes (prefixes) to accept from a peer. of routes (prefixes) to accept from a peer.
Supported Practices. Supported Practices.
Both routing policy misconfiguration and a deliberate attack from Both routing policy misconfiguration and a deliberate attack from
a peer may cause too many routes to be sent to a peer which may a peer may cause too many routes to be sent to a peer which may
exhaust memory resources of the router, introduce routing exhaust the memory resources of the router, introduce routing
instability into the overall routing table, or both. Therefore, instability into the overall routing table, or both. Therefore,
operators may want to restrict the amount of routes received from operators may want to restrict the amount of routes received from
a particular peer router through a maximum prefix limitation a particular peer router through a maximum prefix limitation
approach. approach.
Current Implementations. Current Implementations.
Most BGP implementations support this capability. If too many Most BGP implementations support this capability. If too many
routes are sent, then the router may reset the BGP session or may routes are sent, then the router may reset the BGP session or may
reject excess routes. In either case the device may log the reject excess routes. In either case the device may log the
skipping to change at page 9, line 22 skipping to change at page 9, line 9
table if a policy misconfiguration on the adjacent neighbor is table if a policy misconfiguration on the adjacent neighbor is
causing the condition. If a serious misconfiguration on a peering causing the condition. If a serious misconfiguration on a peering
neighbor has occurred then automatically shutting down the session neighbor has occurred then automatically shutting down the session
and leaving it shut down until being manually cleared is perhaps and leaving it shut down until being manually cleared is perhaps
best and allows for operator intervention to correct as needed. best and allows for operator intervention to correct as needed.
2.2.4. Ability to Limit the Length of Prefixes 2.2.4. Ability to Limit the Length of Prefixes
Capability. Capability.
The device has the capability to allow filtering route updates by The device has the capability to allow filtering of route updates
prefix length. by prefix length.
Supported Practices. Supported Practices.
Some large ISPs declare in their peer BGP policies that they will Some large ISPs declare in their peer BGP policies that they will
not accept the announcements whose prefix length is longer than a not accept the announcements whose prefix length is longer than a
specific threshold. specific threshold.
Current Implementations. Current Implementations.
Most BGP implementations support this capability. Most BGP implementations support this capability.
Considerations. Considerations.
None. None.
2.2.5. Ability to Cooperate in Outbound Route Filtering 2.2.5. Ability to Cooperate in Outbound Route Filtering
Capability. Capability.
A device provides the capability to allow operators to configure A device provides the capability to allow operators to configure
whether "Outbound Route Filtering"/ORF [17] are accepted from or whether Outbound Route Filtering/ORF defined in
sent to other peer routers. [I-D.ietf-idr-route-filter] are accepted from or sent to other
peer routers.
Supported Practices Supported Practices
"Outbound Route Filtering" defines a BGP mechanism to reduce the "Outbound Route Filtering" defines a BGP mechanism to reduce the
number of BGP updates between BGP peers. It will conserve the number of BGP updates between BGP peers. It will conserve the
resource in both sides of peers, since the BGP speaker will not resource in both sides of peers, since the BGP speaker will not
generate updates that will be filtered and the neighbor router generate updates that will be filtered and the neighbor router
will not process them as well. A router with limited resource may will not process them as well. A router with limited resource may
need this feature to prevent overfull routes from peers. need this feature to prevent overfull routes from peers.
skipping to change at page 10, line 21 skipping to change at page 10, line 9
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. Gateway Protocol or IGP) used within a routing domain.
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
therefore not appropriate. therefore not appropriate.
2.3.2. Route Filtering Between IGP Areas 2.3.2. Route Filtering Between IGP Areas
Capability. Capability.
The device provides the capability to allow the network operator The device provides the capability to allow the network operator
to configure route filters which restrict which routes (ie, to configure route filters which restrict which routes (i.e,
address prefixes) are advertised into areas from outside of the address prefixes) are advertised into areas from outside of the
area (ie, from other OSPF or IS-IS areas). area (i.e., from other OSPF or IS-IS areas).
Supported Practices. Supported Practices.
See Current Practices section 2.4.2. See section 2.4.2 of [RFC4778].
Current Implementations. Current Implementations.
TBD. Some OSPF/IS-IS implementations support this capability.
Considerations Considerations
If filters are used which restrict the passing of routes between If filters are used which restrict the passing of routes between
IGP areas, then this may result in some addresses being IGP areas, then this may result in some addresses being
unreachable from some other areas within the same routing domain. unreachable from some other areas within the same routing domain.
It is normal when passing routes into the backbone area (area It is normal when passing routes into the backbone area (area
O.0.0.0 in OSPF, or the level 2 backbone in IS-IS) for routes to 0.0.0.0 in OSPF, or the level 2 backbone in IS-IS) for routes to
be summarized, in the sense that multiple more specific (longer) be summarized, in the sense that multiple more specific (longer)
address prefixes that are reachable in an area may be summarized address prefixes that are reachable in an area may be summarized
into a smaller number of less specific (shorter) address prefixes. into a smaller number of less specific (shorter) address prefixes.
This provides important scaling improvements, but is generally not This provides important scaling improvements, but is generally not
primarily intended to aid in security and is therefore outside of primarily intended to aid in security and is therefore outside of
the scope of this document. the scope of this document.
2.4. Route Filtering during Redistribution 2.4. Route Filtering during Redistribution
Capability. Capability.
skipping to change at page 11, line 33 skipping to change at page 11, line 21
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 is always needed when routes redistributing between IGP Filters are always needed when routes redistributing between IGP
and BGP. For example, it is unfeasible to inject all internet and EGP. For example, it is infeasible to inject all Internet
routes from BGP to IGPs, since IGPs are not able to deal with such routes from EGP to IGPs, since IGPs are not able to deal with such
a 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. None.
3. Route Authentication Capabilities 3. Route Authentication Capabilities
3.1. Ability to configure an authentication mechanism 3.1. Ability to configure an authentication mechanism
Capabilities. Capabilities.
The device has one or more methods to allow the routing protocol The device has one or more methods to allow an authentication
to be configured an authentication mechanism (authentication keys mechanism to be configured for the routing protocol.
and authentication algorithms).
Supported Practices. Supported Practices.
See Current Practices section 2.4.2. See [RFC4778] section 2.4.2.
Current Implementations. Current Implementations.
RFC2385 [5] is deployed widely in BGP. Other routing protocols, [RFC2385] is deployed widely in BGP. Other routing protocols,
such as OSPF, adopt similar technology. such as OSPF, adopt similar technology.
Consideration. Consideration.
In most of current implementations, neither the authentication In most of current implementations, neither the authentication
mechanism nor key can be negotiated. An operator has to configure mechanism nor key can be negotiated. An operator has to configure
it manually, which will affect scalability. it manually, which will affect scalability.
To the date of writing this draft, MD5 is the only cryptographic As of this writing, MD5 is the only cryptographic hash function
hash function used in route authentication. However, recent used in route authentication. However, recent research revealed
research revealed weakness of MD5, which means stronger algorithms weakness of MD5, which means stronger algorithms are necessary.
are necessary.
3.2. Ability to support authentication key chains 3.2. Ability to support authentication key chains
Capabilities. Capabilities.
The device provides a key chain mechanism to update authentication The device provides a key chain mechanism to update authentication
keys of routing protocols. keys of routing protocols.
Supported Practices. Supported Practices.
Using a fixed authentication key is vulnerable to a compromise. A Using a fixed authentication key is vulnerable to a compromise. A
key chain is a series of keys which will be used in configured key chain is a series of keys which will be used in configured
time intervals. A device can transit keys based on system time time intervals. A device can transit keys based on system time
and configured key chain. In this way, it reduces possibility of and configured key chain. In this way, it reduces possibility of
leakage of an authentication key. leakage of an authentication key.
Current Implementations. Current Implementations.
This mechanism could be implemented in most routing protocols. This mechanism is implemented in most routing protocols.
Different vendors provide this feature in different routing Different vendors provide this feature in different routing
protocols, such as RIP, OSPF and BGP. protocols, such as RIP, OSPF and BGP.
Consideration. Consideration.
None. Since the rollover of the key is based on system time on different
routers, it requires clock synchronization across the routers.
4. Ability to Damp Route Flap 4. Ability to Damp Route Flap
Capability. Capability.
The device provides the capability to damp route flaps. The device provides the capability to damp route flaps.
Supported Practices. Supported Practices.
The function to damp route flaps may enhance the stability of The function to damp route flaps may enhance the stability of
routing system and minimize the influence of flapping. It is routing system and minimize the influence of flapping. It is
useful to counter against some DoS attacks. useful to counter against some DoS attacks.
Current Implementations. Current Implementations.
BGP RFD (Route Flap Damping) RFC2439 [6] defined the primary BGP RFD (Route Flap Damping) of [RFC2439] defines the primary
mechanism in BGP to mitigate the influence caused by flapping. mechanism in BGP to mitigate the influence caused by flapping.
Most of current BGP implementations support this capability. Most of current BGP implementations support this capability.
Other routing protocols may be vulnerable to route flaps as well. Other routing protocols may be vulnerable to route flaps as well.
Some vendors introduce SPF (shortest path first) algorithm timers Some vendors introduce SPF (shortest path first) algorithm timers
in OSPF to control parameters, such as the amount of minimal time in OSPF to control parameters, such as the amount of minimal time
between consecutive SPF calculations, which may be used to between consecutive SPF computations, which may be used to
mitigate excessive resource exhaustion caused by link flaps. mitigate excessive resource exhaustion caused by link flaps.
Consideration. Consideration.
MAO [19] described a flaw of current BGP RFD standard RFC2439, [MAO] described a flaw of current BGP RFD standard RFC2439, which
which shows that route flap damping could suppress relatively shows that route flap damping could suppress relatively stable
stable routes and affect routing convergence. routes and affect routing convergence.
Since none of vendors has corrected his BGP implementation, Since, at the time of this writing, no vendors are known to have
RIPE378 [20] proposes that, with the current implementations of fixed this problem, [RIPE378] proposes that, with the current
BGP flap damping, the application of flap damping in ISP networks implementations of BGP flap damping, the application of flap
is not recommended. damping in ISP networks is not recommended.
5. Resource Availability for Router Control Functions 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 such available for management functions. This may include such
skipping to change at page 16, line 39 skipping to change at page 16, line 20
that routers perform control plane processing and maintain state that routers perform control plane processing and maintain state
in response to data plane traffic. Also, the use of multicast in response to data plane traffic. Also, the use of multicast
implies that a single packet input into the network can result in implies that a single packet input into the network can result in
a large number of packets being delivered throughout the network. a large number of packets being delivered throughout the network.
Also, it is possible in some situations for a multicast traffic to Also, it is possible in some situations for a multicast traffic to
*both* enter a loop, and also be delivered to some destinations *both* enter a loop, and also be delivered to some destinations
(implying that many copies of the same packet could be delivered). (implying that many copies of the same packet could be delivered).
Current Implementations. Current Implementations.
TBD None.
Consideration. Consideration.
If the amount of resources used by multicast are not limited, then If the amount of resources used by multicast are not limited, then
it is possible during an attack for multicast to consume it is possible during an attack for multicast to consume
potentially as much as 100% of available memory, processing, or potentially as much as 100% of available memory, processing, or
bandwidth resources, thereby causing network problems. bandwidth resources, thereby causing network problems.
6. Security Considerations 6. Security Considerations
Security is the subject matter of this entire document. This Security is the subject matter of this entire document. This
document lists device capabilities intended to improve the ability of document lists device capabilities intended to improve the ability of
the network to withstand security threats. Operational Security the network to withstand security threats. Operational Security
Current Practices defines the threat model and practices, and lists Current Practices defines the threat model and practices, and lists
justifications for each practice. justifications for each practice.
7. Acknowledgements 7. IANA Considerations
This document has no actions for IANA.
8. Acknowledgements
The authors gratefully acknowledge the contributions of Ron Bonica, The authors gratefully acknowledge the contributions of Ron Bonica,
Ted Seely, Pat Cain, George Jones, and Russ White etc for their Ted Seely, Pat Cain, George Jones, and Russ White etc for their
contributed texts, useful comments and suggestions. contributed texts, useful comments and suggestions.
8. References 9. References
8.1. Normative References
[1] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 9.1. Normative References
environments", RFC 1195, December 1990.
[2] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
Attribute", RFC 1997, August 1996. dual environments", RFC 1195, December 1990.
[3] Fraser, B., "Site Security Handbook", RFC 2196, September 1997. [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996.
[4] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[6] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
Damping", RFC 2439, November 1998. Flap Damping", RFC 2439, November 1998.
[7] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[8] Killalea, T., "Recommended Internet Service Provider Security [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
Services and Procedures", BCP 46, RFC 3013, November 2000. November 1998.
[9] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL [RFC3013] Killalea, T., "Recommended Internet Service Provider
Security Mechanism (GTSM)", RFC 3682, February 2004. Security Services and Procedures", BCP 46, RFC 3013,
November 2000.
[10] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
(BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[11] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006. Communities Attribute", RFC 4360, February 2006.
8.2. Informative References 9.2. Informative References
[12] Jones, G., "Framework for Operational Security Capabilities for [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196,
IP Network Infrastructure", draft-ietf-opsec-framework-03 September 1997.
(work in progress), July 2006.
[13] Kaeo, M., "Operational Security Current Practices", [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
draft-ietf-opsec-current-practices-07 (work in progress), Security Mechanism (GTSM)", RFC 3682, February 2004.
August 2006.
[14] Morrow, C., "Filtering and Rate Limiting Capabilities for IP [RFC4778] Kaeo, M., "Operational Security Current Practices in
Network Infrastructure", draft-ietf-opsec-filter-caps-04 (work Internet Service Provider Environments", RFC 4778,
in progress), September 2006. January 2007.
[15] Bonica, R. and S. Ahmed, "Network Management Access Security [I-D.ietf-opsec-framework]
Capabilities", draft-ietf-opsec-nmasc-00 (work in progress), Jones, G., "Framework for Operational Security
March 2006. Capabilities for IP Network Infrastructure",
draft-ietf-opsec-framework-05 (work in progress),
April 2007.
[16] Callon, R. and G. Jones, "Miscellaneous Capabilities for IP [I-D.ietf-opsec-filter-caps]
Network Infrastructure", draft-ietf-opsec-misc-cap-00 (work in Morrow, C., "Filtering and Rate Limiting Capabilities for
progress), February 2006. IP Network Infrastructure",
draft-ietf-opsec-filter-caps-06 (work in progress),
April 2007.
[17] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability [I-D.ietf-idr-route-filter]
for BGP-4", draft-ietf-idr-route-filter-16 (work in progress), Chen, E. and Y. Rekhter, "Outbound Route Filtering
September 2006. Capability for BGP-4", draft-ietf-idr-route-filter-16
(work in progress), September 2006.
[18] IANA, "INTERNET PROTOCOL V4 ADDRESS SPACE", 2006. [IANA] IANA, "INTERNET PROTOCOL V4 ADDRESS SPACE",
http://www.iana.org/assignments/ipv4-address-space , 2007.
[19] Mao, Z., Govindan, R., Varghese, G., and R. Katz, "Route Flap [MAO] Mao, Z., Govindan, R., Varghese, G., and R. Katz, "Route
Damping Exacerbates Internet Routing Convergence", 2002. Flap Damping Exacerbates Internet Routing Convergence",
Sigcomm , 2002.
[20] RIPE, "Recommendations on Route-flap Damping", May 2006. [RIPE378] RIPE, "Recommendations on Route-flap Damping", RIPE ,
May 2006.
Authors' Addresses Authors' Addresses
Zhao Ye Zhao Ye
Huawei Technologies Huawei Technologies
No. 3, Xinxi Rd No. 3, Xinxi Rd
Shangdi Information Industry Base Shangdi Information Industry Base
Haidian District, Beijing 100085 Haidian District, Beijing 100085
P. R. China P. R. China
 End of changes. 72 change blocks. 
159 lines changed or deleted 149 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/