Routing Area WG                                                P. Savola
Internet-Draft                                                 CSC/FUNET
Intended status: Informational                            March 31, 2006
Expires: October 2, 2006

            Backbone Infrastructure Attacks and Protections

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on October 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   A number of protection mechanisms for attacks against service
   provider backbone network infrastructure have been specified or
   proposed, each of them usually targeting a subset of the problem
   space.  There has never been a more generic analysis of the actual
   problems, and which protection techniques are even necessary (and
   where).  This document tries to provide that higher-level view.

Savola                   Expires October 2, 2006                [Page 1]

Internet-Draft          Attacks Against Backbone              March 2006

Table of Contents

   1.  Introduction and Assumptions . . . . . . . . . . . . . . . . .  3
   2.  Attack Vectors . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Lower-layer Attacks  . . . . . . . . . . . . . . . . . . .  3
     2.2.  Generic DoS on the Router  . . . . . . . . . . . . . . . .  4
     2.3.  Cryptographic Exhaustion Attacks . . . . . . . . . . . . .  4
     2.4.  Unauthorized Neighbor Attacks  . . . . . . . . . . . . . .  4
     2.5.  TCP RST Attacks  . . . . . . . . . . . . . . . . . . . . .  5
     2.6.  ICMP Attacks . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Typical Protection Mechanisms  . . . . . . . . . . . . . . . .  5
     3.1.  Address Filtering  . . . . . . . . . . . . . . . . . . . .  5
     3.2.  GTSM . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  TCP-MD5 and Other Custom Authentication  . . . . . . . . .  6
     3.4.  IPsec and IKE  . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Protocol Analysis  . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  IS-IS  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  BFD  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.4.  BGP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.5.  LDP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 12

Savola                   Expires October 2, 2006                [Page 2]

Internet-Draft          Attacks Against Backbone              March 2006

1.  Introduction and Assumptions

   A number of protection mechanisms for attacks against service
   provider backbone network infrastructure have been specified or
   proposed, each of them usually targeting a subset of the problem
   space.  There has never been a more generic analysis of the actual
   problems, and which protection techniques are even necessary (and
   where).  This document tries to provide that higher-level view.

   We'll assume that the service provider is doing at least some form of
   address filtering at its border devices, i.e., by ensuring that only
   the infrastructure nodes can use infrastructure source IP addresses
   to talk to the other nodes in the infrastructure.  So, for example,
   if a router sees an IP packet coming from a source address assigned
   to another router in the backbone, it can be sure the packet has been
   originated inside the backbone (assuming the physical security or
   nodes in the backbone have not been subverted).

   This requirement can be satisfied by applying ingress filtering at
   all your borders [RFC2827][RFC3704], but just filtering
   infrastructure source IP addresses from the outside is also
   sufficient.  Some may even implement this by blocking access to the
   infrastructure destination addresses at the border, but we do not
   describe this approach as that has a number of other issues.

   Current operational practices are described in
   [I-D.ietf-opsec-current-practices]; while almost all ISPs are capable
   of employing data plane filtering at the edges, at least one major
   ISP is known not do be able to due to legacy hardware limitations.
   Various diltering capabilities have been discussed at more length in

   If this requirement cannot be satisfied, other approaches are
   warranted.  For example, [I-D.zinin-rtg-dos] suggested an alternative
   (and in any case, provides good analysis); IPsec-protecting all the
   control traffic might also be possible if "all bets are off".

2.  Attack Vectors

   We'll describe the most obvious attack vectors.

2.1.  Lower-layer Attacks

   If an attacker has access to a (physical) link, it can obviously
   cause downtime for the link.  In many cases the downtime is not a
   critical threat, as it can be quickly noticed, traffic rerouted, and
   the problem fixed.  Some are more concerned about other forms of

Savola                   Expires October 2, 2006                [Page 3]

Internet-Draft          Attacks Against Backbone              March 2006

   attacks: insertion of eavesdropping or man-in-the-middle devices.
   Fortunately, installing such would require downtime and could be

   This is a more generic issue though: if one is concerned about this,
   one should really provide full integrity protection and even
   confidentiality to *all* the traffic, not just routing protocols.
   Hence, we are not concerned of lower-layer attacks as these are not
   specific to routing protocols.

