idnits 2.17.1 draft-itojun-v6ops-v4mapped-harmful-00.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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** The abstract seems to contain references ([Gilligan,1999], [Hinden,1998]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (Aug 22, 2002) is 7916 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? 'Hinden' on line 112 looks like a reference -- Missing reference section? '1998' on line 112 looks like a reference -- Missing reference section? 'Gilligan' on line 134 looks like a reference -- Missing reference section? '1999' on line 113 looks like a reference -- Missing reference section? 'Nordmark' on line 55 looks like a reference -- Missing reference section? '2000' on line 55 looks like a reference -- Missing reference section? '2002' on line 134 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Jun-ichiro itojun Hagino 3 INTERNET-DRAFT Research Lab, IIJ 4 Expires: Feb 22, 2003 Aug 22, 2002 6 IPv4 mapped address considered harmful 7 draft-itojun-v6ops-v4mapped-harmful-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as ``work in progress.'' 23 To view the list Internet-Draft Shadow Directories, see 24 http://www.ietf.org/shadow.html. 26 Distribution of this memo is unlimited. 28 The internet-draft will expire in 6 months. The date of expiration will 29 be Feb 22, 2003. 31 Abstract 33 IPv6 address architecture [Hinden, 1998] defines IPv4 mapped address. 34 The representation is used in IPv6 basic API [Gilligan, 1999] to denote 35 IPv4 destinations on AF_INET6 socket within the API. At the same time, 36 there are protocol proposals that use IPv4 mapped address on wire. 37 Therefore, IPv4 mapped address has two meanings, and they are not 38 distinguishable from the userland applications. This draft discusses 39 security threats due to the dual use of IPv4 mapped address. It also 40 discusses threats due to the additional complexities introduced by IPv4 41 mapped address. 43 1. Dual meaning of IPv4 mapped address 45 IPv6 basic socket API [Gilligan, 1999] defines the use of IPv4 mapped 46 address with AF_INET6 sockets. IPv4 mapped address is used as an 47 internal identifier for IPv4 peers, on AF_INET6 sockets. The API is 48 designed with IPv4/v6 dual stack nodes in mind. When an IPv4 packet 49 reaches an IPv4/v6 dual stack node, kernel IPv4 layer will handle it, 50 then passes it up to TCP/UDP layer. When TCP/UDP layer finds an 51 AF_INET6 listening socket, it will pass the packet to the listening 52 socket as if it was from the corresponding IPv4 mapped address. Let us 53 call it "basic API behavior" in this draft. 55 Some of the translator technologies such as SIIT [Nordmark, 2000] uses 56 IPv4 mapped address in header fields of actual IPv6 packet on wire. 57 These technologies are designed with IPv6 only nodes in mind. It is 58 assumed that IPv6 packets with IPv4 mapped address will be handled by 59 IPv6 layer then by TCP/UDP layer, and reaches an AF_INET6 socket. Let 60 us call it "SIIT behavior" in this draft. 62 2. Threats due to the use of IPv4 mapped address on wire 64 When userland application on top of AF_INET6 API sees peers with IPv4 65 mapped addresses (like by getpeername(2) or recvfrom(2)), it cannot 66 detect if the packet actually was IPv4 (IPv4 mapped address appeared due 67 to basic API behavior) or IPv6 (SIIT behavior). 69 This ambiguity creates chances to malicious party to trick victim nodes. 70 Here are a couple of examples: 72 o By transmitting IPv6 packet with ::ffff:127.0.0.1 in IPv6 source 73 address field, applications that assume basic API behavior will be 74 tricked to believe that the packet is from the node itself (IPv4 75 loopback address, 127.0.0.1). 77 o By transmitting IPv6 packet to firewall device, with IPv4 mapped 78 address corresponds to address inside the firewall (like 79 ::ffff:10.1.1.1) as the IPv6 source address, malicious party could 80 bypass IPv4 filtering rules and inject traffic inside the firewall. 82 o Assume that the victim node is an IPv4/v6 dual stack node. By 83 transmitting IPv6 packet with IPv4 mapped address corresponds to IPv4 84 broadcast address (::ffff:10.255.255.255) in IPv6 source address 85 field, to TCP/UDP port that swaps IPv6 source and destination address 86 (e.g. UDP port 53, DNS), malicious node can trick the victim node to 87 generate improper IPv4 broadcast traffic; This is because basic API on 88 the victim node will emit transmission requests to destination IPv4 89 mapped address, ::ffff:10.255.255.255, into IPv4 traffic. 91 3. Other threats related to IPv4 mapped address 93 3.1. Access control complexity 95 RFC2553 section 3.7 adds complexity to access controls. Due to the 96 additional complexity, it is likely that there will be many mistakes in 97 access controls. 99 Due to RFC2553 section 3.7, AF_INET6 socket will accept IPv4 packets. 100 On an IPv4/v6 dual stack node, if there is no AF_INET listening socket, 101 normal administrators would believe that there will be no access from 102 IPv4 peers. However, if AF_INET6 listening socket is present, IPv4 103 peers will be able to access the service. 105 To protect applications from this threat, every access control logic has 106 to have a special case handling for IPv4 mapped address. It is 107 impossible to enforce such a requirement to every application 108 implementations. 110 4. Suggested protocol change 112 o In IPv4 address architecture document [Hinden, 1998] explicitly state 113 that IPv4 mapped address is for use within basic API [Gilligan, 1999] 114 , and basic API only. Forbid any other uses. 116 o Move any document that suggests the use of IPv4 mapped address on wire 117 to historic, due to security reasons. 119 The above change will remove the threat due to the use of IPv4 mapped 120 address on wire. 122 Another way is to deprecate RFC2553 section 3.7, however, due to the 123 wide deployment of applications that use IPv6 basic API, the option is 124 not feasible. 126 5. Suggested implementation tips 128 5.1. Kernel/library developers 130 o Do not support IPv4 mapped address on AF_INET6 API (RFC2553 section 131 3.7). By doing so the kernel TCP/UDP code will be greatly simplified, 132 and will reduce the likelihood of security-sensitive kernel bugs. 134 o Implement 2553bis [Gilligan, 2002] IPV6_V6ONLY socket option, and make 135 the default value to on (the default value suggested by the document 136 is "off"). This has almost the same effect as the previous bullet. 137 With the approach you still have to implement complex in-kernel 138 interaction between AF_INET and AF_INET6 socket, which can lead to 139 security-senstive kernel bugs. Also, once a userland application 140 turns the socket option off, your system will become vulnerable. The 141 change will make your stack incompatible with 2553bis section 3.7 and 142 5.3. 144 o Drop any IPv6 native packet with IPv4 mapped address in any of IPv6 145 header fields as well as IPv6 extension header fields. It will make 146 the system incompatible with SIIT. 148 o Drop any IPv6 DNS response that contains IPv4 mapped address. 150 5.2. Application developers 152 o In EVERY userland application check the IPv6 source address, if it 153 embeds bad IPv4 address. This approach is impossible in reality, as 154 it's hard to know what is "bad" address, and there are millions of 155 coders in different places. There is no way to enforce this rule. 157 o Do not try to utilize RFC2553 section 3.7 (IPv4 traffic on AF_INET6 158 socket). Implement server applications by using AF_INET and AF_INET6 159 listening socket. Explicitly set IPV6_V6ONLY socket option to on, 160 whenever the socket option is available on the system. 162 NOTE: Due to the lack of standard behavior in bind(2) semantics, 163 this may not be possible on some systems. Some IPv6 stack does not 164 permit bind(2) to 0.0.0.0, after bind(2) to ::. Also, there is no 165 standard on how IPv4 traffic will be routed when both 0.0.0.0 and 166 :: listening sockets are available on the same port. 168 6. Security considerations 170 The document talks about security issues in the use of IPv4 mapped 171 address. Possible solutions are provided. 173 7. Change History 175 none yet. 177 References 179 Hinden, 1998. 180 R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in 181 RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. 183 Gilligan, 1999. 184 R. Gilligan, S. Thomson, J. Bound, and W. Stevens, "Basic Socket 185 Interface Extensions for IPv6" in RFC2553 (March 1999). 186 ftp://ftp.isi.edu/in-notes/rfc2553.txt. 188 Nordmark, 2000. 189 E. Nordmark, "Stateless IP/ICMP Translator (SIIT)" in RFC2765 (February, 190 2000). ftp://ftp.isi.edu/in-notes/rfc2765.txt. 192 Gilligan, 2002. 193 R. Gilligan, S. Thomson, J. Bound, J. McCann, and W. R. Stevens, "Basic 194 Socket Interface Extensions for IPv6" in draft-ietf-ipngwg- 195 rfc2553bis-06.txt (July 2002). work in progress material. 197 Author's address 199 Jun-ichiro itojun Hagino 200 Research Laboratory, Internet Initiative Japan Inc. 201 Takebashi Yasuda Bldg., 202 3-13 Kanda Nishiki-cho, 203 Chiyoda-ku,Tokyo 101-0054, JAPAN 204 Tel: +81-3-5259-6350 205 Fax: +81-3-5259-6351 206 email: itojun@iijlab.net