idnits 2.17.1 draft-ietf-tsvwg-port-randomization-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 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 (November 30, 2009) is 5254 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-06 -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-08 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group M. Larsen 3 (tsvwg) TietoEnator 4 Internet-Draft F. Gont 5 Intended status: BCP UTN/FRH 6 Expires: June 3, 2010 November 30, 2009 8 Port Randomization 9 draft-ietf-tsvwg-port-randomization-05 11 Abstract 13 Recently, awareness has been raised about a number of "blind" attacks 14 that can be performed against the Transmission Control Protocol (TCP) 15 and similar protocols. The consequences of these attacks range from 16 throughput-reduction to broken connections or data corruption. These 17 attacks rely on the attacker's ability to guess or know the five- 18 tuple (Protocol, Source Address, Destination Address, Source Port, 19 Destination Port) that identifies the transport protocol instance to 20 be attacked. This document describes a number of simple and 21 efficient methods for the selection of the client port number, such 22 that the possibility of an attacker guessing the exact value is 23 reduced. While this is not a replacement for cryptographic methods 24 for protecting the connection, the described port number obfuscation 25 algorithms provide improved security/obfuscation with very little 26 effort and without any key management overhead. The algorithms 27 described in this document are local policies that may be 28 incrementally deployed, and that do not violate the specifications of 29 any of the transport protocols that may benefit from them, such as 30 TCP, UDP, UDP-lite, SCTP, DCCP, and RTP. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on June 3, 2010. 55 Copyright Notice 57 Copyright (c) 2009 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 7 74 2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 7 75 2.2. Ephemeral port selection . . . . . . . . . . . . . . . . . 7 76 2.3. Collision of connection-id's . . . . . . . . . . . . . . . 8 77 3. Obfuscating the Ephemeral Ports . . . . . . . . . . . . . . . 10 78 3.1. Characteristics of a good ephemeral port obfuscation 79 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.2. Ephemeral port number range . . . . . . . . . . . . . . . 11 81 3.3. Ephemeral Port Obfuscation Algorithms . . . . . . . . . . 12 82 3.3.1. Algorithm 1: Simple port randomization algorithm . . . 12 83 3.3.2. Algorithm 2: Another simple port randomization 84 algorithm . . . . . . . . . . . . . . . . . . . . . . 14 85 3.3.3. Algorithm 3: Simple hash-based algorithm . . . . . . . 14 86 3.3.4. Algorithm 4: Double-hash obfuscation algorithm . . . . 17 87 3.3.5. Algorithm 5: Random-increments port selection 88 algorithm . . . . . . . . . . . . . . . . . . . . . . 18 89 3.4. Secret-key considerations for hash-based port 90 obfuscation algorithms . . . . . . . . . . . . . . . . . . 20 91 3.5. Choosing an ephemeral port obfuscation algorithm . . . . . 21 92 4. Port obfuscation and Network Address Port Translation 93 (NAPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 96 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 98 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 99 8.2. Informative References . . . . . . . . . . . . . . . . . . 27 100 Appendix A. Survey of the algorithms in use by some popular 101 implementations . . . . . . . . . . . . . . . . . . . 30 102 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 30 103 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 30 104 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 30 105 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 30 106 A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 30 107 Appendix B. Changes from previous versions of the draft (to 108 be removed by the RFC Editor before publication 109 of this document as a RFC . . . . . . . . . . . . . . 31 110 B.1. Changes from draft-ietf-tsvwg-port-randomization-04 . . . 31 111 B.2. Changes from draft-ietf-tsvwg-port-randomization-03 . . . 31 112 B.3. Changes from draft-ietf-tsvwg-port-randomization-02 . . . 31 113 B.4. Changes from draft-ietf-tsvwg-port-randomization-01 . . . 31 114 B.5. Changes from draft-ietf-tsvwg-port-randomization-00 . . . 31 115 B.6. Changes from draft-larsen-tsvwg-port-randomization-02 . . 31 116 B.7. Changes from draft-larsen-tsvwg-port-randomization-01 . . 32 117 B.8. Changes from draft-larsen-tsvwg-port-randomization-00 . . 32 118 B.9. Changes from draft-larsen-tsvwg-port-randomisation-00 . . 32 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 121 1. Introduction 123 Recently, awareness has been raised about a number of "blind" attacks 124 (i.e., attacks that can be performed without the need to sniff the 125 packets that correspond to the transport protocol instance to be 126 attacked) that can be performed against the Transmission Control 127 Protocol (TCP) [RFC0793] and similar protocols. The consequences of 128 these attacks range from throughput-reduction to broken connections 129 or data corruption [I-D.ietf-tcpm-icmp-attacks] [RFC4953] [Watson]. 131 All these attacks rely on the attacker's ability to guess or know the 132 five-tuple (Protocol, Source Address, Source port, Destination 133 Address, Destination Port) that identifies the transport protocol 134 instance to be attacked. 136 Services are usually located at fixed, 'well-known' ports [IANA] at 137 the host supplying the service (the server). Client applications 138 connecting to any such service will contact the server by specifying 139 the server IP address and service port number. The IP address and 140 port number of the client are normally left unspecified by the client 141 application and thus chosen automatically by the client networking 142 stack. Ports chosen automatically by the networking stack are known 143 as ephemeral ports [Stevens]. 145 While the server IP address and well-known port and the client IP 146 address may be accurately guessed by an attacker, the ephemeral port 147 of the client is usually unknown and must be guessed. 149 This document describes a number of algorithms for the selection of 150 the ephemeral ports, such that the possibility of an off-path 151 attacker guessing the exact value is reduced. They are not a 152 replacement for cryptographic methods of protecting a connection such 153 as IPsec [RFC4301], the TCP MD5 signature option [RFC2385], or the 154 TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt]. For example, 155 they do not provide any mitigation in those scenarios in which the 156 attacker is able to sniff the packets that correspond to the 157 transport protocol connection to be attacked. However, the proposed 158 algorithms provide improved obfuscation with very little effort and 159 without any key management overhead. 161 The mechanisms described in this document are local modifications 162 that may be incrementally deployed, and that does not violate the 163 specifications of any of the transport protocols that may benefit 164 from it, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP 165 [RFC4340], UDP-lite [RFC3828], and RTP [RFC3550]. 167 Since these mechanisms are obfuscation techniques, focus has been on 168 a reasonable compromise between the level of obfuscation and the ease 169 of implementation. Thus the algorithms must be computationally 170 efficient, and not require substantial state. 172 We note that while the technique of mitigating "blind" attacks by 173 obfuscating the ephemeral port election is well-known as "port 174 randomization", the goal of the algorithms described in this document 175 is to reduce the chances of an attacker guessing the ephemeral ports 176 selected for new connections, rather than to actually produce 177 mathematically random sequences of ephemeral ports. 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC 2119 [RFC2119]. 183 2. Ephemeral Ports 185 2.1. Traditional Ephemeral Port Range 187 The Internet Assigned Numbers Authority (IANA) assigns the unique 188 parameters and values used in protocols developed by the Internet 189 Engineering Task Force (IETF), including well-known ports [IANA]. 190 IANA has traditionally reserved the following use of the 16-bit port 191 range of TCP and UDP: 193 o The Well Known Ports, 0 through 1023. 195 o The Registered Ports, 1024 through 49151 197 o The Dynamic and/or Private Ports, 49152 through 65535 199 The range for assigned ports managed by the IANA is 0-1023, with the 200 remainder being registered by IANA but not assigned. 202 The ephemeral port range defined by IANA has traditionally consisted 203 of the 49152-65535 range. 205 2.2. Ephemeral port selection 207 As each communication instance is identified by the five-tuple 208 {protocol, local IP address, local port, remote IP address, remote 209 port}, the selection of ephemeral port numbers must result in a 210 unique five-tuple. 212 Selection of ephemeral ports such that they result in unique five- 213 tuples is handled by some implementations by having a per-protocol 214 global 'next_ephemeral' variable that is equal to the previously 215 chosen ephemeral port + 1, i.e. the selection process is: 217 /* Initialization at system boot time. Could be random */ 218 next_ephemeral = min_ephemeral; 220 /* Ephemeral port selection function */ 221 count = max_ephemeral - min_ephemeral + 1; 223 do { 224 port = next_ephemeral; 225 if (next_ephemeral == max_ephemeral) { 226 next_ephemeral = min_ephemeral; 227 } else { 228 next_ephemeral++; 229 } 231 if (five-tuple is unique) 232 return port; 234 count--; 236 } while (count > 0); 238 return ERROR; 240 Figure 1 242 This algorithm works well provided that the number of connections for 243 a each transport protocol that have a life-time longer than it takes 244 to exhaust the total ephemeral port range is small, so that five- 245 tuple collisions are rare. 247 However, this method has the drawback that the 'next_ephemeral' 248 variable and thus the ephemeral port range is shared between all 249 connections and the next ports chosen by the client are easy to 250 predict. If an attacker operates an "innocent" server to which the 251 client connects, it is easy to obtain a reference point for the 252 current value of the 'next_ephemeral' variable. Additionally, if an 253 attacker could force a client to periodically establish a new TCP 254 connection to an attacker controlled machine (or through an attacker 255 observable routing path), the attacker could subtract consecutive 256 source port values to obtain the number of outoing TCP connections 257 established globally by the target host within that time period (up 258 to wrap-around issues and 5-tuple collisions, of course). 260 2.3. Collision of connection-id's 262 While it is possible for the ephemeral port selection algorithm to 263 verify that the selected port number results in connection-id that is 264 not currently in use at that system, the resulting connection-id may 265 still be in use at a remote system. For example, consider a scenario 266 in which a client establishes a TCP connection with a remote web 267 server, and the web server performs the active close on the 268 connection. While the state information for this connection will 269 disappear at the client side (that is, the connection will be moved 270 to the fictional CLOSED state), the connection-id will remain in the 271 TIME-WAIT state at the web server for 2*MSL (Maximum Segment 272 Lifetime). If the same client tried to create a new incarnation of 273 the previous connection (that is, a connection with the same 274 connection-id as the one in the TIME_WAIT state at the server), a 275 connection-id "collision" would occur. The effect of these 276 collisions range from connection-establishment failures to TIME-WAIT 277 state assassination (with the potential of data corruption) 278 [RFC1337]. In scenarios in which a specific client establishes TCP 279 connections with a specific service at a server, these problems 280 become evident. Therefore, an ephemeral port selection algorithm 281 should ideally minimize the rate of connection-id collisions. 283 A simple approach to minimize the rate of these collisions would be 284 to choose port numbers incrementally, so that a given port number 285 would not be reused until the rest of the port numbers in ephemeral 286 port range have been used for a transport protocol instance. 287 However, if a single global variable were used to keep track of the 288 last ephemeral port selected, ephemeral port numbers would be 289 trivially predictable, thus making it easier for an off-path attacker 290 to "guess" the connection-id in use by a target connection. 291 Section 3.3.3 and Section 3.3.4 describe algorithms that select port 292 numbers incrementally, while still making it difficult for an off- 293 path attacker to predict the ephemeral ports used for future 294 connections. 296 Another possible approach to minimize the rate of collisions of 297 connection-id's would be for both end-points of a TCP connection to 298 keep state about recent connections (e.g., have both end-points end 299 up in the TIME-WAIT state). 301 3. Obfuscating the Ephemeral Ports 303 3.1. Characteristics of a good ephemeral port obfuscation algorithm 305 There are a number of factors to consider when designing a policy of 306 selection of ephemeral ports, which include: 308 o Minimizing the predictability of the ephemeral port numbers used 309 for future connections. 311 o Minimizing collisions of connection-id's 313 o Avoiding conflict with applications that depend on the use of 314 specific port numbers. 316 Given the goal of improving the transport protocol's resistance to 317 attack by obfuscation of the five-tuple that identifies a transport- 318 protocol instance, it is key to minimize the predictability of the 319 ephemeral ports that will be selected for new connections. While the 320 obvious approach to address this requirement would be to select the 321 ephemeral ports by simply picking a random value within the chosen 322 port number range, this straightforward policy may lead to collisions 323 of connection-id's, which could lead to the interoperability problems 324 (namely delays in the establishment of new connections, failures in 325 connection-establishment, or data curruption) discussed in 326 Section 2.3. As discussed in Section 1, it is worth noting that 327 while the technique of mitigating "blind" attacks by obfuscating the 328 ephemeral port election is well-known as "port randomization", the 329 goal of the algorithms described in this document is to reduce the 330 chances of an attacker guessing the ephemeral ports selected for new 331 connections, rather than to actually produce sequences of 332 mathematically random ephemeral port numbers. 334 It is also worth noting that, provided adequate algorithms are in 335 use, the larger the range from which ephemeral pots are selected, the 336 smaller the chances of an attacker are to guess the selected port 337 number. 339 In scenarios in which a specific client establishes connections with 340 a specific service at a server, the problems described in Section 2.3 341 become evident. A good algorithm to minimize the collisions of 342 connection-id's would consider the time a given five-tuple was last 343 used, and would avoid reusing the last recently used five-tuples. A 344 simple approach to minimize the rate of collisions would be to choose 345 port numbers incrementally, so that a given port number would not be 346 reused until the rest of the port numbers in the ephemeral port range 347 have been used for a transport protocol instance. However, if a 348 single global variable were used to keep track of the last ephemeral 349 port selected, ephemeral port numbers would be trivially predictable. 351 It is important to note that a number of applications rely on binding 352 specific port numbers that may be within the ephemeral ports range. 353 If such an application was run while the corresponding port number 354 was in use, the application would fail. Therefore, transport 355 protocols should avoid using those port numbers as ephemeral ports. 357 Port numbers that are currently in use by a TCP in the LISTEN state 358 should not be allowed for use as ephemeral ports. If this rule is 359 not complied, an attacker could potentially "steal" an incoming 360 connection to a local server application by issuing a connection 361 request to the victim client at roughly the same time the client 362 tries to connect to the victim server application [CPNI-TCP] 363 [I-D.gont-tcp-security]. If the SYN segment corresponding to the 364 attacker's connection request and the SYN segment corresponding to 365 the victim client "cross each other in the network", and provided the 366 attacker is able to know or guess the ephemeral port used by the 367 client, a TCP simultaneous open scenario would take place, and the 368 incoming connection request sent by the client would be matched with 369 the attacker's socket rather than with the victim server 370 application's socket. 372 It should be noted that most applications based on popular 373 implementations of TCP API (such as the Sockets API) perform "passive 374 opens" in three steps. Firstly, the application obtains a file 375 descriptor to be used for inter-process communication (e.g., by 376 issuing a socket() call). Secondly, the application binds the file 377 descriptor to a local TCP port number (e.g., by issuing a bind() 378 call), thus creating a TCP in the fictional CLOSED state. Thirdly, 379 the aforementioned TCP is put in the LISTEN state (e.g., by issuing a 380 listen() call). As a result, with such an implementation of the TCP 381 API, even if port numbers in use for TCPs in the LISTEN state were 382 not allowed for use as ephemeral ports, there is a window of time 383 between the second and the third steps in which an attacker could be 384 allowed to select a port number that would be later used for 385 listening to incoming connections. Therefore, these implementations 386 of the TCP API should enforce a stricter requirement for the 387 allocation of port numbers: port numbers that are in use by a TCP in 388 the LISTEN or CLOSED states should not be allowed for allocation as 389 ephemeral ports [CPNI-TCP] [I-D.gont-tcp-security]. 391 3.2. Ephemeral port number range 393 As mentioned in Section 2.1, the ephemeral port range has 394 traditionally consisted of the 49152-65535 range. However, it should 395 also include the range 1024-49151 range. 397 Since this range includes user-specific server ports, this may not 398 always be possible, though. A possible workaround for this potential 399 problem would be to maintain a local list of the port numbers that 400 should not be allocated as ephemeral ports. Thus, before allocating 401 a port number, the ephemeral port selection function would check this 402 list, avoiding the allocation of ports that may be needed for 403 specific applications. 405 Transport protocols SHOULD use the largest possible port range, since 406 this improves the obfuscation provided by the ephemeral port 407 selection algorithms. 409 3.3. Ephemeral Port Obfuscation Algorithms 411 Transport protocols SHOULD obfuscate the allocatation of their 412 ephemeral ports, since this help to mitigate a number of attacks that 413 depend on the attacker's ability to guess or know the five-tuple that 414 identifies the transport protocol instance to be attacked. 416 The following subsections describe a number of algorithms that could 417 be implemented in order to obfuscate the selection of ephemeral port 418 numbers. 420 3.3.1. Algorithm 1: Simple port randomization algorithm 422 In order to address the security issues discussed in Section 1 and 423 Section 2.2, a number of systems have implemented simple ephemeral 424 port number randomization, as follows: 426 /* Ephemeral port selection function */ 427 num_ephemeral = max_ephemeral - min_ephemeral + 1; 428 next_ephemeral = min_ephemeral + (random() % num_ephemeral); 429 count = num_ephemeral; 431 do { 432 if(five-tuple is unique) 433 return next_ephemeral; 435 if (next_ephemeral == max_ephemeral) { 436 next_ephemeral = min_ephemeral; 437 } else { 438 next_ephemeral++; 439 } 441 count--; 442 } while (count > 0); 444 return ERROR; 446 Figure 2 448 We will refer to this algorithm as 'Algorithm 1'. 450 Since the initially chosen port may already be in use with identical 451 IP addresses and server port, the resulting five-tuple might not be 452 unique. Therefore, multiple ports may have to be tried and verified 453 against all existing connections before a port can be chosen. 455 Web proxy servers, NAPTs [RFC2663], and other middle-boxes aggregate 456 multiple peers into the same port space and thus increse the 457 population of used ephemeral ports, and hence the chances of 458 collisions of connection-id's. However, [Allman] has shown that at 459 least in the network scenarios used for measuring the collision 460 properties of the algorithms described in this document, the 461 collision rate resulting from the use of the aforementioned middle- 462 boxes is nevertheless very low. 464 Since this algorithm performs a completely random port selection 465 (i.e., without taking into account the port numbers previously 466 chosen), it has the potential of reusing port numbers too quickly, 467 thus possibly leading to collisions of connection-id's. Even if a 468 given five-tuple is verified to be unique by the port selection 469 algorithm, the five-tuple might still be in use at the remote system. 470 In such a scenario, the connection request could possibly fail 471 ([Silbersack] describes this problem for the TCP case). 473 This algorithm selects ephemeral port numbers randomly and thus 474 reduces the chances of an attacker of guessing the ephemeral port 475 selected for a target connection. Additionally, it prevents 476 attackers from obtaining the number of outgoing connections 477 established by the client in some period of time. 479 3.3.2. Algorithm 2: Another simple port randomization algorithm 481 Another algorithm for selecting a random port number is shown in 482 Figure 3, in which in the event a local connection-id collision is 483 detected, another port number is selected randomly, as follows: 485 /* Ephemeral port selection function */ 486 num_ephemeral = max_ephemeral - min_ephemeral + 1; 487 next_ephemeral = min_ephemeral + (random() % num_ephemeral); 488 count = num_ephemeral; 490 do { 491 if(five-tuple is unique) 492 return next_ephemeral; 494 next_ephemeral = min_ephemeral + (random() % num_ephemeral); 495 count--; 496 } while (count > 0); 498 return ERROR; 500 Figure 3 502 We will refer to this algorithm as 'Algorithm 2'. This algorithm 503 might be unable to select an ephemeral port (i.e., return "ERROR") 504 even if there are port numbers that would result in unique five- 505 tuples, when there are a large number of port numbers already in use. 506 However, the results in [Allman] have shown that in common scenarios, 507 one port choice is enough, and in most cases where more than one 508 choice is needed two choices suffice. Therefore, in those scenarios 509 this would not be problem. 511 3.3.3. Algorithm 3: Simple hash-based algorithm 513 We would like to achieve the port reuse properties of the traditional 514 BSD port selection algorithm (described in Section 2.2), while at the 515 same time achieve the obfuscation properties of Algorithm 1 and 516 Algorithm 2. 518 Ideally, we would like a 'next_ephemeral' value for each set of 519 (local IP address, remote IP addresses, remote port), so that the 520 port reuse frequency is the lowest possible. Each of these 521 'next_ephemeral' variables should be initialized with random values 522 within the ephemeral port range and would thus separate the ephemeral 523 port ranges of the connections entirely. Since we do not want to 524 maintain in memory all these 'next_ephemeral' values, we propose an 525 offset function F(), that can be computed from the local IP address, 526 remote IP address, remote port and a secret key. F() will yield 527 (practically) different values for each set of arguments, i.e.: 529 /* Initialization at system boot time. Could be random. */ 530 next_ephemeral = 0; 532 /* Ephemeral port selection function */ 533 num_ephemeral = max_ephemeral - min_ephemeral + 1; 534 offset = F(local_IP, remote_IP, remote_port, secret_key); 535 count = num_ephemeral; 537 do { 538 port = min_ephemeral + 539 (next_ephemeral + offset) % num_ephemeral; 541 next_ephemeral++; 543 if(five-tuple is unique) 544 return port; 546 count--; 548 } while (count > 0); 550 return ERROR; 552 Figure 4 554 We will refer to this algorithm as 'Algorithm 3'. 556 In other words, the function F() provides a per-connection fixed 557 offset within the global ephemeral port range. Both the 'offset' and 558 'next_ephemeral' variables may take any value within the storage type 559 range since we are restricting the resulting port similar to that 560 shown in Figure 3. This allows us to simply increment the 561 'next_ephemeral' variable and rely on the unsigned integer to simply 562 wrap-around. 564 The function F() should be a cryptographic hash function like MD5 565 [RFC1321]. The function should use both IP addresses, the remote 566 port and a secret key value to compute the offset. The remote IP 567 address is the primary separator and must be included in the offset 568 calculation. The local IP address and remote port may in some cases 569 be constant and not improve the connection separation, however, they 570 should also be included in the offset calculation. 572 Cryptographic algorithms stronger than e.g. MD5 should not be 573 necessary, given that Algorithm #3 is simply an obfuscation 574 technique. The secret should be chosen as random as possible, see 575 [RFC4086] for recommendations on choosing secrets. 577 Note that on multiuser systems, the function F() could include user 578 specific information, thereby providing protection not only on a host 579 to host basis, but on a user to service basis. In fact, any 580 identifier of the remote entity could be used, depending on 581 availability an the granularity requested. With SCTP both hostnames 582 and alternative IP addresses may be included in the association 583 negotiation and either of these could be used in the offset function 584 F(). 586 When multiple unique identifiers are available, any of these can be 587 chosen as input to the offset function F() since they all uniquely 588 identify the remote entity. However, in cases like SCTP where the 589 ephemeral port must be unique across all IP address permutations, we 590 should ideally always use the same IP address to get a single 591 starting offset for each association negotiation from a given remote 592 entity to minimize the possibility of collisions. A simple numerical 593 sorting of the IP addresses and always using the numerically lowest 594 could achieve this. However, since most protocols most likely will 595 report the same IP addresses in the same order in each association 596 setup, this sorting is most likely not necessary and the 'first one' 597 can simply be used. 599 The ability of hostnames to uniquely define hosts can be discussed, 600 and since SCTP always includes at least one IP address, we recommend 601 to use this as input to the offset function F() and ignore hostnames 602 chunks when searching for ephemeral ports. 604 It should be note that, as this algorithm uses a global counter 605 ("next_ephemeral") for selecting ephemeral ports, if an attacker 606 could force a client to periodically establish a new TCP connection 607 to an attacker controlled machine (or through an attacker observable 608 routing path), the attacker could subtract consecutive source port 609 values to obtain the number of outoing TCP connections established 610 globally by the target host within that time period (up to wrap- 611 around issues and 5-tuple collisions, of course). 613 3.3.4. Algorithm 4: Double-hash obfuscation algorithm 615 A tradeoff between maintaining a single global 'next_ephemeral' 616 variable and maintaining 2**N 'next_ephemeral' variables (where N is 617 the width of of the result of F()) could be achieved as follows. The 618 system would keep an array of TABLE_LENGTH short integers, which 619 would provide a separation of the increment of the 'next_ephemeral' 620 variable. This improvement could be incorporated into Algorithm 3 as 621 follows: 623 /* Initialization at system boot time */ 624 for(i = 0; i < TABLE_LENGTH; i++) 625 table[i] = random() % 65536; 627 /* Ephemeral port selection function */ 628 num_ephemeral = max_ephemeral - min_ephemeral + 1; 629 offset = F(local_IP, remote_IP, remote_port, secret_key1); 630 index = G(local_IP, remote_IP, remote_port, secret_key2); 631 count = num_ephemeral; 633 do { 634 port = min_ephemeral + (offset + table[index]) % num_ephemeral; 635 table[index]++; 637 if(five-tuple is unique) 638 return port; 640 count--; 642 } while (count > 0); 644 return ERROR; 646 Figure 5 648 We will refer to this algorithm as 'Algorithm 4'. 650 'table[]' could be initialized with mathematically random values, as 651 indicated by the initialization code in Figure 5. The function G() 652 should be a cryptographic hash function like MD5 [RFC1321]. It 653 should use both IP addresses, the remote port and a secret key value 654 to compute a value between 0 and (TABLE_LENGTH-1). Alternatively, 655 G() could take as "offset" as input, and perform the exclusive-or 656 (xor) operation between all the bytes in 'offset'. 658 The array 'table[]' assures that succesive connections to the same 659 end-point will use increasing ephemeral port numbers. However, 660 incrementation of the port numbers is separated into TABLE_LENGTH 661 different spaces, and thus the port reuse frequency will be 662 (probabilistically) lower than that of Algorithm 3. That is, a 663 connection established with some remote end-point will not 664 necessarily cause the 'next_ephemeral' variable corresponding to 665 other end-points to be incremented. 667 It is interesting to note that the size of 'table[]' does not limit 668 the number of different port sequences, but rather separates the 669 *increments* into TABLE_LENGTH different spaces. The port sequence 670 will result from adding the corresponding entry of 'table[]' to the 671 variable 'offset', which selects the actual port sequence (as in 672 Algorithm 3). [Allman] has found that a TABLE_LENGTH of 10 can 673 result in an improvement over Algorithm 3. Further increasing the 674 TABLE_LENGTH will increase the obfuscation, and possibly further 675 decrease the collision rate. 677 An attacker can perform traffic analysis for any "increment space" 678 into which the attacker has "visibility", namely that the attacker 679 can force the client to establish a transport-protocol connection 680 whose G(offset) identifies the target "increment space". However, 681 the attacker's ability to perform traffic analysis is very reduced 682 when compared to the traditional BSD algorithm (described in 683 Section 2.2) and Algorithm 3. Additionally, an implementation can 684 further limit the attacker's ability to perform traffic analysis by 685 further separating the increment space (that is, using a larger value 686 for TABLE_LENGTH). 688 3.3.5. Algorithm 5: Random-increments port selection algorithm 690 [Allman] introduced another port obfuscation algorithm, which offers 691 a middle ground between the algorithms that select ephemeral ports 692 randomly (such as those described in Section 3.3.1 and 693 Section 3.3.2), and those that offer obfuscation but no randomization 694 (such as those described in Section 3.3.3 and Section 3.3.4). We 695 will refer to this algorithm as 'Algorithm 5'. 697 /* Initialization code at system boot time. */ 698 next_ephemeral = random() % 65536; /* Initialization value */ 699 N = 500; /* Determines the tradeoff */ 701 /* Ephemeral port selection function */ 702 num_ephemeral = max_ephemeral - min_ephemeral + 1; 704 count = num_ephemeral; 706 do { 707 next_ephemeral = next_ephemeral + (random() % N) + 1; 708 port = min_ephemeral + (next_ephemeral % num_ephemeral); 710 if(five-tuple is unique) 711 return port; 713 count--; 714 } while (count > 0); 716 return ERROR; 718 Figure 6 720 This algorithm aims at at producing a monotonically-increasing 721 sequence to prevent the collision of connection-id's, while avoiding 722 the use of fixed increments, which would lead to trivially- 723 predictable sequences. The value "N" allows for direct control of 724 the tradeoff between the level of obfuscation and the port reuse 725 frequency. The smaller the value of "N", the more linear the more 726 similar this algorithm is to the traditioanl BSD port selection 727 algorithm (described in Section 2.2. The larger the value of "N", 728 the more similar this algorithm is to the algorithm described in 729 Section 3.3.1 of this document. 731 When the port numbers wrap, there's the risk of collisions of 732 connection-id's. Therefore, "N" should be selecting according to the 733 following criteria: 735 o It should maximize the wrapping time of the ephemeral port space 737 o It should minimize collisions of connection-id's 739 o It should maximize obfuscation 741 Clearly, these are competing goals, and the decision of which value 742 of "N" to use is a tradeoff. Therefore, the value of "N" should be 743 configurable so that system administrators can make the tradeoff for 744 themselves. 746 3.4. Secret-key considerations for hash-based port obfuscation 747 algorithms 749 Every complex manipulation (like MD5) is no more secure than the 750 input values, and in the case of ephemeral ports, the secret key. If 751 an attacker is aware of which cryptographic hash function is being 752 used by the victim (which we should expect), and the attacker can 753 obtain enough material (e.g. ephemeral ports chosen by the victim), 754 the attacker may simply search the entire secret key space to find 755 matches. 757 To protect against this, the secret key should be of a reasonable 758 length. Key lengths of 32 bits should be adequate, since a 32-bit 759 secret would result in approximately 65k possible secrets if the 760 attacker is able to obtain a single ephemeral port (assuming a good 761 hash function). If the attacker is able to obtain more ephemeral 762 ports, key lengths of 64 bits or more should be used. 764 Another possible mechanism for protecting the secret key is to change 765 it after some time. If the host platform is capable of producing 766 reasonable good random data, the secret key can be changed 767 automatically. 769 Changing the secret will cause abrupt shifts in the chosen ephemeral 770 ports, and consequently collisions may occur. That is, upon changing 771 the secret, the "offset" value (see Figure 4 and Figure 5) used for 772 each destination end-point will be different from that computed with 773 the previous secret, ths leading to the selection of a port number 774 recently used for connecting to the same end-point. 776 Thus the change in secret key should be done with consideration and 777 could be performed whenever one of the following events occur: 779 o The system is being bootstrapped. 781 o Some predefined/random time has expired. 783 o The secret has been used N times (i.e. we consider it insecure). 785 o There are few active connections (i.e., possibility of collision 786 is low). 788 o There is little traffic (the performance overhead of collisions is 789 tolerated). 791 o There is enough random data available to change the secret key 792 (pseudo-random changes should not be done). 794 3.5. Choosing an ephemeral port obfuscation algorithm 796 [Allman] is an empyrical study of the properties of the algorithms 797 described in this document, which has found that all the algorithms 798 described in this document offer low collision rates -- at most 0.3%. 799 That is, in those network scenarios asessed by [Allman] all of the 800 algorithms described in this document perform good in terms of 801 collisions of connection-id's. However, these results may vary 802 depending on the characteristics of network traffic and the specific 803 network setup. 805 The algorithm sketched in Figure 1 is the traditional ephemeral port 806 selection algorithm implemented in BSD-derived systems. It generates 807 a global sequence of ephemeral port numbers, which makes it trivial 808 for an attacker to predict the port number that will be used for a 809 future transport protocol instance. However, it is very simple, and 810 leads to a low port resuse frequency. 812 Algorithm 1 and Algorithm 2 have the advantage that they provide 813 complete randomization. However, they may increase the chances of 814 port number collisions, which could lead to the failure of the 815 connection establishment attempt. [Allman] found that these two 816 algorithms show the largest collision rates (among all the algorithms 817 described in this document). 819 Algorithm 3 provides complete separation in local and remote IP 820 addresses and remote port space, and only limited separation in other 821 dimensions (see Section 3.4). However, implementations should 822 consider the performance impact of computing the cryptographic hash 823 used for the offset. 825 Algorithm 4 improves Algorithm 3, usually leading to a lower port 826 reuse frequency, at the expense of more processor cycles used for 827 computing G(), and additional kernel memory for storing the array 828 'table[]'. 830 Algorithm 5 offers middle ground between the simple randomization 831 algorithms (Algorithm 1 and Algorthm 2) and the hash-based algorithms 832 (Algorithm 3 and Algorithm 4). The upper limit on the random 833 increments (the value "N" in Figure 6 controls the trade-off between 834 randomization and port-reuse frequency. 836 Finally, a special case that may preclude the utilization of 837 Algorithm 3 and Algorithm 4 should be analyzed. There exist some 838 applications that contain the following code sequence: 840 s = socket(); 841 bind(s, IP_address, port = *); 843 Figure 7 845 In some BSD-derived systems, the call to bind() will result in the 846 selection of an ephemeral port number. However, as neither the 847 remote IP address nor the remote port will be available to the 848 ephemeral port selection function, the hash function F() used in 849 Algorithm 3 and Algorithm 4 will not have all the required arguments, 850 and thus the result of the hash function will be impossible to 851 compute. Transport protocols implementating Algorithm 3 or Algorithm 852 4 should consider using Algorithm 2 when facing the scenario just 853 described. 855 An alternative to this behavior would be to implement "lazy binding" 856 in response to the bind() call. That is, selection of an epphemeral 857 port would be delayed until, e.g., connect() or send() are called. 858 Thus, at that point the ephemeral port is actually selected, all the 859 necessary arguments for the hash function F() would be available, and 860 thus Algorithm 3 and Algorithm 4 could still be used in this 861 scenario. This policy has been implemented by Linux [Linux]. 863 4. Port obfuscation and Network Address Port Translation (NAPT) 865 Network Address Port Translation (NAPT) translate both the network 866 address and transport-protocol port number, thus allowing the 867 transport identifiers of a number of private hosts to be multiplexed 868 into the transport identifiers of a single external address. 869 [RFC2663] 871 In those scenarios in which a NAPT is present between the two end- 872 points of transport-protocol connection, the obfuscation of the 873 ephemeral ports (from the point of view of the external network) will 874 depend on the ephemeral port selection function at the NAPT. 875 Therefore, NAPTs should consider obfuscating the ephemeral ports by 876 means of any of the algorithms discussed in this document. It should 877 be noted that in some network scenarios, a NAPT may naturally obscure 878 ephemeral port selections simply due to the vast range of services 879 with which it establishes connections and to the overall rate of the 880 traffic [Allman]. 882 Section 3.5 provides guidance in choosing a port obfuscation 883 algorithm. 885 5. Security Considerations 887 Obfuscating ephemeral ports is no replacement for cryptographic 888 mechanisms, such as IPsec [RFC4301], in terms of protecting transport 889 protocol instances against blind attacks. 891 An eavesdropper, which can monitor the packets that correspond to the 892 connection to be attacked could learn the IP addresses and port 893 numbers in use (and also sequence numbers etc.) and easily attack the 894 connection. Ephemeral port obfuscation does not provide any 895 additional protection against this kind of attacks. In such 896 situations, proper authentication mechanisms such as those described 897 in [RFC4301] should be used. 899 If the local offset function F() results in identical offsets for 900 different inputs, the port-offset mechanism proposed in this document 901 has no or reduced effect. 903 If random numbers are used as the only source of the secret key, they 904 must be chosen in accordance with the recommendations given in 905 [RFC4086]. 907 If an attacker uses dynamically assigned IP addresses, the current 908 ephemeral port offset (Algorithm 3 and Algorithm 4) for a given five- 909 tuple can be sampled and subsequently used to attack an innocent peer 910 reusing this address. However, this is only possible until a re- 911 keying happens as described above. Also, since ephemeral ports are 912 only used on the client side (e.g. the one initiating the 913 connection), both the attacker and the new peer need to act as 914 servers in the scenario just described. While servers using dynamic 915 IP addresses exist, they are not very common and with an appropriate 916 re-keying mechanism the effect of this attack is limited. 918 6. IANA Considerations 920 There are no IANA registries within this document. The RFC-Editor 921 can remove this section before publication of this document as an 922 RFC. 924 7. Acknowledgements 926 The offset function was inspired by the mechanism proposed by Steven 927 Bellovin in [RFC1948] for defending against TCP sequence number 928 attacks. 930 The authors would like to thank (in alphabetical order) Mark Allman, 931 Matthias Bethke, Stephane Bortzmeyer, Brian Carpenter, Vincent 932 Deffontaines, Lars Eggert, Gorry Fairhurst, Guillermo Gont, Alfred 933 Hoenes, Amit Klein, Carlos Pignataro, Kacheong Poon, Joe Touch, and 934 Dan Wing for their valuable feedback on earlier versions of this 935 document. 937 The authors would like to thank FreeBSD's Mike Silbersack for a very 938 fruitful discussion about ephemeral port selection techniques. 940 Fernando Gont would like to thank Carolina Suarez for her love and 941 support. 943 8. References 945 8.1. Normative References 947 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 948 August 1980. 950 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 951 RFC 793, September 1981. 953 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 954 April 1992. 956 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 957 Requirement Levels", BCP 14, RFC 2119, March 1997. 959 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 960 Signature Option", RFC 2385, August 1998. 962 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 963 Jacobson, "RTP: A Transport Protocol for Real-Time 964 Applications", STD 64, RFC 3550, July 2003. 966 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 967 G. Fairhurst, "The Lightweight User Datagram Protocol 968 (UDP-Lite)", RFC 3828, July 2004. 970 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 971 Requirements for Security", BCP 106, RFC 4086, June 2005. 973 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 974 Internet Protocol", RFC 4301, December 2005. 976 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 977 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 979 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 980 RFC 4960, September 2007. 982 8.2. Informative References 984 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 986 [IANA] "IANA Port Numbers", 987 . 989 [I-D.ietf-tcpm-icmp-attacks] 990 Gont, F., "ICMP attacks against TCP", 991 draft-ietf-tcpm-icmp-attacks-06 (work in progress), 992 August 2009. 994 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 995 RFC 1337, May 1992. 997 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 998 RFC 1948, May 1996. 1000 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1001 Translator (NAT) Terminology and Considerations", 1002 RFC 2663, August 1999. 1004 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 1005 RFC 4953, July 2007. 1007 [Allman] Allman, M., "Comments On Selecting Ephemeral Ports", ACM 1008 Computer Communicatiion Review, 39(2), 2009. 1010 [CPNI-TCP] 1011 Gont, F., "CPNI Technical Note 3/2009: Security Assessment 1012 of the Transmission Control Protocol (TCP)", UK Centre 1013 for the Protection of National Infrastructure, 2009. 1015 [I-D.gont-tcp-security] 1016 Gont, F., "Security Assessment of the Transmission Control 1017 Protocol (TCP)", draft-gont-tcp-security-00 (work in 1018 progress), February 2009. 1020 [Linux] The Linux Project, "http://www.kernel.org". 1022 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 1024 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 1026 [OpenSolaris] 1027 OpenSolaris, "http://www.opensolaris.org". 1029 [Silbersack] 1030 Silbersack, M., "Improving TCP/IP security through 1031 randomization without sacrificing interoperability.", 1032 EuroBSDCon 2005 Conference . 1034 [Stevens] Stevens, W., "Unix Network Programming, Volume 1: 1035 Networking APIs: Socket and XTI", Prentice Hall , 1998. 1037 [I-D.ietf-tcpm-tcp-auth-opt] 1038 Touch, J., Mankin, A., and R. Bonica, "The TCP 1039 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-08 1040 (work in progress), October 2009. 1042 [Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", 1043 CanSecWest 2004 Conference . 1045 Appendix A. Survey of the algorithms in use by some popular 1046 implementations 1048 A.1. FreeBSD 1050 FreeBSD implements Algorithm 1, and in response to this document now 1051 uses a 'min_port' of 10000 and a 'max_port' of 65535. [FreeBSD] 1053 A.2. Linux 1055 Linux implements Algorithm 3. If the algorithm is faced with the 1056 corner-case scenario described in Section 3.5, Algorithm 1 is used 1057 instead [Linux]. 1059 A.3. NetBSD 1061 NetBSD does not obfuscate its ephemeral port numbers. It selects 1062 ephemeral port numbers from the range 49152-65535, starting from port 1063 65535, and decreasing the port number for each ephemeral port number 1064 selected [NetBSD]. 1066 A.4. OpenBSD 1068 OpenBSD implements Algorithm 1, with a 'min_port' of 1024 and a 1069 'max_port' of 49151. [OpenBSD] 1071 A.5. OpenSolaris 1073 OpenSolaris implements Algorithm 1, with a 'min_port' of 32768 and a 1074 'max_port' of 65535. [OpenSolaris] 1076 Appendix B. Changes from previous versions of the draft (to be removed 1077 by the RFC Editor before publication of this document as a 1078 RFC 1080 B.1. Changes from draft-ietf-tsvwg-port-randomization-04 1082 o Fixes nits. 1084 B.2. Changes from draft-ietf-tsvwg-port-randomization-03 1086 o Addresses WGLC comments from Mark Allman. See: 1087 http://www.ietf.org/mail-archive/web/tsvwg/current/msg09149.html 1089 B.3. Changes from draft-ietf-tsvwg-port-randomization-02 1091 o Added clarification of what we mean by "port randomization". 1093 o Addresses feedback sent on-list and off-list by Mark Allman. 1095 o Added references to [Allman] and [CPNI-TCP]. 1097 B.4. Changes from draft-ietf-tsvwg-port-randomization-01 1099 o Added Section 2.3. 1101 o Added discussion of "lazy binding in Section 3.5. 1103 o Added discussion of obtaining the number of outgoing connections. 1105 o Miscellaneous editorial changes 1107 B.5. Changes from draft-ietf-tsvwg-port-randomization-00 1109 o Added Section 3.1. 1111 o Changed Intended Status from "Standards Track" to "BCP". 1113 o Miscellaneous editorial changes. 1115 B.6. Changes from draft-larsen-tsvwg-port-randomization-02 1117 o Draft resubmitted as draft-ietf. 1119 o Included references and text on protocols other than TCP. 1121 o Added the second variant of the simple port randomization 1122 algorithm 1124 o Reorganized the algorithms into different sections 1126 o Miscellaneous editorial changes. 1128 B.7. Changes from draft-larsen-tsvwg-port-randomization-01 1130 o No changes. Draft resubmitted after expiration. 1132 B.8. Changes from draft-larsen-tsvwg-port-randomization-00 1134 o Fixed a bug in expressions used to calculate number of ephemeral 1135 ports 1137 o Added a survey of the algorithms in use by popular TCP 1138 implementations 1140 o The whole document was reorganizaed 1142 o Miscellaneous editorial changes 1144 B.9. Changes from draft-larsen-tsvwg-port-randomisation-00 1146 o Document resubmitted after original document by M. Larsen expired 1147 in 2004 1149 o References were included to current WG documents of the TCPM WG 1151 o The document was made more general, to apply to all transport 1152 protocols 1154 o Miscellaneous editorial changes 1156 Authors' Addresses 1158 Michael Vittrup Larsen 1159 TietoEnator 1160 Skanderborgvej 232 1161 Aarhus DK-8260 1162 Denmark 1164 Phone: +45 8938 5100 1165 Email: michael.larsen@tietoenator.com 1167 Fernando Gont 1168 Universidad Tecnologica Nacional / Facultad Regional Haedo 1169 Evaristo Carriego 2644 1170 Haedo, Provincia de Buenos Aires 1706 1171 Argentina 1173 Phone: +54 11 4650 8472 1174 Email: fernando@gont.com.ar