2.2.  Generic DoS on the Router

   A typical attack is to overload a router using various techniques,
   e.g., by sending traffic exceeding the router's forwarding capacity,
   sending special transit packets that go through a "slow-path"
   processing, or by sending some packets directed at the router itself.

   Many of these techniques can be mitigated using implementation-
   specific rate-limiting mechanisms, so they are not addressed further
   in this memo.  However, p protocol designers should be advised to
   avoid any designs which require noticing and processing some special
   packets from the transit traffic (e.g., messages marked with router
   alert option).

2.3.  Cryptographic Exhaustion Attacks

   A special form of the above are attacks which target a protocol which
   uses cryptographic mechanisms, for example TCP-MD5 or IPsec.  The
   attacker sends valid protocol messages with cryptographic signatures
   or other properties to the router, which is forced to perform
   cryptographic validation of the message.  If the cryptographic
   operations are computationally expensive, the attack might succeed
   easier than with other generic DoS mechanisms.

   Some implementation-specific mitigation techniques (rate-limiting
   etc.) have been deployed, but as this affects the choice of a
   protection mechanism due to protocol design, we'll keep this attack
   in scope for this memo.

2.4.  Unauthorized Neighbor Attacks

   Unauthorized nodes can obtain a routing protocol adjacency e.g., on
   links where an IGP has been enabled by misconfiguration, or where
   authentication is not used.  This may result in many different kinds
   of attacks, for example traffic redirection

   At least in theory, some protocols can also be attacked in this way

Savola                   Expires October 2, 2006                [Page 4]

Internet-Draft          Attacks Against Backbone              March 2006

   from outside the link (e.g., OSPF [I-D.ietf-rpsec-ospf-vuln]).

   Therefore special care needs to be made to ensure misconfiguration of
   does not happen.

2.5.  TCP RST Attacks

   TCP sessions can be closed by attackers which can send a TCP RST
   packet with guessed spoofed endpoint identifiers and a sufficiently
   close sequence number.  The attacks and defenses have been described
   at length in [I-D.ietf-tcpm-tcp-antispoof].  One particular approach
   is modifying the TCP state machine [I-D.ietf-tcpm-tcpsecure].

2.6.  ICMP Attacks

   A slightly newer attack is employing ICMP by sending an ICMP type
   which indicates a hard error condition.  ICMP errors must be
   propagated to applications, and most applications heed the errors (as
   they should) e.g., by closing a connection or session.  ICMP attacks
   and defenses against TCP have been extensively described in

   It is also possible to execute ICMP attacks against other protocols
   such as UDP or IPsec, but the impact and whether/how these protocols
   demultiplex received errors have not been extensively studied.  IPsec
   is protected by ICMP attacks through a lot of assumptions (e.g., that
   only ICMP errors from the end-point are accepted) or manual

3.  Typical Protection Mechanisms

   We'll describe some of the most common protection or mitigation
   techniques applied today.

3.1.  Address Filtering

   As described in the first section, we already assume that the
   internal infrastructure is secure from spoofed messages that purport
   to come from inside the infrastructure.  More fine-grained, router-
   specific filters are sometimes deployed as well.

   A functionally similar technique (where available) it to use a
   distinct (public) address block for numbering the infrastructure
   devices, but not advertise it outside your system.  Obviously, this
   requires a separate assignment or fragmenting an aggregate prefix.
   This does not protect from your customers using a default route.

Savola                   Expires October 2, 2006                [Page 5]

Internet-Draft          Attacks Against Backbone              March 2006

3.2.  GTSM

   GTSM [I-D.ietf-rtgwg-rfc3682bis] is a technique where the sender of a
   packet sets the TTL/Hop Count to 255 and the receiver verifies it's
   still 255 (or some other preconfigured value).  This is a very useful
   protection method for control traffic which is inside a single link:
   any packets coming from outside the link can summarily be discarded.

   The open issue at the moment is how GTSM handles TCP RSTs.  I.e.,
   should it require that RSTs for a GTSM-enabled session should be sent
   with TTL=255 and verified to come with TTL=255 (or a configured
   value)?  Do implementations already do this?  Is there a sensible
   transition plan or need to make a change if any?  Note that this has
   only limited impact on GTSM's security as other TCP RST mitigation
   techniques still apply.

   We suggest that the GTSM spec is amended that TCP RSTs relating to to
   a GTSM-enabled protocol port MUST be sent with TTL=255.  (Note that
   this will require a kernel modification, and a means to specify to
   the kernel which ports relate to GTSM.).  The recipients behaviour
   SHOULD be configurable, and it is RECOMMENDED that the default be to
   discard messages where TTL is not 255 (or 255-TrustRadius).

