idnits 2.17.1 draft-itojun-ipv6-transition-abuse-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 10, 2000) is 8691 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) -- Missing reference section? 'Gilligan' on line 146 looks like a reference -- Missing reference section? '1996' on line 45 looks like a reference -- Missing reference section? '2000' on line 195 looks like a reference -- Missing reference section? 'Kent' on line 106 looks like a reference -- Missing reference section? '1998' on line 193 looks like a reference -- Missing reference section? 'Carpenter' on line 138 looks like a reference -- Missing reference section? '1999' on line 182 looks like a reference -- Missing reference section? 'Allman' on line 182 looks like a reference -- Missing reference section? 'Hinden' on line 193 looks like a reference -- Missing reference section? 'Nordmark' on line 195 looks like a reference -- Missing reference section? 'Kantor' on line 273 looks like a reference -- Missing reference section? '1991' on line 273 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Jun-ichiro itojun Hagino 2 INTERNET-DRAFT Research Lab, IIJ 3 Expires: January 10, 2001 July 10, 2000 5 Possible abuse against IPv6 transition technologies 6 draft-itojun-ipv6-transition-abuse-01.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as ``work in progress.'' 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Distribution of this memo is unlimited. 30 The internet-draft will expire in 6 months. The date of expiration will 31 be January 10, 2001. 33 Abstract 35 The document talks about possible abuse of IPv6 transition technologies, 36 which may lead to denial-of-service (DoS) attacks and other problems. 37 IPv6 transition technologies, namely IPv6 over IPv4 tunnelling 38 specifications and some others, have room for abuse by malicious 39 parties. Detailed descriptions and possible workarounds are supplied. 41 1. Abuse of IPv4 compatible address 43 1.1. Problem 45 To implement automatic tunnelling described in RFC1933 [Gilligan, 1996] 46 , IPv4 compatible addresses (like ::123.4.5.6) are used. From IPv6 47 stack point of view, an IPv4 compatible address is considered to be a 48 normal unicast address. If an IPv6 packet has IPv4 compatible addresses 49 in the header, the packet will be encapsulated automatically into an 50 IPv4 packet, with IPv4 address taken from lowermost 4 bytes of the IPv4 51 compatible addresses. Since there is no good way to check if embedded 52 IPv4 address is sane, improper IPv4 packet can be generated as a result. 53 Malicious party can abuse it, by injecting IPv6 packets to an IPv4/v6 54 dual stack node with certain IPv6 source address, to cause transmission 55 of unexpected IPv4 packets. Consider the following scenario: 57 o You have an IPv6 transport-capable DNS server, running on top of 58 IPv4/v6 dual stack node. The node is on IPv4 subnet 10.1.1.0/24. 60 o Malicious party transmits an IPv6 UDP packet to port 53 (DNS), with 61 source address ::10.1.1.255. It does not make difference if it is 62 encapsulated into an IPv4 packet, or is transmitted as a native IPv6 63 packet. 65 o IPv6 transport-capable DNS server will transmit an IPv6 packet as a 66 reply, copying the original source address into the destination 67 address. Note that the IPv6 DNS server will treat IPv6 compatible 68 address as normal IPv6 unicast address. 70 o The reply packet will automatically be encapsulated into IPv4 packet, 71 based on RFC1933 automatic tunnelling. As a result, IPv4 packet 72 toward 10.1.1.255 will be transmitted. This is the subnet broadcast 73 address for your IPv4 subnet, and will (improperly) reach every node 74 on the IPv4 subnet. 76 1.2. Possible solutions 78 For the following sections, possible soluitions are presented in the 79 order of preference (the author recommends to implement solutions that 80 appear earlier). Note that some of the following are partial solution 81 to the problem. Some of the solutions may overwrap, or be able to 82 coexist, with other solutions. Solutions marked with (*) are already 83 incorporated into [Gilligan, 2000] which is an updated version of 84 RFC1933. Note that, however, solutions incorporated into [Gilligan, 85 2000] do not make a complete protection against malicious parties. 87 o Disable automatic tunnelling support. 89 o Reject IPv6 packets with IPv4 compatible address in IPv6 header 90 fields. Note that we may need to check extension headers as well. 92 o Perform ingress filter against IPv6 packet and tunnelled IPv6 packet. 93 Ingress filter should let the packets with IPv4 compatible source 94 address through, only if the source address embeds an IPv4 address 95 belongs to the organization. The approach is a partial solution for 96 avoiding possible transmission of malicious packet, from the 97 organization to the outside. (*) 99 o Whenever possible, check if the addresses on the packet meet the 100 topology you have. For example, if the IPv4 address block for your 101 site is 43.0.0.0/8, and you have a packet from IPv4-wise outside with 102 encapsulated IPv6 source matches ::43.0.0.0/104, it is likely that 103 someone is doing something nasty. This may not be possible to make 104 the filter complete, so consider it as a partial solution. (*) 106 o Require use of IPv4 IPsec, namely authentication header [Kent, 1998] , 107 for encapsulated packet. Even with IPv4 IPsec, reject the packet if 108 the IPv6 compatible address in the IPv6 header does not embed the IPv4 109 address in the IPv4 header. We cannot blindly trust the inner IPv6 110 packet based on the existence of IPv4 IPsec association, since the 111 inner IPv6 packet may be originated by other nodes and forwarded by 112 the authenticated peer. The solution may be impractical, since it 113 only solves very small part of the problem with too many requirements. 115 o Reject inbound/outgoing IPv6 packets, if it has certain IPv4 116 compatible address in IPv6 header fields. Note that we may need to 117 check extension headers as well. The author recommends to check any 118 IPv4 compatible address that is mapped from/to IPv4 address not 119 suitable as IPv4 peer. They include 0.0.0.0/8, 127.0.0.0/8, 120 224.0.0.0/4, 255.255.255.255/32, and subnet broadcast addresses. 121 Since the check can never be perfect (we cannot check for subnet 122 broadcast address in remote site, for example) the direction is not 123 recommend. (*) 125 2. Abuse of 6to4 address 127 6to4 [Carpenter, 2000] is another proposal for IPv6-over-IPv4 packet 128 encapsulation, and is very similar to RFC1933 automatic tunneling 129 mentioned in the previous section. 6to4 address embeds IPv4 address in 130 the middle (2nd byte to 5th byte). If an IPv6 packet has a 6to4 address 131 as destination address, it will be encapsulated into IPv4 packet with 132 the embedded IPv4 address as IPv4 destination. 134 IPv6 packets with 6to4 address have the same problems as those with IPv4 135 compatible address. See the previous section for the details of the 136 problems, and possible solutions. 138 The latest 6to4 draft [Carpenter, 2000] do incoporate some of the 139 solutions presented in the previous section, however, they do not make a 140 complete protection against malicious parties. 142 3. Abuse of IPv4 mapped address 144 3.1. Problems 146 IPv6 basic socket API [Gilligan, 1999] defines the use of IPv4 mapped 147 address with AF_INET6 sockets. IPv4 mapped address is used to handle 148 inbound IPv4 traffic toward AF_INET6 sockets, and outbound IPv4 traffic 149 from AF_INET6 sockets. Inbound case has higher probability of abuse, 150 while outbound case contributes to the abuse as well. Here we briefly 151 describe the kernel behavior in inbound case. When we have an AF_INET6 152 socket bound to IPv6 unspecified address (::), IPv4 traffic, as well as 153 IPv6 traffic, will be captured by the socket. The kernel will present 154 the address of the IPv4 peer to the userland program by using IPv4 155 mapped address. For example, if an IPv4 traffic from 10.1.1.1 is 156 captured by an AF_INET6 socket, the userland program will think that the 157 peer is at ::ffff:10.1.1.1. The userland program can manipulate IPv4 158 mapped address just like it would do against normal IPv6 unicast 159 address. 161 We have three problems with the specification. First, IPv4 mapped 162 address support complicates IPv4 access control mechanisms. For 163 example, if you would like to reject accesses from IPv4 clients to a 164 certain transport layer service, it is not enough to reject accesses to 165 AF_INET socket. You will need to check AF_INET6 socket for accesses 166 from IPv4 clients (seen as accesses from IPv4 mapped address) as well. 168 Secondly, malicious party may be able to use IPv6 packets with IPv4 169 mapped address, to bypass access control. Consider the following 170 scenario: 172 o Attacker throws unencapsulated IPv6 packets, with ::ffff:127.0.0.1 as 173 source address. 175 o The access control code in the server thinks that this is from 176 localhost, and grants accesses. 178 Lastly, malicious party can make servers generate unexpected IPv4 179 traffic. This can be accomplished by sending IPv6 packet with IPv4 180 mapped address as a source (similar to abuse of IPv4 compatible 181 address), or by presenting IPv4 mapped address to servers (like FTP 182 bounce attack [Allman, 1999] from IPv6 to IPv4). The problem is 183 slightly different from the problems with IPv4 compatible addresses and 184 6to4 addresses, since it does not make use of tunnels. It makes use of 185 certain behavior of userland applications. 187 The confusion came from the dual use of IPv4 mapped address, for node- 188 internal representation for remote IPv4 destination/source, and for real 189 IPv6 destination/source. 191 3.2. Possible solutions 193 o In IPv6 addressing architecutre document [Hinden, 1998] , disallow the 194 use of IPv4 mapped addresses on the wire. The change will conflict 195 with SIIT [Nordmark, 2000] , which is the only protocol which tries to 196 use IPv4 mapped address on IPv6 native packet. The dual use of IPv4 197 mapped address (as a host-internal representation of IPv4 198 destinations, and as a real IPv6 address) is the prime source of the 199 problem. 201 o Reject IPv6 packets, if it has IPv4 mapped address in IPv6 header 202 fields. Note that we may need to check extension headers such as 203 routing headers, as well. IPv4 mapped address is internal 204 representation in a node, so doing this will raise no conflicts with 205 existing protocols. We recommend to check the condition in IPv6 input 206 packet processing, and transport layer processing (TCP input and UDP 207 input) to be sure. 209 o Reject DNS replies, or other host name database replies, which contain 210 IPv4 mapped address. Again, IPv4 mapped address is internal 211 represntation in a node and should never appear on external host name 212 databases. 214 o Do not route inbound IPv4 traffic to AF_INET6 sockets. When an 215 application would like to accept IPv4 traffic, it should explicitly 216 open AF_INET sockets. You may want to run two applications instead, 217 one for an AF_INET socket, and another for an AF_INET6 socket. Or you 218 may want to make the functionality optional, off by default, and let 219 the userland applications explicitly enable it. This greatly 220 simplifies access control issues. This approach conflicts with what 221 IPv6 basic API document says, however, it should raise no problem with 222 properly-written IPv6 applications. It only affects server programs, 223 ported by assuming the behavior of AF_INET6 listening socket against 224 IPv4 traffic. 226 o When implementing TCP or UDP stack, explicitly record the wire packet 227 format (IPv4 or IPv6) into connection table. It is unwise to guess 228 the wire packet format, by existence of IPv6 mapped address in the 229 address pair. 231 o We should separately fix problems like FTP bounce attack. 233 o Applications should always check if the connection to AF_INET6 socket 234 is from an IPv4 node (IPv4 mapped address), or IPv6 node. It should 235 then treat the connection as from IPv4 node (not from IPv6 node with 236 special adderss), or reject the connection. This is, however, 237 dangerous to assume that every application implementers are aware of 238 the issue. The solution is not recommended (this is not a solution 239 actually). 241 4. Attacks by combining different address formats 243 Malicious party can use different address formats simultaneously, in a 244 single packet. For example, suppose you have implemented checks for 245 abuse against IPv4 compatible address in automatic tunnel egress module. 246 Bad guys may try to send a native IPv6 packet with 6to4 destination 247 address with IPv4 compatible source address, to bypass security checks 248 against IPv4 compatible address in tunnel decapsulation module. Your 249 implementation will not be able to detect it, since the packet will not 250 visit egress module for automatic tunnels. 252 Analyze code path with great care, and reject any packets that does not 253 look sane. 255 5. Attacks using source address-based authentication 257 5.1. Problems 259 IPv6-to-IPv4 translators [Nordmark, 2000; Tsirtsis, 2000; Hagino, 2000] 260 usually relay, or rewrite, IPv6 packet into IPv4 packet. The IPv4 261 source address in the IPv4 packet will not represent the ultimate source 262 node (IPv6 node). Usually the IPv4 source address represents translator 263 box instead. If we use the IPv4 source address for authentication at 264 the destination IPv4 node, all traffic relayed/translated by the 265 translator box will mistakenly be considered as authentic. 267 The problem applies to IPv4-to-IPv6 translators as well. The problem is 268 similar to proxied services, like HTTP proxy. 270 5.2. Possible solutions 272 o Do not use translators, for protocols that use IP source address as 273 authentication credental (for example, rlogin [Kantor, 1991] ). 275 o translators must implement some sort of access control, to reject any 276 IPv6 traffic from malicious IPv6 nodes. 278 o Do not use source address based authentication. IP source address 279 should not be used as an authentication credental from the first 280 place, since it is very easy for malicious parties to spoof IP source 281 address. 283 6. Conclusions 285 IPv6 transition technologies have been proposed, however, some of them 286 looks immune against abuse. The document presented possible ways of 287 abuse, and possible solutions against them. The presented solutions 288 should be reflected to the revision of specifications referenced. 290 For coming protocols, the author would like to propose a set of 291 guilelines for IPv6 transition technologies: 293 o Tunnels must explicitly be configured. Manual configuration, or 294 automatic configuration with proper authentication, should be okay. 296 o Do not embed IPv4 addresses into IPv6 addresses, for tunnels or other 297 cases. It leaves room for abuse, since we cannot practically check if 298 embedded IPv4 address is sane. 300 o Do not define an IPv6 address format that does not appear on the wire. 301 It complicates access control issues. 303 The author hopes to see more deployment of native IPv6 networks, where 304 tunnelling technologies become unnecessary. 306 7. Security considerations 308 The document talks about security issues in existing IPv6 related 309 protocol specifications. Possible solutions are provided. 311 References 313 Gilligan, 1996. 314 R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and 315 Routers" in RFC1933 (April 1996). ftp://ftp.isi.edu/in- 316 notes/rfc1933.txt. 318 Gilligan, 2000. 319 R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and 320 Routers" in draft-ietf-ngtrans-mech-06.txt (April 2000). work in 321 progress. 323 Kent, 1998. 324 S. Kent and R. Atkinson, "IP Authentication Header" in RFC2402 (November 325 1998). ftp://ftp.isi.edu/in-notes/rfc2402.txt. 327 Carpenter, 2000. 328 Brian Carpenter and Keith Moore, "Connection of IPv6 Domains via IPv4 329 Clouds without Explicit Tunnels" in draft-ietf-ngtrans-6to4-06.txt (June 330 2000). work in progress. 332 Gilligan, 1999. 333 R. Gilligan, S. Thomson, J. Bound, and W. Stevens, "Basic Socket 334 Interface Extensions for IPv6" in RFC2553 (March 1999). 335 ftp://ftp.isi.edu/in-notes/rfc2553.txt. 337 Allman, 1999. 338 M. Allman and S. Ostermann, "FTP Security Considerations" in RFC2577 339 (May 1999). ftp://ftp.isi.edu/in-notes/rfc2577.txt. 341 Hinden, 1998. 342 R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in 343 RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. 345 Nordmark, 2000. 346 E. Nordmark, "Stateless IP/ICMP Translator (SIIT)" in RFC2765 (February, 347 2000). ftp://ftp.isi.edu/in-notes/rfc2765.txt. 349 Tsirtsis, 2000. 350 G. Tsirtsis and P. Srisuresh, "Network Address Translation - Protocol 351 Translation (NAT-PT)" in RFC2766 (February 2000). ftp://ftp.isi.edu/in- 352 notes/rfc2766.txt. 354 Hagino, 2000. 355 Jun-ichiro Hagino and Kazu Yamamoto, "An IPv6-to-IPv4 transport relay 356 translator" in draft-ietf-ngtrans-tcpudp-relay-01.txt (May 2000). work 357 in progress material. 359 Kantor, 1991. 360 B. Kantor, "BSD Rlogin" in RFC1282 (December 1991). 361 ftp://ftp.isi.edu/in-notes/rfc1282.txt. 363 Author's address 365 Jun-ichiro itojun Hagino 366 Research Laboratory, Internet Initiative Japan Inc. 367 Takebashi Yasuda Bldg., 368 3-13 Kanda Nishiki-cho, 369 Chiyoda-ku,Tokyo 101-0054, JAPAN 370 Tel: +81-3-5259-6350 371 Fax: +81-3-5259-6351 372 email: itojun@iijlab.net