Subject: [RPSEC] another threat analysis draft

From: [email-masked]
Date: Wed, 6 Nov 2002 12:38:47 -0500 (EST)

At the same time that Dennis's draft got announced, I offered the following
draft to the chairs.  Tony suggested that I send it to the list as well.
I don't claim that it presents an opposing viewpoint, but I do think that
it has a bit different focus in organization and presentation.

So here it is.

--Sandy

Network Working Group                                      Sandra Murphy
INTERNET DRAFT                                                  NAI Labs
draft-murphy-threat-00.txt                                  October 2002

                    Routing Protocol Threat Analysis

Status of this Memo

This document is an Internet-Draft and is subject to 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/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

Abstract

Routing protocols are subject to attacks that can harm individual users
or the network operations as a whole.  The lack of a common set of
security requirements has led to the use in existing routing protocol of
a variety of different security solutions, which provide various levels
of security coverage.

The RPSEC working group intends to deliver a set of security
requirements for consideration of routing protocol designers.  The first
step in developing the security requirements is to analyze the threats
that face routing protocols.  This document describes the threats,
including threat consequences, threat sources and capabilities, threat
actions, and a breakdown of routing functions that might be separately
attacked.

Murphy                     Expires: April 2003                  [Page 1]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002

Table of Contents

 Status of this Memo ..............................................    1
 Abstract .........................................................    1
1 Introduction ....................................................    3
2 Routing Functions ...............................................    4
2.1 Targeted Functions ............................................    4
3 Threats Sources (Attackers) .....................................    5
3.1 Outsiders .....................................................    5
3.2 Insiders ......................................................    6
4 Threat Actions (Attacks) ........................................    7
5 Threat Consequences (Compromise) ................................    8
6 Security Considerations .........................................    9
7 References ......................................................    9
8 Author's Address ................................................   10

Murphy                     Expires: April 2003                  [Page 2]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002

1.  Introduction

The RPSEC working group is tasked to deliver a description of the
security requirements for routing protocols.  This internet draft
discusses an analysis of the threats that face routing protocols, as a
precursor to developing a common set of security requirements for
routing protocols.

The RPSEC working group is addressing security requirements of routing
protocols, not the security requirements of routers or of operations of
routing systems.  Therefore, this draft specifically does not address
threats to routers (hacking, denial of service flooding attacks, etc.)
or to specific routing protocol implementations (bugs, etc.).  The
security requirements derived from this threat analysis are intended to
be guidance to those who are designing routing protocols; if the threat
is directed at some aspect of routing outside the routing protocol there
is nothing the protocol designers can do to address the threat.

The intent is to construct security requirements that will be applicable
across a wide range of routing protocols: both inter-domain and intra-
domain (EGP and IGP), both wired and wireless, both unicast and
multicast, protocols based on any underlying protocol level (over the
link layer, over IP, over TCP, over clouds, over virtual topologies as
in peer-to-peer, etc.), protocols that communicate over point-to-point
links, over multi-point links, over anycast or multicast links, over
broadcast, and protocols that are multi-hop or directly connected.
While the security solutions that are possible are strongly affected by
such differences, the security requirements should be the same.

The term threat is used in many different ways.  There is the threat
consequence, or compromise, which is the damage done by an attack on a
vulnerability.  There is the threat source, or attacker, which is the
entity in the system that is mounting an attack.  This could be one
single user, a host, a network, or a distributed set of users, hosts,
etc.  There is the threat action, or attack, which is the activity that
the attacker uses to cause the compromise.

This analysis will consider each of these separately.  Security
requirements can be stated in terms of preventing the attack, or in
terms of avoiding the compromise (which does not necessarily mean that
the attack is prevented, only that the damage is avoided somehow), in
terms of eliminating a vulnerability that can be attacked, or in terms
of excluding certain attackers.

Murphy                     Expires: April 2003                  [Page 3]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002

2.  Routing Functions

Routing protocols in general have several common functions:

Transport subsystem
     The routing protocol transmits messages to its peers using some
     underlying protocol.  For some, as in OSPF, this is IP.  For
     others, this can be a broadcast link layer, as in AODV.  Still
     others may run over TCP.  In many cases, the routing protocol is
     subject to attacks on its underlying protocol.

Neighbor state maintenance
     Each protocol has a different mechanism for determining its peers
     in the routing topology.  Some protocols have distinct exchanges
     through which they establish peering relationships, e.g., Hello
     exchanges in OSPF. The peering relationship formation is the first
     step of topology determination.  For protocols that maintain state
     about their peering relationships, attacks that disrupt the peering
     relationship can have widespread consequences.  For example, if the
     DR election is disrupted in an OSPF network, an unauthorized router
     could be chosen as designated router.  This might allow
     unauthorized access to routing information.  In BGP, if a router
     receives a CEASE message, it can break the peering relationship and
     cause any related topology information to be flushed.

