Generic Threats to Routing Protocols
draft-ietf-rpsec-routing-threats-07

[Ballot comment]
ID Nits comes up with some problems including boilerplates being wrong - thought I have no idea what the policy would be for a document last submitted in 2004 -  and some non ascii smart quotes around "trust".

[Ballot comment]
I would have expected Section 4.4 to include some text about spoofing the identity of a management station. This is also related to the last bullet in the list of Adversary Capabilities in section 3.1.1.2 which mentions the capability of an attacker to assume the identity of a management workstation and lead to consequences like the disruption of the routing protocol or forwarding capabilities of a router.

The RFC Editor has requested a new approval from the IESG.

From: RFC Editor
Subject: Re: authors 48 hours: RFC XXXX
          NOW AVAILABLE
Date: Wed, Apr 13 2005 -0700
To: Sandy Murphy
Cc: riw@cisco.com, zinin@psg.com, abbieb@nortelnetworks.com,
    fenner@research.att.com, ttauber@1-4-5.net, yiya@cisco.com, RFC
    Editor

Authors and ADs,

It seems as though this document is being completely re-done.  If this
is the case, please let us know and we will remove the document from
our queue until we receive a new announcement from the IESG Secretary.

Note: this was pulled back from the RFC Editor to resolve a coauthor's concerns about the text.  Re-editing is done, and the modified text will be checked in the WG.

Additional IESG comments:

Ted:
Comment:

The definition of threat wavers between "an adversary" and
the "opportunity for an adversary to hurt you"; this is
especially true in Section 3.1  Consistency here seems
pretty important.

In 3.1.2, this definition is given: "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".
I thought the aim here was to describe consequences,not how they
are achieved.  The consequence here seems to be "packets go in,
but go nowhere".


Nits:

Both abstract and introduction have this statement:

"The document
  provides a summary of generic threats that affects routing protocols."
-->that affect (otherwise it reads as if the summary is doing the affecting).

Section 2.

"routing protocols may need to maintain the state of their"
-->maintain knowledge about the state?

"Routing protocol data plane uses messages to exchange information"
-->The (or A) Routing protocol?

Section 3.

"Routing protocols are subject to treats at the control and data"
--->threats.

Section 3.1.2
"Disruption: This consequence occurs when a legitimate router's
      operation is being interrupted or prevented. Subvert links can"

" interfering routing exchanges, or system integrity."--> interfering with?



--->subverted

ops-dir:

From: Pekka Savola [mailto:pekkas@netcore.fi]
Sent: donderdag 30 oktober 2003 0:10
To: Randy Bush
Cc: ops directorate
Subject: draft-ietf-rpsec-routing-threats-03.txt


Hi,

Comments below.  First time I read it.  Feel free to expose, as always.

High-order bit: so-and-so.  Looks like an OK document, but I'm not sure
how much usefulness there is to it.  The classification of threats etc. is
made in such a way that a real analysis whether some important pieces
could be missing from the consideration is difficult.  That is, it's nice
to read through the document, but I'm not sure if the characterizations,
document organization, threat models etc. are really the useful ones,
enabling easier analysis of the content.

But as I don't have any bright ideas at the moment myself, I think it
should be OK.  Just don't expect to build any other documents on top of
that (e.g., protocol-specific documents looking at how they've addressed
the generic threats) and you should be ok.  If you intend to build new
work on top of this document, it might make sense to think whether the
structure needs beefing up a bit more.


On Fri, 24 Oct 2003, Randy Bush wrote:
>    3. Document Actions
>    3.1 WG Submissions
>    3.1.1 New Item
> ****  o draft-ietf-rpsec-routing-threats-03.txt
>      Generic Threats to Routing Protocols (Informational) - 3 of 3
>      Token: Alex Zinin


more or less substantial comments
---------------------------------

  This documents investigates general threats to routing functions. In
  this work, the "owner" of an address prefix or an AS [17] number is
  an organization that has been granted the right to use that prefix or
  number. Each Regional Internet Registry (RIR) acquires prefixes and
  AS numbers from IANA, and further distributes (delegates use of) them
  to organizations such as ISPs and multi-homed subscribers. For
  address prefixes, delegation typically involves assigning a subset of
  a prefix to an organization, which may, in turn, further delegate
  subsets to other organizations, e.g., subscribers or downstream
  providers.


