Subject: [RPSEC] Initial comments on draft-ietf-rpsec-routing-threats-01.txt

From: Russ White <[email-masked]>
Date: Thu, 15 May 2003 10:47:24 -0400 (Eastern Daylight Time)

Below are some initial thoughts on the most recent version of the draft. I
still have some philosophical differences of opinion on the definitions and
terms we are using here, for instancde "routing protocol" vs "routing
system." I think we should adopt a narrow definition of "routing system"
and use this term, rather than using the term "routing protocol" to refer
to things outside the protocol, such as topology information.

Anyway, thoughts below the sig.

:-)

Russ
__________________________________
[email-masked] CCIE <>< Grace Alone

-----

First general comment: Let's get past peering, neighbor relationships,
and adjacencies. Let's try to use one term to describe all three, even
though routing protocols use all three. I think "adjacent" and "peers"
are clearer, more precise terms than "neighbors," so I'd probably
prefer that we use one of these two. Of course, "adjacent" implies
physical connectivity, which isn't always true, so perhaps we should
go with "peers," although that can have too many bgp implications (?).

I've used "peering" throughout my comments.

-----

   Routing protocols are subject to attacks that can harm individual
   users or the network operations as a whole. This document provides a
   description and a summary of generic threats that affects routing
   protocols in general. The work describes threats, including threat
   sources and capabilities, threat actions, and threat consequences as
   well as a breakdown of routing functions that might be separately
   attacked.

Routing protocols carry information about the topology of a network
which can be used to discover the best path to any given destination
within the network. The best path may be chosen based on its cost in
terms of bandwidth, delay, hop count, or other metric signifying the
length of the path, or it may be chosen based on some set of policies
designed by the network administrator. In either case, devices which
forward traffic (routers), using information and algorithms provided
by routing protocols, can make intelligent decisions when forwarding
traffic from one port to another.

Routing protocols, then are vulnerable to attacks against the
transportation of topology data, and attacks against the validity of
the topology data carried. This document describes the vulnerabilities
of routing protocols, including how they can be attacked in one of
these two areas, and how such attacks can be used to disrupt or
otherwise harm individual use of the network's resources, or force a
failure in the network denying the use of the network's resources in
general.

This work describes such attack methods in terms of threats, including
threat sources and capabilities, threat actions, and threat
consequences.

-----

1. Introduction

   individual users or the network operations as a whole. The document
                                                          ^^^
/This

-----

   The work should be considered as a precursor to developing a common
   ^^^^^^^^

Either replace "The work" with "This work," or, more simply, "It,"
since you're talking about this document in the entire intro, and
there's no real reason to repeat it.

-----

   the document does not address threats to routers such as hacking,

Same thing here.

-----

   denial of service, flooding attacks and others. The document does not
   consider threats that result from bad implementations that are
   related to specific routing.  The security requirements derived from
   this threat analysis are intended to be used as guidance to those who
   are designing routing protocols.

While its well known that bad, incomplete, or poor implementations of
routing protocols may, in themselves, lead to routing problems or
failures, or may increase the risk of a network being attacked
successfully, these issues are not considered here. This document only
considers attacks against robust, well considered implementations of
routing protocols, as outlined in [OSPF], [IS-IS], [RIP], and [BGP].

(provide references for the above)

The security requirements derived from this analysis are intended to
be used as guidance to those who are designing and modifying routing
protocols. They may also be used by routing protocol implementors to
increase the robustness of their impmementations.