Database maintenance
     Routing protocols exchange network topology and reachability
     information.  The routers collect this information in routing
     databases in varying detail.  The maintenance of these databases is
     a significant portion of the function of a routing protocol.  The
     information in the database must be authentic and authorized,
     otherwise the function of routing in the overall network is
     damaged.  For example, if an OSPF router sends LSA's with the wrong
     Advertising Router, the receivers will compute a SPF tree that is
     incorrect and might not forward the traffic.  If a BGP router
     advertises a NLRI that it is not authorized to advertise, then
     receivers might forward that NLRI's traffic toward that router and
     the traffic would not be deliverable.  A PIM router might transmit
     a JOIN message to receive multicast data it would otherwise not
     receive.

2.1.  Targeted Functions

Just as a router's functions can be divided into control and data plane
(protocol traffic vs data traffic), so the routing protocol has a

Murphy                     Expires: April 2003                  [Page 4]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002

control and a data plane.  A routing protocol has some message exchanges
that are intended only for control of the protocol state.  This is the
routing protocol control plane.  Other message exchanges are intended to
distribute the information used to perform the forwarding function,
whether that is to establish a forwarding table in each router or to
return a description of the route to use.  This is the routing protocol
data plane.  Each of the routing functions may have both control and
data aspects, but there will naturally be an emphasis on one or the
other.  Neighbor maintenance is likely to be focused on the routing
protocol control plane aspects, for example, while database maintenance
may have more focus on the routing protocol data plane aspects.

Both the control and the data plane are subject to attack.  An attacker
who is able to target the routing protocol control plane so as to break
a neighbor (e.g., peering, adjacency) relationship can have a strong
effect on the behavior of routing in those routers and likely the
surrounding neighborhood.  An attacker who is able to break a database
exchange between two routers can also effect routing behavior.  In the
routing protocol data plane, an attacker who is able to introduce bogus
data can have a strong effect on the behavior of routing in the
neighborhood.

3.  Threats Sources (Attackers)

Attackers can be outsiders or insiders.  An insider is a legitimate
participant in the routing protocol.  An outsider is any other host or
network.  A host is determined to be an outsider or an insider from the
point of view of a particular router.  Even a legitimate protocol
speaker can be an outsider to a particular router if the router does not
consider the speaker to be a legitimate peer (as could conceivably
happen on a multi-access link).

3.1.  Outsiders

Outsiders can be a remote host in the network, a host on the immediate
peer to peer link, a protocol speaker on a peer to peer link that is not
a configured peer.

Outsider capabilities:

     The strongest assumption is that the outsider has complete access
     to the communication between two legitimate peers so it can read
     any message, can delete messages, can replay any message it had
     read, can modify messages and can insert new messages.  This might
     be true, for example, if the protocol was intended to run over a

Murphy                     Expires: April 2003                  [Page 5]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002

     layer that provided only datagram service - link layer or UDP,
     perhaps - and no authentication was offered.

     A lesser assumption is that the outsider can insert new messages
     into the peer to peer communication but cannot read messages.

     An outsider might be able to read messages and replay messages it
     had read, but not to create new messages.

     An outsider might be able only to read messages, not insert
     messages.

     The outsider might only have the ability to cut the communication
     between peers through the underlying protocol.

Outsiders can be prevented from disrupting routing by providing peer to
peer authentication.  But the protection provided is dependent on
whether the protection is in some underlying protocol, whether link
layer, IP, TCP, etc.  or the protection is in the protocol layer itself.
If the underlying protocol is itself subject to attack (e.g., the
protocol is stateful and the state can be manipulated by an attack),
then protection in the protocol layer will not eliminate those attacks.

3.2.  Insiders

Insiders have a powerful opportunity to disrupt the routing system.
Given their position of trust in the routing system, they possess the
capabilities of the strongest outsider attacker in terms of access to
the communication and in terms of access to routing information.

Routing protocol peers also have access to context that provides an
opportunity to detect bogus routing information.  The difficulty is to
continue to provide rapid response to legitimate network dynamic
behavior while eliminating bogus information, particularly when the
range of legitimate network behavior is large.  For example, a wired
network where the connectivity is sparse may be able to filter routing
information near the "edge" of the network.  But in the core of the
network or in a richly connected network, the possible routing
information may be so varied as to make filtering less useful.  Also, a
wireless network has few constraints on connectivity, so there is no
basis on which to construct filters.

Insider capabilities:

