Routing Area WG P. Savola
Internet-Draft CSC/FUNET
Intended status: Informational March 31, 2006
Expires: October 2, 2006
Backbone Infrastructure Attacks and Protections
draft-savola-rtgwg-backbone-attacks-00.txt
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-
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 2, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
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
[I-D.ietf-opsec-filter-caps].
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
noticeable.
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
[I-D.ietf-rpsec-routing-threats].
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
[I-D.ietf-tcpm-icmp-attacks].
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
configuration.
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
changeable.
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
routers.
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
enough..
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
draft.
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
[I-D.ietf-opsec-current-practices]
Kaeo, M., "Operational Security Current Practices",
draft-ietf-opsec-current-practices-02 (work in progress),
October 2005.
[I-D.ietf-rpsec-ospf-vuln]
Jones, E. and O. Moigne, "OSPF Security Vulnerabilities
Analysis", draft-ietf-rpsec-ospf-vuln-01 (work in
progress), December 2004.
[I-D.ietf-rpsec-routing-threats]
Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", draft-ietf-rpsec-routing-threats-07
(work in progress), October 2004.
[I-D.ietf-rtgwg-rfc3682bis]
Gill, V., "The Generalized TTL Security Mechanism (GTSM)",
draft-ietf-rtgwg-rfc3682bis-05 (work in progress),
April 2005.
[I-D.ietf-tcpm-icmp-attacks]
Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-icmp-attacks-00 (work in progress),
February 2006.
[I-D.ietf-tcpm-tcp-antispoof]
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
[I-D.ietf-opsec-filter-caps]
Morrow, C., "Filtering Capabilities for IP Network
Infrastructure", draft-ietf-opsec-filter-caps-00 (work in
progress), October 2005.
[I-D.ietf-tcpm-tcpsecure]
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.
[I-D.zinin-rtg-dos]
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
CSC/FUNET
Espoo
Finland
Email: psavola@funet.fi
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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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
http://www.ietf.org/ipr.
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
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Savola Expires October 2, 2006 [Page 12]