idnits 2.17.1 draft-okazaki-v6ops-natpt-security-00.txt: -(130): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(148): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(158): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(163): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(165): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(209): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(210): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(283): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(285): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(401): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(404): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(409): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(412): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 41 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 2003) is 7620 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'TunSec' ** Obsolete normative reference: RFC 2766 (ref. 'DNSALG') (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Possible downref: Non-RFC (?) normative reference: ref. 'TransUnman' ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) -- Possible downref: Non-RFC (?) normative reference: ref. 'SecCon' -- Duplicate reference: RFC2766, mentioned in 'RFC2766', was also mentioned in 'DNSALG'. ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) -- Possible downref: Non-RFC (?) normative reference: ref. 'TransIss' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 Internet Draft Satomi Okazaki 3 Anand Desai 4 NTT MCL, Inc. 5 Expires: January 2004 June 2003 7 NAT-PT Security Considerations 9 draft-okazaki-v6ops-natpt-security-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 NAT-PT (RFC2766) is an address translation mechanism designed to 35 facilitate communications between IPv6-only and IPv4-only nodes. 36 This mechanism was designed to be used when tunneling transition 37 mechanisms cannot be used. 39 This document is intended to be a compilation of known security 40 issues related to NAT-PT and includes a few new ones. These issues 41 are discussed in some detail, and suggestions on how to deal with 42 them are included in this document. 44 Table of Contents 46 1.0 Introduction....................................................2 47 2.0 Description of Scheme...........................................3 48 2.1 IPv6-node-initiated communications............................4 49 2.2 IPv4-node-initated communications.............................4 50 3.0 Security analysis...............................................5 51 3.1 End-to-end security...........................................5 52 3.2 Prefix assignment.............................................5 53 3.3 DNS-ALG.......................................................5 54 3.4 Source address spoofing attack................................6 55 3.4.1 Attacker in the NAT-PT stub domain.........................6 56 3.4.2 Attacker outside of NAT-PT stub domain.....................6 57 3.5 An external attacker node.....................................7 58 4.0 Possible solutions..............................................7 59 4.1 End-to-end security...........................................7 60 4.2 Prefix assignment.............................................7 61 4.3 DNS-ALG.......................................................8 62 4.4 Source address spoofing attack................................8 63 4.4.1 Attacker in the NAT-PT stub domain.........................8 64 4.4.2 Attacker outside of the NAT-PT stub domain.................9 65 4.5 An external attacker node.....................................9 66 5.0 Acknowledgements................................................9 67 6.0 Security Considerations.........................................9 68 7.0 References.....................................................10 69 8.0 Authors� Contact Information...................................11 70 9.0 Full Copyright Statement.......................................11 72 1.0 Introduction 74 Given the current deployment of IPv4 and the infrastructure changes 75 necessary to adopt IPv6, there is guaranteed to be a long period in 76 which the two must coexist. Various mechanisms have been proposed 77 to allow for a smooth transition from IPv4 to IPv6. These 78 techniques may be divided into two general types: tunneling 79 mechanisms and translation mechanisms. Translation mechanism 80 documents such as NAT-PT (Network Address Translation � Protocol 81 Translation) [RFC2766] and SIIT (Stateless IP/ICMP Translation 82 Algorithm) [RFC2765] indicate that they are to be used when 83 tunneling techniques are not applicable. Translation mechanisms 84 are intended for use between IPv6-only nodes and IPv4-only nodes. 86 Security issues in tunneling have been examined ([TunSec][SecCon]) 87 to some extent. We are not aware of any dedicated security 88 analysis documents related to translation techniques. In this 89 document, we examine the security of NAT-PT, one of the prominent 90 translation mechanism proposals. We list a few new security issues 91 in addition to those that have been noted in the original draft and 92 some others that have been mentioned in other drafts [DNSALG] 93 [TransUnman] [TransIss] or on the v6ops mailing list. We propose 94 solutions for the security issues that we have found. 96 2.0 Description of Scheme 98 NAT-PT defines a method for allocating a globally unique temporary 99 IPv4 address to an IPv6-only node to allow transparent routing 100 between an IPv6-only node and an IPv4-only node. It is designed to 101 work with a scheme like SIIT, which is a specification for a box 102 that translates IPv4 headers into IPv6 headers and vice versa. 104 The NAT-PT specification defines the functionality of an address 105 translation box that sits on a border router. The NAT-PT box has a 106 pool of globally unique IPv4 addresses to assign to IPv6-only nodes 107 that need to communicate with IPv4-only nodes. There are two types 108 of sessions � those that are initiated by an IPv6 node and those 109 that are initiated by an IPv4 node. Here, we focus on the basic 110 NAT-PT address translation functionality. 112 Suppose that an IPv6-only node X behind a NAT-PT box has the IPv6 113 address FEDC:BA98::7654:3210, and suppose that an IPv4-only node Y 114 in an IPv4 network has the IPv4 address 136.40.1.1. Furthermore, 115 let us say that the NAT-PT box has a pool of globally unique IPv4 116 addresses in the range 140.32.1.1 to 140.32.1.20. 118 +============+ 119 [IPv6 node X]-----[NAT-PT]---|IPv4 Network| �[IPv4 node Y] 120 | +============+ 121 {pool of IPv4 addresses} 123 IPv6 address of X: FEDC:BA98::7654:3210 124 IPv4 address of Y: 136.40.1.1 125 NAT-PT pool of IPv4 addresses: 140.32.1.1 to 140.32.1.20 127 2.1 IPv6-node-initiated communications 129 Suppose IPv6-only node X wishes to initiate communications with 130 IPv4-only node Y. The NAT-PT box in X�s network is associated with 131 some prefix, which we will denote by �PREFIX.� 133 X prepends this prefix to Y�s IPv4 address to get an IPv6 address 134 that looks like �PREFIX::IPv4 address of Y�. The source address 135 and destination address of the packets that X sends to Y look like 136 the following: 138 src: FEDC:BA98::7654:3210 139 dst: PREFIX::136.40.1.1 141 All packets with destination address beginning with PREFIX are 142 routed to the NAT-PT box, as the prefix is chosen to be unique in 143 the stub domain, and the NAT-PT box advertises the prefix for 144 routing purposes. 146 The NAT-PT box then replaces the source address in the packets with 147 the temporary IPv4 address (say 140.32.1.1) it chooses from its 148 pool for X, and the box then strips �PREFIX� from the destination 149 address so that the IPv4 address of Y remains: 151 src: 140.32.1.1 152 dst: 136.40.1.1 154 2.2 IPv4-node-initated communications 156 The case in which a session is initiated by an IPv4 node is a bit 157 more complicated and involves Domain Name Servers (DNSs). The IPv4 158 node Y�s DNS resolver would send a name look-up request (type �A�) 159 for X. This request gets sent through X�s NAT-PT box to the DNS 160 server on X�s network. 162 The NAT-PT contains a DNS-ALG (Application Level Gateway) that 163 translates an �A� query to an �AAAA� or �A6� query and sends it to 164 the DNS server on X�s network. When the IPv6 DNS server responds 165 with an �AAAA� or �A6� record, it is sent through the NAT-PT box, 166 where DNS-ALG translates it into an �A� record and replaces the 167 IPv6 address of X with the corresponding temporary IPv4 address 168 from the pool. 170 3.0 Security analysis 172 In this section, we list all of the security threats that we know 173 of - a number of security threats that have been outlined in the 174 original draft itself, in external documents, and those that we 175 have isolated. 177 3.1 End-to-end security 179 As noted in [RFC2766], NAT-PT and end-to-end security do not work 180 together. When IPv6-only node X initiates communications to IPv4- 181 only node Y, the packet that X forms has an IPv6 source address 182 (FEDC:BA98::7654:3210) and an IPv6 destination address 183 (PREFIX::136.40.1.1), which are used in IPsec (ESP or AH) 184 computations, including TCP/UDP/ICMP checksum computations. 186 Since NAT-PT assigns X an IPv4 address (140.32.1.1) that has no 187 relationship to X�s IPv6 address, there is no way for recipient Y 188 to determine X�s IPv6 address, which is involved in verifying 189 TCP/UDP/ICMP checksum computations. 191 3.2 Prefix assignment 193 The draft [RFC2766] does not describe how the IPv6 nodes learn the 194 prefix that is used to route packets to the NAT-PT box. If the 195 prefix is pre-configured in IPv6 nodes, the IPv6 node would prepend 196 the pre-configured prefix to the address of any IPv4-only node with 197 which it want to initiate communications. However, with a fixed 198 prefix, there might be a reachability problem if the NAT-PT box 199 were to shut down. 201 If an attacker were somehow able to give the IPv6 node a fake 202 prefix, the attacker would be able to steal all of the node�s 203 outbound packets to IPv4 nodes. 205 3.3 DNS-ALG 207 The DNS-ALG is required when allowing IPv4-only-node-initiated 208 communications in the NAT-PT setting. Since DNS-ALG will translate 209 �A� record requests into �AAAA� or �A6� request and conversely, 210 �AAAA� or �A6� records into �A� records, DNS-SEC will not work with 211 NAT-PT, as noted in [RFC2766]. 213 This means that it is possible for an attacker to modify records 214 from DNS-ALG to the IPv4 nodes. 216 3.4 Source address spoofing attack 218 We consider attackers that will use NAT-PT resources. There are 219 two cases: in the first, the attacker is in the same stub domain as 220 the NAT-PT, and in the second, the attacker is outside of the NAT- 221 PT stub domain. 223 3.4.1 Attacker in the NAT-PT stub domain 225 Here, we suppose that an attacker in the same stub domain as NAT-PT 226 sends a packet destined for an IPv4-only node Y on the other side 227 of NAT-PT. We look at the more interesting case in which the 228 attacker forges its source address to be an address that is 229 topologically inside the stub domain. (This address could belong 230 to another node, or it could be unassigned.) 232 Address depletion attack - If the IPv6 attacker sends many such 233 packets, each with a different source address, then the pool of 234 IPv4 addresses may get used up, resulting in a Denial of Service 235 attack. (This vulnerability is also noted in [RFC2766] and 236 [TransIss].) 238 The other attacks exist even without NAT-PT. These are reflection 239 attacks, resource exhaustion attacks, and broadcast/multicast 240 attacks. In a reflection attack, the IPv6 source address is set to 241 that of an existing node. That node will be the recipient of a 242 reflection attack, as the IPv4 node will send response packets to 243 the victim node. In a resource exhaustion attack, the IPv6 source 244 address is set to that of a non-existent node. The return packets 245 will be dropped, but this may still result in a resource exhaustion 246 DoS attack on Y. Finally, in a multicast attack, the IPv6 source 247 address is a multicast address. The return packet from the IPv4 248 node will be sent to the multicast address, resulting in a 249 multicast attack. 251 3.4.2 Attacker outside of NAT-PT stub domain 253 Here, we suppose that an attacker on the other side of NAT-PT sends 254 a packet destined for an IPv6-only node X behind NAT-PT. We look 255 at the more interesting case in which the attacker forges its 256 source address to be an address that is topologically outside the 257 stub domain. (This address could belong to another node, or it 258 could be unassigned.) The same attacks are possible here as in the 259 case described in the previous section. 261 3.5 An external attacker node 263 In this case, an attacker that knows the IP address of the NAT-PT 264 box can send packets directly to the box. It can use NAT-PT 265 resources, preventing legitimate IPv6-only nodes from accessing 266 NAT-PT services. 268 4.0 Possible solutions 270 4.1 End-to-end security 272 End-to-end security is not possible with NAT-PT. One reason is 273 outlined in section 3.1. 275 4.2 Prefix assignment 277 Though it is not specified in [RFC2766], DNS servers and DNS-ALG 278 may be used in outgoing connections to return the prefix 279 information to the IPv6 node. This is a way to avoid the problem 280 of a statically pre-configured prefix. When an IPv6-only node 281 wishes to initiate communications with an IPv4-only node, its 282 resolver would send an �AAAA� query. This query can be passed 283 through the DNS-ALG, which would receive an �A� record in response. 284 In this case, the DNS-ALG can prepend the appropriate prefix for 285 the NAT-PT and translate the �A� record into an �AAAA� or �A6� 286 record and return it to the IPv6 node. 288 The DNS-ALG can also monitor the state of a number of NAT-PT boxes 289 (multiple boxes for scalability) and return the prefixes of those 290 that are running. This idea was stated in [DNSALG] and [mNATPT], 291 as well as in e-mail communication on the v6ops mailing list. 293 As mentioned in [mNATPT], the method by which DNS-ALG determines 294 the state and validity of a NAT-PT box must be secure. The DNS-ALG 295 and each NAT-PT box should be configured with a pairwise unique 296 shared key that will be used for integrity-protected 297 communications. 299 Note that messages from DNS-ALG are not integrity-protected and can 300 therefore be modified. To prevent such a modification, DNS-ALG can 301 sign its packets. DNS-ALG�s public key can be made available like 302 that of a DNS server (see [RFC2535]) or presented in a certificate 303 that has a root CA that is well known to all nodes behind NAT-PT. 304 A shared-key technique may not be as practical. 306 4.3 DNS-ALG 308 The end host (IPv6 node or IPv4 node) will not be able to verify 309 the signature on a DNS record because of the translation that the 310 DNS-ALG performs. 312 However, as is pointed out in [DNSALG], if the host sets the "AD is 313 secure" bit in the DNS header, then it is possible for the local 314 DNS server to verify the signatures. 316 Another option is for DNS-ALG to verify the received records (like 317 a DNS resolver), translate them, and sign the translated records 318 (like a DNS server). DNS-ALG�s public key can be made available 319 like that of a DNS server (see [RFC2535]). 321 A third option would be for a host to have an IPsec security 322 association with the DNS-ALG to protect DNS records. 324 4.4 Source address spoofing attack 326 4.4.1 Attacker in the NAT-PT stub domain 328 The NAT-PT (which sits on a border router) should perform ingress 329 filtering. This would prevent an attacking node in its stub domain 330 that forges its source address from performing a reflection attack 331 on nodes in other stub domains. However, this does not prevent 332 such an attacker from performing a reflection attack on other nodes 333 in the same stub domain. These are not attacks introduced by NAT- 334 PT. 336 The NAT-PT should drop packets whose IPv6 source address is a 337 multicast address. This would prevent the multicast attack. This 338 is not an attack introduced by NAT-PT. 340 One way to get around the address depletion attack is to employ 341 NAPT-PT (Network Address Port Translation - Protocol 342 Translation)[RFC2766], which translates TCP/UDP ports of IPv6 nodes 343 into TCP/UDP ports of the translated IPv4 addresses. However, as 344 the draft points out, IPv4-node-initiated NAPT-PT sessions are 345 restricted to one server per service. 347 Another method of dealing with address depletion is to have a list 348 of nodes to which NAT-PT will offer its translation services. Or 349 for more security, an IPsec security association could be required 350 between the NAT-PT and nodes to which it will offer its services. 352 4.4.2 Attacker outside of the NAT-PT stub domain 354 The NAT-PT should drop packets whose IPv4 source address is a 355 broadcast/multicast address to prevent a broadcast/multicast 356 attack. Furthermore, NAT-PT should filter out packets from outside 357 that claim to have a source address behind NAT-PT. These are not 358 attacks introduced by NAT-PT. 360 The address depletion attack is discussed in the previous section. 362 4.5 An external attacker node 364 NAT-PT should drop packets that are sent directly to its IP address 365 rather than being routed to it via the prefix PREFIX. If NAT-PT 366 maintains a list of nodes to which it will offer its services, this 367 type of attack will be minimized as well. Or for more security, an 368 IPsec security association could be required between the NAT-PT and 369 nodes to which it will offer its services. 371 5.0 Acknowledgements 373 The authors would like to acknowledge DoCoMo USA Labs for support 374 of this work and in particular, James Kempf for helpful comments 375 and insights. 377 6.0 Security Considerations 379 This draft is itself a document about security considerations for 380 NAT-PT. 382 7.0 References 384 [TunSec] Di Battista et al. �Operational procedures for secured 385 management with transition mechanisms,� 28 February 2003. 387 [DNSALG] Durand, A. �Issues with NAT-PT DNS ALG in RFC2766,� 388 , Internet- 389 Draft, 29 January 2003. 391 [RFC2535] Eastlake, D. �Domain Name Security Extensions,� RFC 392 2535, March 1999. 394 [TransUnman] Huitema, C. et al. �Evaluation of Transition 395 Mechanisms for Unmanaged Networks,� , Internet-Draft, 1 November 2002. 398 [RFC2765] Nordmark, E. �Stateless IP/ICMP Translation Algorithm 399 (SIIT),� RFC 2765, February 2000. 401 [mNATPT] Park, S.D. et al. �Scalable mNAT-PT Solution,� , Internet-Draft, May 2003. 404 [SecCon] Savola, P. �Security Considerations for 6to4,� , Internet-Draft, January 406 2003. 408 [RFC2766] Tsirtsis, G. and Srisuresh, P. �Network Address 409 Translation � Protocol Translation (NAT-PT),� RFC 2766, February 410 2000. 412 [TransIss] Van der Pol, R. et al. �Issues when translating between 413 IPv4 and IPv6,� , Internet-Draft, 27 January 2003. 416 8.0 Authors� Contact Information 418 Satomi Okazaki Phone: +1 650 833 3631 419 NTT MCL, Inc. Fax: +1 650 326 1878 420 250 Cambridge Avenue, Suite 300 Email: satomi@nttmcl.com 421 Palo Alto, California 94306 422 USA 424 Anand Desai Phone: +1 650 833 3638 425 NTT MCL, Inc. Fax: +1 650 326 1878 426 250 Cambridge Avenue, Suite 300 Email: anand@nttmcl.com 427 Palo Alto, California 94306 428 USA 430 9.0 Full Copyright Statement 432 Copyright (C) The Internet Society (2001). All Rights Reserved. 433 This document and translations of it may be copied and furnished to 434 others, and derivative works that comment on or otherwise explain 435 it or assist in its implementation may be prepared, copied, 436 published and distributed, in whole or in part, without restriction 437 of any kind, provided that the above copyright notice and this 438 paragraph are included on all such copies and derivative works. 439 However, this document itself may not be modified in any way, such 440 as by removing the copyright notice or references to the Internet 441 Society or other Internet organizations, except as needed for the 442 purpose of developing Internet standards in which case the 443 procedures for copyrights defined in the Internet Standards process 444 must be followed, or as required to translate it into languages 445 other than English. The limited permissions granted above are 446 perpetual and will not be revoked by the Internet Society or its 447 successors or assigns. This document and the information contained 448 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 449 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 450 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 451 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 452 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 453 PARTICULAR PURPOSE.