idnits 2.17.1 draft-nishida-tcpm-apaws-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 1) Option Exchange in SYN This method requires using new codepoint for TCP option and exchange them during SYN negotiation. The use of [RFC6994] is recommended. Since A-PAWS negotiation is 1 bit information (on or off), new option does not need to have any content. Hence, if 16-bit EXID is used, the option size for A-PAWS can be kept in 4 bytes length. In this signaling method, when an endpoint does not find A-PAWS option in received SYN or SYN-ACK segment, it MUST not send segments with A-PAWS logic in Section 3.3. However, it MUST activate A-PAWS receiver logic in Section 3.4 if it has sent A-PAWS option in the SYN packet. This is because some middleboxes may remove A-PAWS option in SYN-ACK. Although this is a straightforward approach, it requires additional option space in SYN segments. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 3) Option Exchange in non-SYN Segments This method uses new codepoint for TCP option, however, the options are not used during SYN negotiation. Just like option exchange in SYN segments, when a endpoint sets A-PAWS option in the segments, it indicates that it can receive the segments from A-PAWS senders. Hence, it MUST activate A-PAWS receiver logic in Section 3.4 if it sends the options. However, it MUST not send segments with A-PAWS logic in Section 3.3 until it receives A-PAWS options. This approach does not require extra option space or special timestamp value in SYN segments. However, negotiating features in non-SYN segments will require to address further arguments such as when to send the options or how to retransmits the options. We will discuss these points in the next section. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Rule 2: An endpoint MUST not send segments with A-PAWS logic in Section 3.3 until it receives A-PAWS option from the other endpoint. -- The document date (June 10, 2014) is 3601 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Nishida 3 Internet-Draft GE Global Research 4 Intended status: Experimental June 10, 2014 5 Expires: December 12, 2014 7 A-PAWS: Alternative Approach for PAWS 8 draft-nishida-tcpm-apaws-01 10 Abstract 12 This documents describe a technique called A-PAWS which can provide 13 protection against old duplicates segments like PAWS. While PAWS 14 requires TCP to set timestamp options in all segments in a TCP 15 connection, A-PAWS supports the same feature without using 16 timestamps. A-PAWS is designed to be used complementary with PAWS. 17 TCP needs to use PAWS when it is necessary and activates A-PAWS only 18 when it is safe to use. Without impairing the reliability and the 19 robustness of TCP, A-PAWS can provide more option space to other TCP 20 extensions. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 12, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 58 3. The A-PAWS Design . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Signaling Method . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Negotiating Features Using non-SYN segments . . . . . . . 5 61 3.3. Sending Behavior . . . . . . . . . . . . . . . . . . . . 6 62 3.4. Receiving Behavior . . . . . . . . . . . . . . . . . . . 7 63 4. When To Use A-PAWS . . . . . . . . . . . . . . . . . . . . . 7 64 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.1. Protection Against Early Incarnations . . . . . . . . . . 8 66 5.2. Protection Against Security Threats . . . . . . . . . . . 8 67 5.3. Middlebox Considerations . . . . . . . . . . . . . . . . 9 68 5.4. Aggressive Mode in A-PAWS . . . . . . . . . . . . . . . . 9 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 8.2. Informative References . . . . . . . . . . . . . . . . . 10 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 PAWS (Protect Against Wrapped Sequences) defined in [RFC1323] is a 79 technique that can identify old duplicate segments in a TCP 80 connection. An old duplicate segment can be generated when it has 81 been delayed by queueing, etc. If such a segment has the sequence 82 number which falls within the receiver's current window, the receiver 83 will accept it without any warning or error. However, this segment 84 can be a segment created by an old connection that has the same port 85 and address pair, or a segments sent 2**32 bytes earlier on the same 86 connection. Although this situation rarely happens, it impairs the 87 reliability of TCP. 89 PAWS utilizes timestamp option in [RFC1323] to provide protection 90 against this. It is assumed that every received TCP segment contains 91 a timestamp. PAWS can identify old duplicate segments by comparing 92 the timestamp in the received segments and the timestamps from other 93 segments received recently. If both TCP endpoints agree to use PAWS, 94 all segments belong to this connection should have timestamp. Since 95 PAWS is the only standardized protection against old duplicate 96 segments, it has been implemented and used in most TCP 97 implementations. However, as some TCP extensions such as [RFC2018], 98 [RFC5925] and [RFC6824] also requires a certain amount of option 99 space in non-SYN segments, using 10-12 bytes length in option space 100 for timestamp in all segments tends to be considered expensive in 101 recent discussions. 103 In addition, although PAWS is necessary for connections which 104 transmit more than 2**32 bytes, it is not very important for other 105 connections since [RFC0793] already has protection against segments 106 from old connections by using timers. Moreover, some research 107 results indicates that most of TCP flows tend to transmit small 108 amount of data, which means only small fraction of TCP connections 109 really need PAWS [QIAN11]. Timestamp option is also used for RTTM 110 (Round Trip Time Measurement) in [RFC1323]. Gathering many RTT 111 samples from the timestamp in every TCP segment looks useful approach 112 to improve RTO estimation. However, some research results shows the 113 number of samples per RTT does not affect the effectiveness of the 114 RTO [MALLMAN99]. Hence, we can think if PAWS is not used, sending a 115 few timestamps per RTT will be sufficient. 117 Based on these observations, we propose a new technique called A-PAWS 118 which can archive similar protection against old duplicates segments. 119 The basic idea of A-PAWS is to attain the same protection against old 120 all duplicate segments as PAWS while reducing the use of TS options 121 in segments. A-PAWS is designed to be used complementary with PAWS. 122 This means an implementation that supports A-PAWS is still required 123 to supports PAWS. A-PAWS is activated only when it is safe to use. 124 This sounds the applicability of A-PAWS is limited, however, we 125 believe TCP will have a lot of chances to save the option space if it 126 uses A-PAWS. 128 There are some discussions that PAWS can also be used to enhance 129 security, however, we still believe that A-PAWS can maintain the same 130 level of security as PAWS. Detailed discussions on this point are 131 provided in Section 5. A-PAWS is an experimental idea yet, but we 132 hope it will contribute to facilitating the use of TCP option space. 134 2. Conventions and Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 3. The A-PAWS Design 142 A-PAWS assumes PAWS as it is designed to be used complementary with 143 PAWS. Hence, a node which supports A-PAWS MUST support PAWS. The 144 following mechanisms are required in TCP in order to perform A-PAWS. 146 3.1. Signaling Method 148 A-PAWS requires a signaling mechanism to enable this feature as it 149 employs different logics from [RFC2119] to process TS options. 150 A-PAWS presumes the use of PAWS. Hence, if TS option is not 151 negotiated during SYN exchanges, A-PAWS MUST NOT be activated. An 152 important point for A-PAWS is that it does not require synchronized 153 signaling between senders and receivers. In Table 1 illustrates 154 possible combinations for PAWS and A-PAWS. It should be noted that 155 when receiver employs A-PAWS, it does not matter if sender uses PAWS 156 or A-PAWS (case 2 and case 4). This allows us to use less 157 synchronized signaling mechanisms described in the following 158 sections. However, we must avoid the situation where the sender 159 activates A-PAWS while the receiver uses PAWS (case 3). 161 +--------+--------+----------+--------------+ 162 | case # | Sender | Receiver | | 163 +--------+--------+----------+--------------+ 164 | 1 | PAWS | PAWS | Work | 165 | | | | | 166 | 2 | PAWS | A-PAWS | Work | 167 | | | | | 168 | 3 | A-PAWS | PAWS | Doesn't work | 169 | | | | | 170 | 4 | A-PAWS | A-PAWS | Work | 171 +--------+--------+----------+--------------+ 173 Table 1: Possible Combinations for PAWS and A-PAWS 175 Based on these requirements, the followings are possible approach for 176 A-PAWS signaling. 178 1) Option Exchange in SYN 179 This method requires using new codepoint for TCP option and 180 exchange them during SYN negotiation. The use of [RFC6994] is 181 recommended. Since A-PAWS negotiation is 1 bit information (on 182 or off), new option does not need to have any content. Hence, if 183 16-bit EXID is used, the option size for A-PAWS can be kept in 4 184 bytes length. In this signaling method, when an endpoint does 185 not find A-PAWS option in received SYN or SYN-ACK segment, it 186 MUST not send segments with A-PAWS logic in Section 3.3. 187 However, it MUST activate A-PAWS receiver logic in Section 3.4 if 188 it has sent A-PAWS option in the SYN packet. This is because 189 some middleboxes may remove A-PAWS option in SYN-ACK. Although 190 this is a straightforward approach, it requires additional option 191 space in SYN segments. 193 2) Timestamp Field Negotiation in SYN 194 This method is based on timestamp field negotiation proposed in 195 [I-D.scheffenegger-tcpm-timestamp-negotiation]. The draft 196 proposes to utilize timestamp values in SYN segments in order to 197 negotiate additional capabilities for timestamps. The advantage 198 of this approach is that it does not require extra option space 199 (hence new codepoint, either) for this, although detailed 200 mechanisms are still under discussion. However, we will need 201 some mechanisms to avoid case 3 in Table 1. 203 3) Option Exchange in non-SYN Segments 204 This method uses new codepoint for TCP option, however, the 205 options are not used during SYN negotiation. Just like option 206 exchange in SYN segments, when a endpoint sets A-PAWS option in 207 the segments, it indicates that it can receive the segments from 208 A-PAWS senders. Hence, it MUST activate A-PAWS receiver logic in 209 Section 3.4 if it sends the options. However, it MUST not send 210 segments with A-PAWS logic in Section 3.3 until it receives 211 A-PAWS options. This approach does not require extra option 212 space or special timestamp value in SYN segments. However, 213 negotiating features in non-SYN segments will require to address 214 further arguments such as when to send the options or how to 215 retransmits the options. We will discuss these points in the 216 next section. 218 3.2. Negotiating Features Using non-SYN segments 220 As explained in Section 3.1, A-PAWS will explore a signaling method 221 that utilizes non-SYN segments. If robust and reliable signaling 222 mechanisms are necessary, we will probably need to invent another 223 three-way handshake like mechanisms that use non-SYN segments. This 224 will require drastic changes in the current TCP semantics. Instead, 225 in case of A-PAWS, we can use a relatively simple and easy mechanism 226 for feature negotiation. One important characteristic for A-PAWS is 227 the signaling mechanism does not require tight synchronization 228 between endpoints. This is because A-PAWS receivers can interact 229 with both A-PAWS senders and PAWS senders. Hence, we can use a less 230 reliable method for A-PAWS signaling. For example, when an endpoint 231 sends A-PAWS option and the other endpoint does not send back A-PAWS 232 option, we are not very sure if the other endpoint disabled the 233 feature or a middlebox in the forward or the return path removed the 234 option. However, A-PAWS endpoints are not confused in these cases by 235 using the following two rules. 237 Rule 1: An endpoint MUST activate A-PAWS receiver logic in 238 Section 3.4 before it sends A-PAWS option. 240 Rule 2: An endpoint MUST not send segments with A-PAWS logic in 241 Section 3.3 until it receives A-PAWS option from the other 242 endpoint. 244 By having these rules, A-PAWS sender logic will not be activated 245 without explicit signaling from its peer, which allows us to avoid 246 the case 3 in Table 1 even if some signaling has been lost. 248 Another discussion point for this signaling method is when to set 249 A-PAWS option in segments. As A-PAWS employs asynchronous signaling, 250 both endpoints basically can set A-PAWS option in segments anytime 251 they want. However, we recommend using the following rules for 252 setting options. 254 Rule 3: An endpoint SHOULD use a data segment when it sets A-PAWS 255 option in a segment. 257 Rule 4: When an endpoint receives a data segment with A-PAWS 258 option, it SHOULD set A-PAWS option for its ACK segment. 260 Rule 5: An endpoint SHOULD NOT set A-PAWS options in retransmitted 261 segments. 263 These rules allow endpoints to have loose synchronized signaling so 264 that they can at least solicit responses from their peers. Of 265 course, even an endpoint solicit a response by setting A-PAWS option 266 in a data segment, it might not receive A-PAWS option in the ACK 267 segment. This can be caused by the lost of the ACK segment or 268 middleboxes that remove unknown options. In order to address these 269 cases, the following rules can be used. 271 Rule 6: As long as an endpoint does not violate the other rules, 272 it MAY set A-PAWS option in multiple data segments with a certain 273 interval in case no A-PAWS options has been sent from the peer. 275 This rule can address the cases where A-PAWS options has been removed 276 by middleboxes or segments with A-PAWS options has been lost. 278 3.3. Sending Behavior 280 A-PAWS enabled TCP transmits segments, it needs to follow the rules 281 below. 283 1. TCP needs to check how many bytes has been transmitted in a 284 connection. If the transmitted bytes exceeds 2**32 - 285 'Sender.Offset', TCP migrates PAWS mode and MUST set timestamp 286 option in all segments to be transmitted. The value for 287 'Sender.Offset' is discussed in Section 5. 289 2. If the number of bytes transmitted in a TCP connection does not 290 exceeds 2**32 - 'Sender.Offset', TCP MAY omit timestamp option in 291 segments as long as it does not affect RTTM. This draft does not 292 define how much TCP can omit timestamps because it should be 293 determined by RTTM. 295 3.4. Receiving Behavior 297 A-PAWS enabled TCP receives segments, it needs to follow the rules 298 below. 300 1. TCP needs to check how many bytes has been received in a TCP 301 connection. If it exceeds 2**32 bytes, A-PAWS nodes SHOULD 302 discard the received segments which does not have timestamp 303 option. TCP MUST perform PAWS check when received bytes exceeds 304 2**32 bytes. 306 2. If the number of bytes received in a TCP connection does not 307 exceeds 2**32 bytes, A-PAWS nodes SHOULD accept the segments even 308 if it does not have timestamp option. A-PAWS nodes MAY skip PAWS 309 check until the received bytes exceeds 2**32 bytes. 311 4. When To Use A-PAWS 313 In basic principal, A-PAWS capable nodes can always use A-PAWS as 314 long as the peers agree with them. However, the following cases 315 require special considerations to enable A-PAWS. 317 1. As "When To Keep Quiet" section in [RFC0793] suggests, it is 318 recommended that TCP keeps quiet for a MSL upon starting up or 319 recovering from a crash where memory of sequence numbers has been 320 lost. However, if timestamps are being used and if the timestamp 321 clock can be guaranteed to be increased monotonically, this quiet 322 time may be unnecessary. Because TCP can identify the segments 323 from old connections by checking the timestamp. We think some 324 TCP implementations may disable the quiet time because of using 325 timestamps from this reason. However, since A-PAWS nodes does 326 not set timestamp options in all segments, TCP cannot rely on 327 this approach. To avoid decreasing the robustness of TCP 328 connection, TCP MUST NOT use A-PAWS for a MSL upon starting up or 329 recovering from a crash. 331 2. Various TCP implementations provide APIs such as setsockopt() 332 that can set SO_REUSEADDR flag on TCP connections. If this flag 333 is set, the TCP connection allows to reuse the same local port 334 without waiting for 2 MSL period. While this option is useful 335 when users want to relaunch applications immediately, it makes 336 the TCP connection a little vulnerable as TCP stack might receive 337 duplicate segments from earlier incarnations. It has been said 338 that PAWS can contribute to mitigate this risk by checking the 339 timestamps in segments. In order to keep the same level of 340 protection, TCP SHOULD NOT enable A-PAWS when SO_REUSEADDR flag 341 is set. 343 5. Discussion 345 As A-PAWS is an experimental logic, the following points need to be 346 considered and discussed. 348 5.1. Protection Against Early Incarnations 350 There are some discussions that timestamp can enhance the robustness 351 against early incarnations. Since A-PAWS does not set timestamps in 352 all segments, some may say that it degrades the robustness of TCP. 353 We believe that the degradation caused by A-PAWS on this point is 354 negligible. As long as TCP limits the usage of A-PAWS as described 355 in Section 4, duplicate segments from early incarnations should not 356 be received by TCP. 358 5.2. Protection Against Security Threats 360 A TCP connection can be identified by a 5-tuple: source address, 361 destination address, source port number, destination port number and 362 protocol. Crackers need to guess all these parameters when they try 363 malicious attacks on the connection. PAWS can enhance the protection 364 for this as it additionally requires timestamp checking. However, we 365 think the effect of PAWS against malicious attacks is limited due to 366 the simplicity of PAWS check. In PAWS, a segment can be considered 367 as an old duplicate if the timestamp in the segment less than some 368 timestamps recently received on the connection. The "less than" in 369 this context is determined by processing timestamp values as 32 bit 370 unsigned integers in a modular 32-bit space. For example, if t1 and 371 t2 are timestamp values, t1 < t2 is verified when 0 < (t2 - t1) < 372 2**31 computed in unsigned 32-bit arithmetic. Hence, if crackers set 373 a random value in the timestamp option, there will be 50% chance for 374 them to trick PAWS check. Moreover, there will be more chances if 375 they send multiple segments with different timestamps, which will not 376 be difficult to perform. 378 In addition, we think there might be a case where using PAWS 379 increases security risks. PAWS recommends to increase timestamp over 380 a system when TCP waives the "quiet time" described in [RFC0793]. 381 However, if timestamps are generated from a global counter, it may 382 leak some information such as system uptime as discussed in 383 [SILBERSACK05]. A-PAWS might be able to allows TCP to use random 384 timestamp values per connections. 386 5.3. Middlebox Considerations 388 A-PAWS is designed to be robust against middleboxes. This means that 389 endpoints will not be messed up even if middleboxes discard A-PAWS 390 option. This is because A-PAWS sender logic is activated only when 391 TCP receives a segment with A-PAWS options. A-PAWS receiver logic 392 does not need to know whether the sender is using PAWS or A-PAWS. 393 Activating A-PAWS receiving logic for PAWS sender might be redundant 394 as it requires additional overheads. However, we believe the 395 overhead will be acceptable in most cases because of the simplicity 396 of A-PAWS logic. 398 Another concern on middleboxes is that they can insert or delete some 399 bytes in TCP connections. If a middlebox inserts extra bytes into a 400 TCP connections, there might be a situation where an A-PAWS sender 401 can transmit segments without timestamp, while an A-PAWS receiver 402 perform PAWS check on them as it already has received 2**32 bytes. 403 In order to avoid discarding segments unnecessarily, we recommend 404 that A-PAWS sender should have a certain amount of offset bytes in 405 order to migrate PAWS mode before the receiver receives 2**32 bytes. 406 We call this protocol parameter 'Sender.Offset'. The proper value 407 for 'Sender.Offset' needs to be discussed. 409 5.4. Aggressive Mode in A-PAWS 411 The current A-PAWS requires TCP to migrate PAWS mode after sending/ 412 receiving 2**32 bytes. However, if both nodes check if 2 MSL has 413 already passed during sending/receiving 2**32 bytes, they might be 414 able to continue using A-PAWS. We call this "Aggressive mode". We 415 currently do not recommend this mode as it requires additional 416 complexities in A-PAWS. 418 6. Security Considerations 420 We believe A-PAWS can maintain the same level of security as PAWS 421 does, but further discussions will be needed. Some security aspects 422 of A-PAWS are discussed in Section 5. 424 7. IANA Considerations 426 This document may request new TCP option codepoint or other 427 resources. 429 8. References 430 8.1. Normative References 432 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 433 793, September 1981. 435 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 436 for High Performance", RFC 1323, May 1992. 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, March 1997. 441 8.2. Informative References 443 [I-D.scheffenegger-tcpm-timestamp-negotiation] 444 Scheffenegger, R., Kuehlewind, M., and B. Trammell, 445 "Additional negotiation in the TCP Timestamp Option field 446 during the TCP handshake", draft-scheffenegger-tcpm- 447 timestamp-negotiation-05 (work in progress), October 2012. 449 [MALLMAN99] 450 Allman, M. and V. Paxson, "On Estimating End-to-End 451 Network Path Properties", Proceedings of the ACM SIGCOMM , 452 September 1999. 454 [QIAN11] Qian, L. and B. Carpenter, "A Flow-Based Performance 455 Analysis of TCP and TCP Applications", 3rd International 456 Conference on Computer and Network Technology (ICCNT 2011) 457 , February 2011. 459 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 460 Selective Acknowledgment Options", RFC 2018, October 1996. 462 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 463 Authentication Option", RFC 5925, June 2010. 465 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 466 "TCP Extensions for Multipath Operation with Multiple 467 Addresses", RFC 6824, January 2013. 469 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 470 6994, August 2013. 472 [SILBERSACK05] 473 Silbersack, M., "Improving TCP/IP security through 474 randomization without sacrificing interoperability.", 475 EuroBSDCon 2005 , November 2005. 477 Author's Address 479 Yoshifumi Nishida 480 GE Global Research 481 2623 Camino Ramon 482 San Ramon, CA 94583 483 USA 485 Email: nishida@wide.ad.jp