idnits 2.17.1 draft-ietf-behave-lsn-requirements-08.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4787, updated by this document, for RFC5378 checks: 2005-01-13) -- 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 11, 2012) is 4307 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4008 (Obsoleted by RFC 7658) == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-26 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-11) exists of draft-ietf-behave-nat-mib-01 == Outdated reference: A later version (-10) exists of draft-ietf-intarea-nat-reveal-analysis-02 == Outdated reference: A later version (-06) exists of draft-donley-nat444-impacts-04 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Perreault, Ed. 3 Internet-Draft Viagenie 4 Updates: 4787 (if approved) I. Yamagata 5 Intended status: BCP S. Miyakawa 6 Expires: January 12, 2013 NTT Communications 7 A. Nakagawa 8 Japan Internet Exchange (JPIX) 9 H. Ashida 10 IS Consulting G.K. 11 July 11, 2012 13 Common requirements for Carrier Grade NATs (CGNs) 14 draft-ietf-behave-lsn-requirements-08 16 Abstract 18 This document defines common requirements for Carrier-Grade NAT 19 (CGN). It updates RFC 4787. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 12, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Requirements for CGNs . . . . . . . . . . . . . . . . . . . . 5 58 4. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 5. Bulk Port Allocation . . . . . . . . . . . . . . . . . . . . . 12 60 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 13 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 66 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 14 67 Appendix A. Change Log (to be removed by RFC Editor prior to 68 publication) . . . . . . . . . . . . . . . . . . . . 16 69 A.1. Changed in -08 . . . . . . . . . . . . . . . . . . . . . 16 70 A.2. Changed in -07 . . . . . . . . . . . . . . . . . . . . . 16 71 A.3. Changed in -06 . . . . . . . . . . . . . . . . . . . . . 17 72 A.4. Changed in -05 . . . . . . . . . . . . . . . . . . . . . 18 73 A.5. Changed in -04 . . . . . . . . . . . . . . . . . . . . . 18 74 A.6. Changed in -03 . . . . . . . . . . . . . . . . . . . . . 18 75 A.7. Changed in -02 . . . . . . . . . . . . . . . . . . . . . 19 76 A.8. Changed in -01 . . . . . . . . . . . . . . . . . . . . . 20 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 79 1. Introduction 81 With the shortage of IPv4 addresses, it is expected that more 82 Internet Service Providers (ISPs) may want to provide a service where 83 a public IPv4 address would be shared by many subscribers. Each 84 subscriber is assigned a private address, and a Network Address 85 Translator (NAT) [RFC2663] situated in the ISP's network translates 86 between private and public addresses. When a second IPv4 NAT is 87 located at the customer edge, this results in two layers of NAT. 89 This service can conceivably be offered alongside others, such as 90 IPv6 services or regular IPv4 service assigning public addresses to 91 subscribers. Some ISPs started offering such a service long before 92 there was a shortage of IPv4 addresses, showing that there are 93 driving forces other than the shortage of IPv4 addresses. One 94 approach to CGN deployment is described in [RFC6264]. 96 This document describes behavior that is required of those multi- 97 subscriber NATs for interoperability. It is not an IETF endorsement 98 of CGN or a real specification for CGN, but rather just a minimal set 99 of requirements that will increase the likelihood of applications 100 working across CGNs. 102 Because subscribers do not receive unique IPv4 addresses, Carrier 103 Grade NATs introduce substantial limitations in communications 104 between subscribers and with the rest of the Internet. In 105 particular, it is considerably more involved to establish proxy 106 functionality at the border between internal and external realms. 107 Some applications may require substantial enhancements, while some 108 others may not function at all in such an environment. Please see 109 "Issues with IP Address Sharing" [RFC6269] for details. 111 This document builds upon previous works describing requirements for 112 generic NATs [RFC4787][RFC5382][RFC5508]. These documents, and their 113 updates if any, still apply in this context. What follows are 114 additional requirements, to be satisfied on top of previous ones. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 Readers are expected to be familiar with "NAT Behavioral Requirements 123 for Unicast UDP" [RFC4787] and the terms defined there. The 124 following additional term is used in this document: 126 Carrier-Grade NAT (CGN): A NAT-based [RFC2663] logical function used 127 to share the same IPv4 address among several subscribers. A CGN 128 is not managed by the subscribers. 130 Note that the term "carrier-grade" has nothing to do with the 131 quality of the NAT; that is left to discretion of implementers. 132 Rather, it is to be understood as a topological qualifier: the 133 NAT is placed in an ISP's network and translates the traffic of 134 potentially many subscribers. Subscribers have limited or no 135 control over the CGN, whereas they typically have full control 136 over a NAT placed on their premises. 138 Note also that the CGN described in this document is IPv4-only. 139 IPv6 address translation is not considered. 141 However, the scenario in which the IPv4-only CGN logical 142 function is used may include IPv6 elements. For example, DS- 143 Lite [RFC6333] uses an IPv4-only CGN logical function in a 144 scenario making use of IPv6 encapsulation. Therefore, this 145 document would also apply to the CGN part of DS-Lite. 147 Figure 1 summarizes a common network topology in which a CGN 148 operates. 150 . 151 : 152 | Internet 153 ............... | ................... 154 | ISP network 155 External pool: | 156 192.0.2.1/26 | 157 ++------++ External realm 158 ........... | CGN |............... 159 ++------++ Internal realm 160 10.0.0.1 | | 161 | | 162 | | ISP network 163 ............. | .. | ................ 164 | | Customer premises 165 10.0.0.100 | | 10.0.0.101 166 ++------++ ++------++ 167 | CPE1 | | CPE2 | etc. 168 ++------++ ++------++ 170 (IP addresses are only for example purposes) 172 Figure 1: CGN network topology 174 Another possible topology is one for hotspots, where there is no 175 customer premise or customer-premises equipment (CPE), but where a 176 CGN serves a bunch of customers who don't trust each other and hence 177 fairness is an issue. One important difference with the previous 178 topology is the absence of a second layer of NAT. This, however, has 179 no impact on CGN requirements since they are driven by fairness and 180 robustness in the service provided to customers, which applies in 181 both cases. 183 3. Requirements for CGNs 185 What follows is a list of requirements for CGNs. They are in 186 addition to those found in other documents such as [RFC4787], 187 [RFC5382], and [RFC5508]. 189 REQ-1: If a CGN forwards packets containing a given transport 190 protocol, then it MUST fulfill that transport protocol's 191 behavioral requirements. Current applicable documents are as 192 follows: 194 A. "NAT Behavioral Requirements for Unicast UDP" [RFC4787] 196 B. "NAT Behavioral Requirements for TCP" [RFC5382] 198 C. "NAT Behavioral Requirements for ICMP" [RFC5508] 200 D. "NAT Behavioral Requirements for DCCP" [RFC5597] 202 If NAT behavioral requirements documents are created for 203 additional protocols, then these new documents MUST update 204 this list by adding themselves to it. 206 Justification: It is crucial for CGNs to maximize the set of 207 applications that can function properly across them. The IETF has 208 documented the best current practices for UDP, TCP, ICMP, and 209 DCCP. 211 REQ-2: A CGN MUST have a default "IP address pooling" behavior of 212 "Paired" (as defined in [RFC4787] section 4.1). A CGN MAY 213 provide a mechanism for administrators to change this 214 behavior on an application protocol basis. 216 * When multiple overlapping internal IP address ranges share 217 the same external IP address pool (e.g., DS-Lite 218 [RFC6333]), the "IP address pooling" behavior applies to 219 mappings between external IP addresses and internal 220 subscribers rather than between external and internal IP 221 addresses. 223 Justification: This stronger form of REQ-2 from [RFC4787] is 224 justified by the stronger need for not breaking applications that 225 depend on the external address remaining constant. 227 Note that this requirement applies regardless of the transport 228 protocol. In other words, a CGN must use the same external IP 229 address mapping for all sessions associated with the same internal 230 IP address, be they TCP, UDP, ICMP, something else, or a mix of 231 different protocols. 233 The justification for allowing other behaviors is to allow the 234 administrator to save external addresses and ports for application 235 protocols that are known to work fine with other behaviors in 236 practice. However, the default behavior MUST be "Paired". 238 REQ-3: The CGN function SHOULD NOT have any limitations on the size 239 nor the contiguity of the external address pool. In 240 particular, the CGN function MUST be configurable with 241 contiguous or non-contiguous external IPv4 address ranges. 243 Justification: Given the increasing rarity of IPv4 addresses, it is 244 becoming harder for an operator to provide large contiguous 245 address pools to CGNs. Additionally, operational flexibility may 246 require non-contiguous address pools for reasons such as 247 differentiated services, routing management, etc. 249 The reason for having SHOULD instead of MUST is to account for 250 limitations imposed by available resources as well as constraints 251 imposed for security reasons. 253 REQ-4: A CGN MUST support limiting the number of external ports (or, 254 equivalently, "identifiers" for ICMP) that are assigned per 255 subscriber. 257 A. Limits MUST be configurable by the CGN administrator. 259 B. Limits MAY be configurable independently per transport 260 protocol. 262 C. Additionally, it is RECOMMENDED that the CGN include 263 administrator-adjustable thresholds to prevent a single 264 subscriber from consuming excessive CPU resources from 265 the CGN (e.g., rate limit the subscriber's creation of 266 new mappings). 268 Justification: A CGN can be considered a network resource that is 269 shared by competing subscribers. Limiting the number of external 270 ports assigned to each subscriber mitigates the DoS attack that a 271 subscriber could launch against other subscribers through the CGN 272 in order to get a larger share of the resource. It ensures 273 fairness among subscribers. Limiting the rate of allocation 274 mitigates a similar attack where the CPU is the resource being 275 targeted instead of port numbers, however this requirement is not 276 a MUST because it is very hard to explicitly call out all CPU- 277 consuming events. 279 REQ-5: A CGN SHOULD support limiting the amount of state memory 280 allocated per mapping and per subscriber. This may include 281 limiting the number of sessions, the number of filters, etc., 282 depending on the NAT implementation. 284 A. Limits SHOULD be configurable by the CGN administrator. 286 B. Additionally, it SHOULD be possible to limit the rate at 287 which memory-consuming state elements are allocated. 289 Justification: A NAT needs to keep track of TCP sessions associated 290 to each mapping. This state consumes resources for which, in the 291 case of a CGN, subscribers may compete. It is necessary to ensure 292 that each subscriber has access to a fair share of the CGN's 293 resources. Limiting the rate of allocation is intended to prevent 294 against CPU resource exhaustion. Item "B" is at the SHOULD level 295 to account for the fact that means other than rate limiting may be 296 used to attain the same goal. 298 REQ-6: It MUST be possible to administratively turn off translation 299 for specific destination addresses and/or ports. 301 Justification: It is common for a CGN administrator to provide 302 access for subscribers to servers installed in the ISP's network 303 in the external realm. When such a server is able to reach the 304 internal realm via normal routing (which is entirely controlled by 305 the ISP), translation is unneeded. In that case, the CGN may 306 forward packets without modification, thus acting like a plain 307 router. This may represent an important efficiency gain. 309 Figure 2 illustrates this use-case. 311 X1:x1 X1':x1' X2:x2 312 +---+from X1:x1 +---+from X1:x1 +---+ 313 | C | to X2:x2 | | to X2:x2 | S | 314 | l |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| e | 315 | i | | G | | r | 316 | e |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| v | 317 | n |from X2:x2 | |from X2:x2 | e | 318 | t | to X1:x1 | | to X1:x1 | r | 319 +---+ +---+ +---+ 321 Figure 2: CGN pass-through 323 REQ-7: It is RECOMMENDED that a CGN have an "Endpoint-Independent 324 Filtering" behavior (as defined in [RFC4787] section 5). If 325 it is known that "Address-Dependent Filtering" does not cause 326 the application-layer protocol to break (how to determine 327 this is out of scope for this document), then it MAY be used 328 instead. 330 Justification: This is a stronger form of REQ-8 from [RFC4787]. 331 This is based on the observation that some games and peer-to-peer 332 applications require EIF for the NAT traversal to work. In the 333 context of a CGN it is important to minimize application breakage. 335 REQ-8: Once an external port is deallocated, it SHOULD NOT be 336 reallocated to a new mapping until at least 120 seconds have 337 passed, with the exceptions being: 339 A. If the CGN tracks TCP sessions (e.g., with a state 340 machine, as in [RFC6146] section 3.5.2.2), TCP ports MAY 341 be reused immediately. 343 B. If external ports are statically assigned to internal 344 addresses (e.g., address X with port range 1000-1999 is 345 assigned to subscriber A, 2000-2999 to subscriber B, 346 etc.), and the assignment remains constant across state 347 loss, then ports MAY be reused immediately. 349 C. If the allocated external ports used address-dependent or 350 address-and-port-dependent filtering before state loss, 351 they MAY be reused immediately. 353 The length of time and the maximum number of ports in this 354 state MUST be configurable by the CGN administrator. 356 Justification: This is necessary in order to prevent collisions 357 between old and new mappings and sessions. It ensures that all 358 established sessions are broken instead of redirected to a 359 different peer. 361 The exceptions are for cases where reusing a port immediately does 362 not create a possibility that packets would be redirected to the 363 wrong peer. One can imagine other exceptions where mapping 364 collisions are avoided, thus justifying the SHOULD level for this 365 requirement. 367 The 120 seconds value corresponds to the Maximum Segment Lifetime 368 (MSL) from [RFC0793]. 370 Note that this requirement also applies to the case when a CGN 371 loses state (due to a crash, reboot, failover to a cold standby, 372 etc.). In that case, ports that were in use at the time of state 373 loss SHOULD NOT be reallocated until at least 120 seconds have 374 passed. 376 REQ-9: A CGN MUST include a Port Control Protocol server 377 [I-D.ietf-pcp-base] with the following constraints on its 378 behavior: 380 A. It MUST NOT permit the lifetime of a mapping to be 381 reduced beyond its current life or be set to zero 382 (deleted). 384 B. It MUST NOT permit a NAT mapping to be created with a 385 lifetime less than the lifetime used for implicit 386 mappings. 388 C. The MAP opcode MAY be permitted if the recommendation of 389 endpoint independent filtering behavior described in 390 REQ-7 is adopted; the map opcode MUST NOT be permitted in 391 other circumstances. These constraints MAY be relaxed if 392 a security mechanism consistent with PCP's Advanced 393 Threat Model (see Section 17.2 of [I-D.ietf-pcp-base]) is 394 used; this is expected to be rare for CGN deployments. 396 D. Mappings created by PCP MUST follow the same deallocation 397 behavior (REQ-8) as implicitly mapped traffic. 399 Justification: Allowing subscribers to manipulate the NAT state 400 table with PCP greatly increases the likelihood that applications 401 will function properly. 403 A study of PCP-less CGN impacts can be found in 404 [I-D.donley-nat444-impacts]. Another study considering the 405 effects of PCP on a peer-to-peer file sharing protocol can be 406 found in [I-D.boucadair-pcp-bittorrent]. 408 Items "A" to "D" are justified as follows: Most of the concern has 409 to do with one customer device interacting negatively with the 410 security of another; this is of particular concern when the 411 devices belong to different customers, but devices belonging to 412 the same customer are in scope for the PCP security analysis as 413 well. Reducing a mapping lifetime or deleting a mapping create 414 DoS opportunities and can create an opportunity for one device to 415 intercept another device's traffic. If a device spoofs creation 416 of a mapping with less than the default lifetime, then that can 417 create DoS or packet capture opportunities. The behavior of REQ-8 418 is critical to avoiding packet capture attacks. 420 REQ-10: CGN implementrers SHOULD make their equipment manageable. 421 Standards-based management using standards such as 422 "Definitions of Managed Objects for NAT" [RFC4008] is 423 RECOMMENDED. 425 Justification: It is anticipated that CGNs will be primarily 426 deployed in ISP networks where the need for management is 427 critical. This requirement is at the SHOULD level to account for 428 the fact that some CGN operators may not need management 429 functionality. 431 Note also that there are efforts within the IETF toward creating a 432 MIB tailored for CGNs (e.g., [I-D.ietf-behave-nat-mib]). 434 REQ-11: When a CGN is unable to create a mapping due to resource 435 constraints or administrative restrictions (i.e., quotas): 437 A. it MUST drop the original packet; 439 B. it SHOULD send an ICMP Destination Unreachable message 440 with code 1 (Host Unreachable) to the sender; 442 C. it SHOULD send a notification (e.g., SNMP trap) towards 443 a management system (if configured to do so); 445 D. and it MUST NOT delete existing mappings in order to 446 "make room" for the new one. (This only applies to 447 normal CGN behavior, not to manual operator 448 intervention.) 450 Justification: This is a slightly different form of REQ-8 from 451 [RFC5508]. Code 1 is preferred to code 13 because it is listed as 452 a "soft error" in [RFC1122], which is important because we don't 453 want TCP stacks to abort the connection attempt in this case. See 454 [RFC5461] for details on TCP's reaction to soft errors. 456 Sending ICMP errors and SNMP traps may be rate-limited for 457 security reasons, which is why requirements B and C are SHOULDs, 458 not a MUSTs. 460 Applications generally handle connection establishment failure 461 better than established connection failure. This is why dropping 462 the packet initiating the new connection is preferred over 463 deleting existing mappings. See also the rationale in [RFC5508] 464 section 6. 466 4. Logging 468 It may be necessary for CGN administrators to be able to identify a 469 subscriber based on external IPv4 address, port, and timestamp in 470 order to deal with abuse. When multiple subscribers share a single 471 external address, the source address and port that are visible at the 472 destination host have been translated from the ones originated by the 473 subscriber. 475 In order to be able to do this, the CGN would need to log the 476 following information for each mapping created: 478 o subscriber identifier (e.g., internal source address or tunnel 479 endpoint identifier) 481 o external source address 483 o external source port 485 o timestamp 487 By "subscriber identifier" we mean information that uniquely 488 identifies a subscriber. For example, in a traditional NAT scenario, 489 the internal source address would be sufficient. In the case of DS- 490 Lite, many subscribers share the same internal address and the 491 subscriber identifier is the tunnel endpoint identifier (i.e., the 492 B4's IPv6 address). 494 A disadvantage of logging mappings is that CGNs under heavy usage may 495 produce large amounts of logs, which may require large storage 496 volume. 498 REQ-12: A CGN SHOULD NOT log destination addresses or ports. 500 Justification: Destination logging at the CGN creates privacy 501 issues. Furthermore, readers should be aware of logging 502 recommendations for Internet-facing servers [RFC6302]. With 503 compliant servers, the destination address and port do not need to 504 be logged by the CGN. This can help reduce the amount of logging. 506 This requirement is at the SHOULD level to account for the fact 507 that there may be other reasons for logging destination addresses 508 or ports. 510 5. Bulk Port Allocation 512 So far we have assumed that a CGN allocates one external port for 513 every outgoing connection. In this section, the impacts of 514 allocating multiple external ports at a time are discussed. 516 There is a range of things a CGN can do: 518 Traditional: For every outgoing connection, allocate one external 519 port. 521 Scattered port set: For an outgoing connection, create a set of 522 several non-consecutive external ports. Subsequent outgoing 523 connections will use ports from the set. When the set is 524 exhausted, a new connection causes a new set to be created. A set 525 is smaller or equal to the user's maximum port limit. 527 Consecutive port set: Same as the scattered port set, but the ports 528 allocated to a set are consecutive. 530 Note that this list is not exhaustive. There is a continuum of 531 behavior that a CGN may choose to implement. For example, a CGN 532 could use scattered port sets of consecutive port sets. 534 The impacts of bulk port allocation are as follows. 536 Port Utilization: The mechanisms at the top of the list are very 537 efficient in their port utilization. In that sense, they have 538 good scaling properties (nothing is wasted). The mechanisms at 539 the bottom of the list will waste ports. The number of wasted 540 ports is proportional to size of the "bin". 542 Logging: Traditional allocation creates a lot of log entries as 543 compared to allocation by port sets which creates much fewer 544 entries. Scattered and consecutive port sets generate the same 545 number of log entries. In the case of consecutive port sets, 546 entries can be expressed very compactly by indicating a range 547 (e.g., "12000-12009"). Some scattered port set allocation schemes 548 can also generate small log entries containing the parameters and 549 algorithm used for the port set generation (see, e.g., [RFC6431]). 551 With large set sizes, the logging frequency for scattered and 552 consecutive port sets can approach that of DHCP servers. 554 Security: Traditional and scattered port sets provide very good 555 security in that ports numbers are not easily guessed. Easily 556 guessed port numbers put subscribers at risk of the attacks 557 described in [RFC6056]. Consecutive port sets provides poor 558 security to subscribers, especially if the set size is small. 560 6. Deployment Considerations 562 Several issues are encountered when CGNs are used [RFC6269]. There 563 is current work in the IETF toward alleviating some of these issues. 564 For example, see [I-D.ietf-intarea-nat-reveal-analysis]. 566 7. IANA Considerations 568 There are no IANA considerations. 570 8. Security Considerations 572 If a malicious subscriber can spoof another subscriber's CPE, it may 573 cause a DoS to that subscriber by creating mappings up to the allowed 574 limit. An ISP can prevent this with ingress filtering, as described 575 in [RFC2827]. 577 This document recommends Endpoint-Independent Filtering (EIF) as the 578 default filtering behavior for CGNs. EIF has security considerations 579 which are discussed in [RFC4787]. 581 NATs sometimes perform fragment reassembly. CGNs would do so at 582 presumably high data rates. Therefore, the reader should be familiar 583 with the potential security issues described in [RFC4963]. 585 9. Acknowledgements 587 Thanks for the input and review by Alexey Melnikov, Arifumi 588 Matsumoto, Barry Leiba, Benson Schliesser, Dai Kuwabara, Dan Wing, 589 Dave Thaler, David Harrington, Francis Dupont, Jean-Francois 590 Tremblay, Joe Touch, Lars Eggert, Kousuke Shishikura, Mohamed 591 Boucadair, Nejc Skoberne, Reinaldo Penno, Sam Hartman, Senthil 592 Sivakumar, Takanori Mizuguchi, Takeshi Tomochika, Tina Tsou, Tomohiro 593 Fujisaki, Tomohiro Nishitani, Tomoya Yoshida, Wesley Eddy, and 594 Yasuhiro Shirasaki. Dan Wing also contributed much of section 5. 596 10. References 598 10.1. Normative References 600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", BCP 14, RFC 2119, March 1997. 603 [RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and 604 C. Wang, "Definitions of Managed Objects for Network 605 Address Translators (NAT)", RFC 4008, March 2005. 607 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 608 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 609 RFC 4787, January 2007. 611 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 612 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 613 RFC 5382, October 2008. 615 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 616 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 617 April 2009. 619 [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) 620 Behavioral Requirements for the Datagram Congestion 621 Control Protocol", BCP 150, RFC 5597, September 2009. 623 [I-D.ietf-pcp-base] 624 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 625 Selkirk, "Port Control Protocol (PCP)", 626 draft-ietf-pcp-base-26 (work in progress), June 2012. 628 10.2. Informative Reference 630 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 631 RFC 793, September 1981. 633 [RFC1122] Braden, R., "Requirements for Internet Hosts - 634 Communication Layers", STD 3, RFC 1122, October 1989. 636 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 637 Translator (NAT) Terminology and Considerations", 638 RFC 2663, August 1999. 640 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 641 Defeating Denial of Service Attacks which employ IP Source 642 Address Spoofing", BCP 38, RFC 2827, May 2000. 644 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 645 Errors at High Data Rates", RFC 4963, July 2007. 647 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 648 February 2009. 650 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 651 Protocol Port Randomization", BCP 156, RFC 6056, 652 January 2011. 654 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 655 NAT64: Network Address and Protocol Translation from IPv6 656 Clients to IPv4 Servers", RFC 6146, April 2011. 658 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 659 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 660 June 2011. 662 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 663 Roberts, "Issues with IP Address Sharing", RFC 6269, 664 June 2011. 666 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 667 "Logging Recommendations for Internet-Facing Servers", 668 BCP 162, RFC 6302, June 2011. 670 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 671 Stack Lite Broadband Deployments Following IPv4 672 Exhaustion", RFC 6333, August 2011. 674 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 675 T. Tsou, "Huawei Port Range Configuration Options for PPP 676 IP Control Protocol (IPCP)", RFC 6431, November 2011. 678 [I-D.ietf-behave-nat-mib] 679 Perreault, S., Tsou, T., and S. Sivakumar, "Additional 680 Managed Objects for Network Address Translators (NAT)", 681 draft-ietf-behave-nat-mib-01 (work in progress), 682 June 2012. 684 [I-D.ietf-intarea-nat-reveal-analysis] 685 Boucadair, M., Touch, J., Levis, P., and R. Penno, 686 "Analysis of Solution Candidates to Reveal a Host 687 Identifier (HOST_ID) in Shared Address Deployments", 688 draft-ietf-intarea-nat-reveal-analysis-02 (work in 689 progress), April 2012. 691 [I-D.donley-nat444-impacts] 692 Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. 693 Colorado, "Assessing the Impact of Carrier-Grade NAT on 694 Network Applications", draft-donley-nat444-impacts-04 695 (work in progress), May 2012. 697 [I-D.boucadair-pcp-bittorrent] 698 Boucadair, M., Zheng, T., Deng, X., and J. Queiroz, 699 "Behavior of BitTorrent service in PCP-enabled networks 700 with Address Sharing", draft-boucadair-pcp-bittorrent-00 701 (work in progress), May 2012. 703 Appendix A. Change Log (to be removed by RFC Editor prior to 704 publication) 706 A.1. Changed in -08 708 o Made it super explicit that we're talking about an IPv4-only CGN 709 logical *function*, not an IPv4-only CGN *scenario*. This changes 710 and simplifies the definition of CGN a bit. 712 o Did NOT change the intended status. Further guidance from IESG is 713 necessary. 715 o Fixed a huge typo in REQ-7. 717 o Fixed bugs in REQ-5-B justification. 719 o Added REQ-9 items A to D which constrain PCP server behavior. 721 A.2. Changed in -07 723 o Fixed sub-requirement numbering in REQ-1. 725 o Reference update. 727 o Changed REQ-2 back to MUST (from SHOULD). 729 o Added reference to RFC6264 (incremental CGN). 731 o Be more clear that this is not an endorsement of CGN. 733 o Make it clear that this draft is only about IPv4. 735 o Added justification for a bunch of SHOULDs and turned the 736 remaining ones into MUSTs. 738 A.3. Changed in -06 740 o Expanded some acronyms. 742 o Added example IP addresses to ASCII art. 744 o Reword transport protocol section. 746 o Stronger words of caution about CGNs. 748 o Refer to RFC for DCCP NAT behaviour. 750 o Note in headers and abstract that this updates RFC 4787. 752 o Remove sentence "This is not to be considered a solution to the 753 shortage of IPv4 addresses." 755 o Remove text having marketing scent. 757 o Change some "MUST ... unless" requirements to "SHOULD ... unless". 759 o Merge REQ-8 and REQ-9. 761 o PCP is now a MUST. 763 o NAT-MIB is now an example rather than specificially required. 765 o When a quota is hit, send ICMP DU code 1 instead of code 3. 767 o Remove mention of "lawful intercept". 769 o Remove discussion on destination logging from section on bulk port 770 allocation. 772 o Remove discussion on address sharing ratio. 774 A.4. Changed in -05 776 o Removed DSCP requirement since it applies to non-CG NATs as well. 778 o Removed instances of "NAT444". 780 o Filtering has no effect on the requirement for a hold down pool. 781 Removed REQ-8-B. 783 o Statically assigned port ranges do not need to go in the hold down 784 pool. Added a new REQ-8-B. 786 o Fixed various nits. More precise text in some places. 788 A.5. Changed in -04 790 o Fixed nits, spelling, updated references. 792 o CGNs SHOULD NOT log destinations. 794 o Allow address-dependent filtering when it does not cause the 795 application protocol to break. 797 o Refer to RFC4787 security considerations on EIF. 799 o Clarify REQ-12 point D (it does not apply to operator 800 intervention). 802 o Changed "CGNs SHOULD limit ..." to "SHOULD support limiting" to 803 make it clear that the operator is in control. 805 o Added reference to RFC 4963. 807 o Added requirement for non-contiguous external address pools. 809 A.6. Changed in -03 811 o Added exceptions for which it is not necessary to wait 120 seconds 812 before reusing a port. 814 o Renamed "random port set" to "scattered port set", which is more 815 accurate. 817 o Log "subscriber identifier" instead of internal address+port to 818 allow for overlapping internal address ranges (DS-Lite). 820 o Adjusted logging text and added reference to I-D.boucadair-pppext- 821 portrange-option. 823 o Adjusted destination logging text for bulk port allocation 824 schemes. 826 o Removed requirement for I-D.ietf-intarea-ipv4-id-update. 828 o Made PCP support a SHOULD-level requirement. 830 o Lowered the level of requirement for not dropping existing 831 mappings in order to "make room" to SHOULD level, and added 832 rationale. 834 A.7. Changed in -02 836 o CGNs MUST support at least TCP, UDP, and ICMP. 838 o Add requirement from I-D.ietf-intarea-ipv4-id-update. 840 o Add informative reference to [RFC6269]. 842 o Add requirement (SHOULD level) for a port forwarding protocol. 844 o Allow any pooling behavior on a per-application protocol basis. 846 o Adjust wording for external port allocation rate limiting. 848 o Add requirement for RFC4008 support (SHOULD level). 850 o Adjust wording for swapping address pools when rebooting. 852 o Add DSCP requirement (stolen from draft-jennings-behave-nat6). 854 o Add informative reference to 855 draft-boucadair-intarea-nat-reveal-analysis. 857 o Add requirement for hold-down pool. 859 o Change definition of CGN. 861 o Avoid usage of "device" loaded word throughout the document. 863 o Add requirement about resource exhaustion. 865 o Change title. 867 o Describe additional CGN topology where there is no NAT444. 869 o Better justification for "Paired" pool behavior. 871 o Make it clear that rate limiting allocation is for preserving CPU 872 resources 874 o Generalize the requirement for limiting the number of TCP sessions 875 per mapping so that it applies to all memory-consuming state 876 elements. 878 o Change CPE to subscriber where it applies throughout the text. 880 o Better terminology for bulk port allocation mechanisms. 882 o Explain how external address pairing works with DS-Lite. 884 A.8. Changed in -01 886 o Terminology: LSN is now CGN. 888 o Imported all requirements from RFCs 4787, 5382, and 5508. This 889 allowed us to eliminate some duplication. 891 o Added references to 892 draft-ietf-intarea-server-logging-recommendations and 893 draft-ford-shared-addressing-issues. 895 o Incorporated a requirement from 896 draft-xu-behave-stateful-nat-standby-06. 898 Authors' Addresses 900 Simon Perreault (editor) 901 Viagenie 902 246 Aberdeen 903 Quebec, QC G1R 2E1 904 Canada 906 Phone: +1 418 656 9254 907 Email: simon.perreault@viagenie.ca 908 URI: http://www.viagenie.ca 909 Ikuhei Yamagata 910 NTT Communications Corporation 911 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 912 Tokyo 108-8118 913 Japan 915 Phone: +81 50 3812 4704 916 Email: ikuhei@nttv6.jp 918 Shin Miyakawa 919 NTT Communications Corporation 920 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 921 Tokyo 108-8118 922 Japan 924 Phone: +81 50 3812 4695 925 Email: miyakawa@nttv6.jp 927 Akira Nakagawa 928 Japan Internet Exchange Co., Ltd. (JPIX) 929 Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku 930 Tokyo 100-0004 931 Japan 933 Phone: +81 90 9242 2717 934 Email: a-nakagawa@jpix.ad.jp 936 Hiroyuki Ashida 937 IS Consulting G.K. 938 12-17 Odenma-cho Nihonbashi Chuo-ku 939 Tokyo 103-0011 940 Japan 942 Email: assie@hir.jp