One document matched: draft-puig-rpsec-generic-requirements-01.txt
Differences from draft-puig-rpsec-generic-requirements-00.txt
Network Working Group JJ. Puig
Internet-Draft E. Jones
Expires: April 23, 2004 D. McPherson
October 24, 2003
Security Requirements for Routing Protocols
draft-puig-rpsec-generic-requirements-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 23, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Routing protocols are subject to attacks that can harm individual
users or the network as a whole. This document provides a description
of basic security requirements for routing protocols and routing
systems.
Puig, et al. Expires April 23, 2004 [Page 1]
Internet-Draft Routing Protocols Security Requirements October 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. General Considerations . . . . . . . . . . . . . . . . . . . 6
2.1 High Level Requirements . . . . . . . . . . . . . . . . . . 6
2.2 Routing Protocols within Scope . . . . . . . . . . . . . . . 6
3. Threats Mitigation Rationale . . . . . . . . . . . . . . . . 7
3.1 Threats Elected for Mitigation . . . . . . . . . . . . . . . 7
3.2 Threats Put Aside . . . . . . . . . . . . . . . . . . . . . 7
4. Routing Functions Overview . . . . . . . . . . . . . . . . . 9
4.1 Routing Protocols Components . . . . . . . . . . . . . . . . 10
4.2 Routing Devices Components . . . . . . . . . . . . . . . . . 11
5. Routes Descriptions . . . . . . . . . . . . . . . . . . . . 12
6. Security Requirements . . . . . . . . . . . . . . . . . . . 13
6.1 Routing Control Plane . . . . . . . . . . . . . . . . . . . 13
6.2 Data Control Plane . . . . . . . . . . . . . . . . . . . . . 15
6.3 Transport Subsystem . . . . . . . . . . . . . . . . . . . . 16
6.4 Addressability . . . . . . . . . . . . . . . . . . . . . . . 17
6.5 Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Cryptographic Considerations . . . . . . . . . . . . . . . . 20
7.1 Basic Cryptographic Requirements . . . . . . . . . . . . . . 20
7.2 Cryptographic Keys Requirements . . . . . . . . . . . . . . 21
7.3 Performances . . . . . . . . . . . . . . . . . . . . . . . . 22
7.4 Use of Cryptography . . . . . . . . . . . . . . . . . . . . 23
7.5 Specific Considerations for External Gateway Protocols . . . 24
7.6 Specific Considerations for Link State Protocols . . . . . . 24
7.7 Specific Considerations for Distance Vectors Protocols . . . 25
7.8 Best Common Practices . . . . . . . . . . . . . . . . . . . 25
7.9 Currently Available Solutions . . . . . . . . . . . . . . . 25
8. Active Participation to Security . . . . . . . . . . . . . . 26
8.1 Checking . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.3 Reacting . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Local Resources Considerations . . . . . . . . . . . . . . . 28
9.1 Denial of Service Attakcks . . . . . . . . . . . . . . . . . 28
9.2 Hardware Resources . . . . . . . . . . . . . . . . . . . . . 28
9.3 Logic (Software) Resources . . . . . . . . . . . . . . . . . 30
10. Inter domain routing issues . . . . . . . . . . . . . . . . 32
10.1 Legitimacy . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.2 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.3 Agreements involving operators . . . . . . . . . . . . . . . 32
11. Security Considerations . . . . . . . . . . . . . . . . . . 33
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
Normative References . . . . . . . . . . . . . . . . . . . . 35
Informative References . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37
A. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 38
B. Protection achieved by the requirements . . . . . . . . . . 39
Puig, et al. Expires April 23, 2004 [Page 2]
Internet-Draft Routing Protocols Security Requirements October 2003
B.1 Protection from Threat Sources . . . . . . . . . . . . . . . 39
B.2 Protection from Threat Actions . . . . . . . . . . . . . . . 39
C. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41
D. Requirements Summary . . . . . . . . . . . . . . . . . . . . 42
E. Revision History . . . . . . . . . . . . . . . . . . . . . . 43
E.1 changes from
draft-ietf-rpsec-routing-security-requirements-00 . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . 44
Puig, et al. Expires April 23, 2004 [Page 3]
Internet-Draft Routing Protocols Security Requirements October 2003
1. Introduction
Routing protocols are subject to threats and attacks that can harm
individual users or the network as a whole [THREATS]. This document
provides a description of basic security requirements for routing
protocols and routing systems.
This work is designed to serve as reference material for current
routing protocols analysis, for extensions design, and as a guidance
for designing new, more secure, routing protocols and routing
systems.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].
Information about security terms is provided in [SEC-GLOSS].
In order to avoid confusion between user traffic forwarding and
routing traffic forwarding, in this document the former is performed
by ``forwarders'' and called ``forwarding'' while the latter is
performed by ``relays'' and called ``relaying''.
Additional terms are defined in acronyms section (Appendix A).
This document is organized as follows:
o Section 2 presents general considerations relative to the security
of routing protocols and routing systems, and routing protocols
categories within scope.
o Some threats defined in [THREATS] can be mitigated, others can
not. Section 3 is a rationale about threats elected for
mitigation.
o Section 4 presents a routing functions overview.
o Section 5 presents an overview of routes descriptions.
o Actual routing protocols security requirements are defined in
Section 6.
o Section 7 describes cryptographic considerations for routing
operations.
o Section 8 provides considerations regarding active behaviors of
routing devices in the overall security of the routing
negotiations.
Puig, et al. Expires April 23, 2004 [Page 4]
Internet-Draft Routing Protocols Security Requirements October 2003
o Section 9 addresses problems related to local resource exhaustion.
o Section 10 introduces the inter-domain puzzle.
o Appendix B explains how threats elected in Section 3 are actually
mitigated by requirements presented in Section 6.
o Appendix C gives examples.
o Appendix D is a summary of the requirements.
Puig, et al. Expires April 23, 2004 [Page 5]
Internet-Draft Routing Protocols Security Requirements October 2003
2. General Considerations
This section provides general considerations on the design of secure
routing protocols.
2.1 High Level Requirements
[OLD] Distribution of destination reachability information with the
required policy considerations (QoS, trusted route, etc.) is what is
expected from a routing protocol.
Routing protocols act as managers of a distributed database with very
quick synchronization times. They are responsible for distributing
information about reachability to destinations attached to the
network, and the distribution of policies about the available paths.
Reachability MUST be protected against unauthorized route deletions
and route additions. Note that these are high level operations;
aggregation, for instance, may result in the same consequences as
announcing new routes; so may the removal of some routing
information, and the policies attending that routing information.
Route attributes (path information, metrics, trusted entity for the
forwarding of specific traffics) SHOULD also be protected. From an
attacker perspective, modifying attributes in order to achieve a
precise goal may be more difficult than injecting an additional
route. Besides, routing protocols may benefit from protection of
routes and lack of protection of route attributes.
[TBD] We have to decide if route attributes require as much
protection as route existence, probably yes. Note that manipulation
of routes associated attributes may achieve the same effects as those
resulting from addition / deletion. May be we should insert the
final requirement decision in an appropriate section (likely,
specific considerations to LSPs and DVPs).
2.2 Routing Protocols within Scope
Currently, routing protocols addressed in this document are those
limited by the rpsec WG charter. This includes distance vectors
protocols and link-state protocols. We are also interested in the
dedicated use of such protocols for intra-domain and inter-domain
routing. Host-to-routers protocols are out of scope.
[TBD] We may need to add some verbosity level off the above ?
Puig, et al. Expires April 23, 2004 [Page 6]
Internet-Draft Routing Protocols Security Requirements October 2003
3. Threats Mitigation Rationale
This section describes which threats extracted from [THREATS] were
considered in establishing these security requirements. Some threats
were put aside because they were considered either not tractable or
not worthing an additional performance / complexity trade-off.
Knowledge of the limits of the requirements presented in this
document is essential.
3.1 Threats Elected for Mitigation
o Spoofing should be mitigated, and this was considered. However,
spoofing is closely tied to the concept of identity and this
identity is often also an address. Protection against address
spoofing requires extra care. [AH] may be seen as an instance of
a protocol with built-in address spoofing protection.
o Falsification is one of the most significant threats against
routing protocols. It is the main target of the requirements
presented in this document.
o Interference is only partly tractable: protection against replay
of out-dated packets, reaction to suspect slowdowns are possible.
However, there is little to nothing that can be done against a
subverted link or router which drop packets or receipts; only
fail-back procedures / redundant paths are applicable here.
o Overload protection requires appropriate design of both the
routing protocol and the routing device. Several sections of this
document bring further information about resources consumption and
exhaustion.
o Byzantine failure occurs when at least one authorized device get
subverted. Thus, many threats are also Byzantine failures. The
Byzantine general problem resolution is limited by hypotheses
which are reminded in this document.
3.2 Threats Put Aside
o Deliberate Exposure, provided that it is NOT also a falsification,
is put aside in this version of the document because it is
currently unclear under which circumstances such a threat may
happen and what is actually the value of the information exposed.
Lastly, it seems that there is little that can be done against
this.
o Sniffing is put aside because protection against it would involve
Puig, et al. Expires April 23, 2004 [Page 7]
Internet-Draft Routing Protocols Security Requirements October 2003
additional resources requirements on routing devices and
additional complexity, whether this would be built directly within
the routing protocol or not. For this version of the document,
authenticity and integrity of routing information got more concern
than it's confidentiality (confidentiality is a MAY).
o Traffic Analysis protection is difficult to achieve and requires a
general approach which cannot be limited to routing protocols
only. Note that an effective protection against traffic analysis
not only involves headers addresses camouflage, but also size and
intermediate times scrambling.
[TBD] Think about setting the confidentiality service as a MAY
requirement; confidentiality thwarts partly interest of exposing /
sniffing / analyzing traffic.
Puig, et al. Expires April 23, 2004 [Page 8]
Internet-Draft Routing Protocols Security Requirements October 2003
4. Routing Functions Overview
[TBD] For the very moment, what you can find here is merely a cut and
paste from the threat doc. The question is: do we really need this
section ? if yes, should we add / change things in the following ? I
suggest we start from this and specialize the description for
specific classes of routing protocols.
This section provides an overview of functions which can be found in
various routing protocols. Following sections may refer to this
description for the sake of an accurate description of some
considerations.
In general, routing protocols share the following functions:
o Transport Subsystem: The routing protocol transmits messages to
its neighbors using some underlying protocol. For example, OSPF
uses IP, while other protocols may run over TCP.
o Neighbor State Maintenance: neighboring relationship formation is
the first step for topology determination. For this reason,
routing protocols may need to maintain the state of their
neighbors. Each routing protocol may use a different mechanism
for determining its neighbors in the routing topology. Some
protocols have distinct exchange through which they establish
neighboring relationships, e.g., Hello exchanges in OSPF.
o Database Maintenance: Routing protocols exchange network topology
and reachability information. The routers collect this
information in routing databases with varying detail. The
maintenance of these databases is a significant portion of the
function of a routing protocol.
A router's functions can be divided into control and data plane
(protocol traffic vs. data traffic). In a similar fashion, a routing
protocol has a control and a data plane. A routing protocol has a
control plane that exchanges messages that are intended only for
control of the protocol state.
Routing protocol data plane uses messages to exchange information
that is intended to be used in the forwarding function. For example,
the information can be used to establish a forwarding table in each
router or to return a description of the route to be used.
Routing functions may affect the control and the data planes.
However, there may be an emphasis on one of the planes as opposed to
the other. For example, neighbor maintenance is likely to focus on
the routing protocol control plane, while database maintenance may
Puig, et al. Expires April 23, 2004 [Page 9]
Internet-Draft Routing Protocols Security Requirements October 2003
focus on the data plane.
[TBD] We should introduce the management plane somewhere !!!
4.1 Routing Protocols Components
[TBD] Honestly, I doubt the following is useful. Comments are welcome
on whether it actually is. If yes, we need advises on actual content.
4.1.1 IGP
IGPs functions are summarized by the above statements. Database
construction is achieved thanks to ``classical'' versions of route
computation algorithms.
4.1.2 EGP
Exterior gateway protocols historically embeds functional features
related to Neighbor Reachability and Network Reachability. These are
almost directly mapped to Neighbor State and Database Maintenance.
Other common functions may include:
o Decision: the process through which local network reachability
information is built from inbound updates received from peers.
The decision function is more specific than a simple route
computation algorithm in that it includes policies configuration
expressed through the management plane.
o Coherence: a EGP may implement a specific mechanism in order to
assert that external gateways from the same AS export coherent
pieces of information.
4.1.3 Link State
Link state protocols functions are achieved through periodic flooding
on unicast or multicast addresses.
4.1.4 Distance Vectors
Database Maintenance function of distance vectors protocols relies on
distributed algorithms. Communication with neighbors is commonly
achieved through broadcast.
4.1.5 Ad-Hoc
Routing protocols for Ad-Hoc Networks implement very specific
approaches of neighbors state and database maintenance. A significant
Puig, et al. Expires April 23, 2004 [Page 10]
Internet-Draft Routing Protocols Security Requirements October 2003
amount of topology knowledge may be acquired in a reactive fashion.
Updates at both control plane level and data plane level may require
either flooding on short periods or active demand.
Routing decisions may eventually be the result of a heuristic on
orthogonal requirements involving also QoS and power management.
Sometimes, multiple path to the same destination are recorded in the
database.
4.1.6 Multicast
[TBD] Is-it really useful a section ? Why did we put it in the first
place ?
Multicast provides an alternate way to address neighbors. Group
membership management relies on specific functions.
4.2 Routing Devices Components
[TBD]
Puig, et al. Expires April 23, 2004 [Page 11]
Internet-Draft Routing Protocols Security Requirements October 2003
5. Routes Descriptions
[TBD] The way routes are presented affects the overall security of
the routing protocol. We should develop on this. E.g. full path
description vs next hop.
Puig, et al. Expires April 23, 2004 [Page 12]
Internet-Draft Routing Protocols Security Requirements October 2003
6. Security Requirements
6.1 Routing Control Plane
6.1.1 Adjacency
Creation of an adjacency relation with a node SHOULD be completed
with the evidence that the peer actually owns the identifier he uses.
Protection of keep-alive messages against falsification and replay
MUST be provided.
[TBD] We need to develop on this !!!
6.1.2 The Byzantine Problem
TBD: presentation of the pb [BYZANTINE]. cf. the threats doc. Wait
until new threats doc evolution.
The following considerations should help in the design of a Byzantine
resistant (either through detection or through robustness) routing
protocol:
o Local instance of the protocol SHOULD NOT rely on correct
operation of a particular neighbor, and SHOULD always apply least
privilege. Only traffic source and destination should be
considered trustworthy.
o Messages MUST be authenticated when sent and checked for their
authenticity when received.
Note that detection and robustness properties are not necessarily
correlated.
6.1.2.1 General Requirements
TBD: explain here how hypothesis needed for tackling correctly the pb
(synchronization, topology considerations...) may be mapped on the
specific context of routing protocols.
Classical hypothesis for Byzantine failure resolution are:
o devices are fully connected,
o the decision that must be agreed upon is binary (yes/no),
o the network is synchronous,
Puig, et al. Expires April 23, 2004 [Page 13]
Internet-Draft Routing Protocols Security Requirements October 2003
o strictly less than a third of the devices are faulty.
Under these hypothesis, a distributed algorithm requires as many
rounds as the number of faults to be tolerated plus one.
Further information about distributed agreement can be found in
[CONSENSUS]. In the following, we will only focus on what makes the
problem tractable in IP networks.
The ability to send messages to all participants simultaneously (c.f.
Section 6.5) allow for simulation of both full connectivity and
synchronization. The fact that routing information is not a
agreeable binary decision has little consequences because agreement
is not an absolute requirement; see Section 6.1.2.4 and [BYZANTINE].
6.1.2.2 Detection of the Occurence of a Byzantine Failure
The protocol algorithm may detect incoherences within the correlated
routing information upon algorithm termination, abnormal attractive
cycles within routes computations, etc. These events may be symptoms
of a Byzantine failure occurring. More trivial evidences of a
possible Byzantine failure is when agreement, termination or validity
of the consensus cannot be achieved.
6.1.2.3 Byzantine Detection
Byzantine detection is much more precise than just detecting a
Byzantine failure and consist in the ability to find out which
participants are subverted. A part of inherent risk of Byzantine
detection is that when the number of traitors grow past a limit, it
may be difficult for a device to figure out which group is subverted.
Sometimes, the considered device may be itself -or conclude it is
itself- faulty.
Automatic responses following a Byzantine detection MUST NOT prevent
the subverted devices from participating again when they cease to
behave incorrectly. Forwarding options when dealing with a detected
subverted device are forwarding along an alternate route if available
(Detour), or forwarding anyway if not (Send & Hope). If only a part
of non faulty participants can achieve the detection then care should
be taken that detection's responses do not deceive non-detector
non-faulty devices (the former would appear faulty to the latter and
the situation would get worse). Simulating a link shutdown with a
subverted device can be investigated. Collaborative approach between
detectors to limit the influence of some subverted devices may be
quite hazardous.
Eventually, note that sharing symmetric material for partial
Puig, et al. Expires April 23, 2004 [Page 14]
Internet-Draft Routing Protocols Security Requirements October 2003
authentication between more than two devices would make Byzantine
detection impossible to achieve in most cases (and so would do the
absence of an authentication mechanism).
6.1.2.4 Byzantine Robustness
Purpose of Byzantine robustness, in the general problem context, is
for any given device to achieve algorithm termination, agreement and
-naturally- validity.
Routing protocols does NOT REQUIRE to achieve neither agreement nor
termination. What matters here is validity, with regard to the
requirements concerning reachability presented Section 2.1. This
manages opportunities for ``severed configurations'' in which some
policy requirements for a traffic could not be enforced though
reachability is still possible / probable.
6.2 Data Control Plane
6.2.1 Data Integrity / Source Authenticity
Messages at the data control plane MUST be protected agaisnt
unauthorized modifications. This implies that exchanges are protected
by a combination of authenticity, integrity and anti-replay
properties.
6.2.2 Legitimacy
Inbound data SHOULD be checked for it's legitimacy.
[TBD] One may investigate use of authorization tokens to do this.
Aggregation will certainly jeopardize such a property. Depending on
the bandwidth available, it may be possible to do without aggregation
for the exchanges (this does not imply that local forwarding table
may not aggregate entries).
6.2.3 Dampening mechanisms for DOS mitigation
The rates at which updates are accepted and probably unstable routes
are propagated MUST be limited.
Further information is available in [DAMPING].
6.2.4 Paths for addressing underclaiming/overclaiming
[TBD] We should remove this section. Protection against overclaiming
is partly addressed through legitimacy control (unless events like
Puig, et al. Expires April 23, 2004 [Page 15]
Internet-Draft Routing Protocols Security Requirements October 2003
aggregation happen). Underclaiming was discarded in the threat doc.
6.3 Transport Subsystem
The Transport Subsystem may already provide the following properties:
o [OLD] (The alternate version below (from Russ) is well formulated)
Neighborhood: a technology may provide a way to address adjacent
neighbors. The neighborhood range in this kind of technology is
typically of one system away and relies on direct mapping over
functions available from the Link Layer.
o Neighbors discovery and maintenance: A given Transport Subsystem
technology may provide a way to discover and communicate with
adjacent devices participating in the routing domain (neighbors).
o [OLD] Integrity: the Transport Subsystem may provide data
integrity. This is insufficient to achieve security without
proper means of authenticating the system which provided the
integrity proof in the first place.
o Integrity: While the Transport Subsystem chosen by the routing
protocol designer may provide error detection code, this does not
provide data integrity from a security point of view. The
Transport Subsystem may also provide data integrity which will
still be useless from a security perspective if the proof is
hop-by-hop or if the secret material used by the data integrity
service cannot be tied to the routing protocol participant
identity.
o Authenticity: if the underlying layer both provides authenticity
and integrity, many routing threats may be thwarted. Further
investigations are required though, among which are studies of
resistance to replay, performance, Byzantine detection and
robustness, etc. In such a case, the documentation of the routing
protocol MUST state which security properties are provided by the
Transport Layer, which are provided by the routing protocol design
and eventually how they interact.
o Separate control channel: if the underlying technology provides
separated channels for control traffic and user data traffic, this
may help against DOS against the routing protocol. Such control
channels may be provided via the same Link Layer infrastructure,
or perhaps via a distinct network.
Puig, et al. Expires April 23, 2004 [Page 16]
Internet-Draft Routing Protocols Security Requirements October 2003
6.3.1 Generic Requirements / Expectation
The choice of the Transport Subsystem for the routing protocol may
ease the requirements. Any routing protocol designed to run on a
specific Transport Subsystem MUST document or provide appropriate
references to the security properties provided by the Transport
Subsystem.
[TBD] A MUST sounds reasonable ?
A routing protocol designed to be, within a certain extent, Transport
Subsystem independent, may provide options to activate built-in
security features on-demand when security provided by a Transport
Subsystem is insufficient. Though such a flexibility would help
avoiding potential redundancy of functions with the Transport
Subsystem and adjusting performance requirements, such an approach is
usually not desirable because of it's added complexity and hazards
and because such a protocol can no longer be ``bridged'' between two
different Transport Subsystems without further processing.
[TBD] The above is complicated a bit. Who would do that anyway ? Do
we remove this ?
6.3.2 Layer 2
Layer two is limited to one (IP) system away. Addressing is available
in anycast, multicast and broadcast.
Some Layer 2 technologies are bundled with built-in cryptographic
protections. However, these are often unused because they require
extra management.
It is highly restrictive to build a routing protocol security upon
the use of a specific layer 2 technology. This greatly limits the
interest of deploying an instance of the protocol.
6.3.3 Layer 3
6.3.4 Layer 4
6.4 Addressability
6.4.1 Broadcast / Multicast
6.4.2 Ad-Hoc / Anycast
Puig, et al. Expires April 23, 2004 [Page 17]
Internet-Draft Routing Protocols Security Requirements October 2003
6.4.3 Unicast
6.5 Neighbors
Neighbors are the peers involved in routing operations which can be
reached within a maximum number of hops (according to the routing
protocol itself). Often, neighbors definition is limited to the
systems that are directly reachable through with the Link Layer,
regardless of the technology actually used for the Transport Layer of
the routing protocol.
There are several ways to ensure that the routing information
actually comes from a system within a max range. Note that this does
not prove that the message itself has been sent by the legitimate
system (for instance, it may be a replay from subverted link). It is
also possible to provide such a feature within the routing protocol.
From a service point of view, it is the original sender's goal to
limit the range of it's messages. From a security point of view, it
is the recipient's responsibility to CHECK that the message does not
come from outside the neighbors zone (e.g. : check use of limited
broadcast in destination address field). Use of the following
recipes should mirror both these concerns. Lastly, all of this only
provides topological protection if used alone.
6.5.1 Use of TTL
In IP packets, the TTL field being decreased by forwarders provides
an easy way in order to limit packets propagation. However, this does
not protect against outsiders, unless forwarders also act as relays,
check origin authenticity of old TTL and authenticate the newly
decreased value.
6.5.2 The TTL Hack
The TTL hack [BTSH] is a way to limit the range effect of routing
messages and to prevent intrusion in the neighborhood in IP networks.
By setting TTL to max value (255), neighbors can check that the
message comes from direct neighbors. Spoofed routing messages coming
from outside the neighborhood range will get their TTL decreased and
be rejected by the routing protocol participants. This does not
protect against insiders, nor against outsiders using tunnels to
carry engineered packets.
6.5.3 Link Layer
Direct use of the Link Layer instead of Network (IP) Layer for
communications of the routing protocol limits neighborhood
Puig, et al. Expires April 23, 2004 [Page 18]
Internet-Draft Routing Protocols Security Requirements October 2003
implicitly. In some cases (VLAN frame hopping, Wireless LANs), an
outsider may still break in the neighbors zone.
6.5.4 Limited Broadcast
Limited broadcast is a simple way to ensure contact with neighbors on
the local network when using a Transport Layer layered over IP.
Puig, et al. Expires April 23, 2004 [Page 19]
Internet-Draft Routing Protocols Security Requirements October 2003
7. Cryptographic Considerations
This section presents cryptographic requirements for routing
protocols.
7.1 Basic Cryptographic Requirements
The following requirements are understood on a producer / consumer of
the routing information basis. Relays which modify the content of
routing messages are considered both consumers and producers. Relays
which do not modify the content of routing messages act as
forwarders, are then considered neither producers nor consumers and
SHOULD NOT need to provide any of the following while acting as
forwarders.
o Integrity: data integrity between the producer and the consumer is
an obvious requirement. A checksum is not an integrity evidence.
Means to have data integrity are signed-hash and keyed-hash. Data
integrity is always closely related to authenticity (see below).
o Anti-replay: this comes here mainly for protection against active
attacks from subverted Links, though this feature will also
provide added protection against natural duplication of packets.
Note that underlying layers may provide an unauthenticated
anti-replay feature, which would be of no use from a security
point of view, unless it gets also authenticated at the pouting
protocol layer. Authentication of routing exchanges sequence
numbers may bring this protection to the protocol.
o Authentication: the above features are of no use without
authentication of the producer. Authenticating correctly the
messages sent from neighbors is the most important security
requirement for a routing protocol. Authentication techniques
that should be considered currently are: digital signature, keyed
hash.
o [TBD] Is it also important to authenticate the consumer ? In some
protocols, peers may establish sessions in which both are
alternatively producer and consumer. In the case such a
`symmetric' rule does not apply, is there a need to authenticate
the consumer or to make sure that only he can access the
information ? Should the consumer acknowledge the reception ?
Should the acknowledgement be authenticated ?
There have been considerations of confidentiality as a mean to
counter disclosure of network topology. The gains from such a
feature are not obvious, especially because traffic analysis of
forwarded data may provide the topology disclosure, and also because
Puig, et al. Expires April 23, 2004 [Page 20]
Internet-Draft Routing Protocols Security Requirements October 2003
public information may be required in order to prove the legitimacy
of routers for announcing or owning routes or prefixes. Besides, this
involves additional performance issues and negotiations which are not
particularly desirable. Providing confidentiality is NOT REQUIRED.
If such a feature is available, it SHOULD be possible to enable /
disable it.
[TBD] Although perhaps confidentiality is more important than
supposed here. Comments ? Topology disclosure may be a more
significant threat for applications than for routing. Should the
routing protocol protect an information that could be used to attack
another protocol ? Is topology disclosure eventually a significant
threat for the routing protocol itself ?
7.2 Cryptographic Keys Requirements
Key management involves several considerations, and routing protocols
involve several interconnected devices, which may be the properties
of distinct organizations. A routing protocol design should analyze
scaling issues; within this context, Public key cryptography is
currently the most appropriate paradigm.
7.2.1 Public Key Cryptography
[TBD] Disclaimer: I'm not sure this section is useful at all, unless
we go in further details ? How far can we go in this specification ?
e.g., Is it suitable to name protocol fields, and to set specific
protection to these ?
Public key cryptography is traditionally associated with drawbacks
such as administration, deployment, reachability, caching.
o Administration cannot be avoided. Because routing devices may not
belong to the same organizations, a kind of trusted third party
must exist to tie identities, public keys and possibly other
contents like suitable addresses or legitimacy to advertise routes
or originate prefixes.
o Deployment is mainly a scaling issue. Temptation is great to rely
upon a mechanism that (almost) succeeded in scaling (DNS, or the
routing network itself). On the other hand, care should be taken
not to misuse or overload these mechanisms. Correlation of such a
mechanism with the routing protocol may lead to easy denials of
service or other attacks that MUST be studied.
o Reachability of the public key information is REQUIRED. This may
be done in-band within the routing protocol, or through a
stand-alone protocol. In the latter case, specific consideration
Puig, et al. Expires April 23, 2004 [Page 21]
Internet-Draft Routing Protocols Security Requirements October 2003
occurs regarding availability of the service under high traffic or
when either forwarding or relaying are severed. Reachability is
useful in order to retrieve keys, but also for revocation checking
or roll-overs.
o Caching should be considered for deployment, reachability and
performance. On the other hand, it jeopardizes revocation of keys
or roll-over. Eventually, authorizations or public material of
the same kind may be kept in a non-volatile storage.
7.2.2 Crypto-hygiene
Limiting key lifetime and refreshing them is good cryptographic
hygiene. Therefore, a mechanism to roll-over keys is REQUIRED both
for public keys and for session keys; Public keys roll-over may not
require a soft transition, while refreshing session keys may require
to move from the old key to the new one with no session interruption.
Lifetime MUST be evaluated both in terms of time and of amount of
data.
7.2.3 Key Strength
[TBD] Give correct lifetime for keys, in years against mips ? Is
there a reference document on this topic ? What about: "m years after
the standardization of the routing protocol, the keying material
should resist n years against p top performance key cracking devices"
?
Strength of public keys should be high. Changing these keys may be
administratively heavy if they are used in EGPs. Besides, a third
party may not emerge if keys have a short lifetime. In IGPs,
strength of these keys should not be that high, though this mainly
depends on internal administration tasks scheduling. It is acceptable
to tear down sessions between routing protocol participants when the
public material is changed.
Strength of symmetric keys does not require to be high: refresh may
happen during low traffic periods (if they exist; if they do not, a
suitable heuristic SHOULD enforce the refresh at an appropriate
time), and verification must be fast. These keys SHOULD be used only
as a fast authentication schemes and the refresh SHOULD NOT result in
torn down sessions.
7.3 Performances
Device resources (CPU, memory) might be overloaded by cryptographic
operations, especially by public key computations. These performance
Puig, et al. Expires April 23, 2004 [Page 22]
Internet-Draft Routing Protocols Security Requirements October 2003
issues should be taken into account when designing a routing
protocol, otherwise they would open the device to other forms of
attacks (denials / degradations of service) that will result in the
same consequences as attacks against routing operations. Performance
evaluation often requires hypothesis on the underlying hardware,
which is somewhat restricting.
When possible, methods to derive a symmetric key from public
exponents should be used, given that the symmetric cryptography
operations considered are less computationally expensive. Caution
should be taken if the number of devices sharing the same symmetric
key is greater than two.
There had been several discussions on the use of a token based fast
rejection scheme, which could be embedded on interfaces of the
devices. Such a scheme would protect against a category of denials
of service in which malign traffic gets in at a high rate. The
management of such a scheme may require a stand-alone protocol and
raises issues when neighbors communicate through several interfaces.
[TBD] Should we develop on other token-based schemes ? How about
building interface dependent token chains when packets / frames are
unicast ? This seems a bit tricky to achieve and would grow in
square(n interfaces). How about a less efficient approach where the
tokens would be checked by the core CPU ? This would infer a little
delay during normal service, but under attack this may avoid
computation of HMAC or DSIG. Is it acceptable to derive a token
chain seed and a session key from only one shared secret material ?
BTW, can the token provide the anti-replay feature if it is added
within an HMAC computation (this, to save space) ? If so, is it still
applicable when the tokens seed and the HMAC secret are derived from
the same material ? Lastly, how about a 'reject with a cookie /
re-request with cookie approach ?
Neighbors authorizations and public materials may be stored in
non-volatile storage. Note that there may exist no route to get this
material after a reboot. However, the routing protocol itself may
also assume in-band provisioning of public material.
[TBD] Does in-band provisioning open a path for resources exhaustion
? Considerations of which other data should be stored in non-volatile
storage ?
Considerations regarding caching are presented in Section 7.2.1.
7.4 Use of Cryptography
[TBD] This section should explain how the above cryptography
Puig, et al. Expires April 23, 2004 [Page 23]
Internet-Draft Routing Protocols Security Requirements October 2003
considerations will help countering common threats. It may be wise
to wait for the next version of the threat draft before going
further. Details are currently rejected in appendix.
Correct use of anti-replay, integrity and authentication should
suffice to protect against deception or usurpation damages resulting
from subverted links or devices (as long as the secret materials are
unavailable to the attacker).
This will be insufficient to prevent disclosure or disruption.
[TBD] Do we need to prevent disclosure anyway ?
Subverted routers which are still authorized participants (that is:
subverted routers owning the suitable material) in the routing
protocol, will be able to process with attacks resulting in all of
these damages. Further protection requires a registry stating
authorizations for the routing devices to be available, in order to
enforce least privileges to the subverted device. This information
would be authenticated by an adequate entity.
Appendix B.1 and Appendix B.2 details which and how threats mentioned
in [THREATS] are thwarted by the requirements presented in this
document.
The following sections present additional guidance for the specific
classes a routing protocol belongs to.
7.5 Specific Considerations for External Gateway Protocols
[TBD] Extract from Russ comments: I think you can mention this, but
it's actually going to be difficult to impossible to find any way of
securing policies within an EGP. Since each administrative domain can
add policies to a given route, anyone can essentially insert any
policy. The question: "Who's policy are we honoring" has to be
answered before we can begin to think about this. The originator's
policy? Or the AS we received the route from? Or the AS that
currently has the route? Or some other AS?
Related considerations:
7.6 Specific Considerations for Link State Protocols
[TBD] Are there such considerations ? May be we should design dummy
protocols to be more explicit or set up a high level division of RPs
features.
Puig, et al. Expires April 23, 2004 [Page 24]
Internet-Draft Routing Protocols Security Requirements October 2003
7.7 Specific Considerations for Distance Vectors Protocols
Distance vector routing protocols are specific because participants
are required to adjust the properties of routes announced by other
participants.
[TBD] Present appropriate protection of attributes. The originator
may authenticate the initial information, and relays may stack in
authenticated costs adjustments, route characteristics updates, etc.
[SMITH]. We have to decide whether trace-ability of distance
adjustments is critical security feature or not.
7.8 Best Common Practices
7.9 Currently Available Solutions
Puig, et al. Expires April 23, 2004 [Page 25]
Internet-Draft Routing Protocols Security Requirements October 2003
8. Active Participation to Security
Topics presented within this section may not be directly tied to the
protocol design. However, it addresses several local considerations
that are requirements for a secure operation of the routing protocol
and of the device it is running on.
8.1 Checking
A routing device may be configured to run extra checks on the routing
state, like checking databases against previous information. Some
active tests may also be triggered: sending source routed ICMP
packets, etc. Such tests may also involve the neighbors. High
caution should be taken regarding implementation of such features and
they should not jeopardize the routing protocol mechanisms.
8.1.1 Passively
8.1.2 Actively
(quantity a/o quality)
8.2 Reporting
8.2.1 Error Messages
8.2.2 Auditable Events
The following events should be audited:
1. Authentication failure
2. Required public information (keys, authority) is not available
3. Errors reported by forwarders
4. Detection of a Byzantine event
5. Detection of a rebooting peer
[TBD] The above has nothing to do with routing. Or has-it ? Should
the protocol automate detect and act according to the detection of
these events ?
8.3 Reacting
Puig, et al. Expires April 23, 2004 [Page 26]
Internet-Draft Routing Protocols Security Requirements October 2003
8.3.1 Routing Databases
8.3.1.1 Graceful degradation
8.3.1.2 Fail-back Procedures
When detecting obvious routing misbehavior which result from misuse
of the routing protocol, but when sources responsible for this
misbehavior cannot be identified (no Byzantine detection), fail-back
procedures may be attempted, based on previous recorded states,
fail-safe states or heuristics on the routing information and on
trust. Degradation of the service should often be better than no
service at all, thus the device may adjust local route costs
information when such events occur. The routing protocol design may
document guidelines and requirements on such procedures.
Network management must be able to install unalterable (static)
routes to allow debugging network problems without interference from
routing protocols.
8.3.2 Filtering
Ingress Filtering, participant exclusion.
A routing device MAY be set to drop/reject routing messages if these
are incorrect with current configuration of the network, e.g. if
they do not belong to the correct range of the IGP, etc.
Note that this protection is topological and partial. Extreme care
should be taken not to jeopardize correct behavior of the protocol.
8.3.3 Correcting
Correcting wrong / malicious routing info
Puig, et al. Expires April 23, 2004 [Page 27]
Internet-Draft Routing Protocols Security Requirements October 2003
9. Local Resources Considerations
Even though this document addresses routing protocols, these cannot
operate without a platform of hardware and software to support them.
All the resources belonging to this platform form what is generally
referred to as a router. Thus, routers comprise all local resources
of a routing daemon participating in a routing session.
This section will first highlight critical underlying components and
their security issues regarding Denial of Service (DoS)
vulnerabilities and then suggest suitable routing protocols'
requirements addressing these issues.
9.1 Denial of Service Attacks
The Computer Emergency Response Team (CERT)
[http://www.cert.org/tech_tips/denial_of_service.html] defines
Denial of Service attacks as being explicit attempts by attackers to
prevent legitimate users of a service from using that service.
Denial of Service attacks can be launched against a target for the
mere purpose of preventing the victim from using a resource or can
be a component of a greater attack that may ultimately aim at
stealing information.
A modern router is a complex system made of several hardware and
software components that interact in the effort to serve the general
purpose of routing as defined in paragraph 2.1. All of these
components are finite resources and therefore intrinsically prone to
Denial of Service. The impact of Denial of Service attacks on
certain local resources can be critical for the routing protocols
running on them.
9.2 Hardware Resources
Almost every hardware component in a router is essential to the
correct functioning of the local instances of the various routing
protocols that run on it, for example - trivially speaking - without
power no packets will be routed. Among others buffers/queues and
CPU cycles are two of the less obvious resources that are critical
for routing protocols.
9.2.1 Buffers/Queues
Buffers are widely used in hardware to store information that needs
to be aggregated or delayed before being consumed. In general once a
buffer is full every subsequent object that needs to be stored in
that queue will simply be discarded. Depending on what messages are
discarded, the consequences of dropping information for routing
Puig, et al. Expires April 23, 2004 [Page 28]
Internet-Draft Routing Protocols Security Requirements October 2003
protocols can vary from negligible to critical.
Since all messages exchanged between participants to a routing
session need to reach the control-plane, the queues and buffers that
support this link are critical for routing protocols. Often people
are deceived by thinking that the throughput of a switching fabric
is roughly the amount of bandwidth needed to launch a DoS attack
against a given router; in reality, routers have smaller bandwidth
links toward the control plane. The goal of an attacker could be
easier in terms of resources, if he/she were to attempt to exhaust
the buffers and queues on the link to the control plane with bogus
control plane packets rather than trying to congest the resources
serving the switching fabric. The goal of such attacks would be to
cause queues and buffers to drop legitimate routing messages
together with bogus ones.
9.2.2 CPU Cycles
Processors units, and in particular Network Processors (NPs), are a
valuable resource that can perform predetermined sets of operations
during a single cycle. Generally speaking, CPU cycles are a finite
resource that is shared among many different processes, some of
these being instances of routing protocols. As a consequence of
congestion, and from an oversimplified point of view, some processes
may be put "on hold" until more CPU cycles are available, or every
process may be "starved a bit". Both scenarios may cause great
damage to interactive processes. In particular routing protocols'
instances may enter critical states where a timely reaction to an
event is necessary but not available.
In general the more a CPU serves an heterogeneous pool of processes,
the more easy it will be for an attacker (or a faulty router) to
find a single service/process that will exhaust a significant
portion of the available CPU cycles, denying service to other
processes, such as routing.
9.2.3 Buffer/Queues and CPU Cycles Requirements
Routing messages SHOULD be identifiable as coming from legitimate
participants in their routing session before being directed towards
the control-plane.
If any rate limiting mechanism is intended by the routing protocol
to mitigate congestion of control-plane links, said solution MUST be
designed ensuring that an attacker cannot directly exploit it in the
attempt to block a legitimate routing peer from exchanging routing
messages.
Puig, et al. Expires April 23, 2004 [Page 29]
Internet-Draft Routing Protocols Security Requirements October 2003
9.2.4 Bandwidth
Routing protocols are based on the exchange of information between
the participants to a session over network links. A link's bandwidth
is finite critical resource that, if starved, can lead to Denial of
Service attacks on the routing protocols. If a link is not
malfunctioning, and neglecting transmission errors, then DoS attacks
on a link's bandwidth can only take place at the link's ends. A
router may receive an aggregate of traffic higher than it can be
forwarded by a given output interface, or a receiving router may not
be capable of handling the current load of traffic incoming on a
given interface due to an internal scheduling priority problem or
because it entered a critical or unknown state.
9.2.4.1 General Mitigation Techniques
Some mitigation techniques can be deployed to limit the exhaustion
of bandwidth between two routing peers; two current examples are:
ingress filtering, as described in RFC 2827 [FILTERING], and
solutions that relay on Quality of Service mandating that the
highest priority and availability be assigned to routing messages.
9.2.5 Bandwidth Requirements
Routing protocols MUST be designed to easily inter-work with lower
layers Quality of Service mechanisms.
9.3 Logic (Software) Resources
Similarly to hardware resources, logic resources can be finite and
therefore exhausted thus affording attackers with the possibility of
launching Denial of Service attacks. Databases are critical
resources for every routing protocol and they may contain
information about link-state, direct neighbors, active peers,
external routes database, etc...
Routing databases have a maximum number of entries that can be
stored in them and this is generally not defined by the routing
protocols. This upper bound can be set by an administrator through a
configuration parameter or can be restricted only by the hardware
memory available to the routing platform. Either way, when this
limit is approaching, for any of the databases maintained by a
routing protocol, some action must be taken.
9.3.1 Logic (Software) Requirements
Routing protocols MUST mandate verification of every piece of
information that can be verified before committing it to any
Puig, et al. Expires April 23, 2004 [Page 30]
Internet-Draft Routing Protocols Security Requirements October 2003
underlying database.
Every piece of information that cannot be verified by the routing
protocol immediately MUST be marked as temporary and means should be
provided, by the routing protocol itself, to keep track of these
entries, verify and discard them as soon as possible.
Every piece of information that cannot be verified by the routing
protocol MUST be installed in the apposite database with the minimum
time to live compatible with its function.
Routing protocols MUST provide mechanisms for routing platforms'
databases, in overflow state, to discard information that will cause
minimum possible disruption to the routing session.
Routing protocols SHOULD be designed as to incorporate feed-back
solutions from databases approaching overflow state so that
mitigative actions can be taken.
Routing protocols SHOULD be designed with the concept of graceful
degradation in mind in order to better survive in case any of the
underlying databases approaches or enters overflow state.
Puig, et al. Expires April 23, 2004 [Page 31]
Internet-Draft Routing Protocols Security Requirements October 2003
10. Inter domain routing issues
10.1 Legitimacy
Availability of the required material (caching/storing)
[Note] It should be clear that a light paradigm would better fit in
most cases, so we should avoid the acronym PKI as much as possible,
though we have to deal with the problem of the trusted party at some
point.
10.2 Policies
Note that policy propagation within a routing protocol which operates
between administrative routing domains, exterior gateway protocols,
is very difficult. This particular area of security is fraught with
difficulties making it next to impossible to actually secure policy
across multiple administrative domains.
10.3 Agreements involving operators
Secure EGPs operations will require kind of agreements between the
involved parties. Though operators may achieve these agreements on a
case by case basis, this is unlikely to be effective in the field.
Emergence of trusted third parties upon which would rely the
diffusion of public key material and relations to prefix ownership
would fit better.
Another question is whether these pieces of information must be tied
with public information related to the system ownership, such as the
organization name. This may lead to specific routing policies or
abuses that would introduce more complexity.
[TBD] Currently, signed tuples carrying /identity (WRT to RP),
address(es), public key, authorization on prefixes and adequate
lifetimes/ should be discussed.
10.3.1 Announcing Routes
[TBD] Legitimacy for advertising routes / updating information. Using
authorization paradigms should be sufficient.
10.3.2 Originating a Prefix / Ownership
[TBD] Ways to prove the right to advertise a prefix. Where will we
find the appropriate victim for the administration of these pieces of
information ?
Puig, et al. Expires April 23, 2004 [Page 32]
Internet-Draft Routing Protocols Security Requirements October 2003
11. Security Considerations
This entire informational draft RFC is security related. Specifically
it addresses security of routing protocols as associated with
requirements to those protocols. In a larger context, this work
builds upon the recognition of the IETF community that signaling and
control/management planes of networked devices need strengthening.
Routing protocols can be considered part of that signaling and
control plane, may be the most important. However, to date, routing
protocols have largely remained unprotected and opened to malicious
attacks. This document discusses inter and intra domain routing
protocol security requirements as we know them today and lays the
foundation for the design of new, more secure, routing protocols.
Puig, et al. Expires April 23, 2004 [Page 33]
Internet-Draft Routing Protocols Security Requirements October 2003
12. Acknowledgements
Mohammed Achemlal, France Telecom R&D, provided feedback and
corrections which will be incorporated in the next version of this
document.
Puig, et al. Expires April 23, 2004 [Page 34]
Internet-Draft Routing Protocols Security Requirements October 2003
Normative References
[SEC-GLOSS]
Shirey, R., "Internet Security Glossary", RFC 2828, May
2000, <http://www.ietf.org/rfc/rfc2828.txt>.
Puig, et al. Expires April 23, 2004 [Page 35]
Internet-Draft Routing Protocols Security Requirements October 2003
Informative References
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998, <http://www.ietf.org/rfc/
rfc2402.txt>.
[BTSH] Vijay, G., Heasley, J. and D. Meyer, "The BGP TTL Security
Hack (BTSH)", Internet Draft; version 02, May 2003,
<http://www.ietf.org/internet-drafts/
draft-gill-btsh-02.txt>.
[BYZANTINE]
Perlman, R., "Network Layer Protocols with Byzantine
Robustness", , August 1988, <http://www.vendian.org/
mncharity/dir3/perlman_thesis/>.
[CONSENSUS]
Coulouris, G., Kindberg, T. and J. Dollimore, "Distributed
Systems: Concepts and Design", Addison Wesley ISBN -
0201619180, 2000 September.
[DAMPING] Villamizar, C., Chandra, R. and R. Govindan, "BGP Route
Flap Damping", RFC 2439, November 1998, <http://
www.ietf.org/rfc/rfc2439.txt>.
[FILTERING]
P.Ferguson, D.Senie, "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing", BCP 38, RFC 2827, May 2000, <http://
www.ietf.org/rfc/rfc2827.txt>.
[KEYWORDS]
Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997, <http:/
/www.ietf.org/rfc/rfc2119.txt>.
[SMITH] Smith, R. and al., "Securing Distance-Vector Routing
Protocols", Symposium on Network and Distributed System
Security , February 1997, <http://www.isoc.org/isoc/
conferences/ndss/97/smith_sl.pdf>.
[THREATS] Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to
Routing Protocols", Internet Draft; version 00, August
2003, <http://www.ietf.org/internet-drafts/
draft-ietf-rpsec-routing-threats-02.txt>.
Puig, et al. Expires April 23, 2004 [Page 36]
Internet-Draft Routing Protocols Security Requirements October 2003
Authors' Addresses
Jean-Jacques Puig
INT / LoR / Piece A-108
9, Rue Charles Fourier
Evry 91011
France
Phone: +33 1 60.76.44.65
Fax: +33 1 60.76.47.11
EMail: jean-jacques.puig@int-evry.fr
URI: http://www-lor.int-evry.fr/~puig/
Emanuele Jones
Alcatel Canada - R&I - Security group
600 March Road
Kanata, ON K2K 2E6
Canada
Phone: +1 613 784 5977
Fax: +1 613 784 8944
EMail: emanuele.jones@alcatel.com
Danny McPherson
Arbor Networks
EMail: danny@arbor.net
Puig, et al. Expires April 23, 2004 [Page 37]
Internet-Draft Routing Protocols Security Requirements October 2003
Appendix A. Acronyms
DVP - Distance Vector Protocol. Routing protocol within which
participants maintain distance vectors to destinations, these vectors
being updated in a distributed algorithm fashion by
inter-participants and participants-destinations distances.
EGP - External Gateway Protocol. Routing protocol used between
different ASs.
IGP - Internal Gateway Protocol. Routing protocol used within a
single AS.
LSP - Link State Protocol. Routing protocol within which local
routing information is broadcast to other participants.
Puig, et al. Expires April 23, 2004 [Page 38]
Internet-Draft Routing Protocols Security Requirements October 2003
Appendix B. Protection achieved by the requirements
B.1 Protection from Threat Sources
B.1.1 Subverted Links
Partial protection against subverted links is gained with
authenticated integrity proof and anti-replay. These links can still
eavesdrop, delay, drop messages.
B.1.2 Subverted Devices
B.2 Protection from Threat Actions
B.2.1 Deliberate Exposure
Unless there is some odd use of assigned numbers (part of the public
address space, etc.) required by local configuration, deliberate
exposure will only mostly result in disclosure of local routing
information. If ciphers are used between peers, the disclosure will
be limited to participants sharing the key material. Note however
that the value of the disclosed information may not be high.
If an entity makes fun use of assigned numbers (we are above all
concerned about address spaces and AS numbers here), then the
deliberate exposure also becomes a falsification (refer to the
adequate section).
B.2.2 Sniffing
Measure against sniffing may be encryption of routing exchanges. It
is not obvious that the intrinsic value of routing information
justify an additional resources investment.
On the other hand, use of steganography or illusions may be
investigated though chances that this provides a powerful alternative
are low, even on high bandwidth links.
B.2.3 Traffic Analysis
B.2.4 Spoofing
B.2.5 Falsification
Authentication of sources should help here (care of anti-replay).
Special considerations apply to DVPs.
Puig, et al. Expires April 23, 2004 [Page 39]
Internet-Draft Routing Protocols Security Requirements October 2003
B.2.6 Interference
B.2.7 Overload
Puig, et al. Expires April 23, 2004 [Page 40]
Internet-Draft Routing Protocols Security Requirements October 2003
Appendix C. Examples
Puig, et al. Expires April 23, 2004 [Page 41]
Internet-Draft Routing Protocols Security Requirements October 2003
Appendix D. Requirements Summary
Puig, et al. Expires April 23, 2004 [Page 42]
Internet-Draft Routing Protocols Security Requirements October 2003
Appendix E. Revision History
E.1 changes from draft-ietf-rpsec-routing-security-requirements-00
Full TOC change.
Puig, et al. Expires April 23, 2004 [Page 43]
Internet-Draft Routing Protocols Security Requirements October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Puig, et al. Expires April 23, 2004 [Page 44]
Internet-Draft Routing Protocols Security Requirements October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Puig, et al. Expires April 23, 2004 [Page 45]
| PAFTECH AB 2003-2026 | 2026-04-22 03:49:31 |