Subject: [RPSEC] AD-review: draft-ietf-rpsec-routing-threats

From: Alex Zinin <[email-masked]>
Date: Fri, 12 Sep 2003 14:44:42 -0700

The draft is a big step forward, I believe. However,
I have several concerns and comments:

Meta-comments

1. Use of the models defined in sections 2 and 2.1

   Seems that section 3 is the only place where the RP functional
   model is used. The rest of the document does not benefit from it,
   i.e. the threat descriptions do not identify the levels at which
   the threat actions and threat consequences occur. Having this type
   of analysis should help formulate the requirements for security
   mechanisms that should cover certain threats.

   The control and data plane within routing protocols does not seem
   to be used in the document at all and I wonder if we really need
   it there.

2. Byzantine failures as a threat.

   Section 4.8 talks about Byzantine failures and is positioned within
   the structure of the document as part of the "Generally
   Identifiable Routing Threats". It was not clear to me what threats
   different from those described in sections 4.1--4.7 are implied
   in this section.

3. Terminology.

   The document uses the term "forward" and "forwarder" to mean
   the routing message or PDU relaying process. This collides with
   the generally accepted use of these terms to mean data packet
   forwarding. My suggestion would be to not confuse these.

More specific comments on the document:

Section 1. Introduction

2nd para:

>    This documents takes a 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 Rggistry (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.

--stands out from the 1st and 3rd. Since it defines a term, it might
be a good idea to move to the very end of the section.

...

>    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 implementers to
>    increase the robustness of their implementations.

I would remove this one--seems that an explanation like this belongs
in the reqs document itself.

> 2. Routing Functions Overview
...
>    o  Transport Subsystem: The routing protocol transmits messages to
>       its neighbors using some underlying protocol.  For example, OSPF
>       uses IP, while AODV uses a broadcast link. Other protocols may run
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
what does this really mean? AODV uses UDP as the transport proto.

> 3. Generic Routing Protocol Threat Model
...
>    At the routing function level threats can affect the transport
>    subsystem, where the routing protocol can be subject to attacks on
>    its underlying protocol. At the neighbor state maintenance level,
>    there are threats that can lead to attacks that can disrupt the
>    neighboring relationship with widespread consequences.  For example,
>    if the DR election is disrupted in an OSPF network,

what is meant by "DR election is disrupted"?

> an unauthorized
>    router could be chosen as designated router.  This might allow
>    unauthorized access to routing information.

In fact, it is not necessary to be a DR to get access to OSPF
LSAs, as they are flooded to all routers.

> In BGP, if a router
>    receives a CEASE message, it can break the neighboring relationship
>    and cause any related topology information to be flushed.

Strictly speaking, BGP does not carry topology information.

>    There are threats against the database maintenance functionality. For
>    example, the information in the database must be authentic and
>    authorized. Threats that jeopardize this information can affect the
>    routing functionality in the overall network.  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.

or will loop it, which is worse

...

> 3.1.1 Threat Sources
...
>    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 host is determined to be an outsider or an
>    insider from the point of view of a particular router.  Even an
>    authorized 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).

This one is really hard to parse. Essentially what the text seems to
say is that an insider is foo, but then that even the insider can
be an outsider. Is it meant to say that router A authorized to
talk to B, but not to C is an outsider to C?

>    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. Furthermore, MANET protocols
>    frequently speak over the broadcast link.
                                             ^
                                      and what does this mean?

> 3.1.2 Threat Consequences
...
>    o  Disclosure: Disclosure of routing information happens when a
>       router successfully accesses the information without being
                                      
does it have to be a router? "an attacker" instead?

> 4.6 Interference
...
>    o  When a subverted link is used to launch the action, the threat
>       consequence zone covers routers that are using the link to
>       exchange the routing information.

not only. attack on a link causes consequences at the neighbor
maintenance level, which causes changes in the database. i.e.,
the consequences are network-wide.

> 4.7 Overload

The section does not talk about state overloading in the control
plane. I.e., since we trust all authorized routers, it is possible
for e.g. a compromised router to trigger creation of an excessive
amount of state that routers within the network are not able to
handle.

> 5. Security Considerations
> 
>    This entire informational draft RFC is security related. Specifically
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          change to "document"?
          
>    it addresses security of routing protocols as associated with threats
>    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.
>    However, to date, routing protocols have largely remained unprotected
>    and open to malicious attacks.  This document discusses inter and
>    intra domain routing protocol threats as we know them today and lays
>    the foundation for a future draft which fully discusses security
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        "other documents that will discuss"?
                        
>    requirements for routing protocols.

> Appendix B. Acronyms

  Some acronyms (e.g., LSRP, iBGP, eBGP) are not used in the document

Regards

--
Alex

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