idnits 2.17.1 draft-bajko-pripaddrassign-04.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 == Line 604 has weird spacing: '... option and a...' -- The document date (March 30, 2012) is 4407 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) -- Looks like a reference, but probably isn't: '0' on line 556 -- Looks like a reference, but probably isn't: '1' on line 554 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire WG Gabor Bajko 3 Internet Draft Teemu Savolainen 4 Intended Status: Standards Track Nokia 5 Expires: September 30, 2012 M. Boucadair 6 P. Levis 7 France Telecom 8 March 30, 2012 10 Port Restricted IP Address Assignment 11 draft-bajko-pripaddrassign-04 13 Abstract 15 This document defines an IPv4 DHCP Option and related behaviours to 16 allocate the same IPv4 address to multiple nodes by sharing the 17 available port space among them. The two sub-options defined in this 18 document specify random port allocation to nodes in order to 19 maximize the entropy of port randomization. 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 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 30, 2012. 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 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Port Restricted IP address assignment September 2010 55 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 59 this document are to be interpreted as described in RFC-2119 60 [RFC2119]. 62 Terminology and Abbreviations used in this Document 64 This document makes use of the following terms: 66 - Port restricted IPv4 address: an IP address which can only be used 67 in conjunction with the specified port or range of ports. Port 68 restriction refers to all known transport protocols (e.g., UDP, 69 TCP, SCTP, DCCP). 71 - Delegated port or port range: it is a port or a range of ports 72 belonging to an IP address managed by an upstream device (such as 73 NAT), which are delegated to a client for use as source address 74 and port when sending packets. 76 CGN Carrier Grade Network Address Translation 77 CPE Consumer Premises Equipment, a device that resides 78 between internet service provider's network and 79 consumers' network. 80 PRA Port Restricted IPv4 Address 82 Port Restricted IP address assignment September 2010 84 Table of Content 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .4 87 2. Port Randomization . . . . . . . . . . . . . . . . . . . . . . .5 88 3. DHCPv4 Option for allocating port restricted public IPv4 89 address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 90 3.1 Port Delegation with Port Mask Allocation . . . . . . . . . . .7 91 3.2 Port Delegation with Random Port Delegation Function . . . . . 7 92 4. Port Mask Sub-Option Usage . . . . . . . . . . . . . . . . . . .9 93 4.1 Illustration Examples . . . . . . . . . . . . . . . . . . . . .9 94 5. Random Port Delegation Function . . . . . . . . . . . . . . . .11 95 6. Option Usage . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 6.1 Client Behaviour . . . . . . . . . . . . . . . . . . . . . . .12 97 6.2 Server Behaviour . . . . . . . . . . . . . . . . . . . . . . .14 98 7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . .15 99 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . .15 100 9. Security considerations. . . . . . . . . . . . . . . . . . . . 16 101 10. Normative References . . . . . . . . . . . . . . . . . . . . .16 102 11. Informative References . . . . . . . . . . . . . . . . . . . .16 103 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . .17 104 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . .17 106 Port Restricted IP address assignment September 2010 108 1. Introduction 110 There are a number of possible solutions to deal with the problem of 111 transitioning from IPv4 to IPv6; however none of them is a one fits 112 all solution. 114 As complementary solution for the IPv4-IPv6 coexistence period, this 115 document describes a method, using a newly defined IPv4 DHCP 116 [RFC2131] option that allows servers to assign port restricted IPv4 117 addresses to requesting clients. By assigning the same IPv4 address 118 to multiple clients, IPv4-only services will continue to be 119 delivered to subscribers without any degradation nor perceived 120 impact. Furthermore, service providers can continue to propose 121 service offerings with sustainable customer base. 123 The proposed solution is intended to be used by large ISPs, who as 124 of the date of writing this document, have a large enough IPv4 125 address pool to be able to allocate one public IPv4 address for each 126 and every client. They expect though that the situation is 127 unsustainable and they will soon not be able to provide every client 128 with a public IPv4 address. Such ISPs have two possibilities to 129 choose from: 130 - deploy Network Address Translation (NAT), which can be a 131 significant investment for ISPs not having NATs yet. The address 132 space limitations of [RFC1918] may even force these large ISPs to 133 deploy double NATs, which come with all the harmful behaviour of 134 Carrier Grade NATs (CGN), as described in [MAEN2008]; or 135 - allocate fragments of the same public IPv4 address directly to 136 multiple clients (which can be CPEs or end hosts), thus avoid the 137 cost of deploying multiple layers of NATs or Carrier Grade NATs. It 138 is however assumed, that the demand for IPv4 addresses will decrease 139 in the not so distant future, being taken over by IPv6, as the 140 proposal in this draft is not by any means a permanent solution for 141 the IPv4 address exhaustion problem. In fact, some presented 142 deployment scenarios require existence of IPv6 access network. 144 For ISPs not having NATs yet, a solution not requiring NATs would 145 probably be preferred. For some other ISPs, who already have NATs in 146 place, increasing the capacity of their NATs might be a viable 147 alternative. 149 In other deployment scenarios, allocation of shared addresses to 150 devices at the edge of the network would result in distribution of 151 NAT functionality to the edges, in some cases even to CPEs 152 [RFC6346]. 154 This document proposes to use new IPv4 DHCP Options to allocate 155 port-restricted IPv4 addresses to the clients. This method is meant 156 to be an IPv4 to IPv6 transition tool, to be only temporarily used 157 during the period when the demand for public IPv4 addresses will 158 exceed the availability of them. 160 Port Restricted IP address assignment September 2010 162 The port restricted IPv4 address option described in this document 163 can be used in various deployment scenarios, some of which are 164 described in [RFC6346]. 166 2. Port Randomization 168 It is well documented that attackers can perform "blind" attacks 169 against transport protocols. The consequences of these attacks range 170 from throughput-reduction to broken connections or data corruption. 171 These attacks rely on the attacker's ability to guess or know the 172 five-tuple (Protocol, Source Address, Destination Address, Source 173 Port, Destination Port) that identifies the transport protocol 174 instance to be attacked. Most of these attacks can be prevented by 175 randomly selecting the client source port number such that the 176 possibility of an attacker guessing the exact value is reduced. 177 [RFC6056] defines a few algorithms which can select a random port 178 from the available port range. Clients usually have the (1024, 179 65535) port range at their disposal to select a random, not yet used 180 port. 182 When an IP address is allocated to multiple clients, the source port 183 range has to be divided between the clients. The smaller the port 184 range, the easier is for an attacker to guess the next port the 185 client is going to use. Therefore, it is imperative to divide the 186 port range between clients sharing the same IP address in such a way 187 that random selection is preserved. This document proposes two 188 different methods for port allocation, which preserves partly or 189 completely the randomness of the source ports: 191 o The first mechanism uses a port mask with a bit locator to 192 communicate a range or multiple ranges of ports to a client. 193 Randomness is preserved when the client is able to select a 194 port randomly across all the available port ranges. The 195 algorithms described in [RFC6056] can be used to select a 196 random port from one port range, but implementations may find 197 it difficult to select random ports across port ranges. Another 198 alternative is to assign noncontiguous port ranges. Guessing a 199 port number within a non-contiguous port ranges is not trivial. 201 o The second mechanism uses a cryptographic function to pre- 202 allocate random ports from the entire port range. The key and 203 other input parameters are communicated to the client, which 204 can calculate the ports it can use, just as the server pre- 205 calculates them. The 'side effect' of this mechanism is that 206 the client is forced to use random ports, as the random ports 207 allowed to be used by the client are pre-allocated by the 208 server. 210 Port Restricted IP address assignment September 2010 212 3. IPv4 DHCP Option for Allocating Port Restricted Public IPv4 Address 214 This section defines a new IPv4 DHCP Option which allows allocation 215 of port restricted IPv4 addresses. 217 The format for the new IPv4 DHCP option is depicted in Figure 1. 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Option Code | length | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Sub-Option 1 | 224 . . 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | ... | 227 . . 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Sub-Option n | 230 . . 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 1: Port Restricted IP Address DHCP Option format 234 Option Code 235 Option Code 236 OPTION-IPv4-PRA - 1 byte 238 Length 239 An 8-bit field indicating the length of the option excluding 240 the 'Option Code' and the 'Length' fields. 242 Sub-options 243 A series of DHCPv4 sub-options. 245 The sub-option layout is depicted in Figure 2. 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Sub-opt Type | length | DATA... . 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 . ...DATA | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 2: Port Restricted IP Address Sub-option layout 255 The sub-option types defined in this document are: 256 1 Port delegation with port mask allocation 257 2 Port delegation with random port delegation function 258 3 260 Length: an 8-bits field indicating the length of the sub-option 261 excluding the 'Sub-opt Type' and the 'Length' fields. The value of 262 the length field is 8 when the Sub-opt Type equals 1, 26 when the 264 Port Restricted IP address assignment September 2010 266 Sub-opt Type equals 2, 12 when the Sub-opt Type equals 3 and 30 when 267 the Sub-opt Type equals 4. 269 3.1 Port Delegation with Port Mask Allocation 271 The format of the DATA field when sub-option type is set to 1 is 272 shown in Figure 3. 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | IPv4 address | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Port Range Value | Port Range Mask | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 3: Port Range sub-option 283 IPv4 address 284 The IPv4 address allocated to the client by the DHCP server, to 285 be used as source address for the outgoing packets. 287 Port Range Value and Port Range Mask 288 Port Range Value indicates the value of the mask to be applied 289 and Port Range Mask indicates the position of the bits which 290 are used to build the mask. 292 Section 4 describes how the client derives the allocated port range 293 from the Port Range Value and Port Range Mask values. 295 3.2 Port Delegation with Random Port Delegation Function 297 The format of the DATA field when sub-option type is set to 2 is 298 shown in Figure 4. 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | IPv4 address | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | function | starting point | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | number of delegated ports | key K ... 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 ... ... 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 ... ... 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 ... ... 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 ... key K | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Figure 4: Random Port delegation sub-option 318 Port Restricted IP address assignment September 2010 320 IPv4 address 321 The IPv4 address allocated to the client by the DHCP server, to 322 be used as source address for the outgoing packets 324 Function 325 A 16 bits field whose value is associated with predefined 326 encryption functions. This specification associates value 1 327 with the predefined function described in Section 5. 329 Starting Point 330 A 16 bits value used as an input to the specified function. 332 Number of delegated ports 333 A 16 bits value specifying the number of ports delegated to the 334 client for use as source port values. 336 Key K 337 A 128 bits key used as input to the predefined function for 338 delegated port calculation. 340 4. Port Mask Sub-Option Usage 342 The port mask sub-option is used to specify one or multiple range of 343 ports pertaining to the given IP address. 345 Concretely, this option is used to notify a remote DHCP client about 346 the Port Mask to be applied when selecting a port value as a source 347 port. The Port Mask option is used to infer a set of allowed port 348 values. A Port Mask defines a set of ports that all have in common a 349 subset of pre-positioned bits. This ports set is also called Port 350 Range. Two port numbers are said to belong to the same Port Range if 351 and only if, they have the same Port Mask. 353 A Port Mask contains two fields: Port Range Value and Port Range 354 Mask. 356 - The 'Port Range Value' field indicates the value of the 357 significant bits of the Port Mask. The 'Port Range Value' is coded as 358 follows: 359 - The significant bits are those where "1" values are set in 360 the Port Range Mask. These bits may take a value of "0" or "1 ". 361 - All the other bits (non significant ones) are set to "0". 363 - The 'Port Range Mask' field indicates the position of the 364 significant bits identified by the bit(s) set to "1". 366 Port Restricted IP address assignment September 2010 368 The Port Range Value field indicates the value of the mask to be 369 applied and the Port Range Mask field indicates the position of the 370 bits which are used to build the mask. The "1" values in the Port 371 Range Mask field indicate by their position the significant bits of 372 the Port Range Value (the pattern of the Port Range Value). 374 For example: 375 - A Port Range Mask field equal to 1000000000000000 indicates 376 that the first bit (the most significant one) is used as a 377 pattern of the Port Range Value field; 379 - A Port Range Mask field equal to 0000101000000000 indicates 380 that the 5th and the 7th most significant bits are used as a 381 pattern of the Port Range Value. 383 The pattern of the Port Range Value is all the fixed bits in the 384 Port Range Value. All the ports the CPE is allowed to use as source 385 ports must have their number in accordance with the pattern. 387 The Port Range Value is coded as follows: 388 - The pattern bits of the Port Range Value are those where "1" 389 values are set in the Port Range Mask. These bits may take a 390 value of 0 or 1. 391 - All the other bits are set to "0". 393 4.1 Illustration Examples 395 In each of the three examples below allocation of 2048 ports is done 396 differently. In all examples it is possible for 32 nodes to share 397 the same public IPv4 address. The 4th example illustrates the 398 ability of the procedure to enforce a balanced distribution of port 399 numbers including the well-known-port values. 401 a) the following Port Range Mask and Port Range Value are conveyed 402 using DHCP to assign a Port Range (from 2048 to 4095) to a given 403 device: 404 - Port Range Value: 0000100000000000 (2048) 405 - Port Range Mask: 1111100000000000 (63488) 407 b) Unlike the previous example, this one illustrates the case where 408 a non Contiguous Port Range is assigned to a given customer's 409 device. In this example, the Port Range Value defines 128 Contiguous 410 Port Ranges, each one with a length of 16 port values. Note that 411 the two first Port Ranges are both in the well-known ports span 412 (i.e., 0-1023) but these two ranges are not adjacent. 414 The following Port Range Mask and Port Range Value are conveyed in 415 DHCP messages: 416 - Port Range Value : 0000000001010000 (80) 417 - Port Range Mask : 0000000111110000 (496) 419 Port Restricted IP address assignment September 2010 421 This means that the 128 following Contiguous Port Ranges are 422 assigned to the same device: 423 - from 80 to 95 424 - from 592 to 607 425 - ... 426 - from 65104 to 65119 428 c) In this example, the Port Range Value defines two Contiguous Port 429 Ranges, each one being 1024 ports long: 431 - Port Range Value : 0000000000000000 (0) 432 - Port Range Mask : 1111010000000000 (62464) 434 This means that the two following Contiguous Port Ranges are 435 assigned to the same device: 436 - from 0 to 1023, and 437 - from 2048 to 3071 439 d) In this example, 64 contiguous Port Ranges are allocated to each 440 CPE (among a set of 4 CPEs sharing the same IPv4 address). 442 Among the 64 Contiguous Port Ranges to each CPE, there is always one 443 within the span of the first 1024 well-known port values. Hereafter 444 is given the Port Range Value and Port Range Mask assigned to 2 CPEs 445 (CPE#0 and CPE#3, CPE#1 and CPE#2 being not represented here): 447 1. CPE#0 449 - Port Range Value: 0000000000000000 (0) 450 - Port Range Mask: 0000001100000000 (768) 452 The CPE#0 has therefore the 64 following Contiguous Port Ranges: 453 - 1st range: 0-255 454 - ... 455 - 64th range: 64512-64767 457 2. CPE#3 459 - Port Range Value: 0000001100000000 (768) 460 - Port Range Mask: 0000001100000000 (768) 462 The CPE#2 has therefore the 64 following Contiguous Port Ranges: 463 - 1st range: 768-1023 464 - ... 465 - 64th range: 65280-65535 467 5. Random Port Delegation Function 469 Delegating random ports can be achieved by defining a function which 470 takes as input a key 'k' and an integer 'x' within the range (1024, 471 65535) and produces an output 'y' also within the range (1024, 472 65535). 474 Port Restricted IP address assignment September 2010 476 The server uses a cryptographical mechanism (described below) to 477 select the random ports for each node. Instead of assigning a range 478 of ports using port mask to the client, the server sends the inputs 479 of a predefined cryptographic mechanism: a key, an initial value, 480 and the number of ports assigned to this node. The client can then 481 calculate the full list of assigned ports itself. 483 The cryptographical mechanism ensures that the entire 64k port range 484 can be efficiently distributed to multiple nodes in a way that when 485 nodes calculate the ports, the results will never overlap with ports 486 other nodes have calculated (property of permutation), and ports in 487 the reserved range (smaller than 1024) are not used. As the 488 randomization is done cryptographically, an attacker seeing a node 489 using some port X cannot determine which other ports the node may be 490 using (as the attacker does not know the key). 492 Calculation of the random port list is done as follows: 494 The cryptographic mechanism uses an encryption function y = E(K,x) 495 that takes as input a key K (for example, 128 bits) and an integer x 496 (the plaintext) in range (1024, 65535), and produces an output y 497 (the ciphertext), also an integer in range (1024, 65535). This 498 section describes one such encryption function, but others are also 499 possible. 501 The server will select the key K. When server wants to allocate e.g. 502 2048 random ports, it selects a starting point 'a' (1024 <= a <= 503 65536-2048) in a way that the range (a, a+2048) does not overlap 504 with any other active client, and calculates the values E(K,a), 505 E(K,a+1), E(K,a+2), ..., E(K,a+2046), E(K,a+2047). These are the 506 port numbers allocated for this node. Instead of sending the port 507 numbers individually, the server just sends the values 'K', ' a', 508 and '2048'. The client will then repeat the same calculation. 510 The server SHOULD use different K for each IPv4 address it allocates 511 to make attacks as difficult as possible. This way, learning the K 512 used in IPv4 address IP1 would not help in attacking IPv4 address 513 IP2 that is allocated by the same server to different nodes. 515 With typical encryption functions (such as AES and DES), the input 516 (plaintext) and output (ciphertext) are blocks of some fixed size; 517 for example, 128 bits for AES, and 64 bits for DES. For port 518 randomization, we need an encryption function whose input and output 519 is an integer in range (1024, 65535). 521 One possible way to do this is to use the 'Generalized-Feistel 522 Cipher' [CIPHERS] construction by Black and Rogaway, with AES as the 523 underlying round function. 525 This would look as follows (using pseudo-code): 527 Port Restricted IP address assignment September 2010 529 def E(k, x): 530 y = Feistel16(k, x) 531 if y >= 1024: 532 return y 533 else: 534 return E(k, y) 536 Note that although E(k,x) is recursive, it is guaranteed to 537 terminate. The average number of iterations is just slightly over 1. 539 Feistel16 is a 16-bit block cipher: 541 def Feistel16(k, x): 542 left = x & 0xff 543 right = x >> 8 544 for round = 1 to 3: 545 temp = left ^ FeistelRound(k, round, right)) 546 left = right 547 right = temp 548 return (right << 8) | left 550 The Feistel round function uses: 552 def FeistelRound(k, round, x): 553 msg[0] = round 554 msg[1] = x 555 msg[2...15] = 0 556 return AES(k, msg)[0] 558 Performance: To generate list of 2048 port numbers, about 6000 calls 559 to AES are required (i.e., encrypting 96 kilobytes). Thus, it will 560 not be a problem for any device that can do, for example, HTTPS (web 561 browsing over SSL/TLS). 563 Other port generator functions may be predefined in Standards Track 564 documents and allocated a not yet allocated 'function' value within 565 the corresponding sub-option type field. 567 6. Option Usage 569 6.1 Client Behaviour 571 A DHCP client which supports the option defined in this document 572 MUST support both sub-option types. 574 A DHCP client which supports the extensions defined in this 575 document, SHOULD insert the option OPTION-IPv4-PRA with both sub- 576 option types into DHCPDISCOVER message to explicitly let the server 577 know that it supports port restricted IPv4 addresses. 578 o In the port mask sub-option type, the client SHALL set the IPv4 579 address and Mask Locator fields to all zeros. The client MAY 581 Port Restricted IP address assignment September 2010 583 indicate the number of desired ports in Port Range Value-field, 584 or set that to all zeroes. 585 o In the random port delegation sub-option type, the client SHALL 586 set the IPv4 address field, key field and starting point field 587 to all zeros. The client MAY indicate in function field which 588 encryption function it prefers, and in the number of delegated 589 ports field the number of ports the client would desire. 591 When a client, which supports the option defined in this document, 592 receives a DHCPOFFER with the 'yiaddr' (client IP address) field set 593 to 0.0.0.0, it SHOULD check for the presence of OPTION-IPv4-PRA 594 option. If the option is present, the client MAY send a DHCPREQUEST 595 message and insert the option OPTION-IPv4-PRA with the corresponding 596 sub-option received in the OPTION-IPv4-PRA option of the previous 597 DHCPOFFER. The client MUST NOT include a 'Requested IP Address' DHCP 598 option (code 50) into this DHCPREQUEST. 600 The client MUST NOT insert the IP address received in OPTION-IPv4- 601 PRA into the 'Requested IP Address' DHCP option (Code 50). 603 When the client receives a DHCPACK message with an option 43 604 containing OPTION-IPv4-PRA option and a sub-option field 1 or 2, it 605 MAY start using the specified IP address in conjunction with the 606 source ports specified by the mechanism chosen by DHCP server. The 607 client SHOULD NOT use the IP address with different source port 608 numbers, as that may result in the packets being NATed, as described 609 in [RFC6346]. 611 In case the initial port set received by the client from the server 612 is exhausted and the client needs additional ports, it MAY request 613 so by sending a new DHCPDISCOVER message. 615 In some deployment scenarios the DHCP client may also act as a DHCP 616 server for a network behind it, in which case the node may further 617 split the allocated set for other nodes. 619 The allocated port-restricted IP address and all the associated 620 parameters are valid until indicated in the IP Address Lease Time 621 Option (option 51). 623 6.2 Server Behaviour 625 When a server, which supports the option defined in this document, 626 receives a DHCPDISCOVER message, it SHOULD check for the presence of 627 the option OPTION-IPv4-PRA. 629 If OPTION-IPv4-PRA is not present in DHCPDISCOVER, the server SHOULD 630 allocate full unrestricted public or private [RFC1918] IPv4 address 632 Port Restricted IP address assignment September 2010 634 to the client, if available, by generating a DHCPOFFER as described 635 in [RFC2131]. 637 The server SHOULD offer the port restricted IPv4 address with option 638 OPTION-IPv4-PRAwhen the server has support for the extensions 639 specified in this document and when the: 640 o DHCP client has included an OPTION-IPv4-PRA option, and server's 641 policy indicates saving unrestricted IPv4 addresses for clients 642 that do not support the extensions defined in this document. 643 The server MUST include only one of the sub-options into the 644 OPTION-IPv4-PRA option. 646 o server receives a DHCPDISCOVER message and server can only 647 offer port restricted IP address to the client 648 o server receives a DHCPDISCOVER message from a client without 649 the OPTION-IPv4-PRA, but knows by means outside the scope of 650 this document that the client supports the usage of port- 651 restricted IPv4 addresses (or it is only entitled to be 652 provisioned with such addresses) 654 When server chooses to offer port restricted IPv4 address for 655 clients with OPTION-IPv4-PRA, it MUST: 656 o set the 'yiaddr' (client IP address) field of the DHCPOFFER 657 message to 0.0.0.0 658 o choose the port allocation mechanisms, if it is not statically 659 configured 660 o select a port restricted IPv4 address to be allocated for the 661 client 662 o generate parameters required for the chosen port allocation 663 mechanism 665 When the server receives a DHCPREQUEST message from the client with 666 OPTION-IPv4-PRA option field containing the IP address and port 667 allocation mechanism parameters it has previously offered to the 668 client, the server MUST send a DHCPACK, where the 'yiaddr' (client 669 IP address) field is set to 0.0.0.0 and the option OPTION-IPv4-PRA 670 option including the IPv4 address and parameters required for the 671 used allocation mechanism. 673 When the server receives a DHCPREQUEST message from the client with 674 an OPTION-IPv4-PRA option field containing an IPv4 address and port 675 set it has previously not offered to the client, the server MUST 676 send a DHCPNAK to the client. 678 When the server detects that a client (e.g. based on a specific 679 hardware address) which has already been allocated with a port 680 restricted IPv4 address, sent another DHCPDISCOVER, it MAY, based on 681 local policy, offer the client with additional port restricted IPv4 682 address. 684 Port Restricted IP address assignment September 2010 686 If the server is deployed in a cascaded DHCP server scenario, the 687 node MAY both act as a DHCP client for another server and DHCP 688 server for other DHCP clients. 690 A server SHOULD ensure the client is residing on an access link 691 where usage of port-restricted addresses is not causing problems, 692 before allocating it a port restricted IPv4 address. 694 The server MUST keep lease times per allocated port sets of the 695 shared IP addresses, in case they are delegated to the client. 697 8. IANA considerations 699 This document defines a new DHCPv4 option as described in section 3: 700 Port Restricted IP Address Option for DHCPv4 (OPTION-IPv4-PRA) TBD. 702 9. Security considerations 704 The solution is generally vulnerable to DoS when used in shared 705 medium or when access network authentication is not a prerequisite 706 to IP address assignment. The solution SHOULD only be used on point- 707 to-point links, tunnels, and/or in environments where authentication 708 at link layer is performed before IP address assignment, and not 709 shared medium. 711 The cryptographically random port delegation mechanism is vulnerable 712 for blind attacks initiated by nodes located in the same 713 administrative domain, served by the same DHCP server, and that are 714 sharing the same public IPv4 address, and therefore have knowledge 715 of the cryptographic key used for that particular public IPv4 716 address. 718 10. References 719 10.1 Normative References 721 [RFC2119] Bradner, S., .Key words for use in RFCs to Indicate 722 Requirement Levels., March 1997 724 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 725 RFC2131, March 1997 727 10.2 Informative References 729 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de 730 Groot, G., Lear, E., "Address Allocation for Private 731 Internets", RFC1918, February 1996 733 Port Restricted IP address assignment September 2010 735 [RFC6056] Larsen, M., Gont, F., .Port Randomization., January 736 2011 738 [RFC6346] Bush, R., Ed., "The A+P Approach to the IPv4 Address 739 Shortage", August 2011 741 [CIPHERS] John Black and Phillip Rogaway: .Ciphers with Arbitrary 742 Finite Domains., Topics in Cryptology - CT-RSA 2002, 743 Lecture Notes in Computer Science vol. 2271, 2002 745 [MAEN2008] Maennel, O., Bush, R., Cittadini, L., Bellovin, S., "A 746 Better Approach than Carrier-Grade-NAT", 2008, 747 Technical Report CUCS-041-08 749 12. Contributors 751 Jean Luc Grimault and Alain Villefranque contributed text to earlier 752 version of the document. 754 The encryption function from Section 5 was provided by Pasi Eronen. 756 The authors would also like to thank Lars Eggert, Olaf Maenel, Randy 757 Bush, Alain Durand, Jean-Luc Grimault, Alain Villefranque for their 758 valuable comments. 760 Authors' Addresses 762 Gabor Bajko 763 gabor(dot)Bajko(at)nokia(dot)com 765 Teemu Savolainen 766 Nokia 767 Hermiankatu 12 D 768 FI-33720 TAMPERE 769 Finland 771 Email: teemu.savolainen@nokia.com 773 Mohamed Boucadair 774 France Telecom 775 Rennes 776 France 778 Email: mohamed.boucadair@orange.com 780 Pierre Levis 781 France Telecom 782 42 rue des Coutures 784 Port Restricted IP address assignment September 2010 786 BP 6243 787 Caen Cedex 4 14066 788 France 790 Email: pierre.levis@orange.com