3.3.  TCP-MD5 and Other Custom Authentication

   At least BGP and LDP are able to use the TCP-MD5 signature option to
   verify the authenticity of control packets.  TCP-MD5 uses manually
   configured static keys, so changing them typically resets the
   protocol session, so the solution is sub-optimal in cases where the
   security procedures require that the keys must be easily and often

   Using TCP-MD5 and other similar authentication mechanisms (e.g., for
   IGPs or BFD) also opens an attack vector for cryptographic exhaustion
   attacks unless implementations have appropriate mechanisms to
   throttle these.  In the case of IGPs, the attack vector is typically
   smaller though.

3.4.  IPsec and IKE

   IPsec and IKE have been proposed as a more comprehensive protection
   mechanism, but it also requires a lot of heavyweight protocol
   machinery, lots of configuration, and cryptographic processing.

4.  Protocol Analysis

   We'll briefly discuss the protocol-specific attack properties below.

Savola                   Expires October 2, 2006                [Page 6]

Internet-Draft          Attacks Against Backbone              March 2006

   ICMP attacks apply to all the IP protocols at least to some degree.
   There is no reasonable way to appropriately protect from these
   attacks by operative methods: the vendors should implement
   countermeasures described in [I-D.ietf-tcpm-icmp-attacks] to mitigate
   this risk.

4.1.  OSPF

   In the past, there has already been some analysis of OSPF attacks
   [I-D.ietf-rpsec-ospf-vuln].  In this context the most important of
   them are: (1) preventing misconfiguration and unauthorized neighbors,
   and (2) ensuring off-path directed attacks as described in Section
   3.1.2 of [I-D.ietf-rpsec-ospf-vuln].

   The former requires configuration change procedures and regular
   audits of OSPF configuration, and disabling OSPF adjacencies on
   customer-facing links, or adding authentication when there are
   multiple routers.  The latter requires using OSPF authentication,
   dropping all OSPF traffic at all the borders, or moving to another,
   less vulnerable protocol (e.g., IS-IS).

   OSPF is also used to some degree with provider-provisioned VPNs by
   the customers.  The author is not familiar with this scenario, so
   these threats are not analyzed.

4.2.  IS-IS

   Routing IP with IS-IS has gained popularity in the backbone networks
   lately.  As IS-IS does not use IP, it is sufficient to prevent
   misconfiguration and unauthorized neighbors.  The same techniques
   apply as to OSPF: configuration change procedures and regular
   configuration audits and disabling IS-IS adjacencies on customer-
   facing links, or adding authentication when there are multiple

4.3.  BFD

   Bidirectional Forwarding Detection (BFD) detects faults in the
   forwarding path between two endpoints.  As a generic mechanism, it
   can be applied to a number of protocols, e.g., OSPF, IS-IS, BGP,
   MPLS, or static routes.

   When BFD is in use for a single-hop scenario, it uses GTSM to protect
   from off-link attackers.  Authentication can also be used e.g., on
   untrusted links.

   XXX: it's a bit cornercase whether to even include BFD here as it's
   not a routing protocol as such; however, as resetting BFD session

Savola                   Expires October 2, 2006                [Page 7]

Internet-Draft          Attacks Against Backbone              March 2006

   could result in losing a protocol adjacency, it seems a relevant

