idnits 2.17.1 draft-ietf-tsvwg-behave-requirements-update-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2015) is 3317 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 2663 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-port-set-07 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG R. Penno 3 Internet-Draft Cisco 4 Intended status: Best Current Practice S. Perreault 5 Expires: August 22, 2015 Viagenie 6 S. Kamiset 7 Insieme Networks 8 M. Boucadair 9 France Telecom 10 K. Naito 11 NTT 12 February 18, 2015 14 Network Address Translation (NAT) Behavioral Requirements Updates 15 draft-ietf-tsvwg-behave-requirements-update-01 17 Abstract 19 This document clarifies and updates several requirements of RFC4787, 20 RFC5382 and RFC5508 based on operational and development experience. 21 The focus of this document is NAPT44. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 22, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. TCP Session Tracking . . . . . . . . . . . . . . . . . . . . 3 67 2.1. TCP Transitory Connection Idle-Timeout . . . . . . . . . 4 68 2.2. TIME_WAIT State . . . . . . . . . . . . . . . . . . . . . 5 69 2.2.1. Proposal: Apply RFC6191 and PAWS to NAT . . . . . . 5 70 2.3. TCP RST . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3. Port Overlapping behavior . . . . . . . . . . . . . . . . . . 8 72 4. Address Pooling Paired (APP) . . . . . . . . . . . . . . . . 8 73 5. EIF Security . . . . . . . . . . . . . . . . . . . . . . . . 9 74 6. EIF Protocol Independence . . . . . . . . . . . . . . . . . . 9 75 7. EIF Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 9 76 7.1. Outbound Mapping Refresh and Error Packets . . . . . . . 10 77 8. EIM Protocol Independence . . . . . . . . . . . . . . . . . . 10 78 9. Port Parity . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 10. Port Randomization . . . . . . . . . . . . . . . . . . . . . 10 80 11. IP Identification (IP ID) . . . . . . . . . . . . . . . . . . 11 81 12. ICMP Query Mappings Timeout . . . . . . . . . . . . . . . . . 11 82 13. Hairpinning Support for ICMP Packets . . . . . . . . . . . . 11 83 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 15. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 86 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 17.1. Normative References . . . . . . . . . . . . . . . . . . 12 88 17.2. Informative References . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 [RFC4787], [RFC5382] and [RFC5508] greatly advanced NAT 94 interoperability and conformance. But with widespread deployment and 95 evolution of NAT more development and operational experience was 96 acquired some areas of the original documents need further 97 clarification or updates. This document provides such clarifications 98 and updates. 100 1.1. Scope 102 This document focuses solely on NAPT44 and its goal is to clarify, 103 fill gaps or update requirements of [RFC4787], [RFC5382] and 104 [RFC5508]. 106 It is out of the scope of this document the creation of completely 107 new requirements not associated with the documents cited above. New 108 requirements would be better served elsewhere and if they are CGN 109 specific in an update to [RFC6888]. 111 1.2. Terminology 113 The reader should be familiar with the terms defined in 114 [RFC2663],[RFC4787],[RFC5382],and [RFC5508] 116 2. TCP Session Tracking 118 [RFC5382] specifies TCP timers associated with various connection 119 states but does not specify the TCP state machine a NAPT44 should use 120 as a basis to apply such timers. The TCP state machine depicted in 121 Figure 1, adapted from [RFC6146], provides guidance on how TCP 122 session tracking could be implemented - it is non-normative. 124 +-----------------------------+ 125 | | 126 V | 127 +------+ CV4 | 128 |CLOSED|-----SYN------+ | 129 +------+ | | 130 ^ | | 131 |TCP_TRANS T.O. | | 132 | V | 133 +-------+ +-------+ | 134 | TRANS | |V4 INIT| | 135 +-------+ +-------+ | 136 | ^ | | 137 data pkt | | | 138 | V4 or V4 RST | | 139 | TCP_EST T.O. | | 140 V | SV4 SYN | 141 +--------------+ | | 142 | ESTABLISHED |<---------+ | 143 +--------------+ | 144 | | | 145 CV4 FIN SV4 FIN | 146 | | | 147 V V | 148 +---------+ +----------+ | 149 |CV4 FIN | | SV4 FIN | | 150 | RCV | | RCV | | 151 +---------+ +----------+ | 152 | | | 153 SV4 FIN CV4 FIN TCP_TRANS 154 | | T.O. 155 V V | 156 +----------------------+ | 157 | CV4 FIN + SV4 FIN RCV|--------------------+ 158 +----------------------+ 160 Figure 1 162 2.1. TCP Transitory Connection Idle-Timeout 164 [RFC5382]:REQ-5 The transitory connection idle-timeout is defined as 165 the minimum time a TCP connection in the partially open or closing 166 phases must remain idle before the NAT considers the associated 167 session a candidate for removal. But the document does not clearly 168 states if these can be configured separately. 170 This document clarifies that a NAT device SHOULD provide different 171 knobs for configuring the open and closing idle timeouts. This 172 document further acknowledges that most TCP flows are very short 173 (less than 10 seconds) [FLOWRATE][TCPWILD] and therefore a partially 174 open timeout of 4 minutes might be excessive if security is a 175 concern. Therefore, it MAY be configured to be less than 4 minutes 176 in such cases. There also may be cases that a timeout of 4 minutes 177 might be excessive. The case and the solution are written below. 179 2.2. TIME_WAIT State 181 The TCP TIME_WAIT state is described in [RFC0793]. The TCP TIME_WAIT 182 state needs to be kept for 2MSL before a connection is CLOSED, for 183 the reasons listed below: 185 1: In the event that packets from a session are delayed in the in- 186 between network, and delivered to the end relatively later, we 187 should prevent the packets from being transferred and interpreted 188 as a packet that belongs to a new session. 190 2: If the remote TCP has not received the acknowledgment of its 191 connection termination request, it will re-send the FIN packet 192 several times. 194 These points are important for the TCP to work without problems. 196 [RFC5382] leaves the handling of TCP connections in TIME_WAIT state 197 unspecified and mentions that TIME_WAIT state is not part of the 198 transitory connection idle-timeout. If the NAT device honors the 199 TIME_WAIT state, each TCP connection and its associated resources is 200 kept for a certain period, typically for four minutes, which consumes 201 port resources. 203 [RFC6191] explains that in certain situation it is necessary to 204 reduce the TIME_WAIT state and defines such a mechanism using TCP 205 timestamps and sequence numbers. When a connection request is 206 received with a four-tuple that is in the TIME-WAIT state, the 207 connection request may be accepted if the sequence number or the 208 timestamp of the incoming SYN segment is greater than the last 209 sequence number seen on the previous incarnation of the connection. 211 This document specifies that a NAT device should keep TCP connections 212 in TIME_WAIT state unless it implements the proposal described in the 213 following sub-section. 215 2.2.1. Proposal: Apply RFC6191 and PAWS to NAT 217 This section proposes to apply [RFC6191] mechanism at NAT. This 218 mechanism MAY be adopted for both clients' and remote hosts' TCP 219 active close. 221 client NAT remote host 222 | | | 223 | FIN | FIN | 224 |------------------------>|------------------------>| 225 | | | 226 | ACK | ACK | 227 |<------------------------|<------------------------| 228 | FIN | FIN | 229 |<------------------------|<------------------------| 230 | | | 231 | ACK(TSval=A) | ACK | 232 |------------------------>|------------------------>| 233 | | - | 234 | | | | 235 | | | | 236 | | | | 237 | | | TIME_WAIT | 238 | | | ->assassinated at x | 239 | | | | 240 | | | | 241 | | | | 242 | SYN(TSval>A) | x SYN | 243 |------------------------>|------------------------>| 244 | | - | 245 | | | | 246 | | | SYN_SENT | 247 | | | | 248 | | | | 250 Also, PAWS works to discard old duplicate packets at NAT. A packet 251 can be discarded as an old duplicate if it is received with a 252 timestamp or sequence number value less than a value recently 253 received on the connection. 255 To make these mechanisms work, we should concern the case that there 256 are several clients with nonsuccessive timestamp or sequence number 257 values are connected to a NAT device (i.e., not monotonically 258 increasing among clients). Two mechanisms to solve this mechanism 259 and applying [RFC6191] and PAWS to NAT are described below. These 260 mechanisms are optional. 262 2.2.1.1. Rewrite timestamp and sequence number values at NAT 264 Rewrite timestamp and sequence number values of outgoings packets at 265 NAT to be monotonically increasing. This can be done by adopting 266 following mechanisms at NAT. 268 A: Store the newest rewritten value of timestamp and sequence number 269 as the "max value at the time". 271 B: NAT rewrite timestamp and sequence number values of incoming 272 packets to be monotonically increasing. 274 When packets come back as replies from remote hosts, NAT rewrite 275 again the timestamp and sequence number values to be the original 276 values. This can be done by adopting following mechanisms at NAT. 278 C: Store the values of original timestamp and sequence number of 279 packets, and rewritten values of those. 281 2.2.1.2. Split an assignable number of port space to each client 283 Adopt following mechanisms at NAT. 285 A: Choose clients that can be assigned ports. 287 B: Split assignable port numbers between clients. 289 Packets from other clients which are not chosen by these mechanisms 290 are rejected at NAT, unless there is unassigned port left. 292 2.2.1.3. Resend the last ACK to the retransmisstted FIN 294 We need to solve another scenario to make [RFC6191] work with NAT. 295 In the case the remote TCP could not receive the acknowledgment of 296 its connection termination request, the NAT device, on behalf of 297 clients, resends the last ACK packet when it receives a FIN packet of 298 the previous connection, and when the state of the previous 299 connection has been deleted from the NAT. This mechanism MAY be used 300 when clients starts closing process, and the remote host could not 301 receive the last ACK. 303 2.2.1.4. Remote host behavior of several implementations 305 To solve the port shortage problem on the client side, the behavior 306 of remote host should be compliant to [RFC6191] or the mechanism 307 written in Section 4.2.2.13 of [RFC1122], since NAT may reuse the 308 same 5 tuple for a new connection. We have investigated behaviors of 309 OSes (e.g., Linux, FreeBSD, Windows, MacOS), and found that they 310 implemented the server side behavior of the above two. 312 2.3. TCP RST 314 [RFC5382] leaves the handling of TCP RST packets unspecified. This 315 document does not try standardize such behavior but clarifies based 316 on operational experience that a NAT that receives a TCP RST for an 317 active mapping and performs session tracking MAY immediately delete 318 the sessions and remove any state associated with it. If the NAT 319 device that performs TCP session tracking receives a TCP RST for the 320 first session that created a mapping, it MAY remove the session and 321 the mapping immediately. 323 3. Port Overlapping behavior 325 [RFC4787] [RFC5382]: REQ-1 Current RFCs specifiy a specific port 326 overlapping behavior, i.e., that the external IP:port can be reused 327 for connections originating from the same internal source IP:port 328 irrespective of the destination. This is known as endpoint- 329 independent mapping. This document clarifies that this port 330 overlapping behavior can be extended to connections originating from 331 different internal source IP:ports as long as their destinations are 332 different. This known as EDM (Endpoint Dependent Mapping). The 333 mechanism below MAY be one optional implement to NAT. 335 If destination addresses and ports are different for outgoing 336 connections started by local clients, NAT MAY assign the same 337 external port as the source ports for the connections. The port 338 overlapping mechanism manages mappings between external packets and 339 internal packets by looking at and storing their 5-tuple (protocol, 340 source address, source port, destination address, destination port) . 341 This enables concurrent use of a single NAT external port for 342 multiple transport sessions, which enables NAT to work correctly in 343 IP address resource limited network. 345 Discussions: 347 [RFC4787] and [RFC5382] requires "endpoint-independent mapping" at 348 NAT, and port overlapping NAT cannot meet the requirement. This 349 mechanism can degrade the transparency of NAT in that its mapping 350 mechanism is endpoint-dependent and makes NAT traversal harder. 351 However, if a NAT adopts endpoint-independent mapping together with 352 endpoint-dependent filtering, then the actual behavior of the NAT 353 will be the same as port overlapping NAT. 355 4. Address Pooling Paired (APP) 357 [RFC4787]: REQ-2 [RFC5382]:ND Address Pooling Paired behavior for NAT 358 is recommended in previous documents but behavior when a public IPv4 359 run out of ports is left undefined. This document clarifies that if 360 APP is enabled new sessions from a subscriber that already has a 361 mapping associated with a public IP that ran out of ports SHOULD be 362 dropped. The administrator MAY provide a knob that allows a NAT 363 device to starting using ports from another public IP when the one 364 that anchored the APP mapping ran out of ports. This is trade-off 365 between subscriber service continuity and APP strict enforcement. 366 (Note, it is sometimes referred as 'soft-APP') 368 5. EIF Security 370 [RFC4787]:REQ-8 and [RFC5382]:REQ-3 End-point independent filtering 371 could potentially result in security attacks from the public realm. 372 In order to handle this, when possible there MUST be strict filtering 373 checks in the inbound direction. A knob SHOULD be provided to limit 374 the number of inbound sessions and a knob SHOULD be provided to 375 enable or disable EIF on a per application basis. This is specially 376 important in the case of Mobile networks where such attacks can 377 consume radio resources and count against the user quota. 379 6. EIF Protocol Independence 381 [RFC4787]:REQ-8 and[RFC5382]: REQ-3 Current RFCs do not specify 382 whether EIF mappings are protocol independent. In other words, if an 383 outbound TCP SYN creates a mapping, it is left undefined whether 384 inbound UDP packets destined to that mapping should be forwarded. 385 This document specifies that EIF mappings SHOULD be protocol 386 independent in order allow inbound packets for protocols that 387 multiplex TCP and UDP over the same IP: port through the NAT and also 388 maintain compatibility with stateful NAT64 RFC6146 [RFC6146]. But, 389 the administrator MAY provide a configuration knob to make it 390 protocol dependent. 392 7. EIF Mapping Refresh 394 [RFC4787]: REQ-6 [RFC5382]: ND The NAT mapping Refresh direction MAY 395 have a "NAT Inbound refresh behavior" of "True" but it does not 396 clarifies how this applies to EIF mappings. The issue in question is 397 whether inbound packets that match an EIF mapping but do not create a 398 new session due to a security policy should refresh the mapping 399 timer. This document clarifies that even when a NAT device has a 400 inbound refresh behavior of TRUE, such packets SHOULD NOT refresh the 401 mapping. Otherwise a simple attack of a packet every 2 minutes can 402 keep the mapping indefinitely. 404 7.1. Outbound Mapping Refresh and Error Packets 406 In the case of NAT outbound refresh behavior there are certain types 407 of packets that should not refresh the mapping even if their 408 direction is outbound. For example, if the mapping is kept alive by 409 ICMP Errors or TCP RST outbound packets sent as response to inbound 410 packets, these SHOULD NOT refresh the mapping. 412 8. EIM Protocol Independence 414 [RFC4787] [RFC5382]: REQ-1 Current RFCs do not specify whether EIM 415 are protocol independent. In other words, if a outbound TCP SYN 416 creates a mapping it is left undefined whether outbound UDP can reuse 417 such mapping and create session. On the other hand, Stateful NAT64 418 [RFC6146] clearly specifies three binding information bases (TCP, 419 UDP, ICMP). This document clarifies that EIM mappings SHOULD be 420 protocol dependent . A knob MAY be provided in order allow protocols 421 that multiplex TCP and UDP over the same source IP and port to use a 422 single mapping. 424 9. Port Parity 426 A NAT devices MAY disable port parity preservation for dynamic 427 mappings. Nevertheless, A NAT SHOULD support means to explicitly 428 request to preserve port parity (e.g., [I-D.ietf-pcp-port-set]). 430 10. Port Randomization 432 A NAT SHOULD follow the recommendations specified in Section 4 of 433 [RFC6056] especially: 435 "A NAPT that does not implement port preservation [RFC4787] 436 [RFC5382] SHOULD obfuscate selection of the ephemeral port of a 437 packet when it is changed during translation of that packet. A 438 NAPT that does implement port preservation SHOULD obfuscate the 439 ephemeral port of a packet only if the port must be changed as a 440 result of the port being already in use for some other session. A 441 NAPT that performs parity preservation and that must change the 442 ephemeral port during translation of a packet SHOULD obfuscate the 443 ephemeral ports. The algorithms described in this document could 444 be easily adapted such that the parity is preserved (i.e., force 445 the lowest order bit of the resulting port number to 0 or 1 446 according to whether even or odd parity is desired)." 448 11. IP Identification (IP ID) 450 A NAT SHOULD handle the Identification field of translated IPv4 451 packets as specified in Section 9 of [RFC6864]. 453 12. ICMP Query Mappings Timeout 455 Section 3.1 of [RFC5508] says that ICMP Query Mappings are to be 456 maintained by NAT device. However, RFC doesn't discuss about the 457 Query Mapping timeout values. Section 3.2 of that RFC only discusses 458 about ICMP Query Session Timeouts. 460 ICMP Query Mappings MAY be deleted once the last the session using 461 the mapping is deleted. 463 13. Hairpinning Support for ICMP Packets 465 [RFC5508]:REQ-7 This requirement specifies that NAT devices enforcing 466 Basic NAT MUST support traversal of hairpinned ICMP Query sessions. 467 This implicitly means that address mappings from external address to 468 internal address (similar to Endpoint Independent Filters) MUST be 469 maintained to allow inbound ICMP Query sessions. If an ICMP Query is 470 received on an external address, NAT device can then translate to an 471 internal IP. [RFC5508]:REQ-7 This requirement specifies that all NAT 472 devices (i.e., Basic NAT as well as NAPT devices) MUST support the 473 traversal of hairpinned ICMP Error messages. This requires NAT 474 devices to maintain address mappings from external IP address to 475 internal IP address in addition to the ICMP Query Mappings described 476 in section 3.1 of that RFC. 478 14. IANA Considerations 480 This document does not require any IANA action. 482 15. Security Considerations 484 In the case of EIF mappings due to high risk of resource crunch, a 485 NAT device MAY provide a knob to limit the number of inbound sessions 486 spawned from a EIF mapping. 488 [I-D.ietf-tcpm-tcp-security] contains a detailed discussion of the 489 security implications of TCP Timestamps and of different timestamp 490 generation algorithms. 492 16. Acknowledgements 494 Thanks to Dan Wing, Suresh Kumar, Mayuresh Bakshi, Rajesh Mohan and 495 Senthil Sivamular for review and discussions 497 17. References 499 17.1. Normative References 501 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 502 793, September 1981. 504 [RFC1122] Braden, R., "Requirements for Internet Hosts - 505 Communication Layers", STD 3, RFC 1122, October 1989. 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 511 Translator (NAT) Terminology and Considerations", RFC 512 2663, August 1999. 514 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 515 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 516 RFC 4787, January 2007. 518 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 519 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 520 RFC 5382, October 2008. 522 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 523 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 524 April 2009. 526 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 527 Protocol Port Randomization", BCP 156, RFC 6056, January 528 2011. 530 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 531 NAT64: Network Address and Protocol Translation from IPv6 532 Clients to IPv4 Servers", RFC 6146, April 2011. 534 [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP 535 Timestamps", BCP 159, RFC 6191, April 2011. 537 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 538 RFC 6864, February 2013. 540 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 541 and H. Ashida, "Common Requirements for Carrier-Grade NATs 542 (CGNs)", BCP 127, RFC 6888, April 2013. 544 17.2. Informative References 546 [FLOWRATE] 547 Zhang, Y., Breslau, L., Paxson, V., and S. Shenker, "On 548 the Characteristics and Origins of Internet Flow Rates", . 550 [I-D.ietf-pcp-port-set] 551 Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, 552 T., and S. Perreault, "Port Control Protocol (PCP) 553 Extension for Port Set Allocation", draft-ietf-pcp-port- 554 set-07 (work in progress), November 2014. 556 [I-D.ietf-tcpm-tcp-security] 557 Gont, F., "Survey of Security Hardening Methods for 558 Transmission Control Protocol (TCP) Implementations", 559 draft-ietf-tcpm-tcp-security-03 (work in progress), March 560 2012. 562 [TCPWILD] Qian, F., Subhabrata, S., Spatscheck, O., Morley Mao, Z., 563 and W. Willinger, "TCP Revisited: A Fresh Look at TCP in 564 the Wild", . 566 Authors' Addresses 568 Reinaldo Penno 569 Cisco Systems, Inc. 570 170 West Tasman Drive 571 San Jose, California 95134 572 USA 574 Email: repenno@cisco.com 576 Simon Perreault 577 Viagenie 578 2875 boul. Laurier, suite D2-630 579 Quebec, QC G1V 2M2 580 Canada 582 Email: simon.perreault@viagenie.ca 583 Sarat Kamiset 584 Insieme Networks 585 California 587 Mohamed Boucadair 588 France Telecom 589 Rennes 35000 590 France 592 Email: mohamed.boucadair@orange.com 594 Kengo Naito 595 NTT 596 Tokyo 597 Japan 599 Email: kengo@lab.ntt.co.jp