(I'm not certain about this last sentence--what does the list think?)

-----

2. Routing Functions Overview

I'd drop the bulleted list, replacing it with subsections, and fill in
more examples and text in each area. Some possible text is given
below. I've also tried to merge in some of the information currently
in the intro just below the section 3 header, so we can eliminate it
there, in an attempt to coalesce some of the information, rather than
letting it wander around among various sections with different
examples, etc.

-----

2.1 Transport Subsystem

Routing protocols transport state and topology information over some
underlying protocol. For example, [OSPF] uses multicast and unicast IP
to carry information between routers, while [AODV] uses broadcast IP
packets. [IS-IS] uses multicast and unicast packets placed directly on
the link layer, rather than IP, to carry information.

Attacks against the transport subsystem of a routing protocol would
include attempts to hijaak the relationship between two peers,
flooding a router with packets to prevent it from forming peering
relationships properly, and (possibly) modifying the information
carried within a routing protocol packet to modify routing, or cause a
peering relationship between routers to fail.

2.2. Neighbor State Maintenance

Any pair of routers running a routing protocol will generally form a
neighbor, or peering, relationship, which can server two
purposes. Some protocols use this relationship to determine topology
information (for instance, in link state protocols, the list of
attached neighbors is advertised as part of the topology information)
and also to provide reliability in transmitting routing information
throughout a routing domain. Each routing protocol uses a different
mechanism for building these neighbor, or peering, relationships. For
instance, routers running [OSPF] will exchange hello's within a
certain state machine to discover neighboring routers.

Attacks against neighbor state maintenance could include hijaaking the
peering relationship between two routers, forcing the peering
relationship between two routers to fail, unauthorized peering in
order to inject false topology or policy information into the routing
protocol.

For instance, if an attacker could inject a false TCP RESET
notification into a session between two BGP peers, the attacker could
disrupt the propagation of routing information, and cause packets
which would otherwise be delivered to be dropped.

(You'll need a reference to the TCP spec here, and maybe a reference
to the BGP MD5 specs, since I think they talk about this attack
specifically.)

(I've changed the next section from database maintenance to topology
information origination and exchange, shortened to topology exchange.)

2.3 Topology Information Origination and Exchange

Routing protocols exchange network topology and reachability
information. Router collect this information from their neighbors or
peers, and use it to determine the best path through the network to
any (or every) given destination within the network. The correct
exchange of this topology information, and the correctness of this
topology information, is significant part of the function of a routing
protocol.

Attacks against the topology information propagated by a routing
protocol includes injecting false information. The results of
injecting this false information could be misdirecting traffic in
order to steal the contents of the packets, misdirecting traffic so it
is arbitrarily dropped at some point, forcing routing loops to occur,
and others.

-----

2.1 Routing Protocol Control and Data Planes

I think I'd drop the entire concept of control and data planes in a
routing protocol, and just use the three classifications mentioned
above, adding examples thee as needed to clarify. I really think it's
confusing to have multiple ways of classifying threats used
interchangably throughout the doc, and even intermixed in some parts.

-----

3. Generic Routing Protocol Threat Model

I think I'd avoid the use of "generic" throughout the entire doc. If
you just say: "Routing Protocols Threat Model," and leave the protocol
out, it should be assumed we are talking about all routing protocols,
and not a specific routing protocol.

-----

   This section develops a model that can be used to identify the
   threats that can affect routing protocols in general. The model
   examines the possible threats that routing protocols can be exposed
   to from unauthorized entities.

The model developed in this section can be used to identify threats to
any routing protocol. It examines attacks which can be launched
against routing from subverted entities within the routing system, and
ofrom entities outside the routing system. Both of these types of
entities are called unauthorized entities.

-----

   Routing protocols are subject to treats at the control and data
   ....
   A PIM router might transmit a JOIN message to receive multicast data
   it would otherwise not receive.

Drop all of this, as it should now be covered in section 2.

-----

3.1 Threat Definitions

   Threat is defined in [1] as a potential for violation of security,
   which exists when there is a circumstance, capability, action, or
   event that could breach security and cause harm. A threat presents
   itself when an attacker has the ability to take advantage of an
   existing security weakness.  Threats can be categorized based on

"A threat," rather than "Threat." Also, I'd use mnemonics for the
references, such as "SECDEFS" rather tha the numbers, as they are
easier for people to remember, and it makes the document easier to
read.

-----

3.1.1 Threat Sources

   There are many sources for threats that may affect routing protocols.
   In some cases, unauthorized entities such as attackers may illegally
   participate in the routing operations. In other circumstances, there
   are threats to routing protocols from entities that are running
   incorrect code, or using invalid configurations.

I think I'd just pull this paragraph. I've tried to rewrite it a
couple of times, and every time I'm either repeating something said
elsewhere, or I'm not really certain what it's supposed to say.

I also think this section needs to be more parallel, see below for
possible text.

-----

There are two axis along which the source of a threat may be
classified: whether the threat originates from an insider or an
outsider, and whether a threat originates from a subverted link, or a
subverted device.

o An isider is a device which is legally able to participate in routing.

o An outsider is a device which is not legally able to partipate in routing.

A device is classified as an insider or an outsider in reference to
the device attacked, not necessarily in the context of the network as
a whole. It is possible for a device which is normally legitimately
attached to one part of the network is moved to another location
within the network where it is no longer a legitimate member of the
routing system.

o Threats originating from a subverted link: A link is subverted when
an attacker gains access to the physcial medium in a way which allows
the attacker to receive and transmit on the link. This threat can
result from failure to use access control mechanisms or the use of
weak access control mechanisms. An attacker may listen to, replay,
delay, or drop routing messages on a subverted link, causing peering
relationships to fail, or hijaaking peering relationships, for instance.

o Threats resulting from subverted devices: A subverted device....

-----

   neighbor. For example, in OSPF (that is, before the MD5 part was
   added), OSPF speaks to all routers on the local link that answer to
   the AllSPFRouters multicast address.  Furthermore, MANET protocols
   frequently speak over the broadcast link.

For example, an OSPF router will form a peering relationship with any
attached device which appears to be running OSPF, unless MD5
authentication (or some other means) is used to prevent the peering
relationship from forming.

I'd pull the manet example, one is enough here, and reference the OSPF
MD5 draft.

-----

3.1.2 Threat Consequences

   A threat consequence is a security violation that results from a
   threat action [1]. 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.

I'm not certain I understand the second sentence in this paragraph?
I'd probably just pull it, and merge the first two paragraphs.

-----

   o  Disclosure: Disclosure of routing information happens when a
      router successfully accesses the information without being
      authorized. Subverted links can cause disclosure, if routing
      exchanges lack confidentiality.  Subverted devices (routers), can
      cause disclosure, as long as they are successfully involved in the
      routing exchanges.  Although inappropriate disclosure of routing
      information can pose a security threat or be part of a later,
      larger, or higher layer attack, confidentiality is not generally a
      design goal of routing protocols.

Maybe this?

Disclosure: Information about the topology, reachable destinations,
and passwords used in a network could be disclosed through routing
protocol exchanges between two routers. Although inappropriate
disclosure of routing information can pose a security threat or
provide the basis for a larger, or higher layer, attack,
confidentiality is not generally a design goal of routing protocols.

-----

   o  Deception: This consequence happens when a legitimate router
      receives a false routing message and believes it to be true.
      Subverted links and/or subverted device (routers)can cause this
      consequence if the receiving router lacks ability  to check
      routing message integrity, routing message origin, authentication
      or peer router authentication.

Maybe:

Deception: When a router receives routing data that appears to be
valid, and modifies its topology information or peering relationships
based on this information, it has been deceived. Subverted links and
subverted devices can be used to deceive other routers. Deception is
particuarly easy if there are no mechanisms in place to validate
information received.

-----

   o  Disruption: This consequence occurs when a legitimate router's
      operation is being interrupted or prevented. Subvert links can
      cause this by replaying, delaying, or dropping routing messages,
      or breaking routing sessions between legitimate routers. Subverted
      devices (router) can cause this consequence by sending false
      routing messages, interfering normal routing exchanges, or
      flooding unnecessary messages. (DoS is a common threat action
      causing disruption.)

Maybe:

Disruption: Occurs when a router's operation is interrupted or
prevented. Attackers can use subverted links to disrupt a router's
operation by replaying, delaying, or dropping routing messages, or by
causing peering relationships between two routers to fail. Attackers
can use subverted devices to disrupt the operation of a router by
sending routing information formatted to cause the receiving router to
fail, interfering with routing exchanges between other devices on the
network, and other means.

-----

o Usurpation: ...

(Are we certain this is spelled right?)

Maybe:

o Usurpation: Occurs when an attacker gains control over a lgeitimate
router's services or functions.

I'm not certain how a subverted link dropping packets would be
considered a usurped device? Or maybe the paragraph is using bad
examples?

-----

   ....
   B to reach Network 1.  In this way, Router B steals the data traffic
   and Router A surrenders its control of the services to Router B. This
   depicted in Figure 1.
   ....

I'm not certain I actually agree with this example.... You still had
to have subverted router b, in which case the router you're using as a
"base of attack" is one you've actually subverted, taking over the
services of the router. You've usurped A, not B. You've modified the
routing information within the system to bypass the router you've not
usurped, but that doesn't equate to subverting the router you've
directed the traffic around.

In other words, you might have usurped the routing system, but you've
not usurped A at all. This is a key distinction, and one reason I
think we should always be thinking in terms of the routing system, and
not the "routing protocol."

A "routing protocol" is mearly a collection of packet formats and
algorithms, and it doesn't make much sense to attack the poor little
beast. Now, if you can attack the information carried within the
routing protocol, which isn't part of the protocol, but the system
within which the routing protocol lives and works (and plays, of
course), that's another issue. As long as we persist in calling the
information within the protocol part of the protocol, we are going to
have these cases where we call directing traffic around a device
subverting or usurping that device.

In any case, the note isn't clearly pulled out of the main text,
either, and it's easy to read the entire following section as part of
the example started at "Note:" This really needs to be cleaned up--I'd
just pull the example as non-relevant and confusing.

-----

   Within the context of the threat consequences described above, damage
   that might result from attacks against the network as a whole may
   include:

I'm not certain how this fits in here.... You are moving from
consequences of certain threats to a protocol to consequences to the
routing system. I would think this entire section should be either
moved up at intro material in its own section, or moved to some
summary section at the end.

-----

3.1.2.1 Threat Consequence Zone

   A threat consequence zone covers an area within which the network
   operations have been affected by the threat consequences.

I've never understood the consequences of a threat--do you mean the
area within which network operation has been affected by the
consequences of an attack? It seems to me what you're trying to say is
the zone where network operations would be impacted by an attack if a
given threat were exploited?

-----

3.1.2.2 Threat Consequence Periods

I would make the same comment on this section--you mean the time
period during which the network is impaired by an attack using one of
the threats outlines above, right?

-----

4.2 Sniffing

Sniffing is a cloqiual term, derived from the name of the Sniffer
product, I'm not certain I would use it here, although it does convey
the meaning you're looking for. I think I'd rather use something like
physical layer packet capture and analysis, or something shorter if
anyone can think of a better term.

-----

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