4.4.  BGP

   Internal BGP sessions run between loopback addresses.  There is no
   need to run TCP-MD5 for outsider protection as address filtering will
   avoid TCP RST attacks.

   External BGP sessions may run multi-hop between loopback addresses or
   single-hop between interface addresses.  The latter case is much more
   common and easier to protect and applying GTSM provides first-order
   resistance to off-link attackers.

   In any case, assuming address filtering, the session can only be
   reset by the peer, or by attacks from the direction of the peer's
   network (e.g., through lack of peer's border filtering).  One can
   therefore question the necessity of further protection as the peer
   can only shoot itself in the foot by killing the BGP session or
   allowing the BGP session be killed through negligence.

   If the link is not trusted (e.g., in some large Ethernet-based
   Internet Exchange points), it may also be desirable ensure that peers
   are not able to reset others' sessions, so a mechanism like TCP-MD5
   may be appropriate.  One should note that the security requirements
   are not necessarily very high as the attacker should already be
   easily traceable on a single link, and thus re-keying may not be
   worth the trouble.

4.5.  LDP

   TBD -- send text, similar to single-hop BGP?

5.  Summary

   IGPs require a great deal of care to ensure that they are not enabled
   on links where they shouldn't be.  Preventing external OSPF attacks
   also requires OSPF authentication everywhere or filtering OSPF
   packets at the edges.

   ICMP attacks are able to cause a great deal of harm to almost all the
   protocols, including IPsec, and there is little to do to mitigate the
   risk except to implement enhanced ICMP payload verification/
   processing techniques.  More study of the impact on connectionless
   protocols and IPsec should be conducted.

   With border address filtering in place, internal sessions are

Savola                   Expires October 2, 2006                [Page 8]

Internet-Draft          Attacks Against Backbone              March 2006

   reasonably safe.  With additional GTSM protection, external private
   interconnection links are also reasonably safe, as the session can
   only be reset by the neighbor or due to lack of filtering, someone
   through the neighbor's network.  TCP-MD5 protection is most
   appropriate for Internet Exchange points with multiple neighbors or
   multihop eBGP sessions, but it's worth remembering that the security
   requirements for the solution are not very high as the attackers have
   very strict topological restrictions.

   IPsec and IKE are obviously an option for heavy-weight protection,
   but impractical (yet) due to configuration complexity and processing
   overhead.  Simplifications in configuration, implementation, and
   cryptographic hardware offloading might help the situation for the
   cases where the use of heavier protection (e.g., possibly Internet
   Exchange points) could be warranted.

6.  IANA Considerations

   This memo makes no request to IANA.

7.  Acknowledgements

   George Jones suggested improvements to the initial version of this

8.  Security Considerations

   This document is all about security, but the most important issues
   that should be noted are its security assumptions:

   o  There is at least certain degree of address filtering at borders,
      else all bets are off.

   o  Lower-layer attacks are not considered a particular concern for
      routing protocols.

   o  Generic DoS attacks against routers can be mitigated using
      implementation-specific measures.

9.  References

Savola                   Expires October 2, 2006                [Page 9]

Internet-Draft          Attacks Against Backbone              March 2006

9.1.  Normative References

              Kaeo, M., "Operational Security Current Practices",
              draft-ietf-opsec-current-practices-02 (work in progress),
              October 2005.

              Jones, E. and O. Moigne, "OSPF Security Vulnerabilities
              Analysis", draft-ietf-rpsec-ospf-vuln-01 (work in
              progress), December 2004.

              Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
              Routing Protocols", draft-ietf-rpsec-routing-threats-07
              (work in progress), October 2004.

              Gill, V., "The Generalized TTL Security Mechanism (GTSM)",
              draft-ietf-rtgwg-rfc3682bis-05 (work in progress),
              April 2005.

              Gont, F., "ICMP attacks against TCP",
              draft-ietf-tcpm-icmp-attacks-00 (work in progress),
              February 2006.

              Touch, J., "Defending TCP Against Spoofing Attacks",
              draft-ietf-tcpm-tcp-antispoof-03 (work in progress),
              February 2006.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, March 2004.

9.2.  Informative References

              Morrow, C., "Filtering Capabilities for IP Network
              Infrastructure", draft-ietf-opsec-filter-caps-00 (work in
              progress), October 2005.

              Stewart, R. and M. Dalal, "Improving TCP's Robustness to

Savola                   Expires October 2, 2006               [Page 10]

Internet-Draft          Attacks Against Backbone              March 2006

              Blind In-Window Attacks", draft-ietf-tcpm-tcpsecure-04
              (work in progress), February 2006.

              Zinin, A., "Protecting Internet Routing Infrastructure
              from Outsider DoS Attacks", draft-zinin-rtg-dos-02 (work
              in progress), May 2005.

Author's Address

   Pekka Savola


Savola                   Expires October 2, 2006               [Page 11]

Internet-Draft          Attacks Against Backbone              March 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Savola                   Expires October 2, 2006               [Page 12]