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