==> overly verbose on IP addressing, which is not leveraged later in
the document, may be outside of the scope?  Definitely needs rewording if
it's staying..

  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
  focus on the data plane.


==> IMHO, the separation of data and control planes in a router is a
simple concept.  However, the separation of data/control planes
in a routing protocol is not (actually, I've very rarely even heard anyone
mention something like that).  And this description (IMHO) does not
flesh it out properly.  If it's staying, I'd recommend trying to reword
to be clearer what which of them entails.

  Threats can originate form outsiders or insiders.  An insider is an
  authorized participant in the routing protocol.  An outsider is any
  other host or network.  A particular router determines if a host is
  an outsider or an insider.  An authorized protocol speaker can be an
  outsider to a particular router if the router does not consider it to
  be a legitimate peer (as could conceivably happen on a multi-access
  link).

==> by the first definition of "insider", the third definition is
already "insider" because it's authorized.. or maybe I don't understand what
you're talking about with the authorized speaker which is an outsider..

  o  Threats that result from subverted links: A link become subverted
      when an attacker gain access (or control) to it through a physical
      medium. The attacker can then take control over the link.  This
      threat can result from the lack (or the use of weak) access
      control mechanisms as applied to physical mediums or channels. The
      attacker may eavesdrop, replay, delay, or drop routing messages,
      or break routing sessions between authorized routers, without
      participating in the routing exchange.

==> this is one-sided view of the subject.  This seems clearly look at the
threat from the perspective of getting physical access to the
link between two routers.

However, there is another case like this: router providing connectivity to
a stub network, e.g., running an OSPF protocol without passive mode
towards a LAN.  These threats are different, at least to a degree, because
typically in these stub network cases, the routing protocol packets do
destined to the third parties do not traverse through the stub network. 
That is, e.g. replay and drop are not really relevant threats..  Not sure
to which degree these should be fleshed out separately..

...

  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
  neighboring relationship from forming.

==> this may need to be considered with the above in mind.  This concentrates
on IP-level protection, which may not be relevant if someone is able
to come in as a middleman in the communication (depends on whether
plain-text is used for authentication -- that is, if I see the
communication, does it help me at all unless I know the key, requring a
router compromise instead of a link -- I guess in most cases some hashes
or others are used instead).

....

4.1 Deliberate Exposure

  Deliberate Exposure occurs when an attacker takes control of a router
  and intentionally releases routing information directly to other
  routers. In some cases, the receiving routers may not be authorized
  to access the leaked routing information. Deliberate exposure is
  always a threat action, however, the exposure of routing information
  may not be.

==> this is written as if this threat was limited to exposing
information to other _routers_.  In fact, the attackers goal might be to
expose it to _himself_, a web page, mail posting, etc. (ie., not necessarily
to other routers) as well.  This would
be a subset of the original threat.

4.2 Sniffing

  Sniffing is an action whereby attackers monitor and/or record the
  routing exchanges between authorized routers.  Attackers can use
  subverted links  to sniff for routing information.

==> this is a limited case of this threat.  In addition to sniffing
the routing information, being in a position like this, it is typically
also possible to sniff the data plane as well?

4.3 Traffic Analysis

  Traffic analysis is action whereby attackers gain routing information
  by analyzing the characteristics of the data traffic on a subverted
  link. Traffic analysis threats can affect any data that is sent in
  the clear over a communication link. This threat is not peculiar to
  routing protocols and is included here for completeness.

==> this is not limited to clear-text communication.  You can typically
analyze many interesting things out of encrypted traffic as well
(e.g. even if all traffic is protected by IPsec ESP). For example, looking at
the destination addresses on the link should yield which prefixes are
(at least) used in the routing protocol, or looking at which
IP addresses communicate might help you guess about multihop iBGP
sessions, etc.

For
  example, if an attacker succeeds in spoofing the identity of a
  router, the subverted router can act as a masquerading router.

==> which router does "subverted" refer to?  This seems to assume
that spoofing would imply hijacking someone else's identity, which
need not be the case (e.g., if a router has configured that everyone
in a specific prefix is allowed to form adjacencies, but you spoof
an address in that prefix but not one that was already used, you don't
hijack an identity) -- similar later

  The consequences of spoofing are:

  o  The deception of peer relationship:  The authorized routers, which
      exchange routing messages with the spoofed router, do not realize
      they are neighboring with a router that is faking another router's
      identity.

