idnits 2.17.1 draft-boucadair-pppext-portrange-option-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 15, 2011) is 4606 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 366 -- Looks like a reference, but probably isn't: '1' on line 364 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft P. Levis 4 Intended status: Informational France Telecom 5 Expires: March 18, 2012 G. Bajko 6 T. Savolainen 7 Nokia 8 T. Tsou 9 Huawei Technologies (USA) 10 September 15, 2011 12 Huawei Port Range Configuration Options for PPP IPCP 13 draft-boucadair-pppext-portrange-option-09 15 Abstract 17 This document defines two Huawei IPCP (IP Configuration Protocol) 18 Options used to convey a set of ports. These options can be used in 19 the context of port range-based solutions or NAT-based ones for port 20 delegation and forwarding purposes. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 18, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Port Range Options . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Description of Port Range Value and Port Range Mask . . . 4 67 2.2. Description of Cryptographically Random Port Range 68 option . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.2.1. Random Port Delegation Function . . . . . . . . . . . 7 70 2.2.2. Description of Cryptographically Random Port Range 71 Option . . . . . . . . . . . . . . . . . . . . . . . . 9 72 2.3. Illustration Examples . . . . . . . . . . . . . . . . . . 10 73 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 10 74 2.3.2. Successful Flow: Port Range Options supported by 75 both the Client and the Server . . . . . . . . . . . . 11 76 2.3.3. Port Range Option Not Supported by the Server . . . . 12 77 2.3.4. Port Range Option not Supported by the Client . . . . 14 78 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 84 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 Within the context of IPv4 address depletion, several solutions have 90 been investigated to share IPv4 addresses. Two flavors can be 91 distinguished: NAT-based solutions (a.k.a., Carrier Grade NAT (CGN, 92 [I-D.ietf-behave-lsn-requirements])) or port range based ones (e.g., 93 [RFC6346] [I-D.boucadair-port-range][I-D.despres-sam]). Port range- 94 based solutions do not require an additional NAT level in the service 95 provider's domain. Several means may be used to convey Port Range 96 information. 98 This document defines the notion of Port Mask which is generic and 99 flexible. Several allocation schemes may be implemented when using a 100 Port Mask. It proposes a basic mechanism that allows the allocation 101 of a unique port range to a requesting client. This document defines 102 Huawei IPCP options to be used to carry Port Range information. 104 IPv4 address exhaustion is only provided as an example of the usage 105 of the PPP IPCP Options defined in this document. In particular, 106 Port Range Options may be used independently of the presence of IP- 107 Address IPCP Option. 109 This document adheres to the consideration defined in [RFC2153]. 111 This document is not a product of pppext working group. 113 Note that IPR disclosures apply to this document (see 114 https://datatracker.ietf.org/ipr/). 116 1.1. Use Cases 118 Port Range Options can be used in port range-based solutions (e.g., 119 [RFC6346]) or in a CGN-based solution. These options can be used in 120 a CGN context to bypass the NAT (i.e., for transparent NAT traversal 121 and avoid involving several NAT levels in the path) or to delegate 122 one or a set of ports to the requesting client (e.g., avoid ALG 123 (Application Level Gateway) or for port forwarding). 125 Section 3.3.1 of [RFC6346] specifies an example of usage of the 126 options defined in this document. 128 1.2. Terminology 130 To differentiate between a Port Range containing a contiguous span of 131 port numbers and a Port Range with non contiguous and possibly random 132 port numbers, the following denominations are used: 134 o Contiguous Port Range: a set of port values which form a 135 contiguous sequence. 137 o Non Contiguous Port Range: a set of port values which does not 138 form a contiguous sequence. 140 o Random Port Range: a cryptographically random set of port values. 142 Unless explicitly mentioned, Port Mask refers to the tuple (Port 143 Range Value, Port Range Mask). 145 In addition, this document makes use of the following terms: 147 o Delegated port or delegated port range: a port or a range of ports 148 belonging to an IP address managed by an upstream device (such as 149 NAT), which are delegated to a client for use as source address 150 and port when sending packets. 152 o Forwarded port or forwarder port range: a port or a range of ports 153 belonging to an IP address managed by an upstream device such as 154 (NAT), which is/are statically mapped to the internal IP address 155 of the client and same port number of the client. 157 This memo uses the same terminology as per [RFC1661]. 159 2. Port Range Options 161 This section defines the IPCP Option for Port Range delegation. The 162 format of vendor-specific options is defined in [RFC2153]. Below are 163 provided the values to be conveyed when the Port Range Option is 164 used: 166 o Organizationally Unique Identifier (OUI): This field is set to 167 781DBA (hex). 169 o Kind: This field is set to F0 (hex). 171 o Value: The content of this field is specified in Section 2.1 and 172 Section 2.2.2. 174 2.1. Description of Port Range Value and Port Range Mask 176 The Port Range Value and Port Range Mask are used to specify one 177 range of ports (contiguous or not contiguous) pertaining to a given 178 IP address. Concretely, Port Range Mask and Port Range Value are 179 used to notify a remote peer about the Port Mask to be applied when 180 selecting a port value as a source port. The Port Range Value is 181 used to infer a set of allowed port values. A Port Range Mask 182 defines a set of ports that all have in common a subset of pre- 183 positioned bits. This set of ports is also called Port Range. 185 Two port numbers are said to belong to the same Port Range if and 186 only if, they have the same Port Range Mask. 188 A Port Mask is composed of a Port Range Value and a Port Range Mask: 190 o The Port Range Value indicates the value of the significant bits 191 of the Port Mask. The Port Range Value is coded as follows: 193 * The significant bits may take a value of 0 or 1. 195 * All the other bits (a.k.a., non significant ones) are set to 0. 197 o The Port Range Mask indicates, by the bit(s) set to 1, the 198 position of the significant bits of the Port Range Value. 200 This IPCP Configuration Option provides a way to negotiate the Port 201 Range to be used on the local end of the link. It allows the sender 202 of the Configure-Request message to state which Port Range associated 203 with a given IP address is desired, or to request the peer to provide 204 the configuration. The peer can provide this information by NAKing 205 the option, and returning a valid Port Range (i.e., (Port Range 206 Value, Port Range Mask)). 208 When a peer issues a request enclosing IPCP Port Range Option, and if 209 the server does not support this option, the Port Range Option is 210 rejected by the server. 212 The set of ports conveyed in an IPCP Port Range Option applies to all 213 transport protocols. 215 The set of ports conveyed in a IPCP Port Range Option are revoked 216 when the link is not any more up (e.g., when Terminate-Request and 217 Terminate-Ack are exchanged). 219 The Port Range IPCP option adheres to the format defined in Section 220 2.1 of [RFC2153]. The "value" field of the option defined in 221 [RFC2153] when conveying Port Range IPCP Option is provided in 222 Figure 1. 224 0 1 2 3 225 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 |M| Reserved | Port Range Value | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Port Range Mask | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 MSB network order is used for encoding Port Range Value and Port 233 Range Mask fields. 235 Figure 1: Format of the Port Range IPCP Option 237 o M: mode bit. It indicates the mode the port range is allocated 238 for. A value of zero indicates the port ranges are delegated, 239 while a value of 1 indicates the port ranges are port forwarded. 241 o Port Range Value (PRV): PRV indicates the value of the significant 242 bits of the Port Mask. By default, no PRV is assigned. 244 o Port Range Mask (PRM): Port Range Mask indicates the position of 245 the bits which are used to build the Port Range Value. By 246 default, no PRM value is assigned. The 1 values in the Port Range 247 Mask indicate by their position the significant bits of the Port 248 Range Value. 250 Figure 2 provides an example of the resulting Port Range: 252 - Port Range Mask is set to 0001010000000000 (5120) and 254 - Port Range Value is set to 0000010000000000 (1024). 256 0 1 257 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 |0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0| Port Range Mask 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | | 262 | | (two significant bits) 263 v v 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 |0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0| Port Range Value 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 |x x x 0 x 1 x x x x x x x x x x| Usable ports (x may be set to 0 or 1) 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 2: Example of Port Range Mask and Port Range Value 274 Port values belonging to this Port Range must have the 4th bit (resp. 275 the sixth one), from the left, set to 0 (resp. 1). Only these port 276 values will be used by the peer when enforcing the configuration 277 conveyed by PPP IPCP. 279 2.2. Description of Cryptographically Random Port Range option 281 A cryptographically random Port Range Option may be used as a 282 mitigation tool against blind attacks described in [RFC6056]. 284 2.2.1. Random Port Delegation Function 286 Delegating random ports can be achieved by defining a function which 287 takes as input a key 'k' and an integer 'x' within the range (1024, 288 65535) and produces an output 'y' also within the port range (1024, 289 65535). 291 The cryptographical mechanism uses the 1024-65535 port range rather 292 than the ephemeral range, 49152 through 65535, for generating a set 293 of ports to optimize the IPv4 address utilization efficiency (see 294 "Appendix B. Address Space Multiplicative Factor" of [RFC6269]). 295 This behavior is compliant with the recommendation to use the whole 296 range 1024-65535 for the ephemeral port selection algorithms (See 297 Section 3.2 of [RFC6056]). 299 The cryptographical mechanism ensures that the entire 64k port range 300 can be efficiently distributed to multiple nodes in a way that when 301 nodes calculate the ports, the results will never overlap with ports 302 other nodes have calculated (property of permutation), and ports in 303 the reserved range (smaller than 1024) are not used. As the 304 randomization is done cryptographically, an attacker seeing a node 305 using some port X cannot determine which other ports the node may be 306 using (as the attacker does not know the key). Calculation of the 307 random port list is done as follows: 309 The cryptographic mechanism uses an encryption function y = E(K,x) 310 that takes as input a key K (for example, 128 bits) and an integer x 311 (the plaintext) in range (1024, 65535), and produces an output y (the 312 ciphertext), also an integer in range (1024, 65535). This section 313 describes one such encryption function, but others are also possible. 315 The server will select the key K. When the server wants to allocate 316 e.g. 2048 random ports, it selects a starting point 'a' (1024 <= a <= 317 65536-2048) in a way that the port range (a, a+2048) does not overlap 318 with any other active client, and calculates the values E(K,a), 319 E(K,a+1), E(K,a+2), ..., E(K,a+2046), E(K,a+2047). These are the 320 port numbers allocated for this node. Instead of sending the port 321 numbers individually, the server just sends the values 'K', ' a', and 322 '2048'. The client will then repeat the same calculation. 324 The server SHOULD use different K for each IPv4 address it allocates 325 to make attacks as difficult as possible. This way, learning the K 326 used in IPv4 address IP1 would not help in attacking IPv4 address IP2 327 that is allocated by the same server to different nodes. 329 With typical encryption functions (such as AES and DES), the input 330 (plaintext) and output (ciphertext) are blocks of some fixed size; 331 for example, 128 bits for AES, and 64 bits for DES. For port 332 randomization, we need an encryption function whose input and output 333 is an integer in range (1024, 65535). 335 One possible way to do this is to use the 'Generalized-Feistel 336 Cipher' [CIPHERS] construction by Black and Rogaway, with AES as the 337 underlying round function. 339 This would look as follows (using pseudo-code): 340 def E(k, x): 341 y = Feistel16(k, x) 342 if y >= 1024: 343 return y 344 else: 345 return E(k, y) 347 Note that although E(k,x) is recursive, it is guaranteed to 348 terminate. The average number of iterations is just slightly over 1. 350 Feistel16 is a 16-bit block cipher: 352 def Feistel16(k, x): 353 left = x & 0xff 354 right = x >> 8 355 for round = 1 to 3: 356 temp = left ^ FeistelRound(k, round, right)) 357 left = right 358 right = temp 359 return (right << 8) | left 360 The Feistel round function uses: 362 def FeistelRound(k, round, x): 363 msg[0] = round 364 msg[1] = x 365 msg[2...15] = 0 366 return AES(k, msg)[0] 367 Performance: To generate list of 2048 port numbers, about 6000 calls 368 to AES are required (i.e., encrypting 96 kilobytes). Thus, it will 369 not be a problem for any device that can do, for example, HTTPS (web 370 browsing over SSL/TLS). 372 2.2.2. Description of Cryptographically Random Port Range Option 374 The cryptographically Random Port Range IPCP Option adheres to the 375 format defined in Section 2.1 of [RFC2153]. The "value" field of the 376 option defined in [RFC2153] when conveying cryptographically Random 377 Port Range IPCP Option is illustrated in Figure 3 379 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 |M| Reserved | function | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | starting point | number of delegated ports | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | key K ... 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 ... ... 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 ... ... 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 ... | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Figure 3: Format of the cryptographically Random Port Range option 396 o M: mode bit. It indicates the mode the port range is allocated 397 for. A value of zero indicates the port ranges are delegated, 398 while a value of 1 indicates the port ranges are port forwarded. 400 o Function: A 16 bit field whose value is associated with predefined 401 encryption functions. This specification associates value 1 with 402 the predefined function described in Section 2.2.1. 404 o Starting Point: A 16 bit value used as an input to the specified 405 function 407 o Number of delegated ports: A 16 bit value specifying the number of 408 ports delegated to the client for use as source port values. 410 o Key K: A 128 bit key used as input to the predefined function for 411 delegated port calculation. 413 When the option is included in the IPCP Configure-Request 'key field' 414 and 'starting point' field SHALL be set to all zeros. The requester 415 MAY indicate in the 'function' field which encryption function 416 requester prefers, and in the 'number of delegated ports' field the 417 number of ports the requester would like to obtain. If requester has 418 no preference it SHALL set also the 'function' field and/or 'number 419 of delegated ports' field to zero. 421 The usage of the option in IPCP message negotiation (Request/Reject/ 422 Nak/Ack) follows the logic described for Port Mask and Port Range 423 options at Section 2.1. 425 2.3. Illustration Examples 427 2.3.1. Overview 429 These flows provide examples of the usage of IPCP to convey the Port 430 Range Option. As illustrated in Figure 4, IPCP messages are 431 exchanged between a Host and a BRAS (Broadband Access Server). 433 1. The first example illustrates a successful IPCP exchange; 435 2. The second example shows the IPCP exchange that occurs when Port 436 Range Option is not supported by the server; 438 3. The third example shows the IPCP exchange that occurs when Port 439 Range Option is not supported by the client; 441 4. The fourth example shows the IPCP exchange that occurs when Port 442 Range Option is not supported by the client and a non null IP 443 (i.e., an address different from 0.0.0.0) address is enclosed in 444 the first configuration request issued by the peer. 446 2.3.2. Successful Flow: Port Range Options supported by both the Client 447 and the Server 449 The following message exchange (i.e., Figure 4) provides an example 450 of successful IPCP configuration operation when the Port Range IPCP 451 Option is used. 453 +-----+ +-----+ 454 | Host| | BRAS| 455 +-----+ +-----+ 456 | | 457 | (1) IPCP Configure-Request | 458 | IP ADDRESS=0.0.0.0 | 459 | PORT RANGE VALUE=0 | 460 | PORT RANGE MASK=0 | 461 |===============================================>| 462 | | 463 | (2) IPCP Configure-Nak | 464 | IP ADDRESS=a.b.c.d | 465 | PORT RANGE VALUE=80 | 466 | PORT RANGE MASK=496 | 467 |<===============================================| 468 | | 469 | (3) IPCP Configure-Request | 470 | IP ADDRESS=a.b.c.d | 471 | PORT RANGE VALUE=80 | 472 | PORT RANGE MASK=496 | 473 |===============================================>| 474 | | 475 | (4) IPCP Configure-Ack | 476 | IP ADDRESS=a.b.c.d | 477 | PORT RANGE VALUE=80 | 478 | PORT RANGE MASK=496 | 479 |<===============================================| 480 | | 482 Figure 4: Successful flow 484 The main steps of this flow are listed below: 486 (1) The Host sends a first Configure-Request which includes the 487 set of options it desires to negotiate. All these Configuration 488 Options are negotiated simultaneously. In this example, 489 Configure-Request carries information about IP-address, Port Range 490 Value and Port Range Mask. In this example, IP-address Option is 491 set to 0.0.0.0, Port Range Value is set to 0 and Port Range Mask 492 is set to 0. 494 (2) BRAS sends back a Configure-Nak and sets the enclosed options 495 to its preferred values. In this example: IP-Address Option is 496 set to a.b.c.d, Port Range Value is set to 80 and Port Range Mask 497 is set to 496. 499 (3) The Host re-sends a Configure-Request requesting IP-address 500 Option to be set to a.b.c.d, Port Range Value to be set to 80 and 501 Port Range Mask to be set to 496. 503 (4) BRAS sends a Configure-Ack message 505 As a result of this exchange, Host is configured to use as local IP 506 address a.b.c.d and the following 128 contiguous Port Ranges 507 resulting of the Port Mask (Port Range Value == 0, Port Range Mask == 508 496): 510 - from 80 to 95 512 - from 592 to 607 514 - ... 516 - from 65104 to 65119 518 2.3.3. Port Range Option Not Supported by the Server 520 This example (Figure 5) depicts an exchange of messages when the BRAS 521 does not support IPCP Port Range Option. 523 +-----+ +-----+ 524 | Host| | BRAS| 525 +-----+ +-----+ 526 | | 527 | (1) IPCP Configure-Request | 528 | IP ADDRESS=0.0.0.0 | 529 | PORT RANGE VALUE=0 | 530 | PORT RANGE MASK=0 | 531 |===============================================>| 532 | | 533 | (2) IPCP Configure-Reject | 534 | PORT RANGE VALUE=0 | 535 | PORT RANGE MASK=0 | 536 |<===============================================| 537 | | 538 | (3) IPCP Configure-Request | 539 | IP ADDRESS=0.0.0.0 | 540 |===============================================>| 541 | | 542 | (4) IPCP Configure-Nak | 543 | IP ADDRESS=a.b.c.d | 544 |<===============================================| 545 | | 546 | (5) IPCP Configure-Request | 547 | IP ADDRESS=a.b.c.d | 548 |===============================================>| 549 | | 550 | (6) IPCP Configure-Ack | 551 | IP ADDRESS=a.b.c.d | 552 |<===============================================| 553 | | 555 Figure 5: Failed flow: Port Range Option not supported by the server 557 The main steps of this flow are listed hereafter: 559 (1) The Host sends a first Configure-Request which includes the 560 set of options it desires to negotiate. All these Configuration 561 Options are negotiated simultaneously. In this example, 562 Configure-Request carries the codes of IP-address, Port Range 563 Value and Port Range Mask options. In this example, IP-address 564 Option is set to 0.0.0.0, Port Range Value is set to 0 and Port 565 Range Mask is set to 0. 567 (2) BRAS sends back a Configure-Reject to decline Port Range 568 option. 570 (3) The Host sends a Configure-Request which includes only the 571 codes of IP-Address option. In this example, IP-Address Option is 572 set to 0.0.0.0. 574 (4) BRAS sends back a Configure-Nak and sets the enclosed option 575 to its preferred value. In this example: IP-Address Option is set 576 to a.b.c.d. 578 (5) The Host re-sends a Configure-Request requesting IP-Address 579 Option to be set to a.b.c.d. 581 (6) BRAS sends a Configure-Ack message. 583 As a result of this exchange, Host is configured to use as local IP 584 address a.b.c.d. This IP address is not a shared IP address. 586 2.3.4. Port Range Option not Supported by the Client 588 This example (Figure 6) depicts exchanges when only shared IP 589 addresses are assigned to end-user's devices. The server is 590 configured to assign only shared IP addresses. If Port Range Options 591 are not enclosed in the configuration request, the request is 592 rejected and the requesting peer will be unable to access the service 593 as depicted in Figure 6. 595 +-----+ +-----+ 596 | Host| | BRAS| 597 +-----+ +-----+ 598 | | 599 | (1) IPCP Configure-Request | 600 | IP ADDRESS=0.0.0.0 | 601 |===============================================>| 602 | | 603 | (2) IPCP Protocol-Reject | 604 |<===============================================| 605 | | 607 Figure 6: Port Range Option not supported by the Client 609 The main steps of this flow are: 611 (1) The Host sends a Configure-Request requesting IP-Address 612 Option to be set to 0.0.0.0 and without enclosing the Port Range 613 Option. 615 (2) BRAS sends a Protocol-Reject message. 617 As a result of this exchange, Host is not able to access the service. 619 3. IANA Considerations 621 No action is required from IANA since this document adheres to 622 [RFC2153]. 624 4. Security Considerations 626 This document does not introduce any security issue in addition to 627 those related to PPP. Service providers should use authentication 628 mechanisms such as CHAP [RFC1994] or PPP link encryption [RFC1968]. 630 The use of small and non-random port range may increase host exposure 631 to attacks described in [RFC6056]. This risk can be reduced by using 632 larger port ranges, by using Random Port Range Option or by 633 activating means to improve the robustness of TCP against Blind In- 634 Window Attacks [RFC5961]. 636 5. Contributors 638 Jean-Luc Grimault and Alain Villefranque contributed to this 639 document. 641 6. Acknowledgements 643 The authors would like to thank C. Jacquenet, J. Carlson, B. 644 Carpenter, M. Townsley and J. Arkko for their review. 646 7. References 648 7.1. Normative References 650 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 651 RFC 1661, July 1994. 653 [RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol 654 (ECP)", RFC 1968, June 1996. 656 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 657 Protocol (CHAP)", RFC 1994, August 1996. 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, March 1997. 662 [RFC2153] Simpson, W. and K. Fox, "PPP Vendor Extensions", RFC 2153, 663 May 1997. 665 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 666 Robustness to Blind In-Window Attacks", RFC 5961, 667 August 2010. 669 7.2. Informative References 671 [CIPHERS] Black, J. and P. Rogaway, "Ciphers with Arbitrary Finite 672 Domains Topics in Cryptology", 2002, < CT-RSA 2002, 673 Lecture Notes in Computer Science vol. 2271>. 675 [I-D.boucadair-port-range] 676 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 677 "IPv4 Connectivity Access in the Context of IPv4 Address 678 Exhaustion: Port Range based IP Architecture", 679 draft-boucadair-port-range-02 (work in progress), 680 July 2009. 682 [I-D.despres-sam] 683 Despres, R., "Scalable Multihoming across IPv6 Local- 684 Address Routing Zones Global-Prefix/Local-Address 685 Stateless Address Mapping (SAM)", draft-despres-sam-03 686 (work in progress), July 2009. 688 [I-D.ietf-behave-lsn-requirements] 689 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 690 and H. Ashida, "Common requirements for Carrier Grade NAT 691 (CGN)", draft-ietf-behave-lsn-requirements-03 (work in 692 progress), August 2011. 694 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 695 Protocol Port Randomization", BCP 156, RFC 6056, 696 January 2011. 698 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 699 Roberts, "Issues with IP Address Sharing", RFC 6269, 700 June 2011. 702 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 703 IPv4 Address Shortage", RFC 6346, August 2011. 705 Authors' Addresses 707 Mohamed Boucadair 708 France Telecom 709 Rennes 35000 710 France 712 Email: mohamed.boucadair@orange-ftgroup.com 714 Pierre Levis 715 France Telecom 716 Caen 717 France 719 Email: pierre.levis@orange-ftgroup.com 721 Gabor Bajko 722 Nokia 724 Email: gabor(dot)bajko(at)nokia(dot)com 726 Teemu Savolainen 727 Nokia 729 Email: teemu.savolainen@nokia.com 731 Tina Tsou 732 Huawei Technologies (USA) 733 2330 Central Expressway 734 Santa Clara, CA 95050 735 USA 737 Phone: +1 408 330 4424 738 Email: tina.tsou.zouting@huawei.com