idnits 2.17.1 draft-gont-6man-teredo-loops-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4380, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4380, updated by this document, for RFC5378 checks: 2003-06-09) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 8, 2010) is 4978 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance (6man) F. Gont 3 Internet-Draft UK CPNI 4 Updates: 4380 (if approved) September 8, 2010 5 Intended status: Standards Track 6 Expires: March 12, 2011 8 Mitigating Teredo Rooting Loop Attacks 9 draft-gont-6man-teredo-loops-00.txt 11 Abstract 13 Recently, a number of routing loop vulnerabilities were discovered in 14 Teredo. This document specifies a number of security checks to be 15 performed by Teredo hosts and Teredo servers such that these 16 vulnerabilities are eliminated. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 12, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Teredo Attacks . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Teredo Client to NAT . . . . . . . . . . . . . . . . . . . 3 55 2.1.1. Operational considerations . . . . . . . . . . . . . . 4 56 2.1.2. Implementation considerations . . . . . . . . . . . . . 4 57 2.2. Teredo Server . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2.1. Operational considerations . . . . . . . . . . . . . . 5 59 2.2.2. Implementation considerations . . . . . . . . . . . . . 5 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 66 Appendix A. Changes from previous versions of the draft (to 67 be removed by the RFC Editor before publishing 68 this document as an RFC) . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 [USENIX-WOOT] describes a number routing loop attacks that can be 74 performed, in a number of scenarios, against IPv6 automatic tunneling 75 mechanisms, possibly resulting in Denial of Service (DoS). This 76 document discusses the two Teredo routing loop attacks described 77 [USENIX-WOOT], and specifies a number of security checks such that 78 these vulnerabilities are eliminated. 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 2. Teredo Attacks 86 2.1. Teredo Client to NAT 88 This attack targets a Teredo client and the NAT(s) through which the 89 Teredo client connects to the public Internet. It assumes that the 90 NAT is of type "cone", and that the aforementioned NAT supports hair- 91 pin routing with source address translation. 93 The attack is initiated by sending a Teredo packet, with its IPv4 94 Source Address and its IPv4 Destination Address set to the Teredo 95 Mapped Address of the victim Teredo client, and the UDP Source Port 96 and the UDP Destination Port set to the Teredo Mapped Port of the 97 victim Teredo client. The IPv6 Source Address and IPv6 Destination 98 Address of the encapsulated IPv6 packet are Teredo addresses, with 99 their client IPv4 field and their Port field set to the "mapped IPv4 100 address" and the obfuscated "mapped UDP port" of the victim Teredo 101 client, respectively. The C (cone) bit of the IPv6 Destination 102 Address should be set to "1" (indicating a cone NAT) and the UG bits 103 of the same address should be set to "00" (indicating a non-global 104 unicast identifier). The Server IPv4 field and/or the other bits of 105 the Flags field of the IPv6 Destination Address should be different 106 from that of the victim Teredo client, such that the resulting 107 address is not the IPv6 address of the victim Teredo client. 109 The idea is that the forged IPv6 Source Address be such that it 110 passes the source address validation checks recommended in 111 [RFC4380]. The forged IPv6 Destination Address should cause the 112 packet to be looped back to the victim Teredo client, but should 113 not be the Teredo address of the victim Teredo client (or else the 114 packet would be processed by the Teredo client and the loop would 115 not occur). 117 Assuming that there already exists a corresponding mapping in the NAT 118 (as a result of the Teredo Initial Qualification Procedure), the 119 victim Teredo client will receive the forged packet. [Nakibly and 120 Arov, 2009] found that in some implementations, if the receiving node 121 is in forwarding mode (i.e., it is acting as a router), it will 122 forward the encapsulated IPv6 packet over the Teredo tunnel (as the 123 victim Teredo client was not the final destination of the packet). 124 This will result in a forwarding loop that will finish only when the 125 Hop Limit field of the encapsulated IPv6 packet is decremented to 0, 126 possibly leading to a Denial of Service (DoS). 128 There are a number of considerations that should be made about this 129 attack vector. Some of these considerations are operational, while 130 others have to do with the Teredo implementation at the victim Teredo 131 client. 133 2.1.1. Operational considerations 135 Firstly, given the deployment model of Teredo, it seems unlikely that 136 a node acting as a router would enable Teredo for obtaining its IPv6 137 connectivity. Secondly, enforcement of ingress/egress filtering 138 would probably mitigate this attack (although it would not prevent a 139 malicious node on the same network as the victim Teredo client from 140 launching the attack). 142 2.1.2. Implementation considerations 144 Given that Teredo is a mechanism of "last resort" for obtaining IPv6 145 connectivity by IPv6 hosts, a node SHOULD NOT forward over the Teredo 146 tunnel IPv6 packets that were not originated on the local node, and 147 SHOULD discard those packets received over the Teredo tunnel that are 148 not destined to the Teredo client. These security checks completely 149 eliminate this vulnerability. 151 2.2. Teredo Server 153 This attack vector engages only one victim, a Teredo server, and 154 consists in having the Teredo server send a Teredo bubble destined to 155 itself, which will result in a forwarding loop that will continue 156 indefinitely. 158 As the Teredo server decapsulates the bubble packet (an empty IPv6 159 datagram) and re-encapsulates it in another IPv4 packet before 160 forwarding it, there is no mechanism to limit the number of times 161 a bubble packet is "forwarded". 163 The attack consists in sending a forged "Teredo bubble" with the IPv4 164 Source Address and the IPv4 Destination Address both set to the IPv4 165 address of the victim Teredo server, and the UDP Source Port and the 166 UDP Destination Port both set to the Teredo UDP Port (3544). The 167 IPv6 Source Address and the IPv6 Destination Address of the 168 encapsulated IPv6 packet should have their client IPv4 field set to 169 the obfuscated IPv4 address of the victim Teredo server, and the 170 their Port field set to the obfuscated Teredo UDP port (3544). The 171 Server IPv4 field and the Flags field can be set to any value. 173 The idea is that the IPv6 Source Address must be such that the 174 forged Teredo packet will pass the source address validation 175 checks described in [RFC4380]. The IPv6 Destination Address must 176 be such that the forged Teredo bubble is re-sent by the victim 177 Teredo server to its own IPv4 address and Teredo UDP Port. 179 There are a number of considerations that should be made about this 180 attack vector. Some of these considerations are operational, while 181 others have to do with the Teredo implementation at the victim Teredo 182 client. 184 2.2.1. Operational considerations 186 Implementation of ingress/egress filtering would probably mitigate 187 this attack. However, ingres/egres filtering should not be relied 188 upon as the "first line of defense". 190 2.2.2. Implementation considerations 192 In order for this attack to succeed, a Teredo server must be willing 193 to accept a Teredo packet that contains its own address in the IPv4 194 Source Address field, and accept the Source Address and the 195 Destination Address of the encapsulated IPv6 packet to embed its own 196 (obfuscated) address in the "client IPv4" field. There are no 197 legitimate reasons for a Teredo packet to contain such values. 198 Therefore, this vulnerability could be eliminated by having Teredo 199 servers silently discard such Teredo packets. 201 Teredo servers MUST discard Teredo packets that have an IPv4 Source 202 Address equal to one of the receiving server's IPv4 addresses, and 203 MUST discard Teredo packets that embed the (obfuscated) IPv4 address 204 of the receiving server in the "client IPv4" field of the Source 205 Address or the Destination Address of the encapsulated IPv6 packet. 207 3. Security Considerations 209 This document updates [RFC4380] such that the two Teredo routing loop 210 vulnerabilities described in [USENIX-WOOT] are eliminated. 212 4. IANA Considerations 214 This document has no actions for IANA. 216 5. Acknowledgements 218 The routing loop attacks against Teredo discussed in this document 219 were discovered by Gabi Nakibly and Michael Arov, and documented in 220 [USENIX-WOOT]. 222 This document is heavily based on the upcoming document "Security 223 Implications of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6]. 225 Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for 226 their continued support. 228 6. References 230 6.1. Normative References 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, March 1997. 235 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 236 Network Address Translations (NATs)", RFC 4380, 237 February 2006. 239 6.2. Informative References 241 [CPNI-IPv6] 242 Gont, F., "Security Assessment of the Internet Protocol 243 version 6 (IPv6)", UK Centre for the Protection of 244 National Infrastructure, (to be published). 246 [USENIX-WOOT] 247 Nakibly, G., "Routing Loop Attacks using IPv6 Tunnels", 248 USENIX WOOT, 2009. 250 Appendix A. Changes from previous versions of the draft (to be removed 251 by the RFC Editor before publishing this document as an 252 RFC) 254 Author's Address 256 Fernando Gont 257 UK Centre for the Protection of National Infrastructure 259 Email: fernando@gont.com.ar 260 URI: http://www.cpni.gov.uk