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]