==> this actually includes a lot of other consequences, need to spell it
out -- be able to do everything authorized, e.g. blackhole, loop,
forge routing information to eavesdrop, etc.etc.

  o  Where disruption is concerned, the consequence zone includes the
      routers that are on the path of misdirected data traffic (Router B
      in Figure 2 and Figure 3).

==> plus those routers in the path in the internet which got this traffic
they would not otherwise get..


4.5.1.2 Misclaiming

  A misclaiming threat is defined as an attacker action advertising its
  authorized control of some network resources in a way that is not
  intended by the authoritative network administrator.


==> this is exactly what seems to happen with overclaiming as well. 
Apparently these two issues haven't been sufficiently well spelled out
as I'm missing something.. (note: the next section on forwarder attacks lists
only misstatement, not e.g. overstatement :-)






editorial:
----------

  in BGP, if a router receives a CEASE message, it can lead to breaking
  of its neighboring relationship to other routers.

==> s/breaking of/breaking off/ ? (or remove "of" ?)

  A PIM router might transmit a JOIN message to receive multicast data
  it would otherwise not receive

==> s/receive/receive./

      when an attacker gain access (or control) to it through a physical

==> s/gain/gains/

      Subverted links and/or subverted device (routers)can cause this

==> s/device (routers)/devices (routers) / (2 typos)

      routing message integrity, routing message origin, authentication
      or peer router authentication.

==> different variations of authentication twice, intentional or a typo?

      operation is being interrupted or prevented. Subvert links can

==> s/Subvert/Subverted/

      devices (router) can cause this consequence by sending false

==> s/router/routers/

Subverted routers can
      cause this consequence by sending false routing information,
      interfering routing exchanges, or system integrity.

==> "or system integrity" is abrupt -- something missing?

  However, Router B is compromised and advertises a lower metric.

==> s/lower/better/ (lower is not always better :-)

  subverted links  to sniff for routing information.

==> s/links /links/

  attacker's location and  what data traffic has passed through. A

==> s/and /and/

  Falsification is an intentional action whereby false routing
  information is sent by a subverted router. To falsify the routing
  information, an attacker has to be either the originator or a
  forwarder of the routing information. False routing information
  describes the network in an unrealistic fashion, whether or not
  intended by the authoritative network administrator.

  To falsify the routing information, an attacker has to be either the
  originator or a forwarder of the routing information. It cannot be a
  receiver-only.

==> Remove "To falsify ..." sentence from the first paragraph,
roughly duplicates..

      the attacker(Router C in Figure 2 and Figure 3).


==> s/attacker(/attacker (/

  A misclaiming threat is defined as an attacker action advertising its
  authorized control of some network resources in a way that is not

==> s/attacker action/action where an attacker is/ ?

  might increase the path cost by two hops instead of one. In BGP, the
  attacker might delete some AS numbers from the AS PATH.

==> s/AS/AS_/ ?

  The threat consequence area and period are also similar.

==> s/area/zone/ ?

  or by replaying out-dated packets, or by delaying responses, or by
  denial of receipts, and breaking synchronization.

==> s/and/or by/ for consistency ?

  Subverted, unauthorized and masquerading routers can slowdown their

==> s/slow/slow /

  [8]  Cheung, S.  et. al., "Protecting Routing Infrastructures from 
        Denial of Service using co-operative intrusion detection", In
        Proceedings  of the 1995 IEEE Symposium on Security and Privacy
        , May 1995.

  [9]  Bradley, K.  et. al., "A distributed Network Monitoring
        approach", Published , November 2001.

==> some references are not used, and these could be removed.  There are
probably more of them than just these two..

Appendix B. Acronyms

  AODV - Ad-hoc On-demand Distance Vector routing protocol

==> similarly, the acronyms should be cleaned of those that are not used in
the text or aren't otherwise relevant.

  administration. Each AS      normally uses a single interior gateway

==> kill the extra spaces :-)

5. Security Considerations

  This entire document is security related. Specifically the document 
  addresses security of routing protocols as associated with threats to
  those protocols. [...]
                                  This document discusses inter- and
  intra-domain routing protocol threats that are currently known [...]

==> the section should probably be more explicit that this document is
supposed to be protocol-independent.