Network Working Group D. McPherson
Internet-Draft JJ. Puig
Expires: March 22, 2004 September 22, 2003
Security Requirements for Routing Protocols
draft-puig-rpsec-generic-requirements-00
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 March 22, 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.
McPherson & Puig Expires March 22, 2004 [Page 1]
Internet-Draft Routing Protocols Security Requirements September 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. General Considerations . . . . . . . . . . . . . . . . . . . 5
2.1 What MUST / SHOULD be protected ? . . . . . . . . . . . . . 5
2.2 Transport Layer Considerations . . . . . . . . . . . . . . . 5
3. Cryptographic Requirements . . . . . . . . . . . . . . . . . 8
3.1 Basic Cryptographic Requirements . . . . . . . . . . . . . . 8
3.2 Cryptographic Keys Requirements . . . . . . . . . . . . . . 9
3.2.1 Public Key Cryptography . . . . . . . . . . . . . . . . . . 9
3.2.2 Crypto-hygiene . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.3 Key Strength . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Performances . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Use of Cryptography . . . . . . . . . . . . . . . . . . . . 11
3.5 Specific Considerations for External Gateway Protocols . . . 12
3.6 Specific Considerations for Link State Protocols . . . . . . 12
3.7 Specific Considerations for Distance Vectors Protocols . . . 13
4. Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1 Use of TTL . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 The TTL Hack . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4 Limited Broadcast . . . . . . . . . . . . . . . . . . . . . 15
5. The Byzantine Problem . . . . . . . . . . . . . . . . . . . 16
5.1 General Requirements . . . . . . . . . . . . . . . . . . . . 16
5.2 Detection of the Occurence of a Byzantine Failure . . . . . 17
5.3 Byzantine Detection . . . . . . . . . . . . . . . . . . . . 17
5.4 Byzantine Robustness . . . . . . . . . . . . . . . . . . . . 17
6. Local Considerations . . . . . . . . . . . . . . . . . . . . 19
6.1 Priorities and Traffic Control . . . . . . . . . . . . . . . 19
6.2 Extra checks . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3 Filtering . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4 Fail-back Procedures . . . . . . . . . . . . . . . . . . . . 19
6.5 Auditable Events . . . . . . . . . . . . . . . . . . . . . . 20
7. Agreements Requirements . . . . . . . . . . . . . . . . . . 21
7.1 Authenticating Public Keys . . . . . . . . . . . . . . . . . 21
7.2 Announcing Routes . . . . . . . . . . . . . . . . . . . . . 21
7.3 Originating a Prefix . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . 22
Normative References . . . . . . . . . . . . . . . . . . . . 23
Informative References . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24
A. Protection from Threat Sources . . . . . . . . . . . . . . . 26
A.1 Subverted Links . . . . . . . . . . . . . . . . . . . . . . 26
A.2 Subverted Devices . . . . . . . . . . . . . . . . . . . . . 26
B. Protection from Threat Actions . . . . . . . . . . . . . . . 27
B.1 Deliberate Exposure . . . . . . . . . . . . . . . . . . . . 27
B.2 Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.3 Traffic Analysis . . . . . . . . . . . . . . . . . . . . . . 27
McPherson & Puig Expires March 22, 2004 [Page 2]
Internet-Draft Routing Protocols Security Requirements September 2003
B.4 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.5 Falsification . . . . . . . . . . . . . . . . . . . . . . . 27
B.6 Interference . . . . . . . . . . . . . . . . . . . . . . . . 27
B.7 Overload . . . . . . . . . . . . . . . . . . . . . . . . . . 27
C. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 28
D. Requirements Summary . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . 30
McPherson & Puig Expires March 22, 2004 [Page 3]
Internet-Draft Routing Protocols Security Requirements September 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 C).
This document is organized as follows:
o Section 2 presents general considerations relative to the security
of routing protocols and routing systems.
o Section 3 defines cryptographic requirements for routing
operations.
o Section 4 presents the neighbors issue.
o Section 5 provides guidance for tackling Byzantine failures.
o Considerations on local decisions are given Section 6.
o Agreements requirements and operations involving network operators
responsibility are presented Section 7.
McPherson & Puig Expires March 22, 2004 [Page 4]
Internet-Draft Routing Protocols Security Requirements September 2003
2. General Considerations
This section provides general considerations on the design of secure
routing protocols.
2.1 What MUST / SHOULD be protected ?
[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 Transport Layer Considerations
The choice of the Transport Layer for the routing protocol may ease
the requirements presented in the following sections. Any routing
protocol designed to run on a specific Transport Layer MUST document
or provide appropriate references to the security properties provided
by the Transport Layer.
[TBD] A MUST sounds reasonable, yet we can move to a SHOULD.
A routing protocol designed to be, within a certain extent, Transport
Layer independent, may provide options to activate built-in security
McPherson & Puig Expires March 22, 2004 [Page 5]
Internet-Draft Routing Protocols Security Requirements September 2003
features on-demand when security provided by a Transport Layer is
insufficient. Though such a flexibility would help avoiding
potential redundancy of functions with the Transport Layer 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 Layers without further processing.
[TBD] I realize the above is complicated a bit. Who would do that
anyway ? Do we remove this ?
The Transport Layer may already provide the following properties:
o [OLD VERSION] - I think 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 Layer
technology may provide a way to discover and communicate with
adjacent devices participating in the routing domain (neighbors).
o [OLD VERSION] - Integrity: the Transport Layer 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 Layer 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 Layer 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 states 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
McPherson & Puig Expires March 22, 2004 [Page 6]
Internet-Draft Routing Protocols Security Requirements September 2003
channels may be provided via the same Link Layer infrastructure,
or perhaps via a distinct network.
McPherson & Puig Expires March 22, 2004 [Page 7]
Internet-Draft Routing Protocols Security Requirements September 2003
3. Cryptographic Requirements
This section presents cryptographic requirements for routing
protocols.
3.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
McPherson & Puig Expires March 22, 2004 [Page 8]
Internet-Draft Routing Protocols Security Requirements September 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 ?
3.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.
3.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
McPherson & Puig Expires March 22, 2004 [Page 9]
Internet-Draft Routing Protocols Security Requirements September 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.
3.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.
3.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.
3.3 Performances
Device resources (CPU, memory) might be overloaded by cryptographic
operations, especially by public key computations. These performance
McPherson & Puig Expires March 22, 2004 [Page 10]
Internet-Draft Routing Protocols Security Requirements September 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 inline provisioning of public material.
[TBD] Does inline 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 3.2.1.
3.4 Use of Cryptography
[TBD] This section should explain how the above cryptography
McPherson & Puig Expires March 22, 2004 [Page 11]
Internet-Draft Routing Protocols Security Requirements September 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 A and Appendix B 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.
3.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:
3.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.
McPherson & Puig Expires March 22, 2004 [Page 12]
Internet-Draft Routing Protocols Security Requirements September 2003
3.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.
McPherson & Puig Expires March 22, 2004 [Page 13]
Internet-Draft Routing Protocols Security Requirements September 2003
4. 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.
4.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.
4.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.
4.3 Link Layer
Direct use of the Link Layer instead of Network (IP) Layer for
communications of the routing protocol limits neighborhood
implicitly. In some cases (VLAN frame hopping, Wireless LANs), an
outsider may still break in the neighbors zone.
McPherson & Puig Expires March 22, 2004 [Page 14]
Internet-Draft Routing Protocols Security Requirements September 2003
4.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.
McPherson & Puig Expires March 22, 2004 [Page 15]
Internet-Draft Routing Protocols Security Requirements September 2003
5. 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:
Never rely to correct operation of a particular neighbor, always
apply least privilege. Only traffic source and destination are
trustworthy.
Authenticate sent messages, check authenticity of received
messages.
Note that detection and robustness properties are not necessarily
correlated.
5.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,
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 4) 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 5.4 and [BYZANTINE].
McPherson & Puig Expires March 22, 2004 [Page 16]
Internet-Draft Routing Protocols Security Requirements September 2003
5.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.
5.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
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).
5.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
McPherson & Puig Expires March 22, 2004 [Page 17]
Internet-Draft Routing Protocols Security Requirements September 2003
reachability is still possible / probable.
McPherson & Puig Expires March 22, 2004 [Page 18]
Internet-Draft Routing Protocols Security Requirements September 2003
6. Local Considerations
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.
6.1 Priorities and Traffic Control
Route lookup function SHOULD have higher priority than route
maintenance function.
Traffic overload may provoke DOS of routing negotiations, while these
would precisely help in balancing the high traffic. Forwarding is
usually the principal purpose of devices running routing protocols.
In order to achieve correctness of forwarding tables, means to
enforce availability of the medium to the routing protocol SHOULD be
provided (e.g. through the use of an adequate queue policy). For the
same reasons, routing traffic SHOULD also be rate limited, so that a
routing exchange overload does not jeopardize forwarding of current
user traffic (which is likely to carry routing device administration
traffic under such circumstances).
6.2 Extra checks
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.
6.3 Filtering
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.
6.4 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
McPherson & Puig Expires March 22, 2004 [Page 19]
Internet-Draft Routing Protocols Security Requirements September 2003
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.
6.5 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 ?
McPherson & Puig Expires March 22, 2004 [Page 20]
Internet-Draft Routing Protocols Security Requirements September 2003
7. Agreements Requirements
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.
7.1 Authenticating Public Keys
[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.
7.2 Announcing Routes
[TBD] Legitimacy for advertising routes / updating information. Using
authorization paradigms should be sufficient.
7.3 Originating a Prefix
[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 ?
McPherson & Puig Expires March 22, 2004 [Page 21]
Internet-Draft Routing Protocols Security Requirements September 2003
8. 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.
McPherson & Puig Expires March 22, 2004 [Page 22]
Internet-Draft Routing Protocols Security Requirements September 2003
Normative References
[SEC-GLOSS]
Shirey, R., "Internet Security Glossary", RFC 2828, May
2000, <http://www.ietf.org/rfc/rfc2828.txt>.
McPherson & Puig Expires March 22, 2004 [Page 23]
Internet-Draft Routing Protocols Security Requirements September 2003
Informative References
[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.
[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>.
Authors' Addresses
Danny McPherson
Arbor Networks
EMail: danny@arbor.net
McPherson & Puig Expires March 22, 2004 [Page 24]
Internet-Draft Routing Protocols Security Requirements September 2003
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/
McPherson & Puig Expires March 22, 2004 [Page 25]
Internet-Draft Routing Protocols Security Requirements September 2003
Appendix A. Protection from Threat Sources
A.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.
A.2 Subverted Devices
McPherson & Puig Expires March 22, 2004 [Page 26]
Internet-Draft Routing Protocols Security Requirements September 2003
Appendix B. Protection from Threat Actions
B.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 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.3 Traffic Analysis
B.4 Spoofing
B.5 Falsification
Authentication of sources should help here (care of anti-replay).
Special considerations apply to DVPs.
B.6 Interference
B.7 Overload
McPherson & Puig Expires March 22, 2004 [Page 27]
Internet-Draft Routing Protocols Security Requirements September 2003
Appendix C. 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.
McPherson & Puig Expires March 22, 2004 [Page 28]
Internet-Draft Routing Protocols Security Requirements September 2003
Appendix D. Requirements Summary
McPherson & Puig Expires March 22, 2004 [Page 29]
Internet-Draft Routing Protocols Security Requirements September 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
McPherson & Puig Expires March 22, 2004 [Page 30]
Internet-Draft Routing Protocols Security Requirements September 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.
McPherson & Puig Expires March 22, 2004 [Page 31]
