idnits 2.17.1 draft-itojun-v6ops-v4mapped-harmful-02.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 == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages 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,2003], [Nordmark,2000], [Hinden,2003]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 114: '...o IPv6 nodes MUST NOT generate packets...' RFC 2119 keyword, line 116: '...rs, and any other chained headers MUST...' RFC 2119 keyword, line 119: '...o IPv6 nodes SHOULD NOT generate packe...' RFC 2119 keyword, line 120: '... (As a particular exception, it MAY be...' RFC 2119 keyword, line 125: '...o IPv6 nodes MUST silently discard pac...' (7 more instances...) 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 (Oct 21, 2003) is 7485 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 142 looks like a reference -- Missing reference section? '2003' on line 144 looks like a reference -- Missing reference section? 'Gilligan' on line 144 looks like a reference -- Missing reference section? 'Nordmark' on line 66 looks like a reference -- Missing reference section? '2000' on line 66 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Craig Metz 3 INTERNET-DRAFT Extreme Networks 4 Expires: Apr 21, 2004 Jun-ichiro itojun Hagino 5 Research Lab, IIJ 6 Oct 21, 2003 8 IPv4-Mapped Addresses on the Wire Considered Harmful 9 draft-itojun-v6ops-v4mapped-harmful-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as ``work in progress.'' 25 To view the list Internet-Draft Shadow Directories, see 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 Apr 21, 2004. 33 Abstract 35 The IPv6 Addressing Architecture [Hinden, 2003] defines the "IPv4-mapped 36 IPv6 address." These addresses are used in the IPv6 basic API 37 [Gilligan, 2003] to denote IPv4 addresses using AF_INET6 sockets. These 38 addresses are used in protocol proposals such as SIIT [Nordmark, 2000] 39 to denote IPv6 communication using AF_INET6 sockets. Therefore, 40 IPv4-mapped addresses have two different meanings, and they are not 41 distinguishable from the user-land applications. 43 This draft discusses security threats due to this ambiguity of 44 IPv4-mapped address. It also discusses threats due to the additional 45 complexities introduced by IPv4-mapped addresses. Finally, it proposes 46 to resolve these problems by forbidding protocols from using IPv4-mapped 47 addresses for IPv6 communications. 49 ^L 51 DRAFT IPv4-mapped Addr. on Wire Considered Harmful Oct 2003 53 1. Dual meaning of IPv4-mapped address 55 Basic Socket Interface Extensions for IPv6 [Gilligan, 2003] defines the 56 use of IPv4-mapped address with AF_INET6 sockets. IPv4-mapped addresses 57 are used to represent IPv4 addresses using the IPv6 API (e.g., on 58 AF_INET6 sockets). The API is designed with IPv4/v6 dual stack nodes in 59 mind. When an IPv4 packet reaches an IPv4/v6 dual stack node, the 60 node's IPv4 layer will process it, then pass it to the transport layer. 61 When the transport layer finds an AF_INET6 listening socket, it will 62 pass the packet to the listening socket as if it was from the 63 corresponding IPv4-mapped address. In this document, we will refer to 64 this as the "basic API behavior." 66 Some IPv6 translation protocols, such as SIIT [Nordmark, 2000] , uses 67 IPv4-mapped addresses actual IPv6 packets on the wire. These protocols 68 are designed for use with IPv6-only nodes. When an IPv6 packet 69 containing these addresses reaches a node, the node's IPv6 layer will 70 process it, then pass it to the transport layer. When the transport 71 layer finds an AF_INET6 listening socket, it will pass the packet to the 72 listening socket with the IPv4-mapped address intact. In this document, 73 we will refer to this as the "SIIT behavior." 75 2. Threats due to the use of IPv4-mapped address on wire 77 When an application using the AF_INET6 API receives an IPv4-mapped 78 addresses (for example, returned by getpeername(2) or recvfrom(2)), it 79 cannot detect if the packet received by the node actually used IPv4 80 (basic API behavior) or IPv6 (SIIT behavior). 82 This ambiguity creates an opportunity that a malicious party can exploit 83 in order to deceive victim nodes. For example: 85 o If an attacker transmits an IPv6 packet with ::ffff:127.0.0.1 in the 86 IPv6 source address field, he might be able to bypass a node's access 87 controls by deceiving applications into believing that the packet is 88 from the node itself (e.g., the IPv4 loopback address, 127.0.0.1). 89 The same attack might be performed using the node's IPv4 interface 90 address instead. 92 o If an attacker transmits an IPv6 packet with IPv4-mapped addresses in 93 the IPv6 destination address field corresponding to IPv4 addresses 94 inside a site's security perimeter (e.g., ::ffff:10.1.1.1), he might 95 be able to bypass IPv4 packet filtering rules and traverse a site's 96 firewall. 98 o If an attacker transmits an IPv6 packet with IPv4-mapped addresses in 99 the IPv6 source and destination fields to a protocol that swaps IPv6 100 source and destination addresses, he might be able to use a node as a 101 proxy for certain types of attacks. For example, this might be used 102 to construct broadcast multiplication and proxy TCP port scan attacks. 104 ^L 106 DRAFT IPv4-mapped Addr. on Wire Considered Harmful Oct 2003 108 3. Recommended solution 110 Forbid the use of IPv4-mapped address on wire. 112 The IPv6 node requirements: 114 o IPv6 nodes MUST NOT generate packets that contain IPv4-mapped 115 addresses in any network layer field. Specifically, the IPv6 header, 116 routing header, options headers, and any other chained headers MUST 117 NOT contain IPv4-mapped addresses. 119 o IPv6 nodes SHOULD NOT generate packets that contain IPv4-mapped 120 addresses in any field. (As a particular exception, it MAY be 121 acceptable for fields referring to third-party nodes to contain 122 IPv4-mapped addresses. Implementors must ensure that, where this is 123 allowed, it is done with great care.) 125 o IPv6 nodes MUST silently discard packets that contain IPv4-mapped 126 address in IPv6 header fields, or IPv6 extension header fields. 128 The IPv6 router requirements: 130 o IPv6 routers MUST NOT forward packets that contain IPv4-mapped 131 addresses in any field the router processes. Specifically, the IPv6 132 header, routing header, and the hop-by-hop options headers parsed by 133 the router MUST NOT contain IPv4-mapped addresses. 135 o IPv6 routers MUST NOT advertise any prefixes into a routing protocol 136 that are within the IPv4-mapped address space. Further, IPv6 routers 137 MUST appropriately discard and/or ignore any received prefixes within 138 the IPv4-mapped address space. 140 Standards requirements: 142 o The IPv6 address architecture document [Hinden, 2003] MUST explicitly 143 state that IPv4-mapped addresses are exclusively for uses local to a 144 node as specified in the basic API [Gilligan, 2003] and MUST never 145 appear in the wire. 147 o Any document that suggests the use of IPv4-mapped addresses in packets 148 on the wire SHOULD be modified to remove such usage. This will remove 149 the threat due to the use of IPv4-mapped address on wire. 151 An alternate solution is to deprecate IPv4-mapped addresses from the 152 basic API. Due to the wide deployment of applications that use IPv6 153 basic API, further study of this option's feasibility is required. This 154 solution is not mutually exclusive with the recommended solution. 156 ^L 158 DRAFT IPv4-mapped Addr. on Wire Considered Harmful Oct 2003 160 4. Suggested implementation tips 162 4.1. System (e.g., kernel and library) developers 164 o Drop any IPv6 packet with IPv4-mapped addresses in any of IPv6 header 165 fields as well as IPv6 extension header fields. (N.B., this will make 166 the system incompatible with the current version of SIIT [Nordmark, 167 2000] ) 169 o Drop any AAAA DNS response that contains IPv4-mapped addresses. 171 5. Security considerations 173 This document discusses security issues with the use of IPv4-mapped 174 address. A recommended and alternate solution is provided. 176 6. Change History 178 00 -> 01 179 Craig Metz joins the team. Updates based on feedback given at 180 v6ops interim meeting fall 2002. Move API issues to a separate 181 draft. 183 01 -> 02 184 2553bis draft is now RFC3493. Refer RFC3513 instead of RFC2373. 186 References 188 Hinden, 2003. 189 R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in 190 RFC3513 (April 2003). ftp://ftp.isi.edu/in-notes/rfc3513.txt. 192 Gilligan, 2003. 193 R. Gilligan, S. Thomson, J. Bound, J. McCann, and W. R. Stevens, "Basic 194 Socket Interface Extensions for IPv6" in RFC3493 (February 2003). 195 ftp://ftp.isi.edu/in-notes/rfc3493.txt. 197 Nordmark, 2000. 198 E. Nordmark, "Stateless IP/ICMP Translator (SIIT)" in RFC2765 (February, 199 2000). ftp://ftp.isi.edu/in-notes/rfc2765.txt. 201 Author's addresses 203 ^L 205 DRAFT IPv4-mapped Addr. on Wire Considered Harmful Oct 2003 207 Craig Metz 208 Extreme Networks 209 220 Spring Street, Suite 100 210 Herndon, VA 20170-5209, USA 211 Tel: +1 703 885 6721 212 email: cmetz@inner.net 214 Jun-ichiro itojun Hagino 215 Research Laboratory, Internet Initiative Japan Inc. 216 Takebashi Yasuda Bldg., 217 3-13 Kanda Nishiki-cho, 218 Chiyoda-ku,Tokyo 101-0054, JAPAN 219 Tel: +81-3-5259-6350 220 Fax: +81-3-5259-6351 221 email: itojun@iijlab.net 223 ^L