idnits 2.17.1 draft-ietf-tcpm-tcp-auth-opt-10.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2385, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 921 has weird spacing: '...fic_key r-I...' == Line 923 has weird spacing: '...fic_key r-IP ...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 31, 2010) is 5193 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-09 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'Le09') ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3517 (Obsoleted by RFC 6675) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-05) exists of draft-ietf-tcpm-tcpmss-02 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-05 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-10 -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-05) exists of draft-touch-tcp-ao-nat-01 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TCPM WG J. Touch 2 Internet Draft USC/ISI 3 Obsoletes: 2385 A. Mankin 4 Intended status: Proposed Standard Johns Hopkins Univ. 5 Expires: July 2010 R. Bonica 6 Juniper Networks 7 January 31, 2010 9 The TCP Authentication Option 10 draft-ietf-tcpm-tcp-auth-opt-10.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 This document may contain material from IETF Documents or IETF 18 Contributions published or made publicly available before November 19 10, 2008. The person(s) controlling the copyright in some of this 20 material may not have granted the IETF Trust the right to allow 21 modifications of such material outside the IETF Standards Process. 22 Without obtaining an adequate license from the person(s) controlling 23 the copyright in such materials, this document may not be modified 24 outside the IETF Standards Process, and derivative works of it may 25 not be created outside the IETF Standards Process, except to format 26 it for publication as an RFC or to translate it into languages other 27 than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on July 31, 2010. 47 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Abstract 64 This document specifies the TCP Authentication Option (TCP-AO), which 65 obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO 66 specifies the use of stronger Message Authentication Codes (MACs), 67 protects against replays even for long-lived TCP connections, and 68 provides more details on the association of security with TCP 69 connections than TCP MD5. TCP-AO is compatible with either static 70 master key tuple (MKT) configuration or an external, out-of-band MKT 71 management mechanism; in either case, TCP-AO also protects 72 connections when using the same MKT across repeated instances of a 73 connection, using traffic keys derived from the MKT, and coordinates 74 MKT changes between endpoints. The result is intended to support 75 current infrastructure uses of TCP MD5, such as to protect long-lived 76 connections (as used, e.g., in BGP and LDP), and to support a larger 77 set of MACs with minimal other system and operational changes. TCP-AO 78 uses a different option identifier than TCP MD5, even though TCP-AO 79 and TCP MD5 are never permitted to be used simultaneously. TCP-AO 80 supports IPv6, and is fully compatible with the proposed requirements 81 for the replacement of TCP MD5. 83 Table of Contents 85 1. Contributors...................................................3 86 2. Introduction...................................................4 87 2.1. Applicability Statement...................................5 88 2.2. Executive Summary.........................................5 89 3. Conventions used in this document..............................7 90 4. The TCP Authentication Option..................................7 91 4.1. Review of TCP MD5 Option..................................7 92 4.2. The TCP-AO Option.........................................8 94 5. TCP-AO Keys and Their Properties..............................10 95 5.1. Master Key Tuple.........................................10 96 5.2. Traffic Keys.............................................12 97 5.3. MKT Properties...........................................13 98 6. Per-Connection TCP-AO Parameters..............................14 99 7. Cryptographic Algorithms......................................15 100 7.1. MAC Algorithms...........................................15 101 7.2. Traffic Key Derivation Functions.........................18 102 7.3. Traffic Key Establishment and Duration Issues............22 103 7.3.1. MKT Reuse Across Socket Pairs.......................22 104 7.3.2. MKTs Use Within a Long-lived Connection.............23 105 8. Additional Security Mechanisms................................23 106 8.1. Coordinating Use of New MKTs.............................23 107 8.2. Preventing replay attacks within long-lived connections..24 108 9. TCP-AO Interaction with TCP...................................26 109 9.1. TCP User Interface.......................................27 110 9.2. TCP States and Transitions...............................28 111 9.3. TCP Segments.............................................28 112 9.4. Sending TCP Segments.....................................29 113 9.5. Receiving TCP Segments...................................30 114 9.6. Impact on TCP Header Size................................32 115 9.7. Connectionless Resets....................................33 116 9.8. ICMP Handling............................................34 117 10. Obsoleting TCP MD5 and Legacy Interactions...................34 118 11. Interactions with Middleboxes................................35 119 11.1. Interactions with non-NAT/NAPT Middleboxes..............35 120 11.2. Interactions with NAT/NAPT Devices......................36 121 12. Evaluation of Requirements Satisfaction......................36 122 13. Security Considerations......................................42 123 14. IANA Considerations..........................................43 124 15. References...................................................44 125 15.1. Normative References....................................44 126 15.2. Informative References..................................45 127 16. Acknowledgments..............................................47 129 1. Contributors 131 This document evolved as the result of collaboration of the TCP 132 Authentication Design team (tcp-auth-dt), whose members were 133 (alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy, 134 Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy 135 Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus 136 Westerlund. The text of this document is derived from a proposal by 137 Joe Touch and Allison Mankin [To06] (originally from June 2006), 138 which was both inspired by and intended as a counterproposal to the 139 revisions to TCP MD5 suggested in a document by Ron Bonica, Brian 140 Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07] 141 (originally from Sept. 2005) and in a document by Brian Weis [We05]. 143 Russ Housley suggested L4/application layer management of the master 144 key tuples. Steve Bellovin motivated the KeyID field. Eric Rescorla 145 suggested the use of ISNs in the traffic key computation and SNEs to 146 avoid replay attacks, and Brian Weis extended the computation to 147 incorporate the entire connection ID and provided the details of the 148 traffic key computation. Mark Allman, Wes Eddy, Lars Eggert, Ted 149 Faber, Russ Housley, Gregory Lebovitz, Tim Polk, Eric Rescorla, Joe 150 Touch, and Brian Weis developed the master key coordination 151 mechanism. 153 2. Introduction 155 The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates 156 TCP segments, including the TCP IPv4 pseudoheader, TCP header, and 157 TCP data. It was developed to protect BGP sessions from spoofed TCP 158 segments which could affect BGP data or the robustness of the TCP 159 connection itself [RFC2385][RFC4953]. 161 There have been many recent concerns about TCP MD5. Its use of a 162 simple keyed hash for authentication is problematic because there 163 have been escalating attacks on the algorithm itself [Wa05]. TCP MD5 164 also lacks both key management and algorithm agility. This document 165 adds the latter, and provides a simple key coordination mechanism 166 giving the ability to move from one key to another within the same 167 connection. It does not however provide for complete cryptographic 168 key management to be handled in-band of TCP, because TCP SYN segments 169 lack sufficient remaining space to handle such a negotiation (see 170 Section 9.6). This document obsoletes the TCP MD5 option with a more 171 general TCP Authentication Option (TCP-AO), to support the use of 172 other, stronger hash functions, provide replay protection for long- 173 lived connections and across repeated instances of a single 174 connection, coordinate key changes between endpoints, and to provide 175 a more structured recommendation on external key management. The 176 result is compatible with IPv6, and is fully compatible with proposed 177 requirements for a replacement for TCP MD5 [Be07]. 179 TCP-AO obsoletes TCP MD5, although a particular implementation may 180 support both mechanisms for backward compatibility. For a given 181 connection, only one can be in use. TCP MD5-protected connections 182 cannot be migrated to TCP-AO because TCP MD5 does not support any 183 changes to a connection's security algorithm once established. 185 2.1. Applicability Statement 187 TCP-AO is intended to support current uses of TCP MD5, such as to 188 protect long-lived connections for routing protocols, such as BGP and 189 LDP. It is also intended to provide similar protection to any long- 190 lived TCP connection, as might be used between proxy caches, e.g., 191 and is not designed solely or primarily for routing protocol uses. 193 TCP-AO is intended to replace (and thus obsolete) the use of TCP MD5. 194 TCP-AO enhances the capabilities of TCP MD5 as summarized in Section 195 2.2. 197 TCP-AO not intended to replace the use of the IPsec suite (IPsec and 198 IKE) to protect TCP connections [RFC4301][RFC4306]. Specific 199 differences are noted in Section 2.2. In fact, we recommend the use 200 of IPsec and IKE, especially where IKE's level of existing support 201 for parameter negotiation, session key negotiation, or rekeying are 202 desired. TCP-AO is intended for use only where the IPsec suite would 203 not be feasible, e.g., as has been suggested is the case to support 204 some routing protocols [RFC4953], or in cases where keys need to be 205 tightly coordinated with individual transport sessions [Be07]. 207 TCP-AO is not intended to replace the use of Transport Layer Security 208 (TLS) [RFC5246], sBGP or soBGP [Le09], or any other mechanisms that 209 protect only the TCP data stream. TCP-AO protects the transport 210 layer, preventing attacks from disabling the TCP connection itself 211 [RFC4953]. Data stream mechanisms protect only the contents of the 212 TCP segments, and can be disrupted when the connection is affected. 213 Some of these data protection protocols - notably TLS - offer a 214 richer set of key management and authentication mechanisms than TCP- 215 AO, and thus protect the data stream in a different way. TCP-AO may 216 be used together with these data stream protections to complement 217 each others' strengths. 219 2.2. Executive Summary 221 This document replaces TCP MD5 as follows [RFC2385]: 223 o TCP-AO uses a separate option Kind for TCP-AO (TBD-IANA-KIND). 225 o TCP-AO allows TCP MD5 to continue to be used concurrently for 226 legacy connections. 228 o TCP-AO replaces MD5's single MAC algorithm with MACs specified in 229 a separate document and can be extended to include other MACs. 231 o TCP-AO allows rekeying during a TCP connection, assuming that an 232 out-of-band protocol or manual mechanism provides the new keys. 233 The option includes a 'key ID' which allows the efficient 234 concurrent use of multiple keys, and a key coordination mechanism 235 using a 'receive next key ID' manages the key change within a 236 connection. Note that TCP MD5 does not preclude rekeying during a 237 connection, but does not require its support either. Further, 238 TCP-AO supports key changes with zero segment loss, whereas key 239 changes in TCP MD5 can lose segments in transit during the 240 changeover or require trying multiple keys on each received 241 segment during key use overlap because it lacks an explicit key 242 ID. Although TCP recovers lost segments through retransmission, 243 loss can have a substantial impact on performance. 245 o TCP-AO provides automatic replay protection for long-lived 246 connections using sequence number extensions. 248 o TCP-AO ensures per-connection traffic keys as unique as the TCP 249 connection itself, using TCP's initial sequence numbers (ISNs) for 250 differentiation, even when static master key tuples are used 251 across repeated instances of connections on a single socket pair. 253 o TCP-AO specifies the details of how this option interacts with 254 TCP's states, event processing, and user interface. 256 o The TCP-AO option is 2 bytes shorter than TCP MD5 (16 bytes 257 overall, rather than 18) in the initially specified default case 258 (using a 96-bit MAC). 260 This document differs from an IPsec/IKE solution in that TCP-AO as 261 follows [RFC4301][RFC4306]: 263 o TCP-AO does not support dynamic parameter negotiation. 265 o TCP-AO uses TCP's socket pair (source address, destination 266 address, source port, destination port) as a security parameter 267 index, rather than using a separate field as an index (IPsec's 268 SPI). 270 o TCP-AO forces a change of computed MACs when a connection 271 restarts, even when reusing a TCP socket pair (IP addresses and 272 port numbers) [Be07]. 274 o TCP-AO does not support encryption. 276 o TCP-AO does not authenticate ICMP messages (some ICMP messages may 277 be authenticated when using IPsec, depending on the 278 configuration). 280 3. Conventions used in this document 282 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 283 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 284 document are to be interpreted as described in RFC-2119 [RFC2119]. 286 In this document, these words will appear with that interpretation 287 only when in ALL CAPS. Lower case uses of these words are not to be 288 interpreted as carrying RFC-2119 significance. 290 In this document, the characters ">>" proceeding an indented line(s) 291 indicates a compliance requirement statement using the key words 292 listed above. This convention aids reviewers in quickly identifying 293 or finding the explicit compliance requirements of this RFC. 295 4. The TCP Authentication Option 297 The TCP Authentication Option (TCP-AO) uses a TCP option Kind value 298 of TBD-IANA-KIND. 300 4.1. Review of TCP MD5 Option 302 For review, the TCP MD5 option is shown in Figure 1. 304 +---------+---------+-------------------+ 305 | Kind=19 |Length=18| MD5 digest... | 306 +---------+---------+-------------------+ 307 | ...digest (con't)... | 308 +---------------------------------------+ 309 | ... | 310 +---------------------------------------+ 311 | ... | 312 +-------------------+-------------------+ 313 | ...digest (con't) | 314 +-------------------+ 316 Figure 1 The TCP MD5 Option [RFC2385] 318 In the TCP MD5 option, the length is fixed, and the MD5 digest 319 occupies 16 bytes following the Kind and Length fields (each one 320 byte), using the full MD5 digest of 128 bits [RFC1321]. 322 The TCP MD5 option specifies the use of the MD5 digest calculation 323 over the following values in the following order: 325 1. The IP pseudoheader (IP source and destination addresses, protocol 326 number, and segment length). 328 2. The TCP header excluding options and checksum. 330 3. The TCP data payload. 332 4. A key. 334 4.2. The TCP-AO Option 336 The new TCP-AO option provides a superset of the capabilities of TCP 337 MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new 338 Kind field, and similar Length field to TCP MD5, a KeyID field, and a 339 RNextKeyID field as shown in Figure 2. 341 +------------+------------+------------+------------+ 342 | Kind | Length | KeyID | RNextKeyID | 343 +------------+------------+------------+------------+ 344 | MAC ... 345 +-----------------------------------... 347 ...-----------------+ 348 ... MAC (con't) | 349 ...-----------------+ 351 Figure 2 The TCP-AO Option 353 The TCP-AO defines the fields as follows: 355 o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP- 356 AO uses a new Kind value of TBD-IANA-KIND. 358 >> An endpoint MUST NOT use TCP-AO for the same connection in 359 which TCP MD5 is used. When both options appear, TCP MUST silently 360 discard the segment. 362 >> A single TCP segment MUST NOT have more than one TCP-AO option. 363 When multiple TCP-AO options appear, TCP MUST discard the segment. 365 o Length: An unsigned 1-byte field indicating the length of the TCP- 366 AO option in bytes, including the Kind, Length, KeyID, RNextKeyID, 367 and MAC fields. 369 >> The Length value MUST be greater than or equal to 4. When the 370 Length value is less than 4, TCP MUST discard the segment. 372 >> The Length value MUST be consistent with the TCP header length; 373 this is a consistency check and avoids overrun/underrun abuse. 374 When the Length value is invalid, TCP MUST discard the segment. 376 Values of 4 and other small values larger than 4 (e.g., indicating 377 MAC fields of very short length) are of dubious utility but are 378 not specifically prohibited. 380 o KeyID: An unsigned 1-byte field indicating the MKT used to 381 generate the traffic keys which were used to generate the MAC that 382 authenticates this segment. 384 It supports efficient key changes during a connection and/or to 385 help with key coordination during connection establishment, to be 386 discussed further in Section 8.1. Note that the KeyID has no 387 cryptographic properties - it need not be random, nor are there 388 any reserved values. 390 >> KeyID values MAY be the same in both directions of a 391 connection, but do not have to be and there is no special meaning 392 when they are. 394 o RNextKeyID: An unsigned 1-byte field indicating the MKT that the 395 sender is ready use to receive authenticated segments, i.e., the 396 desired 'receive next' keyID. 398 It supports efficient key change coordination, to be discussed 399 further in Section 8.1. Note that the RNextKeyID has no 400 cryptographic properties - it need not be random, nor are there 401 any reserved values. 403 o MAC: Message Authentication Code. Its contents are determined by 404 the particulars of the security association. Typical MACs are 96- 405 128 bits (12-16 bytes), but any length that fits in the header of 406 the segment being authenticated is allowed. The MAC computation is 407 described further in Section 7.1. 409 >> Required support for TCP-AO MACs are defined in [Le09]; other 410 MACs MAY be supported. 412 The TCP-AO option fields do not indicate the MAC algorithm either 413 implicitly (as with TCP MD5) or explicitly. The particular algorithm 414 used is considered part of the configuration state of the 415 connection's security and is managed separately (see Section 5). 417 Please note that the use of TCP-AO does not affect TCP's advertised 418 maximum segment size (MSS), as is the case for all TCP options 419 [Bo09]. 421 The remainder of this document explains how the TCP-AO option is 422 handled and its relationship to TCP. 424 5. TCP-AO Keys and Their Properties 426 TCP-AO relies on two sets of keys to authenticate incoming and 427 outgoing segments: master key tuples (MKTs) and traffic keys. MKTs 428 are used to derive unique traffic keys, and include the keying 429 material used to generate those traffic keys, as well as indicating 430 the associated parameters under which traffic keys are used. Such 431 parameters include whether TCP options are authenticated, and 432 indicators of the algorithms used for traffic key derivation and MAC 433 calculation. Traffic keys are the keying material used to compute the 434 MAC of individual TCP segments. 436 5.1. Master Key Tuple 438 A Master Key Tuple (MKT) describes TCP-AO properties to be associated 439 with one or more connections. It is composed of the following: 441 o TCP connection identifier. A TCP socket pair, i.e., a local IP 442 address, a remote IP address, a TCP local port, and a TCP remote 443 port. Values can be partially specified using ranges (e.g., 2-30), 444 masks (e.g., 0xF0), wildcards (e.g., "*"), or any other suitable 445 indication. 447 o TCP option flag. This flag indicates whether TCP options other 448 than TCP-AO are included in the MAC calculation. When options are 449 included, the content of all options, in the order present, are 450 included in the MAC, with TCP-AO's MAC field zeroed out. When the 451 options are not included, all options other than TCP-AO are 452 excluded from all MAC calculations (skipped over, not zeroed). 453 Note that TCP-AO, with its MAC field zeroed out, is always 454 included in the MAC calculation, regardless of the setting of this 455 flag; this protects the indication of the MAC length as well as 456 the key ID fields (KeyID, RNextKeyID). The option flag applies to 457 TCP options in both directions (incoming and outgoing segments). 459 o IDs. The values used in the KeyID or RNextKeyID of a TCP-AO 460 option; used to differentiate MKTs in concurrent use (KeyID), as 461 well as to indicate when MKTs are ready for use in the opposite 462 direction (RNextKeyID). 464 Each MKT has two IDs - a SendID and a RecvID. The SendID is 465 inserted as the KeyID of the TCP-OP option of outgoing segments, 466 and the RecvID is matched against the KeyID of the TCP-AO option 467 of incoming segments. These and other uses of these two IDs are 468 described further in Section 9.4 and 9.5. 470 >> MKT IDs MUST support any value, 0-255 inclusive. There are no 471 reserved ID values. 473 ID values are assigned arbitrarily. They can be assigned in 474 sequence, or based on any method mutually agreed by the connection 475 endpoints (e.g., using an external MKT management mechanism). 477 >> IDs MUST NOT be assumed to be randomly assigned. 479 o Master key. A byte sequence used for generating traffic keys, this 480 may be derived from a separate shared key by an external protocol 481 over a separate channel. This sequence is used in the traffic key 482 generation algorithm described in Section 7.2. 484 Implementations are advised to keep master key values in a 485 private, protected area of memory or other storage. 487 o Key Derivation Function (KDF). Indicates the key derivation 488 function and its parameters, as used to generate traffic keys from 489 master keys. Explained further in Section 7.1 of this document and 490 specified in detail in [Le09]. 492 o Message Authentication Code (MAC) algorithm. Indicates the MAC 493 algorithm and its parameters as used for this connection, 494 explained further in Section 7.1 of this document and specified in 495 detail in [Le09]. 497 >> Components of a MKT MUST NOT change during a connection. 499 MKT component values cannot change during a connection because TCP 500 state is coordinated during connection establishment. TCP lacks a 501 handshake for modifying that state after a connection has been 502 established. 504 >> The set of MKTs MAY change during a connection. 506 MKT parameters are not changed. Instead, new MKTs can be installed, 507 and a connection can change which MKT it uses. 509 >> The IDs of MKTs MUST NOT overlap where their TCP connection 510 identifiers overlap. 512 This document does not address how MKTs are created by users or 513 processes. It is presumed that a MKT affecting a particular 514 connection cannot be destroyed during an active connection - or, 515 equivalently, that its parameters are copied to an area local to the 516 connection (i.e., instantiated) and so changes would affect only new 517 connections. The MKTs can be managed by a separate application 518 protocol. 520 5.2. Traffic Keys 522 A traffic key is a key derived from the MKT and the local and remote 523 IP address pairs and TCP port numbers, and, for established 524 connections, the TCP Initial Sequence Numbers (ISNs) in each 525 direction. Segments exchanged before a connection is established use 526 the same information, substituting zero for unknown values (e.g., 527 ISNs not yet coordinated). 529 A single MKT can be used to derive any of four different traffic 530 keys: 532 o Send_SYN_traffic_key 534 o Receive_SYN_traffic_key 536 o Send_other_traffic_key 538 o Receive_other_traffic_key 540 Note that the keys are unidirectional. A given connection typically 541 uses only three of these keys, because only one of the SYN keys is 542 typically used. All four are used only when a connection goes through 543 'simultaneous open' [RFC793]. 545 The relationship between MKTs and traffic keys is shown in Figure 546 Figure 3. Traffic keys are indicated with a "*". Note that every MKT 547 can be used to derive any of the four traffic keys, but only the keys 548 actually needed to handle the segments of a connection need to be 549 computed. Section 7.2 provides further details on how traffic keys 550 are derived. 552 MKT-A MKT-B 553 +---------------------+ +------------------------+ 554 | SendID = 1 | | SendID = 5 | 555 | RecvID = 2 | | RecvID = 6 | 556 | MAC = HMAC-SHA1 | | MAC = AES-CMAC | 557 | KDF = KDF-HMAC-SHA1 | | KDF = KDF-AES-128-CMAC | 558 +---------------------+ +------------------------+ 559 | | 560 +----------+----------+ | 561 | | | 562 v v v 563 Connection 1 Connection 2 Connection 3 564 +------------------+ +------------------+ +------------------+ 565 | * Send_SYN_key | | * Send_SYN_key | | * Send_SYN_key | 566 | * Recv_SYN_key | | * Recv_SYN_key | | * Recv_SYN_key | 567 | * Send_Other_key | | * Send_Other_key | | * Send_Other_key | 568 | * Send_Other_key | | * Send_Other_key | | * Send_Other_key | 569 +------------------+ +------------------+ +------------------+ 571 Figure 3 Relationship between MKTs and traffic keys 573 5.3. MKT Properties 575 TCP-AO requires that every protected TCP segment match exactly one 576 MKT. When an outgoing segment matches an MKT, TCP-AO is used. When no 577 match occurs, TCP-AO is not used. Multiple MKTs may match a single 578 outgoing segment, e.g., when MKTs are being changed. Those MKTs 579 cannot have conflicting IDs (as noted elsewhere), and some mechanism 580 must determine which MKT to use for each given outgoing segment. 582 >> An outgoing TCP segment MUST match at most one desired MKT, 583 indicated by the segment's socket pair. The segment MAY match 584 multiple MKTs, provided that exactly one MKT is indicated as desired. 585 Other information in the segment MAY be used to determine the desired 586 MKT when multiple MKTs match; such information MUST NOT include 587 values in any TCP option fields. 589 We recommend that the mechanism used to select from among multiple 590 MKTs use only information that TCP-AO would authenticate. Because 591 MKTs may indicate that non-TCP-AO options are ignored in the MAC 592 calculation, we recommend that TCP options should not be used to 593 determine MKTs. 595 >> An incoming TCP segment containing the TCP-AO option MUST match at 596 exactly one MKT, indicated solely by the segment's socket pair and 597 its TCP-AO KeyID. 599 Incoming segments include an indicator in the TCP-AO option to select 600 from among multiple matching MKTs - the KeyID field. TCP-AO requires 601 that the KeyID alone be used to differentiate multiple matching MKTs, 602 so that MKT changes can be coordinated using the TCP-AO key change 603 coordination mechanism. 605 >> When an outgoing TCP segment matches no MKTs, TCP-AO is not used. 607 TCP-AO is always used when outgoing segments match an MKT, and is not 608 used otherwise. 610 6. Per-Connection TCP-AO Parameters 612 TCP-AO uses a small number of parameters associated with each 613 connection that uses the TCP-AO option, once instantiated. These 614 values can be stored in the Transport Control Block (TCP) [RFC793]. 615 These values are explained in subsequent sections of this document as 616 noted; they include: 618 1. Current_key - the MKT currently used to authenticate outgoing 619 segments, whose SendID is inserted in outgoing segments as KeyID 620 (see Section 9.4, step 5). Incoming segments are authenticated 621 using the MKT corresponding to the segment and the KeyID in its 622 TCP-AO header (see Section 9.5, step 5), as matched against the 623 MKT TCP connection identifier and the MKT RecvID. There is only 624 one current_key at any given time on a particular connection. 626 >> Every TCP connection in a non-IDLE state MUST have at most one 627 current_key specified. 629 2. Rnext_key -the MKT currently preferred for incoming (received) 630 segments, whose RecvID is inserted in outgoing segments as 631 RNextKeyID (see Section 9.5, step 5). 633 >> Each TCP connection in a non-IDLE state MUST have at most one 634 rnext_key specified. 636 3. A pair of Sequence Numbers Extensions (SNEs). SNEs are used to 637 prevent replay attacks, as described in Section 8.2. Each SNE is 638 initialized to zero upon connection establishment. Its use in the 639 MAC calculation is described in Section 7.1. 641 4. One or more MKTs. These are the MKTs that match this connection's 642 socket pair. 644 MKTs are used, together with other parameters of a connection, to 645 create traffic keys unique to each connection, as described in 646 Section 7.2. These traffic keys can be cached after computation, and 647 can be stored in the TCB with the corresponding MKT information. They 648 can be considered part of the per-connection parameters. 650 7. Cryptographic Algorithms 652 TCP-AO also uses cryptographic algorithms to compute the MAC (Message 653 Authentication Code) used to authenticate a segment and its headers; 654 these are called MAC algorithms and are specified in a separate 655 document to facilitate updating the algorithm requirements 656 independently from the protocol [Le09]. TCP-AO also uses 657 cryptographic algorithms to convert MKTs, which can be shared across 658 connections, into unique traffic keys for each connection. These are 659 called Key Derivation Functions (KDFs), and are specified [Le09]. 660 This section describes how these algorithms are used by TCP-AO. 662 7.1. MAC Algorithms 664 MAC algorithms take a variable-length input and a key and output a 665 fixed-length number. This number is used to determine whether the 666 input comes from a source with that same key, and whether the input 667 has been tampered in transit. MACs for TCP-AO have the following 668 interface: 670 MAC = MAC_alg(traffic_key, message) 672 INPUT: MAC_alg, traffic_key, message 674 OUTPUT: MAC 676 where: 678 o MAC_alg - the specific MAC algorithm used for this computation. 679 The MAC algorithm specifies the output length, so no separate 680 output length parameter is required. This is specified as 681 described in [Le09]. 683 o Traffic_key - traffic key used for this computation. This is 684 computed from the connection's current MKT as described in Section 685 7.2. 687 o Message - input data over which the MAC is computed. In TCP-AO, 688 this is the TCP segment prepended by the IP pseudoheader and TCP 689 header options, as described in Section 7.1. 691 o MAC - the fixed-length output of the MAC algorithm, given the 692 parameters provided. 694 At the time of this writing, the algorithms' definitions for use in 695 TCP-AO, as described in [Le09] are each truncated to 96 bits. Though 696 the algorithms each output a larger MAC, 96 bits provides a 697 reasonable tradeoff between security and message size, for fitting 698 into the TCP-AO header. Though could change in the future, so TCP-AO 699 header sizes should not be assumed as fixed length. 701 The MAC algorithm employed for the MAC computation on a connection is 702 done so by definition in the MKT, per [Le09]'s definitions. 704 The mandatory-to-implement MAC algorithms for use with TCP-AO are 705 described in a separate RFC [Le09]. This allows the TCP-AO 706 specification to proceed along the standards track even if changes 707 are needed to its associated algorithms and their labels (as might be 708 used in a user interface or automated MKT management protocol) as a 709 result of the ever evolving world of cryptography. 711 >> Additional algorithms, beyond those mandated for TCP-AO, MAY be 712 supported. 714 The data input to the MAC is the following fields in the following 715 sequence, interpreted in network-standard byte order: 717 1. The sequence number extension (SNE), in network-standard byte 718 order, as follows (described further in Section 8.2): 720 +--------+--------+--------+--------+ 721 | SNE | 722 +--------+--------+--------+--------+ 724 Figure 4 Sequence number extension 726 The SNE for transmitted segments is maintained locally in the 727 SND.SNE value; for received segments, a local RCV.SNE value is 728 used. The details of how these values are maintained and used is 729 described in Sections 8.2, 9.4, and 9.5. 731 2. The IP pseudoheader: IP source and destination addresses, protocol 732 number and segment length, all in network byte order, prepended to 733 the TCP header below. The IP pseudoheader is exactly as used for 734 the TCP checksum in either IPv4 or IPv6 [RFC793][RFC2460]: 736 +--------+--------+--------+--------+ 737 | Source Address | 738 +--------+--------+--------+--------+ 739 | Destination Address | 740 +--------+--------+--------+--------+ 741 | zero | Proto | TCP Length | 742 +--------+--------+--------+--------+ 744 Figure 5 TCP IPv4 pseudoheader [RFC793] 746 +--------+--------+--------+--------+ 747 | | 748 + + 749 | | 750 + Source Address + 751 | | 752 + + 753 | | 754 + + 755 +--------+--------+--------+--------+ 756 | | 757 + + 758 | | 759 + Destination Address + 760 | | 761 + + 762 | | 763 +--------+--------+--------+--------+ 764 | Upper-Layer Payload Length | 765 +--------+--------+--------+--------+ 766 | zero | Next Header | 767 +--------+--------+--------+--------+ 769 Figure 6 TCP IPv6 pseudoheader [RFC2460] 771 3. The TCP header, by default including options, and where the TCP 772 checksum and TCP-AO MAC fields are set to zero, all in network 773 byte order. 775 The TCP option flag of the MKT indicates whether the TCP options 776 are included in the MAC. When included, only the TCP-AO MAC field 777 is zeroed. 779 When TCP options are not included, all TCP options except for TCP- 780 AO are omitted from MAC processing. Again, the TCP-AO MAC field is 781 zeroed for the MAC processing. 783 4. The TCP data, i.e., the payload of the TCP segment. 785 Note that the traffic key is not included as part of the data; the 786 MAC algorithm indicates how to use the traffic key, e.g., as HMACs do 787 [RFC2104][RFC2403]. The traffic key is derived from the current MKT 788 as described in Sections 7.2. 790 7.2. Traffic Key Derivation Functions 792 TCP-AO's traffic keys are derived from the MKTs using Key Derivation 793 Functions (KDFs). The KDFs used in TCP-AO have the following 794 interface: 796 traffic_key = KDF_alg(master_key, context, output_length) 798 INPUT: KDF_alg, master_key, context, output_length 800 OUTPUT: traffic_key 802 where: 804 o KDF_alg - the specific key derivation function (KDF) that is the 805 basic building block used in constructing the traffic key, as 806 indicated in the MKT. This is specified as described in [Le09]. 808 o Master_key - The master_key string, as will be stored into the 809 associated MKT. 811 o Context - The context used as input in constructing the 812 traffic_key, as specified in [Le09]. The specific way this context 813 is used, in conjunction with other information, to create the raw 814 input to the KDF is also explained further in [Le09]. 816 o Output_length - The desired output length of the KDF, i.e., the 817 length to which the KDF's output will be truncated. This is 818 specified as described in [Le09]. 820 o Traffic_key - The desired output of the KDF, of length 821 output_length, to be used as input to the MAC algorithm, as 822 described in Section 7.1. 824 The context used as input to the KDF combines TCP socket pair with 825 the endpoint initial sequence numbers (ISNs) of a connection. This 826 data is unique to each TCP connection instance, which enables TCP-AO 827 to generate unique traffic keys for that connection, even from a MKT 828 used across many different connections or across repeated connections 829 that share a socket pair. Unique traffic keys are generated without 830 relying on external key management properties. The KDF context is 831 defined in Figure 7 and Figure 8. 833 +--------+--------+--------+--------+ 834 | Source Address | 835 +--------+--------+--------+--------+ 836 | Destination Address | 837 +--------+--------+--------+--------+ 838 | Source Port | Dest. Port | 839 +--------+--------+--------+--------+ 840 | Source ISN | 841 +--------+--------+--------+--------+ 842 | Dest. ISN | 843 +--------+--------+--------+--------+ 845 Figure 7 KDF Context for an IPv4 connection 846 +--------+--------+--------+--------+ 847 | | 848 + + 849 | | 850 + Source Address + 851 | | 852 + + 853 | | 854 + + 855 +--------+--------+--------+--------+ 856 | | 857 + + 858 | | 859 + Destination Address + 860 | | 861 + + 862 | | 863 +--------+--------+--------+--------+ 864 | Source Port | Dest. Port | 865 +--------+--------+--------+--------+ 866 | Source ISN | 867 +--------+--------+--------+--------+ 868 | Dest. ISN | 869 +--------+--------+--------+--------+ 871 Figure 8 KDF Context for an IPv6 connection 873 Traffic keys are directional, so "source" and "destination" are 874 interpreted differently for incoming and outgoing segments. For 875 incoming segments, source is the remote side, whereas for outgoing 876 segments source is the local side. This further ensures that 877 connection keys generated for each direction are unique. 879 For SYN segments (segments with the SYN set, but the ACK not set), 880 the destination ISN is not known. For these segments, the connection 881 key is computed using the context shown above, in which the 882 Destination ISN value is zero. For all other segments, the ISN pair 883 is used when known. If the ISN pair is not known, e.g., when sending 884 a RST after a reboot, the segment should be sent without 885 authentication; if authentication was required, the segment cannot 886 have been MAC'd properly anyway and would have been dropped on 887 receipt. 889 >> TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination 890 ISN of zero (whether sent or received); all other segments use the 891 known ISN pair. 893 Overall, this means that each connection will use up to four distinct 894 traffic keys for each MKT: 896 o Send_SYN_traffic_key - the traffic key used to authenticate 897 outgoing SYNs. The source ISN known (the TCP connection's local 898 ISN), and the destination (remote) ISN is unknown (and so the 899 value 0 is used). 901 o Receive_SYN_traffic_key - the traffic key used to authenticate 902 incoming SYNs. The source ISN known (the TCP connection's remote 903 ISN), and the destination (remote) ISN is unknown (and so the 904 value 0 is used). 906 o Send_other_traffic_key - the traffic key used to authenticate all 907 other outgoing TCP segments. 909 o Receive_other_traffic_key - the traffic key used to authenticate 910 all other incoming TCP segments. 912 The following table describes how each of these traffic keys is 913 computed, where the TCP-AO algorithms refer to source (S) and 914 destination (D) values of the IP address, TCP port, and ISN, and each 915 segment (incoming or outgoing) has a values that refer to the local 916 side of the connection (l) and remote side (r): 918 S-IP S-port S-ISN D-IP D-port D-ISN 919 ---------------------------------------------------------------- 920 Send_SYN_traffic_key l-IP l-port l-ISN r-IP r-port 0 921 Receive_SYN_traffic_key r-IP r-port r-ISN l-IP l-port 0 922 Send_other_traffic_key l-IP l-port l-ISN r-IP r-port r-ISN 923 Receive_other_traffic_key r-IP r-port r-ISN l-IP l-port l-ISN 925 The use of both ISNs in the traffic key computations ensures that 926 segments cannot be replayed across repeated connections reusing the 927 same socket, their 32-bit space avoids repeated use except under 928 reboot, and reuse assumes both sides repeat their use on the same 929 connection). We do expect that: 931 >> Endpoints should select ISNs pseudorandomly, e.g., as in [RFC1948] 933 A SYN is authenticated using a destination ISN of zero (whether sent 934 or received), and all other segments would be authenticated using the 935 ISN pair for the connection. There are other cases in which the 936 destination ISN is not known, but segments are emitted, such as after 937 an endpoint reboots, when is possible that the two endpoints would 938 not have enough information to authenticate segments. This is 939 addressed further in Section 9.7. 941 7.3. Traffic Key Establishment and Duration Issues 943 The TCP-AO option does not provide a mechanism for traffic key 944 negotiation or parameter negotiation (MAC algorithm, length, or use 945 of the TCP-AO option), or for coordinating rekeying during a 946 connection. We assume out-of-band mechanisms for MKT establishment, 947 parameter negotiation, and rekeying. This separation of MKT use from 948 MKT management is similar to that in the IPsec security suite 949 [RFC4301][RFC4306]. 951 We encourage users of TCP-AO to apply known techniques for generating 952 appropriate MKTs, including the use of reasonable master key lengths, 953 limited traffic key sharing, and limiting the duration of MKT use 954 [RFC3562]. This also includes the use of per-connection nonces, as 955 suggested in Section 7.2. 957 TCP-AO supports rekeying in which new MKTs are negotiated and 958 coordinated out-of-band, either via a protocol or a manual procedure 959 [RFC4808]. New MKT use is coordinated using the out-of-band mechanism 960 to update both TCP endpoints. When only a single MKT is used at a 961 time, the temporary use of invalid MKTs could result in segments 962 being dropped; although TCP is already robust to such drops, TCP-AO 963 uses the KeyID field to avoid such drops. A given connection can have 964 multiple matching MKTs, where the KeyID field is used to identify the 965 MKT that corresponds to the traffic key used for a segment, to avoid 966 the need for expensive trial-and-error testing of MKTs in sequence. 968 TCP-AO provides an explicit MKT coordination mechanism, described in 969 Section 8.1. Such a mechanism is useful when new MKTs are installed, 970 or when MKTs are changed, to determine when to commence using 971 installed MKTs. 973 Users are advised to manage MKTs following the spirit of the advice 974 for key management when using TCP MD5 [RFC3562], notably to use 975 appropriate key lengths (12-24 bytes) and to avoid sharing MKTs among 976 multiple BGP peering arrangements. 978 7.3.1. MKT Reuse Across Socket Pairs 980 MKTs can be reused across different socket pairs within a host, or 981 across different instances of a socket pair within a host. In either 982 case, replay protection is maintained. 984 MKTs reused across different socket pairs cannot enable replay 985 attacks because the TCP socket pair is included in the MAC, as well 986 as in the generation of the traffic key. MKTs reused across repeated 987 instances of a given socket pair cannot enable replay attacks because 988 the connection ISNs are included in the traffic key generation 989 algorithm, and ISN pairs are unlikely to repeat over useful periods. 991 7.3.2. MKTs Use Within a Long-lived Connection 993 TCP-AO uses sequence number extensions (SNEs) to prevent replay 994 attacks within long-lived connections. Explicit MKT rollover, 995 accomplished by external means and indexed using the KeyID field, can 996 be used to change keying material for various reasons (e.g., 997 personnel turnover), but is not required to support long-lived 998 connections. 1000 8. Additional Security Mechanisms 1002 TCP-AO adds mechanisms to support efficient use, especially in 1003 environments where only manual keying is available. These include the 1004 previously described mechanisms for supporting multiple concurrent 1005 MKTs (via the KeyID field) and for generating unique per-connection 1006 traffic keys (via the KDF). This section describes additional 1007 mechanisms to coordinate MKT changes and to prevent replay attacks 1008 when a traffic key is not changed for long periods of time. 1010 8.1. Coordinating Use of New MKTs 1012 At any given time, a single TCP connection may have multiple MKTs 1013 specified for each segment direction (incoming, outgoing). TCP-AO 1014 provides a mechanism to indicate when a new MKT is ready, to allow 1015 the sender to commence use of that new MKT. This mechanism allows new 1016 MKT use to be coordinated, to avoid unnecessary loss due to sender 1017 authentication using a MKT not yet ready at the receiver. 1019 Note that this is intended as an optimization. Deciding when to start 1020 using a key is a performance issue. Deciding when to remove an MKT is 1021 a security issue. Invalid MKTs are expected to be removed. TCP-AO 1022 provides no mechanism to coordinate their removal, as we consider 1023 this a key management operation. 1025 New MKT use is coordinated through two ID fields in the header: 1027 o KeyID 1029 o RNextKeyID 1031 KeyID represents the outgoing MKT information used by the segment 1032 sender to create the segment's MAC (outgoing), and the corresponding 1033 incoming keying information used by the segment receiver to validate 1034 that MAC. It contains the SendID of the MKT in active use in that 1035 direction. 1037 RNextKeyID represents the preferred MKT information to be used for 1038 subsequent received segments ('receive next'). I.e., it is a way for 1039 the segment sender to indicate a ready incoming MKT for future 1040 segments it receives, so that the segment receiver can know when to 1041 switch MKTs (and thus their KeyIDs and associated traffic keys). It 1042 indicates the RecvID of the MKT desired to for incoming segments. 1044 There are two pointers kept by each side of a connection, as noted in 1045 the per-connection information (see Section 6): 1047 o Currently active outgoing MKT (Current_key) 1049 o Current preference for incoming MKT (rnext_key) 1051 Current_key indicates a MKT that is used to authenticate outgoing 1052 segments. Upon connection establishment, it points to the first MKT 1053 selected for use. 1055 Rnext_key points to an incoming MKT that is ready and preferred for 1056 use. Upon connection establishment, this points to the currently 1057 active incoming MKT. It can be changed when new MKTs are installed 1058 (e.g., either by automatic MKT management protocol operation or by 1059 user manual selection). 1061 Rnext_key is changed only by manual user intervention or MKT 1062 management protocol operation. It is not manipulated by TCP-AO. 1063 Current_key is updated by TCP-AO when processing received TCP 1064 segments as discussed in the segment processing description in 1065 Section 9.5. Note that the algorithm allows the current_key to change 1066 to a new MKT, then change back to a previously used MKT (known as 1067 "backing up"). This can occur during a MKT change when segments are 1068 received out of order, and is considered a feature of TCP-AO, because 1069 reordering does not result in drops. The only way to avoid reuse of 1070 previously used MKTs is to remove the MKT when it is no longer 1071 considered permitted. 1073 8.2. Preventing replay attacks within long-lived connections 1075 TCP uses a 32-bit sequence number which may, for long-lived 1076 connections, roll over and repeat. This could result in TCP segments 1077 being intentionally and legitimately replayed within a connection. 1078 TCP-AO prevents replay attacks, and thus requires a way to 1079 differentiate these legitimate replays from each other, and so it 1080 adds a 32-bit sequence number extension (SNE) for transmitted and 1081 received segments. 1083 The SNE extends TCP's sequence number so that segments within a 1084 single connection are always unique. When TCP's sequence number rolls 1085 over, there is a chance that a segment could be repeated in total; 1086 using an SNE differentiates even identical segments sent with 1087 identical sequence numbers at different times in a connection. TCP-AO 1088 emulates a 64-bit sequence number space by inferring when to 1089 increment the high-order 32-bit portion (the SNE) based on 1090 transitions in the low-order portion (the TCP sequence number). 1092 TCP-AO thus maintains SND.SNE for transmitted segments, and RCV.SNE 1093 for received segments, both initialized as zero when a connection 1094 begins. The intent of these SNEs is, together with TCP's 32-bit 1095 sequence numbers, to provide a 64-bit overall sequence number space. 1097 For transmitted segments SND.SNE can be implemented by extending 1098 TCP's sequence number to 64-bits; SND.SNE would be the top (high- 1099 order) 32 bits of that number. For received segments, TCP-AO needs to 1100 emulate the use of a 64-bit number space, and correctly infer the 1101 appropriate high-order 32-bits of that number as RCV.SNE from the 1102 received 32-bit sequence number and the current connection context. 1104 The implementation of SNEs is not specified in this document, but one 1105 possible way is described here that can be used for either RCV.SNE, 1106 SND.SNE, or both. 1108 Consider an implementation with two SNEs as required (SND.SNE, RCV. 1109 SNE), and additional variables as listed below, all initialized to 1110 zero, as well as a current TCP segment field (SEG.SEQ): 1112 o SND.PREV_SEQ, needed to detect rollover of SND.SEQ 1114 o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ 1116 o SND.SNE_FLAG, which indicates when to increment the SND.SNE 1118 o RCV.SNE_FLAG, which indicates when to increment the RCV.SNE 1120 When a segment is received, the following algorithm (in C-like 1121 pseudocode) computes the SNE used in the MAC; this is the "RCV" side, 1122 and an equivalent algorithm can be applied to the "SND" side: 1124 /* set the flag when the SEG.SEQ first rolls over */ 1125 if ((RCV.SNE_FLAG == 0) 1126 && (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) { 1127 RCV.SNE = RCV.SNE + 1; 1128 RCV.SNE_FLAG = 1; 1129 } 1130 /* decide which SNE to use after incremented */ 1131 if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) { 1132 SNE = RCV.SNE - 1; # use the pre-increment value 1133 } else { 1134 SNE = RCV.SNE; # use the current value 1135 } 1136 /* reset the flag in the *middle* of the window */ 1137 if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) { 1138 RCV.SNE_FLAG = 0; 1139 } 1140 /* save the current SEQ for the next time through the code */ 1141 RCV.PREV_SEQ = SEG.SEQ; 1143 In the above code, the first line when the sequence number first 1144 rolls over, i.e., when the new number is low (in the bottom half of 1145 the number space) and the old number is high (in the top half of the 1146 number space). The first time this happens, the SNE is incremented 1147 and a flag is set. 1149 If the flag is set and a high number is seen, it must be a reordered 1150 segment, so use the pre-increment SNE, otherwise use the current SNE. 1151 The flag will be cleared by the time the number rolls all the way 1152 around. 1154 The flag prevents the SNE from being incremented again until the flag 1155 is reset, which happens in the middle of the window (when the old 1156 number is in the bottom half and the new is in the top half). Because 1157 the receive window is never larger than half of the number space, it 1158 is impossible to both set and reset the flag at the same time - 1159 outstanding segments, regardless of reordering, cannot straddle both 1160 regions simultaneously. 1162 9. TCP-AO Interaction with TCP 1164 The following is a description of how TCP-AO affects various TCP 1165 states, segments, events, and interfaces. This description is 1166 intended to augment the description of TCP as provided in RFC-793, 1167 and its presentation mirrors that of RFC-793 as a result [RFC793]. 1169 9.1. TCP User Interface 1171 The TCP user interface supports active and passive OPEN, SEND, 1172 RECEIVE, CLOSE, STATUS and ABORT commands. TCP-AO does not alter this 1173 interface as it applies to TCP, but some commands or command 1174 sequences of the interface need to be modified to support TCP-AO. 1175 TCP-AO does not specify the details of how this is achieved. 1177 TCP-AO requires the TCP user interface be extended to allow the MKTs 1178 to be configured, as well as to allow an ongoing connection to manage 1179 which MKTs are active. The MKTs need to be configured prior to 1180 connection establishment, and the set of MKTs may change during a 1181 connection: 1183 >> TCP OPEN, or the sequence of commands that configure a connection 1184 to be in the active or passive OPEN state, MUST be augmented so that 1185 a MKT can be configured. 1187 >> A TCP-AO implmentation MUST allow the set of MKTs for ongoing TCP 1188 connections (i.e., not in the CLOSED state) to be modified. 1190 The MKTs associated with a connection needs to be available for 1191 confirmation; this includes the ability to read the MKTs: 1193 >> TCP STATUS SHOULD be augmented to allow the MKTs of a current or 1194 pending connection to be read (for confirmation). 1196 Senders may need to be able to determine when the outgoing MKT 1197 changes (KeyID) or when a new preferred MKT (RNextKeyID) is 1198 indicated; these changes immediately affect all subsequent outgoing 1199 segments: 1201 >> TCP SEND, or a sequence of commands resulting in a SEND, MUST be 1202 augmented so that the preferred outgoing MKT (Current_key) and/or the 1203 preferred incoming MKT rnext_key of a connection can be indicated. 1205 It may be useful to change the outgoing active MKT (Current_key) even 1206 when no data is being sent, which can be achieved by sending a zero- 1207 length buffer or by using a non-send interface (e.g., socket options 1208 in Unix), depending on the implementation. 1210 It is also useful to indicate recent segment KeyID and RNextKeyID 1211 values received; although there could be a number of such values, 1212 they are not expected to change quickly so any recent sample should 1213 be sufficient: 1215 >> TCP RECEIVE, or the sequence of commands resulting in a RECEIVE, 1216 MUST be augmented so that the KeyID and RNextKeyID of a recently 1217 received segment is available to the user out-of-band (e.g., as an 1218 additional parameter to RECEIVE, or via a STATUS call). 1220 9.2. TCP States and Transitions 1222 TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, 1223 FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and 1224 CLOSED. 1226 >> A MKT MAY be associated with any TCP state. 1228 9.3. TCP Segments 1230 TCP includes control (at least one of SYN, FIN, RST flags set) and 1231 data (none of SYN, FIN, or RST flags set) segments. Note that some 1232 control segments can include data (e.g., SYN). 1234 >> All TCP segments MUST be checked against the set of MKTs for 1235 matching TCP connection identifiers. 1237 >> TCP segments whose TCP-AO option does not validate MUST be 1238 silently discarded. 1240 >> A TCP-AO implementation MUST allow for configuration of the 1241 behavior of segments with the TCP-AO option but that do not match an 1242 MKT. The initial default of this configuration SHOULD be to silently 1243 accept such connections. If this is not the desired case, an MKT can 1244 be included to match such connections, or the connection can indicate 1245 that TCP-AO is required. Alternately, the configuration can be 1246 changed to discard segments with the AO option not matching an MKT. 1248 >> Silent discard events SHOULD be signaled to the user as a warning, 1249 and silent accept events MAY be signaled to the user as a warning. 1250 Both warnings, if available, MUST be accessible via the STATUS 1251 interface. Either signal MAY be asynchronous, but if so they MUST be 1252 rate-limited. Either signal MAY be logged; logging SHOULD allow rate- 1253 limiting as well. 1255 All TCP-AO processing occurs between the interface of TCP and IP; for 1256 incoming segments, this occurs after validation of the TCP checksum. 1257 For outgoing segments, this occurs before computation of the TCP 1258 checksum. 1260 Note that use of the TCP-AO option is not negotiated within TCP. It 1261 is the responsibility of the receiver to determine when TCP-AO is 1262 required via other means (e.g., out of band, manually or with an key 1263 management protocol) and to enforce that requirement. 1265 9.4. Sending TCP Segments 1267 The following procedure describes the modifications to TCP to support 1268 TCP-AO when a segment departs. 1270 >> Note that TCP-AO MUST be the last TCP option processed on outgoing 1271 segments, because its MAC calculation may include the values of other 1272 TCP options. 1274 1. Find the per-connection parameters for the segment: 1276 a. If the segment is a SYN, then this is the first segment of a 1277 new connection. Find the matching MKT for this segment based 1278 on the segment's socket pair. 1280 i. If there is no matching MKT, omit the TCP-AO option. 1281 Proceed with transmitting the segment. 1283 ii. If there is a matching MKT, then set the per-connection 1284 parameters as needed (see Section 6). Proceed with the 1285 step 2. 1287 b. If the segment is not a SYN, then determine whether TCP-AO is 1288 being used for the connection and use the MKT as indicated by 1289 the current_key value from the per-connection parameters (see 1290 Section 6) and proceed with the step 2. 1292 2. Using the per-connection parameters: 1294 a. Augment the TCP header with the TCP-AO, inserting the 1295 appropriate Length and KeyID based on the MKT indicated by 1296 current_key (using the current_key MKT's SendID as the TCP-AO 1297 KeyID). Update the TCP header length accordingly. 1299 b. Determine SND.SNE as described in Section 8.2. 1301 c. Determine the appropriate traffic key, i.e., as pointed to by 1302 current_key (as noted in Section 8.1, and as probably cached 1303 in the TCB). I.e., use the send_SYN_traffic_key for SYN 1304 segments, and the send_other_traffic_key for other segments. 1306 d. Determine the RNextKeyID as indicated by the rnext_key 1307 pointer, and insert it in the TCP-AO option (using the 1308 rnext_key MKT's RecvID as the TCP-AO KeyID) (as noted in 1309 Section 8.1). 1311 e. Compute the MAC using the MKT (and cached traffic key) and 1312 data from the segment as specified in Section 7.1. 1314 f. Insert the MAC in the TCP-AO MAC field. 1316 g. Proceed with transmitting the segment. 1318 9.5. Receiving TCP Segments 1320 The following procedure describes the modifications to TCP to support 1321 TCP-AO when a segment arrives. 1323 >> Note that TCP-AO MUST be the first TCP option processed on 1324 incoming segments, because its MAC calculation may include the values 1325 of other TCP options which could change during TCP option processing. 1326 This also protects the behavior of all other TCP options from the 1327 impact of spoofed segments or modified header information. 1329 >> Note that TCP-AO checks MUST be performed for all incoming SYNs to 1330 avoid accepting SYNs lacking the TCP-AO option where required. Other 1331 segments can cache whether TCP-AO is needed in the TCB. 1333 1. Find the per-connection parameters for the segment: 1335 a. If the segment is a SYN, then this is the first segment of a 1336 new connection. Find the matching MKT for this segment, using 1337 the segment's socket pair and its TCP-AO KeyID, matched 1338 against the MKT's TCP connection identifier and the MKT's 1339 RecvID. 1341 i. If there is no matching MKT, remove the TCP-AO option 1342 from the segment. Proceed with further TCP handling of 1343 the segment. 1345 NOTE: this presumes that connections that do not match 1346 any MKT should be silently accepted, as noted in Sec 9.3. 1348 ii. If there is a matching MKT, then set the per-connection 1349 parameters as needed (see Section 6). Proceed with the 1350 step 2. 1352 2. Using the per-connection parameters: 1354 a. Check that the segment's TCP-AO Length matches the length 1355 indicated by the MKT. 1357 i. If lengths differ, silently discard the segment. Log 1358 and/or signal the event as indicated in Section 9.3. 1360 b. Determine the segment's RCV.SNE as described in Section 8.2. 1362 c. Determine the segment's traffic key from the MKT as described 1363 in Section 7.1 (and as likely cached in the TCB). I.e., use 1364 the receive_SYN_traffic_key for SYN segments, and the 1365 receive_other_traffic_key for other segments. 1367 d. Compute the segment's MAC using the MKT (and its derived 1368 traffic key) and portions of the segment as indicated in 1369 Section 7.1. 1371 i. If the computed MAC differs from the TCP-AO MAC field 1372 value, silently discard the segment. Log and/or signal 1373 the event as indicated in Section 9.3. 1375 e. Compare the received RNextKeyID value to the currently active 1376 outgoing KeyID value (Current_key MKT's SendID). 1378 i. If they match, no further action is required. 1380 ii. If they differ, determine whether the RNextKeyID MKT is 1381 ready. 1383 1. If the MKT corresponding to the segment's socket 1384 pair and RNextKeyID is not available, no action is 1385 required (RNextKeyID of a received segment needs to 1386 match the MKT's SendID). 1388 2. If the matching MKT corresponding to the segment's 1389 socket pair and RNextKeyID is available: 1391 a. Set Current_key to the RNextKeyID MKT. 1393 f. Proceed with TCP processing of the segment. 1395 It is suggested that TCP-AO implementations validate a segment's 1396 Length field before computing a MAC, to reduce the overhead incurred 1397 by spoofed segments with invalid TCP-AO fields. 1399 Additional reductions in MAC validation overhead can be supported in 1400 the MAC algorithms, e.g., by using a computation algorithm that 1401 prepends a fixed value to the computed portion and a corresponding 1402 validation algorithm that verifies the fixed value before investing 1403 in the computed portion. Such optimizations would be contained in the 1404 MAC algorithm specification, and thus are not specified in TCP-AO 1405 explicitly. Note that the KeyID cannot be used for connection 1406 validation per se, because it is not assumed random. 1408 9.6. Impact on TCP Header Size 1410 The TCP-AO option, using the initially required 96-bit MACs, uses a 1411 total of 16 bytes of TCP header space [Le09]. TCP-AO is thus 2 bytes 1412 smaller than the TCP MD5 option (18 bytes). 1414 Note that TCP option space is most critical in SYN segments, because 1415 flags in those segments could potentially increase the option space 1416 area in other segments. Because TCP ignores unknown segments, 1417 however, it is not possible to extend the option space of SYNs 1418 without breaking backward-compatibility. 1420 TCP's 4-bit data offset requires that the options end 60 bytes (15 1421 32-bit words) after the header begins, including the 20-byte header. 1422 This leaves 40 bytes for options, of which 15 are expected in current 1423 implementations (listed below), leaving at most 25 for other uses. 1424 TCP-AO consumes 16 bytes, leaving 9 bytes for additional SYN options 1425 (depending on implementation dependant alignment padding, which could 1426 consume another 2 bytes at most). 1428 o SACK permitted (2 bytes) [RFC2018][RFC3517] 1430 o Timestamps (10 bytes) [RFC1323] 1432 o Window scale (3 bytes) [RFC1323] 1434 After a SYN, the following options are expected in current 1435 implementations of TCP: 1437 o SACK (10bytes) [RFC2018][RFC3517] (18 bytes if D-SACK [RFC2883]) 1439 o Timestamps (10 bytes) [RFC1323] 1441 TCP-AO continues to consume 16 bytes in non-SYN segments, leaving a 1442 total of 24 bytes for other options, of which the timestamp consumes 1443 10. This leaves 14 bytes, of which 10 are used for a single SACK 1444 block. When two SACK blocks are used, such as to handle D-SACK, a 1445 smaller TCP-AO MAC would be required to make room for the additional 1446 SACK block (i.e., to leave 18 bytes for the D-SACK variant of the 1447 SACK option) [RFC2883]. Note that D-SACK is not supportable in TCP 1448 MD5 in the presence of timestamps, because TCP MD5's MAC length is 1449 fixed and too large to leave sufficient option space. 1451 Although TCP option space is limited, we believe TCP-AO is consistent 1452 with the desire to authenticate TCP at the connection level for 1453 similar uses as were intended by TCP MD5. 1455 9.7. Connectionless Resets 1457 TCP-AO allows TCP resets (RSTs) to be exchanged provided both sides 1458 have established valid connection state. After such state is 1459 established, if one side reboots, TCP-AO prevents TCP's RST mechanism 1460 from clearing out old state on the side that did not reboot. This 1461 happens because the rebooting side has lost its connection state, and 1462 thus its traffic keys. 1464 It is important that implementations are capable of detecting 1465 excesses of TCP connections in such a configuration and can clear 1466 them out if needed to protect its memory usage [Ba09]. To protect 1467 against such state from accumulating and not being cleared out, a 1468 number of recommendations are made: 1470 >> Connections using TCP-AO SHOULD also use TCP keepalives [RFC1122]. 1472 The use of keepalives ensures that connections whose keys are lost 1473 are terminated after a finite time. Keepalives help ensure the TCP 1474 state is cleared out in such a case; the alternative, of allowing 1475 unauthenticated RSTs to be received, would allow one of the primary 1476 vulnerabilities that TCP-AO is intended to protect against. 1478 Keepalives ensure that connections are dropped across reboots, but 1479 this can have a detrimental effect on some protocols. In specific, 1480 BGP reacts poorly to such connection drops; "graceful restart" was 1481 introduced to address this effect [RFC4724], and extended to support 1482 BGP with MPLS [RFC4781]. As a result: 1484 >> BGP connections SHOULD require support for graceful restart when 1485 using TCP-AO. 1487 We recognize that support for graceful restart is not always 1488 feasible. As a result: 1490 >> When BGP without graceful restart is used with TCP-AO, both sides 1491 of the connection SHOULD save traffic keys in storage that persists 1492 across reboots and restore them after a reboot, and SHOULD limit any 1493 performance impacts that result from this storage/restoration. 1495 9.8. ICMP Handling 1497 TCP can be attacked both in-band, using TCP segments, or out-of-band 1498 using ICMP. ICMP packets cannot be protected using TCP-AO mechanisms, 1499 however; in this way, both TCP-AO and IPsec do not directly solve the 1500 need for protected ICMP signaling. TCP-AO does make specific 1501 recommendations on how to handle certain ICMPs, beyond what IPsec 1502 requires, and these are made possible because TCP-AO operates inside 1503 the context of a TCP connection. 1505 IPsec makes recommendations regarding dropping ICMPs in certain 1506 contexts, or requiring that they are endpoint authenticated in others 1507 [RFC4301]. There are other mechanisms proposed to reduce the impact 1508 of ICMP attacks by further validating ICMP contents and changing the 1509 effect of some messages based on TCP state, but these do not provide 1510 the level of authentication for ICMP that TCP-AO provides for TCP 1511 [Go09]. As a result, we recommend a conservative approach to 1512 accepting ICMP attacks as summarized in [Go09]: 1514 >> A TCP-AO implementation MUST default to ignore incoming ICMP 1515 messages of Type 3 (destination unreachable) Codes 2-4 (protocol 1516 unreachable, port unreachable, and fragmentation needed - 'hard 1517 errors') intended for connections that match MKTs. 1519 >> A TCP-AO implementation SHOULD allow whether such ICMPs are 1520 ignored to be configured on a per-connection basis. 1522 >> A TCP-AO implementation SHOULD implement measures to protect ICMP 1523 "packet too big" messages, some examples of which are discussed in 1524 [Go09] 1526 >> An implementation SHOULD allow ignored ICMPs to be logged. 1528 This control affects only ICMPs that currently require 'hard errors', 1529 which would abort the TCP connection [RFC1122]. This recommendation 1530 is intended to be similar to how IPsec would handle those messages, 1531 with an additional default assumed [RFC4301]. 1533 10. Obsoleting TCP MD5 and Legacy Interactions 1535 TCP-AO obsoletes TCP MD5. As we have noted earlier: 1537 >> TCP implementations MUST support TCP-AO. 1539 Systems implementing TCP MD5 only are considered legacy, and ought to 1540 be upgraded when possible. In order to support interoperation with 1541 such legacy systems until upgrades are available: 1543 >> TCP MD5 SHOULD be supported where interactions with legacy systems 1544 is needed. 1546 >> A system that supports both TCP-AO and TCP MD5 MUST use TCP-AO for 1547 connections unless not supported by its peer, at which point it MAY 1548 use TCP MD5 instead. 1550 >> A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for a 1551 particular TCP connection, but MAY support TCP-AO and TCP MD5 1552 simultaneously for different connections (notably to support legacy 1553 use of TCP MD5). 1555 The Kind value explicitly indicates whether TCP-AO or TCP MD5 is used 1556 for a particular connection in TCP segments. 1558 It is possible that MKTs could be augmented to support TCP MD5, 1559 although use of MKTs is not described in RFC2385. 1561 It is possible to require TCP-AO for a connection or TCP MD5, but it 1562 is not possible to require 'either'. When an endpoint is configured 1563 to require TCP MD5 for a connection, it must be added to all outgoing 1564 segments and validated on all incoming segments [RFC2385]. TCP MD5's 1565 requirements prohibit the speculative use of both options for a given 1566 connection, e.g., to be decided by the other end of the connection. 1568 11. Interactions with Middleboxes 1570 TCP-AO may interact with middleboxes, depending on their behavior 1571 [RFC3234]. Some middleboxes either alter TCP options (such as TCP-AO) 1572 directly or alter the information TCP-AO includes in its MAC 1573 calculation. TCP-AO may interfere with these devices, exactly where 1574 the device modifies information TCP-AO is designed to protect. 1576 11.1. Interactions with non-NAT/NAPT Middleboxes 1578 TCP-AO supports middleboxes that do not change the IP addresses or 1579 ports of segments. Such middleboxes may modify some TCP options, in 1580 which case TCP-AO would need to be configured to ignore all options 1581 in the MAC calculation on connections traversing that element. 1583 Note that ignoring TCP options may provide less protection, i.e., TCP 1584 options could be modified in transit, and such modifications could be 1585 used by an attacker. Depending on the modifications, TCP could have 1586 compromised efficiency (e.g., timestamp changes), or could cease 1587 correct operation (e.g., window scale changes). These vulnerabilities 1588 affect only the TCP connections for which TCP-AO is configured to 1589 ignore TCP options. 1591 11.2. Interactions with NAT/NAPT Devices 1593 TCP-AO cannot interoperate natively across NAT/NAPT devices, which 1594 modify the IP addresses and/or port numbers. We anticipate that 1595 traversing such devices may require variants of existing NAT/NAPT 1596 traversal mechanisms, e.g., encapsulation of the TCP-AO-protected 1597 segment in another transport segment (e.g., UDP), as is done in IPsec 1598 [RFC2663][RFC3947]. Such variants can be adapted for use with TCP-AO, 1599 or IPsec NAT traversal can be used instead in such cases [RFC3947]. 1601 An alternate proposal for accommodating NATs extends TCP-AO 1602 independently of this specification [To10]. 1604 12. Evaluation of Requirements Satisfaction 1606 TCP-AO satisfies all the current requirements for a revision to TCP 1607 MD5, as summarized below [Be07]. 1609 1. Protected Elements 1611 A solution to revising TCP MD5 should protect (authenticate) the 1612 following elements. 1614 This is supported - see Section 7.1. 1616 a. IP pseudoheader, including IPv4 and IPv6 versions. 1618 Note that we do not allow optional coverage because IP 1619 addresses define a connection. If they can be coordinated 1620 across a NAT/NAPT, the sender can compute the MAC based on the 1621 received values; if not, a tunnel is required, as noted in 1622 Section 11.2. 1624 b. TCP header. 1626 Note that we do not allow optional port coverage because ports 1627 define a connection. If they can be coordinated across a 1628 NAT/NAPT, the sender can compute the MAC based on the received 1629 values; if not, a tunnel is required, as noted in Section 1630 11.2. 1632 c. TCP options. 1634 Note that TCP-AO allows exclusion of TCP options from 1635 coverage, to enable use with middleboxes that modify options 1636 (except when they modify TCP-AO itself). See Section 11. 1638 d. TCP payload data. 1640 2. Option Structure Requirements 1642 A solution to revising TCP MD5 should use an option with the 1643 following structural requirements. 1645 This is supported - see Section 7.1. 1647 a. Privacy. 1649 The option should not unnecessarily expose information about 1650 the TCP-AO mechanism. The additional protection afforded by 1651 keeping this information private may be of little value, but 1652 also helps keep the option size small. 1654 TCP-AO exposes only the MKT IDs, MAC, and overall option 1655 length on the wire. Note that short MACs could be obscured by 1656 using longer option lengths but specifying a short MAC length 1657 (this is equivalent to a different MAC algorithm, and is 1658 specified in the MKT). See Section 4.2. 1660 b. Allow optional per connection. 1662 The option should not be required on every connection; it 1663 should be optional on a per connection basis. 1665 This is supported because the set of MKTs can be installed to 1666 match some connections and not others. Connections not 1667 matching any MKT do not require TCP-AO. Further, incoming 1668 segments containing the TCP-AO option are not discarded solely 1669 because they include the option, provided they do not match 1670 any MKT. 1672 c. Require non-optional. 1674 The option should be able to be specified as required for a 1675 given connection. 1677 This is supported because the set of MKTs can be installed to 1678 match some connections and not others. Connections matching 1679 any MKT require TCP-AO. 1681 d. Standard parsing. 1683 The option should be easily parseable, i.e., without 1684 conditional parsing, and follow the standard RFC 793 option 1685 format. 1687 This is supported - see Section 4.2. 1689 e. Compatible with Large Windows and SACK. 1691 The option should be compatible with the use of the Large 1692 Windows and SACK options. 1694 This is supported - see Section 9.6. The size of the option is 1695 intended to allow use with Large Windows and SACK. See also 1696 Section 2.2, which indicates that TCP-AO is 2 bytes shorter 1697 than TCP MD5 in the default case, assuming a 96-bit MAC. 1699 3. Cryptography requirements 1701 A solution to revising TCP MD5 should support modern cryptography 1702 capabilities. 1704 a. Baseline defaults. 1706 The option should have a default that is required in all 1707 implementations. 1709 TCP-AO uses a default required algorithm as specified in 1710 [Le09], as noted in Section 7.1. 1712 b. Good algorithms. 1714 The option should use algorithms considered accepted by the 1715 security community, which are considered appropriately safe. 1716 The use of non-standard or unpublished algorithms should be 1717 avoided. 1719 TCP-AO uses MACs as indicated in [Le09]. The KDF is also 1720 specified in [Le09]. The KDF input string follows the typical 1721 design (see [Le09]). 1723 c. Algorithm agility. 1725 The option should support algorithms other than the default, 1726 to allow agility over time. 1728 TCP-AO allows any desired algorithm, subject to TCP option 1729 space limitations, as noted in Section 4.2. The use of set of 1730 MKTs allows separate connections to use different algorithms, 1731 both for the MAC and the KDF. 1733 d. Order-independent processing. 1735 The option should be processed independently of the proper 1736 order, i.e., they should allow processing of TCP segments in 1737 the order received, without requiring reordering. This avoids 1738 the need for reordering prior to processing, and avoids the 1739 impact of misordered segments on the option. 1741 This is supported - see Sections 9.3, 9.4, and 9.5. Note that 1742 pre-TCP processing is further required, because TCP segments 1743 cannot be discarded solely based on a combination of 1744 connection state and out-of-window checks; many such segments, 1745 although discarded, cause a host to respond with a replay of 1746 the last valid ACK, e.g. [RFC793]. See also the derivation of 1747 the SNE, which is reconstituted at the receiver using a 1748 demonstration algorithm that avoids the need for reordering 1749 (in Section 8.2). 1751 e. Security parameter changes require key changes. 1753 The option should require that the MKT change whenever the 1754 security parameters change. This avoids the need for 1755 coordinating option state during a connection, which is 1756 typical for TCP options. This also helps allow "bump in the 1757 stack" implementations that are not integrated with endpoint 1758 TCP implementations. 1760 Parameters change only when a new MKT is used. See Section 5. 1762 4. Keying requirements. 1764 A solution to revising TCP MD5 should support manual keying, and 1765 should support the use of an external automated key management 1766 system (e.g., a protocol or other mechanism). 1768 Note that TCP-AO does not specify a MKT management system. 1770 a. Intraconnection rekeying. 1772 The option should support rekeying during a connection, to 1773 avoid the impact of long-duration connections. 1775 This is supported by the use of IDs and multiple MKTs; see 1776 Section 5. 1778 b. Efficient rekeying. 1780 The option should support rekeying during a connection without 1781 the need to expend undue computational resources. In 1782 particular, the options should avoid the need to try multiple 1783 keys on a given segment. 1785 This is supported by the use of the KeyID. See Section 8.1. 1787 c. Automated and manual keying. 1789 The option should support both automated and manual keying. 1791 The use of MKTs allows external automated and manual keying. 1792 See Section 5. This capability is enhanced by the generation 1793 of unique per-connection keys, which enables use of manual 1794 MKTs with automatically generated traffic keys as noted in 1795 Section 7.2. 1797 d. Key management agnostic. 1799 The option should not assume or require a particular key 1800 management solution. 1802 This is supported by use of a set of MKTs. See Section 5. 1804 5. Expected Constraints 1806 A solution to revising TCP MD5 should also abide by typical safe 1807 security practices. 1809 a. Silent failure. 1811 Receipt of segments failing authentication must result in no 1812 visible external action and must not modify internal state, 1813 and those events should be logged. 1815 This is supported - see Sections 9.3, 9.4, and 9.5. 1817 b. At most one such option per segment. 1819 Only one authentication option can be permitted per segment. 1821 This is supported by the protocol requirements - see Section 1822 4.2. 1824 c. Outgoing all or none. 1826 Segments out of a TCP connection are either all authenticated 1827 or all not authenticated. 1829 This is supported - see Section 9.4. 1831 d. Incoming all checked. 1833 Segments into a TCP connection are always checked to determine 1834 whether their authentication should be present and valid. 1836 This is supported - see Section 9.5. 1838 e. Non-interaction with TCP MD5. 1840 The use of this option for a given connection should not 1841 preclude the use of TCP MD5, e.g., for legacy use, for other 1842 connections. 1844 This is supported - see Section 9.7. 1846 f. "Hard" ICMP discard. 1848 The option should allow certain ICMPs to be discarded, notably 1849 Type 3 (destination unreachable), Codes 2-4 (transport 1850 protocol unreachable, port unreachable, or fragmentation 1851 needed and IP DF field set), i.e., the ones indicating the 1852 failure of the endpoint to communicate. 1854 This is supported - see Section 13. 1856 g. Maintain TCP connection semantics, in which the socket pair 1857 alone defines a TCP association and all its security 1858 parameters. 1860 This is supported - see Sections 5 and 11. 1862 13. Security Considerations 1864 Use of TCP-AO, like use of TCP MD5 or IPsec, will impact host 1865 performance. Connections that are known to use TCP-AO can be attacked 1866 by transmitting segments with invalid MACs. Attackers would need to 1867 know only the TCP connection ID and TCP-AO Length value to 1868 substantially impact the host's processing capacity. This is similar 1869 to the susceptibility of IPsec to on-path attacks, where the IP 1870 addresses and SPI would be visible. For IPsec, the entire SPI space 1871 (32 bits) is arbitrary, whereas for routing protocols typically only 1872 the source port (16 bits) is arbitrary (typically with less than 16 1873 bits of randomness [La09]). As a result, it would be easier for an 1874 off-path attacker to spoof a TCP-AO segment that could cause receiver 1875 validation effort. However, we note that between Internet routers 1876 both ports could be arbitrary (i.e., determined a-priori out of 1877 band), which would constitute roughly the same off-path antispoofing 1878 protection of an arbitrary SPI. 1880 TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets 1881 typically occur after peer crashes, either in response to new 1882 connection attempts or when data is sent on stale connections; in 1883 either case, the recovering endpoint may lack the connection key 1884 required (e.g., if lost during the crash). This may result in time- 1885 outs, rather than more responsive recovery after such a crash. 1886 Recommendations for mitigating this effect are discussed in Section 1887 9.7. 1889 TCP-AO does not include a fast decline capability, e.g., where a SYN- 1890 ACK is received without an expected TCP-AO option and the connection 1891 is quickly reset or aborted. Normal TCP operation will retry and 1892 timeout, which is what should be expected when the intended receiver 1893 is not capable of the TCP variant required anyway. Backoff is not 1894 optimized because it would present an opportunity for attackers on 1895 the wire to abort authenticated connection attempts by sending 1896 spoofed SYN-ACKs without the TCP-AO option. 1898 TCP-AO is intended to provide similar protections to IPsec, but is 1899 not intended to replace the use of IPsec or IKE either for more 1900 robust security or more sophisticated security management. TCP-AO is 1901 intended to protect the TCP protocol itself from attacks that TLS, 1902 sBGP/soBGP, and other data stream protection mechanism cannot. Like 1903 IPsec, TCP-AO does not address the overall issue of ICMP attacks on 1904 TCP, but does limit the impact of ICMPs, as noted in Section 9.8. 1906 TCP-AO includes the TCP connection ID (the socket pair) in the MAC 1907 calculation. This prevents different concurrent connections using the 1908 same MKT (for whatever reason) from potentially enabling a traffic- 1909 crossing attack, in which segments to one socket pair are diverted to 1910 attack a different socket pair. When multiple connections use the 1911 same MKT, it would be useful to know that segments intended for one 1912 ID could not be (maliciously or otherwise) modified in transit and 1913 end up being authenticated for the other ID. That requirement would 1914 place an additional burden of uniqueness on MKTs within endsystems, 1915 and potentially across endsystems. Although the resulting attack is 1916 low probability, the protection afforded by including the received ID 1917 warrants its inclusion in the MAC, and does not unduly increase the 1918 MAC calculation or MKT management. 1920 The use of any security algorithm can present an opportunity for a 1921 CPU DOS attack, where the attacker sends false, random segments that 1922 the receiver under attack expends substantial CPU effort to reject. 1923 In IPsec, such attacks are reduced by the use of a large Security 1924 Parameter Index (SPI) and Sequence Number fields to partly validate 1925 segments before CPU cycles are invested validated the Integrity Check 1926 Value (ICV). In TCP-AO, the socket pair performs most of the function 1927 of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay 1928 attacks, isn't needed due to TCP's Sequence Number, which is used to 1929 reorder received segments (provided the sequence number doesn't wrap 1930 around, which is why TCP-AO adds the SNE in Section 8.2). TCP already 1931 protects itself from replays of authentic segment data as well as 1932 authentic explicit TCP control (e.g., SYN, FIN, ACK bits, but even 1933 authentic replays could affect TCP congestion control [Sa99]. TCP-AO 1934 does not protect TCP congestion control from this last form of attack 1935 due to the cumbersome nature of layering a windowed security sequence 1936 number within TCP in addition to TCP's own sequence number; when such 1937 protection is desired, users are encouraged to apply IPsec instead. 1939 Further, it is not useful to validate TCP's Sequence Number before 1940 performing a TCP-AO authentication calculation, because out-of-window 1941 segments can still cause valid TCP protocol actions (e.g., ACK 1942 retransmission) [RFC793]. It is similarly not useful to add a 1943 separate Sequence Number field to the TCP-AO option, because doing so 1944 could cause a change in TCP's behavior even when segments are valid. 1946 14. IANA Considerations 1948 [NOTE: This section be removed prior to publication as an RFC] 1950 The TCP-AO option defines no new namespaces. 1952 The TCP-AO option requires that IANA allocate a value from the TCP 1953 option Kind namespace, to be replaced for TCP-IANA-KIND throughout 1954 this document. 1956 To specify MAC and KDF algorithms, TCP-AO refers to a separate 1957 document that may involve IANA actions [Le09]. 1959 15. References 1961 15.1. Normative References 1963 [Le09] Lebovitz, G., E. Rescorla, "Cryptographic Algorithms for 1964 TCP's Authentication Option, TCP-AO", draft-ietf-tcpm-tcp- 1965 ao-crypto-02, Oct. 2009. 1967 [RFC793] Postel, J., "Transmission Control Protocol," STD-7, 1968 RFC-793, Standard, Sept. 1981. 1970 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 1971 Communication Layers," RFC-1122, Oct. 1989. 1973 [RFC2018] Mathis, M., J. Mahdavi, S. Floyd, A. Romanow, "TCP 1974 Selective Acknowledgement Options", RFC-2018, Proposed 1975 Standard, April 1996. 1977 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1978 Requirement Levels", BCP-14, RFC-2119, Best Current 1979 Practice, March 1997. 1981 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1982 Signature Option," RFC-2385, Proposed Standard, Aug. 1998. 1984 [RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP 1985 and AH," RFC-2403, Proposed Standard, Nov. 1998. 1987 [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6 1988 (IPv6) Specification," RFC-2460, Proposed Standard, Dec. 1989 1998. 1991 [RFC2883] Floyd, S., J. Mahdavi, M. Mathis, M. Podolsky, "An 1992 Extension to the Selective Acknowledgement (SACK) Option 1993 for TCP", RFC-2883, Proposed Standard, July 2000. 1995 [RFC3517] Blanton, E., M. Allman, K. Fall, L. Wang, "A Conservative 1996 Selective Acknowledgment (SACK)-based Loss Recovery 1997 Algorithm for TCP", RFC-3517, Proposed Standard, April 1998 2003. 2000 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," 2001 RFC-4306, Proposed Standard, Dec. 2005. 2003 [RFC4724] Sangli, S., E. Chen, R. Fernando, J. Scudder, Y. Rekhter, 2004 "Graceful Restart Mechanism for BGP," RFC-4724, Jan. 2007. 2006 [RFC4781] Rekhter, Y., R. Aggarwal, "Graceful Restart Mechanism for 2007 BGP with MPLS," RFC-4781, Jan. 2007. 2009 15.2. Informative References 2011 [Ba09] Bashyam, M., M. Jethanandani,, A. Ramaiah "Clarification of 2012 sender behaviour in persist condition," draft-ananth-tcpm- 2013 persist-02, (work in progress), Jan. 2010. 2015 [Be07] Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem 2016 Statement and Requirements for a TCP Authentication 2017 Option," draft-bellovin-tcpsec-01, (work in progress), Jul. 2018 2007. 2020 [Bo07] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler, 2021 "Authentication for TCP-based Routing and Management 2022 Protocols," draft-bonica-tcp-auth-06, (work in progress), 2023 Feb. 2007. 2025 [Bo09] Borman, D., "TCP Options and MSS," draft-ietf-tcpm-tcpmss- 2026 02, Jul. 2009. 2028 [La09] Larsen, M., F. Gont, "Port Randomization," draft-ietf- 2029 tsvwg-port-randomization-05, Nov. 09. 2031 [Go09] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- 2032 attacks-10, (work in progress), Jan. 2010. 2034 [Le09] Lepinski, M., S. Kent, "An Infrastructure to Support Secure 2035 Internet Routing," draft-ietf-sidr-arch-09, (work in 2036 progress), Oct. 2009. 2038 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, 2039 Informational, April 1992. 2041 [RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for 2042 High Performance," RFC-1323, May 1992. 2044 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks," 2045 RFC-1948, Informational, May 1996. 2047 [RFC2104] Krawczyk, H., M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 2048 for Message Authentication," RFC-2104, Informational, Feb. 2049 1997. 2051 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 2052 Translator (NAT) Terminology and Considerations", RFC 2663, 2053 August 1999. 2055 [RFC3234] Carpenter, B., S. Brim, "Middleboxes: Taxonomy and Issues," 2056 RFC-3234, Informational, Feb. 2002. 2058 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 2059 Signature Option," RFC-3562, Informational, July 2003. 2061 [RFC3947] Kivinen, T., B. Swander, A. Huttunen, V. Volpe, 2062 "Negotiation of NAT-Traversal in the IKE," RFC-3947, 2063 Proposed Standard, Jan. 2005. 2065 [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet 2066 Protocol," RFC-4301, Proposed Standard, Dec. 2005. 2068 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5," 2069 RFC-4808, Informational, Mar. 2007. 2071 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks," 2072 RFC-4953, Informational, Jul. 2007. 2074 [RFC5246] Dierks, T., E. Rescorla, "The Transport Layer Security 2075 (TLS) Protocol Version 1.2," RFC-5246, Aug. 2008. 2077 [Sa99] Savage, S., N. Cardwell, D. Wetherall, T. Anderson, "TCP 2078 Congestion Control with a Misbehaving Receiver," ACM 2079 Computer Communications Review, V29, N5, pp71-78, October 2080 1999. 2082 [SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4)," 2083 Specification SDN.401, Revision 1.2, July 12, 1988. 2085 [To06] Touch, J., A. Mankin, "The TCP Simple Authentication 2086 Option," draft-touch-tcpm-tcp-simple-auth-03, (expired work 2087 in progress), Oct. 2006. 2089 [To10] Touch, J., "A TCP Authentication Option NAT Extension," 2090 draft-touch-tcp-ao-nat-01, Jan. 2010. 2092 [Wa05] Wang, X., H. Yu, "How to break MD5 and other hash 2093 functions," Proc. IACR Eurocrypt 2005, Denmark, pp.19-35. 2095 [We05] Weis, B., "TCP Message Authentication Code Option," draft- 2096 weis-tcp-mac-option-00, (expired work in progress), Dec. 2097 2005. 2099 16. Acknowledgments 2101 Alfred Hoenes, Charlie Kaufman, Adam Langley, and numerous other 2102 members of the TCPM WG provided substantial feedback on this 2103 document. 2105 This document was prepared using 2-Word-v2.0.template.dot. 2107 Authors' Addresses 2109 Joe Touch 2110 USC/ISI 2111 4676 Admiralty Way 2112 Marina del Rey, CA 90292-6695 2113 U.S.A. 2115 Phone: +1 (310) 448-9151 2116 Email: touch@isi.edu 2117 URL: http://www.isi.edu/touch 2119 Allison Mankin 2120 Johns Hopkins Univ. 2121 Washington, DC 2122 U.S.A. 2124 Phone: 1 301 728 7199 2125 Email: mankin@psg.com 2126 URL: http://www.psg.com/~mankin/ 2128 Ronald P. Bonica 2129 Juniper Networks 2130 2251 Corporate Park Drive 2131 Herndon, VA 20171 2132 U.S.A. 2134 Email: rbonica@juniper.net