One document matched: draft-ietf-opsec-routing-capabilities-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY rfc1195 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1195.xml">
<!ENTITY rfc1997 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1997.xml">
<!ENTITY rfc2328 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml">
<!ENTITY rfc2385 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2385.xml">
<!ENTITY rfc2439 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2439.xml">
<!ENTITY rfc2453 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2453.xml">
<!ENTITY rfc3013 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3013.xml">
<!ENTITY rfc4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY rfc4360 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4360.xml">
<!ENTITY __reference.RFC.2196__ez0kshs9 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2196.xml">
<!ENTITY __reference.RFC.3682__ez0ksxp6 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3682.xml">
<!ENTITY __reference.RFC.4778__ez0kt53o SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4778.xml">
<!ENTITY FILTER SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-opsec-filter-caps.xml">
<!ENTITY ORF SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-route-filter.xml">
]>
<!-- may be omitted for very short documents -->
<?rfc toc="yes"?>
<!-- these two save paper: start new sections from the same page etc. -->
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!-- other categories: bcp, exp, historic, std -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<rfc category="bcp" docName="draft-ietf-opsec-routing-capabilities-03.txt"
ipr="full3978">
<front>
<title abbrev="routing-capabilities">Routing Control Plane Security
Capabilities</title>
<author fullname="Zhao Ye" initials="Y." surname="Zhao">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>No. 3, Xinxi Rd</street>
<street>Shangdi Information Industry Base</street>
<city>Haidian District</city>
<region>Beijing</region>
<code>100085</code>
<country>P. R. China</country>
</postal>
<email>ye.zhao_ietf@hotmail.com</email>
</address>
</author>
<author fullname="Miao Fuyou" initials="F.Y." surname="Miao">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>No. 3, Xinxi Rd</street>
<street>Shangdi Information Industry Base</street>
<city>Haidian District</city>
<region>Beijing</region>
<code>100085</code>
<country>P. R. China</country>
</postal>
<phone>+86 10 8288 2008</phone>
<email>miaofy@huawei.com</email>
</address>
</author>
<author fullname="Ross W. Callon" initials="R." surname="Callon">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford, MA</city>
<code>01886</code>
<country>USA</country>
</postal>
<email>rcallon@juniper.net</email>
</address>
</author>
<date day="15" month="June" year="2007" />
<area>Security</area>
<workgroup>OPSEC Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>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, for authentication of routing protocol
packets, and for ensuring resource availability for control
functions.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document is defined in the context of <xref format="default"
target="RFC4778">Operational Security Current Practices in Internet
Service Provider Environments, </xref>.</t>
<t>This document lists the security capabilities needed for the routing
control plane of IP infrastructure to support the practices defined in
<xref format="default" target="RFC4778"></xref>. In particular this
includes capabilities for route filtering and for authentication of
routing protocol packets.</t>
<t>Note that this document lists capabilities that can reasonably be
expected to be currently deployed in the context of existing standards.
Extensions to existing protocol standards and development of new
protocol standards are outside of the scope of this effort. The
preferred capabilities needed for securing the routing infrastructure
may evolve over time.</t>
<t>There will be other capabilities which are needed to fully secure a
router infrastructure. <xref format="default" target="RFC4778"></xref>
defines the goals, motivation, scope, definitions, intended audience,
threat model, potential attacks and give justifications for each of the
practices.</t>
<section title="Threat model">
<t>The capabilities listed in this document are intended to aid in
preventing or mitigating the threats outlined in <xref
format="default" target="RFC4778"></xref>.</t>
</section>
<section title="Format and Definition of Capabilities">
<t>Each individual capability will be defined using the four elements,
"Capability", "Supported Practices", "Current Implementations", and
"Considerations". The Capability section describes a feature to be
supported by the device. The Supported Practice section cites
practices described in [RFC4778] that are supported by this
capability. The Current Implementation section is intended to give
examples of implementations of the capability, citing technology and
standards current at the time of writing. It is expected that the
choice of features to implement the capabilities will change over
time. The Considerations section lists operational and resource
constraints, limitations of current implementations, and
trade-offs.</t>
</section>
<section title="Packet Filtering versus Route Filtering">
<t>It is useful to make a distinction between Packet Filtering versus
Route Filtering.</t>
<t>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. In general packet filters are based on contents of the network
(IP) and transport (TCP, UDP) layers, and are mostly stateless, in the
sense that whether or not a filter applies to a particular packet is a
function of that packet (including the contents of IP and transport
layer headers, size of packet, incoming interface, and similar
characteristics), but does not depend upon the contents of other
packets which might be part of the same stream (and thus which may
also be forwarded by the same router). One common minor exception to
the "stateless" nature of packet filters is that packets that match a
particular filter may be counted and/or rate limited (the act of
counting therefore represents a very simple "state" associated with
the filter).</t>
<t>Because of the simplicity and stateless nature of packet filters,
they can typically be implemented with very high performance. It is
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
counter very high bandwidth attacks, such as large DDoS attacks.</t>
<t>Packet filtering capabilities are outside of the scope of this
document. A detailed description of packet filtering capabilities can
be found in <xref target="I-D.ietf-opsec-filter-caps"> </xref>.</t>
<t>The Term "route filter" is used to refer to filters that routers
apply to the content of routing protocol packets that they are either
sending or receiving. Typically these therefore occur at the
application layer (although which route filters are applied to a
particular packet may be a function of network layer information, such
as what interface the packet is received on, or the source address for
the packet -- indicating the system that transmitted the packet).</t>
<t>Route filters are typically implemented in some sort of processor.
In many cases the total bandwidth which can be received by the
processor is considerably less than the sum of the rate that packets
may be received on all interfaces to a router. Therefore in general
route filters cannot handle the same bandwidth as packet filters.
Route filters are however very useful in that they can be applied to
the contents of routing packets.</t>
</section>
</section>
<section title="Route Filtering Capabilities">
<section title="General Route Filtering Capabilities">
<section title="Ability to Filter Inbound or Outbound Routes">
<t>Capability.<list style="empty">
<t>The device provides the ability to filter which routes may be
received with <xref target="RFC4271"> </xref>, as well as the
ability to filter which routes are announced into each routing
protocol.</t>
</list></t>
<t>Supported Practices.<list style="empty">
<t>See section 2.4.2 of <xref target="RFC4778"></xref>.</t>
<t>It is a beneficial practice to configure routing filters in
both directions, which will counter potential misconfiguration
in either peer. Also, incoming route filters will prevent a
deliberate attacker from injecting invalid routing
information.</t>
</list></t>
<t>Current Implementations.<list style="empty">
<t>The unicast routing protocols used with IP can be classified
into path vector routing protocols (such as BGP), distance
vector protocols (such as <xref target="RFC2453"> </xref>) and
link state protocols (such as <xref target="RFC2328"></xref> and
<xref target="RFC1195"></xref>). Because of differences in the
protocols, route filters will affect them in different ways.</t>
<t>Take BGP for example, an implementation may check a received
route against inbound filters to determine whether to install it
into the overall route table or not. Also, it will restrict the
routes which will go out to neighbors against outbound route
filters.</t>
<t>However, as to link state protocols, such as OSPF, a router
maintains a topology database and exchanges link state
information with neighbors. Since route filters do not influence
the link state database, route filters will only affect which
routes are advertised into the routing protocol. That is to say,
only inbound route filters are effective on link state
protocols.</t>
<t>Most of the routing protocols support methods to configure
route filters which permit or deny learning or advertising of
specific routes.</t>
</list></t>
<t>Considerations.<list style="empty">
<t>None.</t>
</list></t>
</section>
<section title="Ability to Filter Routes by Prefix">
<t>Capability.<list style="empty">
<t>The device supports filtering routes based on prefix.</t>
</list></t>
<t>Supported Practices.<list style="empty">
<t>See section 2.4.2 of <xref target="RFC4778"></xref>.</t>
</list></t>
<t>Current Implementations.<list style="empty">
<t>The filter may include a list of specific prefixes to be
accepted or rejected. The filter may alternately include a list
of prefixes, such that more specific (longer) prefixes, which
are included in the more inclusive (shorter) prefix, are
accepted, rejected, or summarized into the shorter prefix.</t>
</list></t>
<t>Considerations.<list style="empty">
<t>Operators may wish to ignore advertisements for routes to
specific addresses, such as private addresses, reserved
addresses and multicast addresses, etc. The up-to-date
allocation of IPv4 address space can be found in <xref
target="IANA"></xref>.</t>
</list></t>
</section>
</section>
<section title="Route Filtering of Exterior Gateway Protocol">
<t>An exterior gateway protocol is used to exchange external routing
information between different autonomous systems. Since BGP is the
most widely used protocol, this section mainly depicts special routing
filter capabilities of BGP.</t>
<section title="Ability to Filter Routes by Route Attributes">
<t>Capability.<list style="empty">
<t>The device supports filtering routing updates by route
attributes.</t>
</list></t>
<t>Supported Practices.<list style="empty">
<t>See <xref target="RFC3013"></xref> , section 3.2 of<xref
target="RFC2196"> </xref> and section 2.4.2 of <xref
target="RFC4778"></xref>.</t>
</list></t>
<t>Current Implementations.<list style="empty">
<t>In comparison with other routing protocols, BGP defines
various path attributes to describe characteristics of routes.
Besides filtering by specific prefixes, BGP also provides
capability to use some path attributes to precisely filter
routes to determine whether a route is accepted from or sent to
a neighboring router.</t>
<t>These filters may be based upon any combination of route
attributes, such as: <list style="symbols">
<t>Restrictions on the Content of AS_PATH. Restrictions on
the contents of the AS PATH are frequently used: for
example, the received AS_PATH may be checked to ensure the
sending AS is actually contained in the received
AS_PATH.</t>
<t>Restrictions on Communities. Implementations could filter
received routes based on the set of communities <xref
target="RFC1997"></xref> or extended communities <xref
target="RFC4360"> </xref>.</t>
</list></t>
</list></t>
<t>Considerations.<list style="empty">
<t>None.</t>
</list></t>
</section>
<section title="Ability to Filter Routing Update by TTL">
<t>Capability.<list style="empty">
<t>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 field in the IPv6 header.</t>
<t>Note that <xref target="I-D.ietf-opsec-filter-caps"> </xref>
specifies:</t>
<t>Capability.<list style="empty">
<t>The filtering mechanism supports filtering based on the
value(s) of any portion of the protocol headers for IP,
ICMP, UDP and TCP.</t>
</list></t>
<t>The ability to filter based on TTL is therefore a packet
filtering capability which is already implicitly covered by the
capabilities listed in Filtering Capabilities. Since this
capability is particularly important for BGP, we felt that it is
worth mentioning here.</t>
</list></t>
<t>Supported Practices.<list style="empty">
<t>See <xref target="RFC4778"> </xref> section 2.4.2 and <xref
target="RFC3682"></xref>.</t>
</list></t>
<t>Current Implementations.<list style="empty">
<t>Most current BGP implementations support this capability to
protect BGP sessions.</t>
</list></t>
<t>Considerations.<list style="empty">
<t>There will be situations in which the distance to the
neighboring router is more than one hop away. This for example
is common for I-BGP.</t>
</list></t>
</section>
<section title="Ability to Limit the Number of Routes from a Peer">
<t>Capability.<list style="empty">
<t>The device should provide a means to configure the maximum
number of routes (prefixes) to accept from a peer.</t>
</list></t>
<t>Supported Practices.<list style="empty">
<t>Both routing policy misconfiguration and a deliberate attack
from a peer may cause too many routes to be sent to a peer which
may exhaust the memory resources of the router, introduce
routing instability into the overall routing table, or both.
Therefore, operators may want to restrict the amount of routes
received from a particular peer router through a maximum prefix
limitation approach.</t>
</list></t>
<t>Current Implementations.<list style="empty">
<t>Most BGP implementations support this capability. If too many
routes are sent, then the router may reset the BGP session or
may reject excess routes. In either case the device may log the
failure event (at a minimum), or shut down the BGP session.</t>
</list></t>
<t>Considerations.<list style="empty">
<t>Operators must be cognizant of the need to allow for valid
swings in routing announcements between themselves, and as such
should always set the max-prefix limit to some agreed upon
number plus a sane amount for overhead to allow for these
necessary announcement swings. Individual implementations
amongst ISPs are unique, and depending on equipment supplier(s)
different implementation options are available. Most equipment
vendors offer implementation options ranging from just logging
excessive prefixes being received to automatically shutting down
the session. If the option of reestablishing a session after
some pre-configured idle timeout has been reached is available,
it should be understood that automatically reestablishing the
session may continuously introduce instability into the overall
routing table if a policy misconfiguration on the adjacent
neighbor is causing the condition. If a serious misconfiguration
on a peering neighbor has occurred then automatically shutting
down the session and leaving it shut down until being manually
cleared is perhaps best and allows for operator intervention to
correct as needed.</t>
</list></t>
</section>
<section title="Ability to Limit the Length of Prefixes">
<t>Capability.<list style="empty">
<t>The device has the capability to allow filtering of route
updates by prefix length.</t>
</list></t>
<t>Supported Practices.<list style="empty">
<t>Some large ISPs declare in their peer BGP policies that they
will not accept the announcements whose prefix length is longer
than a specific threshold.</t>
</list></t>
<t>Current Implementations.<list style="empty">
<t>Most BGP implementations support this capability.</t>
</list></t>
<t>Considerations.<list style="empty">
<t>None.</t>
</list></t>
</section>
<section title="Ability to Cooperate in Outbound Route Filtering">
<t>Capability.<list style="empty">
<t>A device provides the capability to allow operators to
configure whether Outbound Route Filtering/ORF defined in <xref
target="I-D.ietf-idr-route-filter"> </xref> are accepted from or
sent to other peer routers.</t>
</list></t>
<t>Supported Practices<list style="empty">
<t>"Outbound Route Filtering" defines a BGP mechanism to reduce
the number of BGP updates between BGP peers. It will conserve
the resource in both sides of peers, since the BGP speaker will
not generate updates that will be filtered and the neighbor
router will not process them as well. A router with limited
resource may need this feature to prevent overfull routes from
peers.</t>
</list></t>
<t>Current Implementations.<list style="empty">
<t>ORF may be based on prefix, path attributes. Currently, most
implementations support prefix-based ORF.</t>
</list></t>
<t>Considerations.<list style="empty">
<t>None.</t>
</list></t>
</section>
</section>
<section title="Route Filtering of Interior Gateway Protocols">
<t>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.</t>
<section title="Route Filtering Within an IGP Area">
<t>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
therefore not appropriate.</t>
</section>
<section title="Route Filtering Between IGP Areas">
<t>Capability.<list style="empty">
<t>The device provides the capability to allow the network
operator to configure route filters which restrict which routes
(i.e, address prefixes) are advertised into areas from outside
of the area (i.e., from other OSPF or IS-IS areas).</t>
</list></t>
<t>Supported Practices.<list style="empty">
<t>See section 2.4.2 of <xref target="RFC4778"> </xref>.</t>
</list></t>
<t>Current Implementations.<list style="empty">
<t>Some OSPF/IS-IS implementations support this capability.</t>
</list></t>
<t>Considerations<list style="empty">
<t>If filters are used which restrict the passing of routes
between IGP areas, then this may result in some addresses being
unreachable from some other areas within the same routing
domain.</t>
<t>It is normal when passing routes into the backbone area (area
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)
address prefixes that are reachable in an area may be summarized
into a smaller number of less specific (shorter) address
prefixes. This provides important scaling improvements, but is
generally not primarily intended to aid in security and is
therefore outside of the scope of this document.</t>
</list></t>
</section>
</section>
<section title="Route Filtering during Redistribution">
<t>Capability.<list style="empty">
<t>The device provides a means to filter routes when distributing
them between routing protocols or between routing protocol
processes running in the single device.</t>
</list></t>
<t>Supported Practices.<list style="empty">
<t>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.</t>
<t>Filters are always needed when routes redistributing between
IGP and EGP. For example, it is infeasible to inject all Internet
routes from EGP to IGPs, since IGPs are not able to deal with such
a large number of routes.</t>
</list></t>
<t>Current Implementations.<list style="empty">
<t>Most implementations allow applying a filter based on a prefix
list to control redistribution.</t>
</list></t>
<t>Considerations<list style="empty">
<t>None.</t>
</list></t>
</section>
</section>
<section title="Route Authentication Capabilities">
<section title="Ability to configure an authentication mechanism">
<t>Capabilities.<list style="empty">
<t>The device has one or more methods to allow an authentication
mechanism to be configured for the routing protocol.</t>
</list></t>
<t>Supported Practices.<list style="empty">
<t>See <xref target="RFC4778"> </xref> section 2.4.2.</t>
</list></t>
<t>Current Implementations.<list style="empty">
<t><xref target="RFC2385"></xref> is deployed widely in BGP. Other
routing protocols, such as OSPF, adopt similar technology.</t>
</list></t>
<t>Consideration.<list style="empty">
<t>In most of current implementations, neither the authentication
mechanism nor key can be negotiated. An operator has to configure
it manually, which will affect scalability.</t>
<t>As of this writing, MD5 is the only cryptographic hash function
used in route authentication. However, recent research revealed
weakness of MD5, which means stronger algorithms are
necessary.</t>
</list></t>
</section>
<section title="Ability to support authentication key chains">
<t>Capabilities.<list style="empty">
<t>The device provides a key chain mechanism to update
authentication keys of routing protocols.</t>
</list></t>
<t>Supported Practices.<list style="empty">
<t>Using a fixed authentication key is vulnerable to a compromise.
A key chain is a series of keys which will be used in configured
time intervals. A device can transit keys based on system time and
configured key chain. In this way, it reduces possibility of
leakage of an authentication key.</t>
</list></t>
<t>Current Implementations.<list style="empty">
<t>This mechanism is implemented in most routing protocols.
Different vendors provide this feature in different routing
protocols, such as RIP, OSPF and BGP.</t>
</list></t>
<t>Consideration.<list style="empty">
<t>Since the rollover of the key is based on system time on
different routers, it requires clock synchronization across the
routers.</t>
</list></t>
</section>
</section>
<section title="Ability to Damp Route Flap">
<t>Capability.<list style="empty">
<t>The device provides the capability to damp route flaps.</t>
</list></t>
<t>Supported Practices.<list style="empty">
<t>The function to damp route flaps may enhance the stability of
routing system and minimize the influence of flapping. It is useful
to counter against some DoS attacks.</t>
</list></t>
<t>Current Implementations.<list style="empty">
<t>BGP RFD (Route Flap Damping) of <xref target="RFC2439"> </xref>
defines the primary mechanism in BGP to mitigate the influence
caused by flapping. Most of current BGP implementations support this
capability.</t>
<t>Other routing protocols may be vulnerable to route flaps as well.
Some vendors introduce SPF (shortest path first) algorithm timers in
OSPF to control parameters, such as the amount of minimal time
between consecutive SPF computations, which may be used to mitigate
excessive resource exhaustion caused by link flaps.</t>
</list></t>
<t>Consideration.<list style="empty">
<t><xref target="MAO"></xref> described a flaw of current BGP RFD
standard RFC2439, which shows that route flap damping could suppress
relatively stable routes and affect routing convergence.</t>
<t>Since, at the time of this writing, no vendors are known to have
fixed this problem, <xref target="RIPE378"> </xref> proposes that,
with the current implementations of BGP flap damping, the
application of flap damping in ISP networks is not recommended.</t>
</list></t>
</section>
<section title="Resource Availability for Router Control Functions">
<section title="Ensure Resources for Management Functions">
<t>Capability.<list style="empty">
<t>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 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.</t>
</list></t>
<t>Supported Practices.<list style="empty">
<t>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.</t>
</list></t>
<t>Current Implementations.<list style="empty">
<t>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 management functions in comparison with other
functions performed by the device, providing separate queues for
management traffic, use of operating systems or other methods that
partition resources between processes or functions, and so on.</t>
</list></t>
<t>Consideration.<list style="empty">
<t>Imagine a service provider with 1,000,000 DSL subscribers, most
of whom have no firewall protection. Imagine that a large portion
of these subscribers machines were infected with a new worm that
enabled them to be used in coordinated fashion as part of large
denial of service attack that involved flooding. It is entirely
possible that such an attack could in some cases cause processor
saturation or other internal resource saturation on routers
causing the routers to become unmanageable. A DoS attack against
hosts could therefore become a DoS attack against the network.</t>
<t>Guarantee of resources within an individual device is not a
panacea. Control packets may not make it across a saturated link.
This requirement simply says that the device should ensure
resources for management 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 remains manageable.</t>
</list></t>
</section>
<section title="Ensure Resources for Routing Functions">
<t>Capability.<list style="empty">
<t>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 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.</t>
</list></t>
<t>Supported Practices.<list style="empty">
<t>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
can cause the protocol to drop adjacencies and/or to send out
additional routing packets, potentially destabilizing the routing
protocol and/or adding to whatever congestion may be causing the
problem.</t>
</list></t>
<t>Current Implementations.<list style="empty">
<t>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.</t>
</list></t>
<t>Consideration.<list style="empty">
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section title="Limit Resources used by IP Multicast">
<t>Capability.<list style="empty">
<t>This capability specifies that some mechanism(s) is provided to
allow the control plane resources used by IP multicast, including
processing and memory, to be limited to some level which is less
than 100% of the total available processing and memory. In some
cases the maximum limit of resources used by multicast may be
configurable. Routers may also provide a mechanism(s) to allow the
amount of link bandwidth consumed by IP multicast on any
particular link to be limited to some level which is less than
100% of total available bandwidth on that link.</t>
</list></t>
<t>Supported Practices.<list style="empty">
<t>IP multicast has characteristics which may potentially impact
the availability of IP networks. In particular, IP multicast
requires that routers perform control plane processing and
maintain state in response to data plane traffic. Also, the use of
multicast implies that a single packet input into the network can
result in a large number of packets being delivered throughout the
network. Also, it is possible in some situations for a multicast
traffic to *both* enter a loop, and also be delivered to some
destinations (implying that many copies of the same packet could
be delivered).</t>
</list></t>
<t>Current Implementations.<list style="empty">
<t>None.</t>
</list></t>
<t>Consideration.<list style="empty">
<t>If the amount of resources used by multicast are not limited,
then it is possible during an attack for multicast to consume
potentially as much as 100% of available memory, processing, or
bandwidth resources, thereby causing network problems.</t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t>Security is the subject matter of this entire document. This document
lists device capabilities intended to improve the ability of the network
to withstand security threats. Operational Security Current Practices
defines the threat model and practices, and lists justifications for
each practice.</t>
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section title="Acknowledgements">
<t>The authors gratefully acknowledge the contributions of Ron Bonica,
Ted Seely, Pat Cain, George Jones, and Russ White etc for their
contributed texts, useful comments and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1195;
&rfc1997;
&rfc2328;
&rfc2385;
&rfc2439;
&rfc2453;
&rfc3013;
&rfc4271;
&rfc4360;
</references>
<references title="Informative References">
&__reference.RFC.2196__ez0kshs9;
&__reference.RFC.3682__ez0ksxp6;
&__reference.RFC.4778__ez0kt53o;
&FILTER;
&ORF;
<reference anchor="IANA">
<front>
<title>INTERNET PROTOCOL V4 ADDRESS SPACE</title>
<author>
<organization abbrev="IANA">IANA</organization>
</author>
<date year="2007" />
</front>
<seriesInfo name="http://www.iana.org/assignments/ipv4-address-space"
value="" />
<format target="http://www.iana.org/assignments/ipv4-address-space"
type="TXT" />
</reference>
<reference anchor="MAO">
<front>
<title>Route Flap Damping Exacerbates Internet Routing
Convergence</title>
<author fullname="Zhuoqing Morley Mao" initials="Z.Q." surname="Mao">
<organization abbrev=" "></organization>
</author>
<author fullname="Ramesh Govindan" initials="R." surname="Govindan">
<organization abbrev=" "></organization>
</author>
<author fullname="George Varghese" initials="G." surname="Varghese">
<organization abbrev=" "></organization>
</author>
<author fullname="Randy H. Katz" initials="R.H." surname="Katz">
<organization abbrev=" "></organization>
</author>
<date year="2002" />
</front>
<seriesInfo name="Sigcomm" value="" />
<format target="http://www.sigcomm.org/sigcomm2002/papers/routedampening.html"
type="TXT" />
</reference>
<reference anchor="RIPE378">
<front>
<title>Recommendations on Route-flap Damping</title>
<author>
<organization abbrev="RIPE">RIPE</organization>
</author>
<date month="May" year="2006" />
</front>
<seriesInfo name="RIPE" value="" />
<format target="http://www.ripe.net/ripe/docs/ripe-378.txt" type="TXT" />
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 20:38:35 |