Murphy                     Expires: April 2003                  [Page 6]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002

     Complete access to peer to peer communication, to the underlying
     protocol state, to routing information, to authentication data,
     etc.  Able to insert new or modified messages, replay old messages,
     delete messages, read messages, etc. at will.

When a host or network behaves in a way contrary to the protocol
specification or in a way that is not authorized, the behavior is called
a "Byzantine failure".  These failures can include timing errors
(producing messages at intervals contrary to the specification),
protocol errors (producing messages at variance with the specification,
e.g., responding with the incorrect message type), or data errors
(producing messages that carry faulty data).

Byzantine routing failures have been observed in the Internet since its
inception.  Failures can be the result of hardware or software faults,
of misconfiguration by the router operators, or of deliberate subversion
by a malicious party.  The great majority of publicized accounts of
Byzantine failures have been of faulty or misconfigured routers.  Public
accounts of deliberately subverted routers have been rare.

4.  Threat Actions (Attacks)

The activities that might be used to attack a routing protocols include:

masquerade
     The attacker, whether insider or outsider, may adopt the identity
     of a legitimate peer. (This is an attack against origin
     authenticity.)

interception
     The attacker gains access to routing information that is considered
     sensitive.  (This is an attack against confidentiality, i.e.,
     privacy.)

falsification
     The attacker is able to substitute modified messages for valid
     routing messages.  (This is an attack against integrity.)

misuse
     The attacker is able to introduce unauthorized routing information
     that disrupts routing behavior.  (This is an attack against
     authorized use.)

replay
     The attacker is able to re-introduce previously transmitted

Murphy                     Expires: April 2003                  [Page 7]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002

     messages.  (This is an attack against freshness.)

These attacks might be used by insider or outsider to accomplish any of
the compromises listed below.

5.  Threat Consequences (Compromise)

The compromise to the behavior of the routing system can damage a
particular network or host or can damage the operation of the network as
a whole.

The damage that might result from attacks against the network as a whole
include:

     network congestion: more data traffic is forwarded through some
     portion of the network than would otherwise need to carry the
     traffic,

     blackhole: large amounts of traffic are directed to be forwarded
     through one router that cannot handle the increased level of
     traffic and drops many/most/all packets,

     looping: data traffic is forwarded along a route that loops, so
     that the data is never delivered (resulting in network congestion),

     partition: some portion of the network believes that it is
     partitioned from the rest of the network when it is not,

     disclosure: the routing information is sensitive and is revealed to
     an unauthorized entity,

     churn: the forwarding in the network changes (unnecessarily) at a
     rapid pace, resulting in large variations in the data delivery
     patterns (and adversely affecting congestion control techniques),

     instability: the protocol becomes unstable so that convergence on a
     global forwarding state is not achieved, and

     overload: the protocol messages themselves become a significant
     portion of the traffic the network carries.

The damage that might result from attacks against a particular host or
network address include:

Murphy                     Expires: April 2003                  [Page 8]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002

     starvation: data traffic destined for the network or host is
     forwarded to a part of the network that cannot deliver it,

     eavesdrop: data traffic is forwarded through some router or network
     that would otherwise not see the traffic, affording an opportunity
     to see the data or at least the data delivery pattern,

     cut: some portion of the network believes that it has no route to
     the host or network when it is in fact connected,

     delay: data traffic destined for the network or host is forwarded
     along a route that is in some way inferior to the route it would
     otherwise take,

     looping: data traffic for the network or host is forwarded along a
     route that loops, so that the data is never delivered,

It is important to consider all compromises, because some security
solutions can protect against one attack but not against others.  It
might be possible to design a security solution that protected against
an attack that eavesdropped on one destination's traffic without
protecting against an attack that overwhelmed a router.  Or that
prevented a starvation attack against one host, but not against a net-
wide blackhole.  The security requirements must be clear as to which
compromises are being avoided and which must be addressed by other means
(e.g., by administrative means outside the protocol).

6.  Security Considerations

This entire memo is about security, describing the threats to routing
protocols.

7.  References

[1]  Y. Rekhter and T. Li,  "A Border Gateway Protocol 4 (BGP-4)",
     RFC1771, March 1995.

[2]  John Moy, "OSPF Version 2", RFC 1583, March 1994.

[3]  C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy and C. Orange,
     "Routing Policy System Security", RFC 2725,  December, 1999.

[4]  R. Shirey,"Internet Security Glossary", RFC 2828, May 2000.

Murphy                     Expires: April 2003                  [Page 9]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002

8.  Author's Address

Sandra Murphy
Network Associates, Inc.
NAI Labs
3060 Washington Road
Glenwood, MD  21738
EMail: [email-masked]

Murphy                     Expires: April 2003                 [Page 10]

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec