idnits 2.17.1 draft-ietf-tcpm-tcp-auth-opt-11.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 952 has weird spacing: '...fic_key r-I...' == Line 954 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 (March 23, 2010) is 5148 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-06 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-11 -- 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: September 2010 R. Bonica 6 Juniper Networks 7 March 23, 2010 9 The TCP Authentication Option 10 draft-ietf-tcpm-tcp-auth-opt-11.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 September 23, 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. Conventions used in this document..............................4 87 3. Introduction...................................................4 88 3.1. Applicability Statement...................................5 89 3.2. Executive Summary.........................................6 90 4. The TCP Authentication Option..................................7 91 4.1. Review of TCP MD5 Option..................................7 92 4.2. The TCP Authentication Option Format......................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.........................19 102 7.3. Traffic Key Establishment and Duration Issues............22 103 7.3.1. MKT Reuse Across Socket Pairs.......................23 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.............................24 107 8.2. Preventing replay attacks within long-lived connections..25 108 9. TCP-AO Interaction with TCP...................................27 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...................35 118 11. Interactions with Middleboxes................................36 119 11.1. Interactions with non-NAT/NAPT Middleboxes..............36 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..........................................44 124 15. References...................................................45 125 15.1. Normative References....................................45 126 15.2. Informative References..................................46 127 16. Acknowledgments..............................................48 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 TCP's initial sequence numbers (ISNs) in the 146 traffic key computation and SNEs to avoid replay attacks, and Brian 147 Weis extended the computation to incorporate the entire connection ID 148 and provided the details of the traffic key computation. Mark Allman, 149 Wes Eddy, Lars Eggert, Ted Faber, Russ Housley, Gregory Lebovitz, Tim 150 Polk, Eric Rescorla, Joe Touch, and Brian Weis developed the master 151 key coordination mechanism. 153 2. Conventions used in this document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC-2119 [RFC2119]. 159 In this document, these words will appear with that interpretation 160 only when in ALL CAPS. Lower case uses of these words are not to be 161 interpreted as carrying RFC-2119 significance. 163 In this document, the characters ">>" preceeding an indented line(s) 164 indicates a compliance requirement statement using the key words 165 listed above. This convention aids reviewers in quickly identifying 166 or finding the explicit compliance requirements of this RFC. 168 3. Introduction 170 The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates 171 TCP segments, including the TCP IPv4 pseudoheader, TCP header, and 172 TCP data. It was developed to protect BGP sessions from spoofed TCP 173 segments which could affect BGP data or the robustness of the TCP 174 connection itself [RFC2385][RFC4953]. 176 There have been many recent concerns about TCP MD5. Its use of a 177 simple keyed hash for authentication is problematic because there 178 have been escalating attacks on the algorithm itself [Wa05]. TCP MD5 179 also lacks both key management and algorithm agility. This document 180 adds the latter, and provides a simple key coordination mechanism 181 giving the ability to move from one key to another within the same 182 connection. It does not however provide for complete cryptographic 183 key management to be handled in-band of TCP, because TCP SYN segments 184 lack sufficient remaining space to handle such a negotiation (see 185 Section 9.6). This document obsoletes the TCP MD5 option with a more 186 general TCP Authentication Option (TCP-AO). This new option supports 187 the use of other, stronger hash functions, provides replay protection 188 for long-lived connections and across repeated instances of a single 189 connection, coordinates key changes between endpoints, and provides a 190 more explicit recommendation for external key management. The result 191 is compatible with IPv6, and is fully compatible with proposed 192 requirements for a replacement for TCP MD5 [Be07]. 194 TCP-AO obsoletes TCP MD5, although a particular implementation may 195 support both mechanisms for backward compatibility. For a given 196 connection, only one can be in use. TCP MD5-protected connections 197 cannot be migrated to TCP-AO because TCP MD5 does not support any 198 changes to a connection's security algorithm once established. 200 3.1. Applicability Statement 202 TCP-AO is intended to support current uses of TCP MD5, such as to 203 protect long-lived connections for routing protocols, such as BGP and 204 LDP. It is also intended to provide similar protection to any long- 205 lived TCP connection, as might be used between proxy caches, e.g., 206 and is not designed solely or primarily for routing protocol uses. 208 TCP-AO is intended to replace (and thus obsolete) the use of TCP MD5. 209 TCP-AO enhances the capabilities of TCP MD5 as summarized in Section 210 3.2. This document recommends overall that: 212 >> TCP implementations that support TCP MD5 MUST support TCP-AO. 214 >> TCP-AO SHOULD be implemented where the protection afforded by TCP 215 authentiation is needed, either because IPsec is not supported, or 216 because TCP-AO's particular properties are needed (e.g., per- 217 connection keys). 219 >> TCP-AO MAY be implemented elsewhere. 221 TCP-AO is not intended to replace the use of the IPsec suite (IPsec 222 and IKE) to protect TCP connections [RFC4301][RFC4306]. Specific 223 differences are noted in Section 3.2. In fact, we recommend the use 224 of IPsec and IKE, especially where IKE's level of existing support 225 for parameter negotiation, session key negotiation, or rekeying are 226 desired. TCP-AO is intended for use only where the IPsec suite would 227 not be feasible, e.g., as has been suggested is the case to support 228 some routing protocols [RFC4953], or in cases where keys need to be 229 tightly coordinated with individual transport sessions [Be07]. 231 TCP-AO is not intended to replace the use of Transport Layer Security 232 (TLS) [RFC5246], sBGP or soBGP [Le09], or any other mechanisms that 233 protect only the TCP data stream. TCP-AO protects the transport 234 layer, preventing attacks from disabling the TCP connection itself 235 [RFC4953]. Data stream mechanisms protect only the contents of the 236 TCP segments, and can be disrupted when the connection is affected. 237 Some of these data protection protocols - notably TLS - offer a 238 richer set of key management and authentication mechanisms than TCP- 239 AO, and thus protect the data stream in a different way. TCP-AO may 240 be used together with these data stream protections to complement 241 each others' strengths. 243 3.2. Executive Summary 245 This document replaces TCP MD5 as follows [RFC2385]: 247 o TCP-AO uses a separate option Kind (TBD-IANA-KIND). 249 o TCP-AO allows TCP MD5 to continue to be used concurrently for 250 legacy connections. 252 o TCP-AO replaces TCP MD5's single MAC algorithm with MACs specified 253 in a separate document and can be extended to include other MACs. 255 o TCP-AO allows rekeying during a TCP connection, assuming that an 256 out-of-band protocol or manual mechanism provides the new keys. 257 The option includes a 'key ID' which allows the efficient 258 concurrent use of multiple keys, and a key coordination mechanism 259 using a 'receive next key ID' manages the key change within a 260 connection. Note that TCP MD5 does not preclude rekeying during a 261 connection, but does not require its support either. Further, 262 TCP-AO supports key changes with zero segment loss, whereas key 263 changes in TCP MD5 can lose segments in transit during the 264 changeover or require trying multiple keys on each received 265 segment during key use overlap because it lacks an explicit key 266 ID. Although TCP recovers lost segments through retransmission, 267 loss can have a substantial impact on performance. 269 o TCP-AO provides automatic replay protection for long-lived 270 connections using sequence number extensions. 272 o TCP-AO ensures per-connection traffic keys as unique as the TCP 273 connection itself, using TCP's initial sequence numbers (ISNs) for 274 differentiation, even when static master key tuples are used 275 across repeated instances of connections on a single socket pair. 277 o TCP-AO specifies the details of how this option interacts with 278 TCP's states, event processing, and user interface. 280 o TCP-AO is 2 bytes shorter than TCP MD5 (16 bytes overall, rather 281 than 18) in the initially specified default case (using a 96-bit 282 MAC). 284 TCP-AO differs from an IPsec/IKE solution in as follows 285 [RFC4301][RFC4306]: 287 o TCP-AO does not support dynamic parameter negotiation. 289 o TCP-AO includes TCP's socket pair (source address, destination 290 address, source port, destination port) as a security parameter 291 index (together with the KeyID), rather than using a separate 292 field as an index (IPsec's SPI). 294 o TCP-AO forces a change of computed MACs when a connection 295 restarts, even when reusing a TCP socket pair (IP addresses and 296 port numbers) [Be07]. 298 o TCP-AO does not support encryption. 300 o TCP-AO does not authenticate ICMP messages (some ICMP messages may 301 be authenticated when using IPsec, depending on the 302 configuration). 304 4. The TCP Authentication Option 306 The TCP Authentication Option (TCP-AO) uses a TCP option Kind value 307 of TBD-IANA-KIND. The following sections describe TCP-AO and provide 308 a review of TCP MD5 for comparison. 310 4.1. Review of TCP MD5 Option 312 For review, the TCP MD5 option is shown in Figure 1. 314 +---------+---------+-------------------+ 315 | Kind=19 |Length=18| MD5 digest... | 316 +---------+---------+-------------------+ 317 | ...digest (con't)... | 318 +---------------------------------------+ 319 | ... | 320 +---------------------------------------+ 321 | ... | 322 +-------------------+-------------------+ 323 | ...digest (con't) | 324 +-------------------+ 326 Figure 1 The TCP MD5 Option [RFC2385] 328 In the TCP MD5 option, the length is fixed, and the MD5 digest 329 occupies 16 bytes following the Kind and Length fields (each one 330 byte), using the full MD5 digest of 128 bits [RFC1321]. 332 The TCP MD5 option specifies the use of the MD5 digest calculation 333 over the following values in the following order: 335 1. The IP pseudoheader (IP source and destination addresses, protocol 336 number, and segment length). 338 2. The TCP header excluding options and checksum. 340 3. The TCP data payload. 342 4. A key. 344 4.2. The TCP Authentication Option Format 346 TCP-AO provides a superset of the capabilities of TCP MD5, and is 347 minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new Kind field, 348 and similar Length field to TCP MD5, a KeyID field, and a RNextKeyID 349 field as shown in Figure 2. 351 +------------+------------+------------+------------+ 352 | Kind | Length | KeyID | RNextKeyID | 353 +------------+------------+------------+------------+ 354 | MAC ... 355 +-----------------------------------... 357 ...-----------------+ 358 ... MAC (con't) | 359 ...-----------------+ 361 Figure 2 The TCP Authentication Option (TCP-AO) 363 TCP-AO defines these fields as follows: 365 o Kind: An unsigned 1-byte field indicating TCP-AO. TCP-AO uses a 366 new Kind value of TBD-IANA-KIND. 368 >> An endpoint MUST NOT use TCP-AO for the same connection in 369 which TCP MD5 is used. When both options appear, TCP MUST silently 370 discard the segment. 372 >> A single TCP segment MUST NOT have more than one TCP-AO in its 373 options sequence. When multiple TCP-AOs appear, TCP MUST discard 374 the segment. 376 o Length: An unsigned 1-byte field indicating the length of the 377 option in bytes, including the Kind, Length, KeyID, RNextKeyID, 378 and MAC fields. 380 >> The Length value MUST be greater than or equal to 4. When the 381 Length value is less than 4, TCP MUST discard the segment. 383 >> The Length value MUST be consistent with the TCP header length. 384 When the Length value is invalid, TCP MUST discard the segment. 386 This Length check implies that the sum of the sizes of all 387 options, when added to the size of the base TCP header (5 words), 388 matches the TCP Offset field exactly. This full verification can 389 be computed because RFC 793 specifies the size of the required 390 options, and RFC 1122 requires that all new options follow a 391 common format with a fixed length field location 392 [RFC793][RFC1122]. A partial verification can be limited to check 393 only TCP-AO, so that the TCP-AO length, when added to the TCP-AO 394 offset from start of the TCP header, does not exceed the TCP 395 header size as indicated in the TCP header Offset field. 397 Values of 4 and other small values larger than 4 (e.g., indicating 398 MAC fields of very short length) are of dubious utility but are 399 not specifically prohibited. 401 o KeyID: An unsigned 1-byte field indicating the master key tuple 402 (MKT, as defined in Section 5.1) used to generate the traffic keys 403 which were used to generate the MAC that authenticates this 404 segment. 406 It supports efficient key changes during a connection and/or to 407 help with key coordination during connection establishment, to be 408 discussed further in Section 8.1. Note that the KeyID has no 409 cryptographic properties - it need not be random, nor are there 410 any reserved values. 412 >> KeyID values MAY be the same in both directions of a 413 connection, but do not have to be and there is no special meaning 414 when they are. 416 This allows MKTs to be installed on a set of devices without 417 coordinating the KeyIDs across an entire in advance, and allows 418 new devices to be added to the set using a group of MKTs later 419 without requiring renumbering of KeyIDs. These two capabilities 420 are particularly important when used with wildcards in the TCP 421 socket pair of the MKT, i.e., when a MKT is used among a set of 422 devices specified by a pattern (as noted in Section 5.1). 424 o RNextKeyID: An unsigned 1-byte field indicating the MKT that is 425 ready at the sender to be used to authenticate received segments, 426 i.e., the desired 'receive next' keyID. 428 It supports efficient key change coordination, to be discussed 429 further in Section 8.1. Note that the RNextKeyID has no 430 cryptographic properties - it need not be random, nor are there 431 any reserved values. 433 o MAC: Message Authentication Code. Its contents are determined by 434 the particulars of the security association. Typical MACs are 96- 435 128 bits (12-16 bytes), but any length that fits in the header of 436 the segment being authenticated is allowed. The MAC computation is 437 described further in Section 7.1. 439 >> Required support for TCP-AO MACs are defined in [Le09]; other 440 MACs MAY be supported. 442 TCP-AO fields do not indicate the MAC algorithm either implicitly (as 443 with TCP MD5) or explicitly. The particular algorithm used is 444 considered part of the configuration state of the connection's 445 security and is managed separately (see Section 5). 447 Please note that the use of TCP-AO does not affect TCP's advertised 448 maximum segment size (MSS), as is the case for all TCP options 449 [Bo09]. 451 The remainder of this document explains how TCP-AO is handled and its 452 relationship to TCP. 454 5. TCP-AO Keys and Their Properties 456 TCP-AO relies on two sets of keys to authenticate incoming and 457 outgoing segments: master key tuples (MKTs) and traffic keys. MKTs 458 are used to derive unique traffic keys, and include the keying 459 material used to generate those traffic keys, as well as indicating 460 the associated parameters under which traffic keys are used. Such 461 parameters include whether TCP options are authenticated, and 462 indicators of the algorithms used for traffic key derivation and MAC 463 calculation. Traffic keys are the keying material used to compute the 464 MAC of individual TCP segments. 466 5.1. Master Key Tuple 468 A Master Key Tuple (MKT) describes TCP-AO properties to be associated 469 with one or more connections. It is composed of the following: 471 o TCP connection identifier. A TCP socket pair, i.e., a local IP 472 address, a remote IP address, a TCP local port, and a TCP remote 473 port. Values can be partially specified using ranges (e.g., 2-30), 474 masks (e.g., 0xF0), wildcards (e.g., "*"), or any other suitable 475 indication. 477 o TCP option flag. This flag indicates whether TCP options other 478 than TCP-AO are included in the MAC calculation. When options are 479 included, the content of all options, in the order present, are 480 included in the MAC, with TCP-AO's MAC field zeroed out. When the 481 options are not included, all options other than TCP-AO are 482 excluded from all MAC calculations (skipped over, not zeroed). 483 Note that TCP-AO, with its MAC field zeroed out, is always 484 included in the MAC calculation, regardless of the setting of this 485 flag; this protects the indication of the MAC length as well as 486 the key ID fields (KeyID, RNextKeyID). The option flag applies to 487 TCP options in both directions (incoming and outgoing segments). 489 o IDs. The values used in the KeyID or RNextKeyID of TCP-AO; used to 490 differentiate MKTs in concurrent use (KeyID), as well as to 491 indicate when MKTs are ready for use in the opposite direction 492 (RNextKeyID). 494 Each MKT has two IDs - a SendID and a RecvID. The SendID is 495 inserted as the KeyID of the TCP-OP option of outgoing segments, 496 and the RecvID is matched against the TCP-AO KeyID of incoming 497 segments. These and other uses of these two IDs are described 498 further in Section 9.4 and 9.5. 500 >> MKT IDs MUST support any value, 0-255 inclusive. There are no 501 reserved ID values. 503 ID values are assigned arbitrarily, i.e., the values are not 504 monotonically increasing, have no reserved values, and are 505 otherwise not meaningful. They can be assigned in sequence, or 506 based on any method mutually agreed by the connection endpoints 507 (e.g., using an external MKT management mechanism). 509 >> IDs MUST NOT be assumed to be randomly assigned. 511 o Master key. A byte sequence used for generating traffic keys, this 512 may be derived from a separate shared key by an external protocol 513 over a separate channel. This sequence is used in the traffic key 514 generation algorithm described in Section 7.2. 516 Implementations are advised to keep master key values in a 517 private, protected area of memory or other storage. 519 o Key Derivation Function (KDF). Indicates the key derivation 520 function and its parameters, as used to generate traffic keys from 521 master keys. Explained further in Section 7.1 of this document and 522 specified in detail in [Le09]. 524 o Message Authentication Code (MAC) algorithm. Indicates the MAC 525 algorithm and its parameters as used for this connection, 526 explained further in Section 7.1 of this document and specified in 527 detail in [Le09]. 529 >> Components of a MKT MUST NOT change during a connection. 531 MKT component values cannot change during a connection because TCP 532 state is coordinated during connection establishment. TCP lacks a 533 handshake for modifying that state after a connection has been 534 established. 536 >> The set of MKTs MAY change during a connection. 538 MKT parameters are not changed. Instead, new MKTs can be installed, 539 and a connection can change which MKT it uses. 541 >> The IDs of MKTs MUST NOT overlap where their TCP connection 542 identifiers overlap. 544 This document does not address how MKTs are created by users or 545 processes. It is presumed that a MKT affecting a particular 546 connection cannot be destroyed during an active connection - or, 547 equivalently, that its parameters are copied to an area local to the 548 connection (i.e., instantiated) and so changes would affect only new 549 connections. The MKTs can be managed by a separate application 550 protocol. 552 5.2. Traffic Keys 554 A traffic key is a key derived from the MKT and the local and remote 555 IP address pairs and TCP port numbers, and, for established 556 connections, the TCP Initial Sequence Numbers (ISNs) in each 557 direction. Segments exchanged before a connection is established use 558 the same information, substituting zero for unknown values (e.g., 559 ISNs not yet coordinated). 561 A single MKT can be used to derive any of four different traffic 562 keys: 564 o Send_SYN_traffic_key 565 o Receive_SYN_traffic_key 567 o Send_other_traffic_key 569 o Receive_other_traffic_key 571 Note that the keys are unidirectional. A given connection typically 572 uses only three of these keys, because only one of the SYN keys is 573 typically used. All four are used only when a connection goes through 574 'simultaneous open' [RFC793]. 576 The relationship between MKTs and traffic keys is shown in Figure 3. 577 Traffic keys are indicated with a "*". Note that every MKT can be 578 used to derive any of the four traffic keys, but only the keys 579 actually needed to handle the segments of a connection need to be 580 computed. Section 7.2 provides further details on how traffic keys 581 are derived. 583 MKT-A MKT-B 584 +---------------------+ +------------------------+ 585 | SendID = 1 | | SendID = 5 | 586 | RecvID = 2 | | RecvID = 6 | 587 | MAC = HMAC-SHA1 | | MAC = AES-CMAC | 588 | KDF = KDF-HMAC-SHA1 | | KDF = KDF-AES-128-CMAC | 589 +---------------------+ +------------------------+ 590 | | 591 +----------+----------+ | 592 | | | 593 v v v 594 Connection 1 Connection 2 Connection 3 595 +------------------+ +------------------+ +------------------+ 596 | * Send_SYN_key | | * Send_SYN_key | | * Send_SYN_key | 597 | * Recv_SYN_key | | * Recv_SYN_key | | * Recv_SYN_key | 598 | * Send_Other_key | | * Send_Other_key | | * Send_Other_key | 599 | * Recv_Other_key | | * Recv_Other_key | | * Recv_Other_key | 600 +------------------+ +------------------+ +------------------+ 602 Figure 3 Relationship between MKTs and traffic keys 604 5.3. MKT Properties 606 TCP-AO requires that every protected TCP segment match exactly one 607 MKT. When an outgoing segment matches an MKT, TCP-AO is used. When no 608 match occurs, TCP-AO is not used. Multiple MKTs may match a single 609 outgoing segment, e.g., when MKTs are being changed. Those MKTs 610 cannot have conflicting IDs (as noted elsewhere), and some mechanism 611 must determine which MKT to use for each given outgoing segment. 613 >> An outgoing TCP segment MUST match at most one desired MKT, 614 indicated by the segment's socket pair. The segment MAY match 615 multiple MKTs, provided that exactly one MKT is indicated as desired. 616 Other information in the segment MAY be used to determine the desired 617 MKT when multiple MKTs match; such information MUST NOT include 618 values in any TCP option fields. 620 We recommend that the mechanism used to select from among multiple 621 MKTs use only information that TCP-AO would authenticate. Because 622 MKTs may indicate that options other than TCP-AO are ignored in the 623 MAC calculation, we recommend that TCP options should not be used to 624 determine MKTs. 626 >> An incoming TCP segment including TCP-AO MUST match exactly one 627 MKT, indicated solely by the segment's socket pair and its TCP-AO 628 KeyID. 630 Incoming segments include an indicator inside TCP-AO to select from 631 among multiple matching MKTs - the KeyID field. TCP-AO requires that 632 the KeyID alone be used to differentiate multiple matching MKTs, so 633 that MKT changes can be coordinated using the TCP-AO key change 634 coordination mechanism. 636 >> When an outgoing TCP segment matches no MKTs, TCP-AO is not used. 638 TCP-AO is always used when outgoing segments match an MKT, and is not 639 used otherwise. 641 6. Per-Connection TCP-AO Parameters 643 TCP-AO uses a small number of parameters associated with each 644 connection that uses TCP-AO, once instantiated. These values can be 645 stored in the Transport Control Block (TCP) [RFC793]. These values 646 are explained in subsequent sections of this document as noted; they 647 include: 649 1. Current_key - the MKT currently used to authenticate outgoing 650 segments, whose SendID is inserted in outgoing segments as KeyID 651 (see Section 9.4, step 5). Incoming segments are authenticated 652 using the MKT corresponding to the segment and its TCP-AO KeyID 653 (see Section 9.5, step 5), as matched against the MKT TCP 654 connection identifier and the MKT RecvID. There is only one 655 current_key at any given time on a particular connection. 657 >> Every TCP connection in a non-IDLE state MUST have at most one 658 current_key specified. 660 2. Rnext_key -the MKT currently preferred for incoming (received) 661 segments, whose RecvID is inserted in outgoing segments as 662 RNextKeyID (see Section 9.5, step 5). 664 >> Each TCP connection in a non-IDLE state MUST have at most one 665 rnext_key specified. 667 3. A pair of Sequence Numbers Extensions (SNEs). SNEs are used to 668 prevent replay attacks, as described in Section 8.2. Each SNE is 669 initialized to zero upon connection establishment. Its use in the 670 MAC calculation is described in Section 7.1. 672 4. One or more MKTs. These are the MKTs that match this connection's 673 socket pair. 675 MKTs are used, together with other parameters of a connection, to 676 create traffic keys unique to each connection, as described in 677 Section 7.2. These traffic keys can be cached after computation, and 678 can be stored in the TCB with the corresponding MKT information. They 679 can be considered part of the per-connection parameters. 681 7. Cryptographic Algorithms 683 TCP-AO uses cryptographic algorithms to compute the MAC (Message 684 Authentication Code) that is used to authenticate a segment and its 685 headers; these are called MAC algorithms and are specified in a 686 separate document to facilitate updating the algorithm requirements 687 independently from the protocol [Le09]. TCP-AO also uses 688 cryptographic algorithms to convert MKTs, which can be shared across 689 connections, into unique traffic keys for each connection. These are 690 called Key Derivation Functions (KDFs), and are specified [Le09]. 691 This section describes how these algorithms are used by TCP-AO. 693 7.1. MAC Algorithms 695 MAC algorithms take a variable-length input and a key and output a 696 fixed-length number. This number is used to determine whether the 697 input comes from a source with that same key, and whether the input 698 has been tampered in transit. MACs for TCP-AO have the following 699 interface: 701 MAC = MAC_alg(traffic_key, message) 703 INPUT: MAC_alg, traffic_key, message 705 OUTPUT: MAC 707 where: 709 o MAC_alg - the specific MAC algorithm used for this computation. 710 The MAC algorithm specifies the output length, so no separate 711 output length parameter is required. This is specified as 712 described in [Le09]. 714 o Traffic_key - traffic key used for this computation. This is 715 computed from the connection's current MKT as described in Section 716 7.2. 718 o Message - input data over which the MAC is computed. In TCP-AO, 719 this is the TCP segment prepended by the IP pseudoheader and TCP 720 header options, as described in Section 7.1. 722 o MAC - the fixed-length output of the MAC algorithm, given the 723 parameters provided. 725 At the time of this writing, the algorithms' definitions for use in 726 TCP-AO, as described in [Le09] are each truncated to 96 bits. Though 727 the algorithms each output a larger MAC, 96 bits provides a 728 reasonable tradeoff between security and message size. Though could 729 change in the future, so TCP-AO size should not be assumed as fixed 730 length. 732 The MAC algorithm employed for the MAC computation on a connection is 733 done so by definition in the MKT, per [Le09]'s definitions. 735 The mandatory-to-implement MAC algorithms for use with TCP-AO are 736 described in a separate RFC [Le09]. This allows the TCP-AO 737 specification to proceed along the IETF standards track even if 738 changes are needed to its associated algorithms and their labels (as 739 might be used in a user interface or automated MKT management 740 protocol) as a result of the ever evolving world of cryptography. 742 >> Additional algorithms, beyond those mandated for TCP-AO, MAY be 743 supported. 745 The data input to the MAC is the following fields in the following 746 sequence, interpreted in network-standard byte order: 748 1. The sequence number extension (SNE), in network-standard byte 749 order, as follows (described further in Section 8.2): 751 +--------+--------+--------+--------+ 752 | SNE | 753 +--------+--------+--------+--------+ 755 Figure 4 Sequence number extension 757 The SNE for transmitted segments is maintained locally in the 758 SND.SNE value; for received segments, a local RCV.SNE value is 759 used. The details of how these values are maintained and used is 760 described in Sections 8.2, 9.4, and 9.5. 762 2. The IP pseudoheader: IP source and destination addresses, protocol 763 number and segment length, all in network byte order, prepended to 764 the TCP header below. The IP pseudoheader is exactly as used for 765 the TCP checksum in either IPv4 or IPv6 [RFC793][RFC2460]: 767 +--------+--------+--------+--------+ 768 | Source Address | 769 +--------+--------+--------+--------+ 770 | Destination Address | 771 +--------+--------+--------+--------+ 772 | zero | Proto | TCP Length | 773 +--------+--------+--------+--------+ 775 Figure 5 TCP IPv4 pseudoheader [RFC793] 776 +--------+--------+--------+--------+ 777 | | 778 + + 779 | | 780 + Source Address + 781 | | 782 + + 783 | | 784 + + 785 +--------+--------+--------+--------+ 786 | | 787 + + 788 | | 789 + Destination Address + 790 | | 791 + + 792 | | 793 +--------+--------+--------+--------+ 794 | Upper-Layer Payload Length | 795 +--------+--------+--------+--------+ 796 | zero | Next Header | 797 +--------+--------+--------+--------+ 799 Figure 6 TCP IPv6 pseudoheader [RFC2460] 801 3. The TCP header, by default including options, and where the TCP 802 checksum and TCP-AO MAC fields are set to zero, all in network 803 byte order. 805 The TCP option flag of the MKT indicates whether the TCP options 806 are included in the MAC. When included, only the TCP-AO MAC field 807 is zeroed. 809 When TCP options are not included, all TCP options except for TCP- 810 AO are omitted from MAC processing. Again, the TCP-AO MAC field is 811 zeroed for the MAC processing. 813 4. The TCP data, i.e., the payload of the TCP segment. 815 Note that the traffic key is not included as part of the data; the 816 MAC algorithm indicates how to use the traffic key, e.g., as HMACs do 817 [RFC2104][RFC2403]. The traffic key is derived from the current MKT 818 as described in Sections 7.2. 820 7.2. Traffic Key Derivation Functions 822 TCP-AO's traffic keys are derived from the MKTs using Key Derivation 823 Functions (KDFs). The KDFs used in TCP-AO have the following 824 interface: 826 traffic_key = KDF_alg(master_key, context, output_length) 828 INPUT: KDF_alg, master_key, context, output_length 830 OUTPUT: traffic_key 832 where: 834 o KDF_alg - the specific key derivation function (KDF) that is the 835 basic building block used in constructing the traffic key, as 836 indicated in the MKT. This is specified as described in [Le09]. 838 o Master_key - The master_key string, as will be stored into the 839 associated MKT. 841 o Context - The context used as input in constructing the 842 traffic_key, as specified in [Le09]. The specific way this context 843 is used, in conjunction with other information, to create the raw 844 input to the KDF is also explained further in [Le09]. 846 o Output_length - The desired output length of the KDF, i.e., the 847 length to which the KDF's output will be truncated. This is 848 specified as described in [Le09]. 850 o Traffic_key - The desired output of the KDF, of length 851 output_length, to be used as input to the MAC algorithm, as 852 described in Section 7.1. 854 The context used as input to the KDF combines TCP socket pair with 855 the endpoint initial sequence numbers (ISNs) of a connection. This 856 data is unique to each TCP connection instance, which enables TCP-AO 857 to generate unique traffic keys for that connection, even from a MKT 858 used across many different connections or across repeated connections 859 that share a socket pair. Unique traffic keys are generated without 860 relying on external key management properties. The KDF context is 861 defined in Figure 7 and Figure 8. 863 +--------+--------+--------+--------+ 864 | Source Address | 865 +--------+--------+--------+--------+ 866 | Destination Address | 867 +--------+--------+--------+--------+ 868 | Source Port | Dest. Port | 869 +--------+--------+--------+--------+ 870 | Source ISN | 871 +--------+--------+--------+--------+ 872 | Dest. ISN | 873 +--------+--------+--------+--------+ 875 Figure 7 KDF Context for an IPv4 connection 877 +--------+--------+--------+--------+ 878 | | 879 + + 880 | | 881 + Source Address + 882 | | 883 + + 884 | | 885 + + 886 +--------+--------+--------+--------+ 887 | | 888 + + 889 | | 890 + Destination Address + 891 | | 892 + + 893 | | 894 +--------+--------+--------+--------+ 895 | Source Port | Dest. Port | 896 +--------+--------+--------+--------+ 897 | Source ISN | 898 +--------+--------+--------+--------+ 899 | Dest. ISN | 900 +--------+--------+--------+--------+ 902 Figure 8 KDF Context for an IPv6 connection 904 Traffic keys are directional, so "source" and "destination" are 905 interpreted differently for incoming and outgoing segments. For 906 incoming segments, source is the remote side, whereas for outgoing 907 segments source is the local side. This further ensures that 908 connection keys generated for each direction are unique. 910 For SYN segments (segments with the SYN set, but the ACK not set), 911 the destination ISN is not known. For these segments, the connection 912 key is computed using the context shown above, in which the 913 Destination ISN value is zero. For all other segments, the ISN pair 914 is used when known. If the ISN pair is not known, e.g., when sending 915 a RST after a reboot, the segment should be sent without 916 authentication; if authentication was required, the segment cannot 917 have been MAC'd properly anyway and would have been dropped on 918 receipt. 920 >> TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination 921 ISN of zero (whether sent or received); all other segments use the 922 known ISN pair. 924 Overall, this means that each connection will use up to four distinct 925 traffic keys for each MKT: 927 o Send_SYN_traffic_key - the traffic key used to authenticate 928 outgoing SYNs. The source ISN known (the TCP connection's local 929 ISN), and the destination (remote) ISN is unknown (and so the 930 value 0 is used). 932 o Receive_SYN_traffic_key - the traffic key used to authenticate 933 incoming SYNs. The source ISN known (the TCP connection's remote 934 ISN), and the destination (remote) ISN is unknown (and so the 935 value 0 is used). 937 o Send_other_traffic_key - the traffic key used to authenticate all 938 other outgoing TCP segments. 940 o Receive_other_traffic_key - the traffic key used to authenticate 941 all other incoming TCP segments. 943 The following table describes how each of these traffic keys is 944 computed, where the TCP-AO algorithms refer to source (S) and 945 destination (D) values of the IP address, TCP port, and ISN, and each 946 segment (incoming or outgoing) has a values that refer to the local 947 side of the connection (l) and remote side (r): 949 S-IP S-port S-ISN D-IP D-port D-ISN 950 ---------------------------------------------------------------- 951 Send_SYN_traffic_key l-IP l-port l-ISN r-IP r-port 0 952 Receive_SYN_traffic_key r-IP r-port r-ISN l-IP l-port 0 953 Send_other_traffic_key l-IP l-port l-ISN r-IP r-port r-ISN 954 Receive_other_traffic_key r-IP r-port r-ISN l-IP l-port l-ISN 956 The use of both ISNs in the traffic key computations ensures that 957 segments cannot be replayed across repeated connections reusing the 958 same socket, their 32-bit space avoids repeated use except under 959 reboot, and reuse assumes both sides repeat their use on the same 960 connection). We do expect that: 962 >> Endpoints should select ISNs pseudorandomly, e.g., as in [RFC1948] 964 A SYN is authenticated using a destination ISN of zero (whether sent 965 or received), and all other segments would be authenticated using the 966 ISN pair for the connection. There are other cases in which the 967 destination ISN is not known, but segments are emitted, such as after 968 an endpoint reboots, when it is possible that the two endpoints would 969 not have enough information to authenticate segments. This is 970 addressed further in Section 9.7. 972 7.3. Traffic Key Establishment and Duration Issues 974 TCP-AO does not provide a mechanism for traffic key negotiation or 975 parameter negotiation (MAC algorithm, length, or use of TCP-AO on a 976 connection), or for coordinating rekeying during a connection. We 977 assume out-of-band mechanisms for MKT establishment, parameter 978 negotiation, and rekeying. This separation of MKT use from MKT 979 management is similar to that in the IPsec security suite 980 [RFC4301][RFC4306]. 982 We encourage users of TCP-AO to apply known techniques for generating 983 appropriate MKTs, including the use of reasonable master key lengths, 984 limited traffic key sharing, and limiting the duration of MKT use 985 [RFC3562]. This also includes the use of per-connection nonces, as 986 suggested in Section 7.2. 988 TCP-AO supports rekeying in which new MKTs are negotiated and 989 coordinated out-of-band, either via a protocol or a manual procedure 990 [RFC4808]. New MKT use is coordinated using the out-of-band mechanism 991 to update both TCP endpoints. When only a single MKT is used at a 992 time, the temporary use of invalid MKTs could result in segments 993 being dropped; although TCP is already robust to such drops, TCP-AO 994 uses the KeyID field to avoid such drops. A given connection can have 995 multiple matching MKTs, where the KeyID field is used to identify the 996 MKT that corresponds to the traffic key used for a segment, to avoid 997 the need for expensive trial-and-error testing of MKTs in sequence. 999 TCP-AO provides an explicit MKT coordination mechanism, described in 1000 Section 8.1. Such a mechanism is useful when new MKTs are installed, 1001 or when MKTs are changed, to determine when to commence using 1002 installed MKTs. 1004 Users are advised to manage MKTs following the spirit of the advice 1005 for key management when using TCP MD5 [RFC3562], notably to use 1006 appropriate key lengths (12-24 bytes) and to avoid sharing MKTs among 1007 multiple BGP peering arrangements. 1009 7.3.1. MKT Reuse Across Socket Pairs 1011 MKTs can be reused across different socket pairs within a host, or 1012 across different instances of a socket pair within a host. In either 1013 case, replay protection is maintained. 1015 MKTs reused across different socket pairs cannot enable replay 1016 attacks because the TCP socket pair is included in the MAC, as well 1017 as in the generation of the traffic key. MKTs reused across repeated 1018 instances of a given socket pair cannot enable replay attacks because 1019 the connection ISNs are included in the traffic key generation 1020 algorithm, and ISN pairs are unlikely to repeat over useful periods. 1022 7.3.2. MKTs Use Within a Long-lived Connection 1024 TCP-AO uses sequence number extensions (SNEs) to prevent replay 1025 attacks within long-lived connections. Explicit MKT rollover, 1026 accomplished by external means and indexed using the KeyID field, can 1027 be used to change keying material for various reasons (e.g., 1028 personnel turnover), but is not required to support long-lived 1029 connections. 1031 8. Additional Security Mechanisms 1033 TCP-AO adds mechanisms to support efficient use, especially in 1034 environments where only manual keying is available. These include the 1035 previously described mechanisms for supporting multiple concurrent 1036 MKTs (via the KeyID field) and for generating unique per-connection 1037 traffic keys (via the KDF). This section describes additional 1038 mechanisms to coordinate MKT changes and to prevent replay attacks 1039 when a traffic key is not changed for long periods of time. 1041 8.1. Coordinating Use of New MKTs 1043 At any given time, a single TCP connection may have multiple MKTs 1044 specified for each segment direction (incoming, outgoing). TCP-AO 1045 provides a mechanism to indicate when a new MKT is ready, to allow 1046 the sender to commence use of that new MKT. This mechanism allows new 1047 MKT use to be coordinated, to avoid unnecessary loss due to sender 1048 authentication using a MKT not yet ready at the receiver. 1050 Note that this is intended as an optimization. Deciding when to start 1051 using a key is a performance issue. Deciding when to remove an MKT is 1052 a security issue. Invalid MKTs are expected to be removed. TCP-AO 1053 provides no mechanism to coordinate their removal, as we consider 1054 this a key management operation. 1056 New MKT use is coordinated through two ID fields in the header: 1058 o KeyID 1060 o RNextKeyID 1062 KeyID represents the outgoing MKT information used by the segment 1063 sender to create the segment's MAC (outgoing), and the corresponding 1064 incoming keying information used by the segment receiver to validate 1065 that MAC. It contains the SendID of the MKT in active use in that 1066 direction. 1068 RNextKeyID represents the preferred MKT information to be used for 1069 subsequent received segments ('receive next'). I.e., it is a way for 1070 the segment sender to indicate a ready incoming MKT for future 1071 segments it receives, so that the segment receiver can know when to 1072 switch MKTs (and thus their KeyIDs and associated traffic keys). It 1073 indicates the RecvID of the MKT desired to for incoming segments. 1075 There are two pointers kept by each side of a connection, as noted in 1076 the per-connection information (see Section 6): 1078 o Currently active outgoing MKT (Current_key) 1080 o Current preference for incoming MKT (rnext_key) 1082 Current_key indicates a MKT that is used to authenticate outgoing 1083 segments. Upon connection establishment, it points to the first MKT 1084 selected for use. 1086 Rnext_key points to an incoming MKT that is ready and preferred for 1087 use. Upon connection establishment, this points to the currently 1088 active incoming MKT. It can be changed when new MKTs are installed 1089 (e.g., either by automatic MKT management protocol operation or by 1090 user manual selection). 1092 Rnext_key is changed only by manual user intervention or MKT 1093 management protocol operation. It is not manipulated by TCP-AO. 1094 Current_key is updated by TCP-AO when processing received TCP 1095 segments as discussed in the segment processing description in 1096 Section 9.5. Note that the algorithm allows the current_key to change 1097 to a new MKT, then change back to a previously used MKT (known as 1098 "backing up"). This can occur during a MKT change when segments are 1099 received out of order, and is considered a feature of TCP-AO, because 1100 reordering does not result in drops. The only way to avoid reuse of 1101 previously used MKTs is to remove the MKT when it is no longer 1102 considered permitted. 1104 8.2. Preventing replay attacks within long-lived connections 1106 TCP uses a 32-bit sequence number which may, for long-lived 1107 connections, roll over and repeat. This could result in TCP segments 1108 being intentionally and legitimately replayed within a connection. 1109 TCP-AO prevents replay attacks, and thus requires a way to 1110 differentiate these legitimate replays from each other, and so it 1111 adds a 32-bit sequence number extension (SNE) for transmitted and 1112 received segments. 1114 The SNE extends TCP's sequence number so that segments within a 1115 single connection are always unique. When TCP's sequence number rolls 1116 over, there is a chance that a segment could be repeated in total; 1117 using an SNE differentiates even identical segments sent with 1118 identical sequence numbers at different times in a connection. TCP-AO 1119 emulates a 64-bit sequence number space by inferring when to 1120 increment the high-order 32-bit portion (the SNE) based on 1121 transitions in the low-order portion (the TCP sequence number). 1123 TCP-AO thus maintains SND.SNE for transmitted segments, and RCV.SNE 1124 for received segments, both initialized as zero when a connection 1125 begins. The intent of these SNEs is, together with TCP's 32-bit 1126 sequence numbers, to provide a 64-bit overall sequence number space. 1128 For transmitted segments SND.SNE can be implemented by extending 1129 TCP's sequence number to 64-bits; SND.SNE would be the top (high- 1130 order) 32 bits of that number. For received segments, TCP-AO needs to 1131 emulate the use of a 64-bit number space, and correctly infer the 1132 appropriate high-order 32-bits of that number as RCV.SNE from the 1133 received 32-bit sequence number and the current connection context. 1135 The implementation of SNEs is not specified in this document, but one 1136 possible way is described here that can be used for either RCV.SNE, 1137 SND.SNE, or both. 1139 Consider an implementation with two SNEs as required (SND.SNE, RCV. 1140 SNE), and additional variables as listed below, all initialized to 1141 zero, as well as a current TCP segment field (SEG.SEQ): 1143 o SND.PREV_SEQ, needed to detect rollover of SND.SEQ 1145 o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ 1147 o SND.SNE_FLAG, which indicates when to increment the SND.SNE 1149 o RCV.SNE_FLAG, which indicates when to increment the RCV.SNE 1151 When a segment is received, the following algorithm (in C-like 1152 pseudocode) computes the SNE used in the MAC; this is the "RCV" side, 1153 and an equivalent algorithm can be applied to the "SND" side: 1155 /* set the flag when the SEG.SEQ first rolls over */ 1156 if ((RCV.SNE_FLAG == 0) 1157 && (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) { 1158 RCV.SNE = RCV.SNE + 1; 1159 RCV.SNE_FLAG = 1; 1160 } 1161 /* decide which SNE to use after incremented */ 1162 if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) { 1163 SNE = RCV.SNE - 1; # use the pre-increment value 1164 } else { 1165 SNE = RCV.SNE; # use the current value 1166 } 1167 /* reset the flag in the *middle* of the window */ 1168 if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) { 1169 RCV.SNE_FLAG = 0; 1170 } 1171 /* save the current SEQ for the next time through the code */ 1172 RCV.PREV_SEQ = SEG.SEQ; 1174 In the above code, the first line when the sequence number first 1175 rolls over, i.e., when the new number is low (in the bottom half of 1176 the number space) and the old number is high (in the top half of the 1177 number space). The first time this happens, the SNE is incremented 1178 and a flag is set. 1180 If the flag is set and a high number is seen, it must be a reordered 1181 segment, so use the pre-increment SNE, otherwise use the current SNE. 1183 The flag will be cleared by the time the number rolls all the way 1184 around. 1186 The flag prevents the SNE from being incremented again until the flag 1187 is reset, which happens in the middle of the window (when the old 1188 number is in the bottom half and the new is in the top half). Because 1189 the receive window is never larger than half of the number space, it 1190 is impossible to both set and reset the flag at the same time - 1191 outstanding segments, regardless of reordering, cannot straddle both 1192 regions simultaneously. 1194 9. TCP-AO Interaction with TCP 1196 The following is a description of how TCP-AO affects various TCP 1197 states, segments, events, and interfaces. This description is 1198 intended to augment the description of TCP as provided in RFC-793, 1199 and its presentation mirrors that of RFC-793 as a result [RFC793]. 1201 9.1. TCP User Interface 1203 The TCP user interface supports active and passive OPEN, SEND, 1204 RECEIVE, CLOSE, STATUS and ABORT commands. TCP-AO does not alter this 1205 interface as it applies to TCP, but some commands or command 1206 sequences of the interface need to be modified to support TCP-AO. 1207 TCP-AO does not specify the details of how this is achieved. 1209 TCP-AO requires the TCP user interface be extended to allow the MKTs 1210 to be configured, as well as to allow an ongoing connection to manage 1211 which MKTs are active. The MKTs need to be configured prior to 1212 connection establishment, and the set of MKTs may change during a 1213 connection: 1215 >> TCP OPEN, or the sequence of commands that configure a connection 1216 to be in the active or passive OPEN state, MUST be augmented so that 1217 a MKT can be configured. 1219 >> A TCP-AO implementation MUST allow the set of MKTs for ongoing TCP 1220 connections (i.e., not in the CLOSED state) to be modified. 1222 The MKTs associated with a connection needs to be available for 1223 confirmation; this includes the ability to read the MKTs: 1225 >> TCP STATUS SHOULD be augmented to allow the MKTs of a current or 1226 pending connection to be read (for confirmation). 1228 Senders may need to be able to determine when the outgoing MKT 1229 changes (KeyID) or when a new preferred MKT (RNextKeyID) is 1230 indicated; these changes immediately affect all subsequent outgoing 1231 segments: 1233 >> TCP SEND, or a sequence of commands resulting in a SEND, MUST be 1234 augmented so that the preferred outgoing MKT (Current_key) and/or the 1235 preferred incoming MKT rnext_key of a connection can be indicated. 1237 It may be useful to change the outgoing active MKT (Current_key) even 1238 when no data is being sent, which can be achieved by sending a zero- 1239 length buffer or by using a non-send interface (e.g., socket options 1240 in Unix), depending on the implementation. 1242 It is also useful to indicate recent segment KeyID and RNextKeyID 1243 values received; although there could be a number of such values, 1244 they are not expected to change quickly so any recent sample should 1245 be sufficient: 1247 >> TCP RECEIVE, or the sequence of commands resulting in a RECEIVE, 1248 MUST be augmented so that the KeyID and RNextKeyID of a recently 1249 received segment is available to the user out-of-band (e.g., as an 1250 additional parameter to RECEIVE, or via a STATUS call). 1252 9.2. TCP States and Transitions 1254 TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, 1255 FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and 1256 CLOSED. 1258 >> A MKT MAY be associated with any TCP state. 1260 9.3. TCP Segments 1262 TCP includes control (at least one of SYN, FIN, RST flags set) and 1263 data (none of SYN, FIN, or RST flags set) segments. Note that some 1264 control segments can include data (e.g., SYN). 1266 >> All TCP segments MUST be checked against the set of MKTs for 1267 matching TCP connection identifiers. 1269 >> TCP segments whose TCP-AO does not validate MUST be silently 1270 discarded. 1272 >> A TCP-AO implementation MUST allow for configuration of the 1273 behavior of segments with TCP-AO but that do not match an MKT. The 1274 initial default of this configuration SHOULD be to silently accept 1275 such connections. If this is not the desired case, an MKT can be 1276 included to match such connections, or the connection can indicate 1277 that TCP-AO is required. Alternately, the configuration can be 1278 changed to discard segments with the AO option not matching an MKT. 1280 >> Silent discard events SHOULD be signaled to the user as a warning, 1281 and silent accept events MAY be signaled to the user as a warning. 1282 Both warnings, if available, MUST be accessible via the STATUS 1283 interface. Either signal MAY be asynchronous, but if so they MUST be 1284 rate-limited. Either signal MAY be logged; logging SHOULD allow rate- 1285 limiting as well. 1287 All TCP-AO processing occurs between the interface of TCP and IP; for 1288 incoming segments, this occurs after validation of the TCP checksum. 1289 For outgoing segments, this occurs before computation of the TCP 1290 checksum. 1292 Note that use of TCP-AO on a connection not negotiated within TCP. It 1293 is the responsibility of the receiver to determine when TCP-AO is 1294 required via other means (e.g., out of band, manually or with an key 1295 management protocol) and to enforce that requirement. 1297 9.4. Sending TCP Segments 1299 The following procedure describes the modifications to TCP to support 1300 inserting TCP-AO when a segment departs. 1302 >> Note that TCP-AO MUST be the last TCP option processed on outgoing 1303 segments, because its MAC calculation may include the values of other 1304 TCP options. 1306 1. Find the per-connection parameters for the segment: 1308 a. If the segment is a SYN, then this is the first segment of a 1309 new connection. Find the matching MKT for this segment based 1310 on the segment's socket pair. 1312 i. If there is no matching MKT, omit TCP-AO. Proceed with 1313 transmitting the segment. 1315 ii. If there is a matching MKT, then set the per-connection 1316 parameters as needed (see Section 6). Proceed with the 1317 step 2. 1319 b. If the segment is not a SYN, then determine whether TCP-AO is 1320 being used for the connection and use the MKT as indicated by 1321 the current_key value from the per-connection parameters (see 1322 Section 6) and proceed with the step 2. 1324 2. Using the per-connection parameters: 1326 a. Augment the TCP header with TCP-AO, inserting the appropriate 1327 Length and KeyID based on the MKT indicated by current_key 1328 (using the current_key MKT's SendID as the TCP-AO KeyID). 1329 Update the TCP header length accordingly. 1331 b. Determine SND.SNE as described in Section 8.2. 1333 c. Determine the appropriate traffic key, i.e., as pointed to by 1334 current_key (as noted in Section 8.1, and as probably cached 1335 in the TCB). I.e., use the send_SYN_traffic_key for SYN 1336 segments, and the send_other_traffic_key for other segments. 1338 d. Determine the RNextKeyID as indicated by the rnext_key 1339 pointer, and insert it in the TCP-AO RNextKeyID field (using 1340 the rnext_key MKT's RecvID as the TCP-AO KeyID) (as noted in 1341 Section 8.1). 1343 e. Compute the MAC using the MKT (and cached traffic key) and 1344 data from the segment as specified in Section 7.1. 1346 f. Insert the MAC in the TCP-AO MAC field. 1348 g. Proceed with transmitting the segment. 1350 9.5. Receiving TCP Segments 1352 The following procedure describes the modifications to TCP to support 1353 TCP-AO when a segment arrives. 1355 >> Note that TCP-AO MUST be the first TCP option processed on 1356 incoming segments, because its MAC calculation may include the values 1357 of other TCP options which could change during TCP option processing. 1358 This also protects the behavior of all other TCP options from the 1359 impact of spoofed segments or modified header information. 1361 >> Note that TCP-AO checks MUST be performed for all incoming SYNs to 1362 avoid accepting SYNs lacking TCP-AO where required. Other segments 1363 can cache whether TCP-AO is needed in the TCB. 1365 1. Find the per-connection parameters for the segment: 1367 a. If the segment is a SYN, then this is the first segment of a 1368 new connection. Find the matching MKT for this segment, using 1369 the segment's socket pair and its TCP-AO KeyID, matched 1370 against the MKT's TCP connection identifier and the MKT's 1371 RecvID. 1373 i. If there is no matching MKT, remove TCP-AO from the 1374 segment. Proceed with further TCP handling of the 1375 segment. 1377 NOTE: this presumes that connections that do not match 1378 any MKT should be silently accepted, as noted in Sec 9.3. 1380 ii. If there is a matching MKT, then set the per-connection 1381 parameters as needed (see Section 6). Proceed with the 1382 step 2. 1384 2. Using the per-connection parameters: 1386 a. Check that the segment's TCP-AO Length matches the length 1387 indicated by the MKT. 1389 i. If lengths differ, silently discard the segment. Log 1390 and/or signal the event as indicated in Section 9.3. 1392 b. Determine the segment's RCV.SNE as described in Section 8.2. 1394 c. Determine the segment's traffic key from the MKT as described 1395 in Section 7.1 (and as likely cached in the TCB). I.e., use 1396 the receive_SYN_traffic_key for SYN segments, and the 1397 receive_other_traffic_key for other segments. 1399 d. Compute the segment's MAC using the MKT (and its derived 1400 traffic key) and portions of the segment as indicated in 1401 Section 7.1. 1403 i. If the computed MAC differs from the TCP-AO MAC field 1404 value, silently discard the segment. Log and/or signal 1405 the event as indicated in Section 9.3. 1407 e. Compare the received RNextKeyID value to the currently active 1408 outgoing KeyID value (Current_key MKT's SendID). 1410 i. If they match, no further action is required. 1412 ii. If they differ, determine whether the RNextKeyID MKT is 1413 ready. 1415 1. If the MKT corresponding to the segment's socket 1416 pair and RNextKeyID is not available, no action is 1417 required (RNextKeyID of a received segment needs to 1418 match the MKT's SendID). 1420 2. If the matching MKT corresponding to the segment's 1421 socket pair and RNextKeyID is available: 1423 a. Set Current_key to the RNextKeyID MKT. 1425 f. Proceed with TCP processing of the segment. 1427 It is suggested that TCP-AO implementations validate a segment's 1428 Length field before computing a MAC, to reduce the overhead incurred 1429 by spoofed segments with invalid TCP-AO fields. 1431 Additional reductions in MAC validation overhead can be supported in 1432 the MAC algorithms, e.g., by using a computation algorithm that 1433 prepends a fixed value to the computed portion and a corresponding 1434 validation algorithm that verifies the fixed value before investing 1435 in the computed portion. Such optimizations would be contained in the 1436 MAC algorithm specification, and thus are not specified in TCP-AO 1437 explicitly. Note that the KeyID cannot be used for connection 1438 validation per se, because it is not assumed random. 1440 9.6. Impact on TCP Header Size 1442 TCP-AO, using the initially required 96-bit MACs, uses a total of 16 1443 bytes of TCP header space [Le09]. TCP-AO is thus 2 bytes smaller than 1444 the TCP MD5 option (18 bytes). 1446 Note that TCP option space is most critical in SYN segments, because 1447 flags in those segments could potentially increase the option space 1448 area in other segments. Because TCP ignores unknown segments, 1449 however, it is not possible to extend the option space of SYNs 1450 without breaking backward-compatibility. 1452 TCP's 4-bit data offset requires that the options end 60 bytes (15 1453 32-bit words) after the header begins, including the 20-byte header. 1454 This leaves 40 bytes for options, of which 15 are expected in current 1455 implementations (listed below), leaving at most 25 for other uses. 1456 TCP-AO consumes 16 bytes, leaving 9 bytes for additional SYN options 1457 (depending on implementation dependant alignment padding, which could 1458 consume another 2 bytes at most). 1460 o SACK permitted (2 bytes) [RFC2018][RFC3517] 1461 o Timestamps (10 bytes) [RFC1323] 1463 o Window scale (3 bytes) [RFC1323] 1465 After a SYN, the following options are expected in current 1466 implementations of TCP: 1468 o SACK (10bytes) [RFC2018][RFC3517] (18 bytes if D-SACK [RFC2883]) 1470 o Timestamps (10 bytes) [RFC1323] 1472 TCP-AO continues to consume 16 bytes in non-SYN segments, leaving a 1473 total of 24 bytes for other options, of which the timestamp consumes 1474 10. This leaves 14 bytes, of which 10 are used for a single SACK 1475 block. When two SACK blocks are used, such as to handle D-SACK, a 1476 smaller TCP-AO MAC would be required to make room for the additional 1477 SACK block (i.e., to leave 18 bytes for the D-SACK variant of the 1478 SACK option) [RFC2883]. Note that D-SACK is not supportable in TCP 1479 MD5 in the presence of timestamps, because TCP MD5's MAC length is 1480 fixed and too large to leave sufficient option space. 1482 Although TCP option space is limited, we believe TCP-AO is consistent 1483 with the desire to authenticate TCP at the connection level for 1484 similar uses as were intended by TCP MD5. 1486 9.7. Connectionless Resets 1488 TCP-AO allows TCP resets (RSTs) to be exchanged provided both sides 1489 have established valid connection state. After such state is 1490 established, if one side reboots, TCP-AO prevents TCP's RST mechanism 1491 from clearing out old state on the side that did not reboot. This 1492 happens because the rebooting side has lost its connection state, and 1493 thus its traffic keys. 1495 It is important that implementations are capable of detecting 1496 excesses of TCP connections in such a configuration and can clear 1497 them out if needed to protect its memory usage [Ba09]. To protect 1498 against such state from accumulating and not being cleared out, a 1499 number of recommendations are made: 1501 >> Connections using TCP-AO SHOULD also use TCP keepalives [RFC1122]. 1503 The use of TCP keepalives ensures that connections whose keys are 1504 lost are terminated after a finite time; a similar effect can be 1505 achieved at the application layer, e.g., with BGP keepalives 1506 [RFC4271]. Either kind of keepalive helps ensure the TCP state is 1507 cleared out in such a case; the alternative, of allowing 1508 unauthenticated RSTs to be received, would allow one of the primary 1509 vulnerabilities that TCP-AO is intended to protect against. 1511 Keepalives ensure that connections are dropped across reboots, but 1512 this can have a detrimental effect on some protocols. In specific, 1513 BGP reacts poorly to such connection drops, even if caused by the use 1514 of BGP keepalives; "graceful restart" was introduced to address this 1515 effect [RFC4724], and extended to support BGP with MPLS [RFC4781]. As 1516 a result: 1518 >> BGP connections SHOULD require support for graceful restart when 1519 using TCP-AO. 1521 We recognize that support for graceful restart is not always 1522 feasible. As a result: 1524 >> When BGP without graceful restart is used with TCP-AO, both sides 1525 of the connection SHOULD save traffic keys in storage that persists 1526 across reboots and restore them after a reboot, and SHOULD limit any 1527 performance impacts that result from this storage/restoration. 1529 9.8. ICMP Handling 1531 TCP can be attacked both in-band, using TCP segments, or out-of-band 1532 using ICMP. ICMP packets cannot be protected using TCP-AO mechanisms, 1533 however; in this way, both TCP-AO and IPsec do not directly solve the 1534 need for protected ICMP signaling. TCP-AO does make specific 1535 recommendations on how to handle certain ICMPs, beyond what IPsec 1536 requires, and these are made possible because TCP-AO operates inside 1537 the context of a TCP connection. 1539 IPsec makes recommendations regarding dropping ICMPs in certain 1540 contexts, or requiring that they are endpoint authenticated in others 1541 [RFC4301]. There are other mechanisms proposed to reduce the impact 1542 of ICMP attacks by further validating ICMP contents and changing the 1543 effect of some messages based on TCP state, but these do not provide 1544 the level of authentication for ICMP that TCP-AO provides for TCP 1545 [Go09]. As a result, we recommend a conservative approach to 1546 accepting ICMP messages as summarized in [Go09]: 1548 >> A TCP-AO implementation MUST default to ignore incoming ICMPv4 1549 messages of Type 3 (destination unreachable) Codes 2-4 (protocol 1550 unreachable, port unreachable, and fragmentation needed - 'hard 1551 errors') and ICMPv6 Type 1 (destination unreachable) Code 1 1552 (administratively prohibited) and Code 4 (port unreachable) intended 1553 for connections in synchronized states (ESTABLISHED, FIN-WAIT-1, FIN- 1554 WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT) that match MKTs. 1556 >> A TCP-AO implementation SHOULD allow whether such ICMPs are 1557 ignored to be configured on a per-connection basis. 1559 >> A TCP-AO implementation SHOULD implement measures to protect ICMP 1560 "packet too big" messages, some examples of which are discussed in 1561 [Go09] 1563 >> An implementation SHOULD allow ignored ICMPs to be logged. 1565 This control affects only ICMPs that currently require 'hard errors', 1566 which would abort the TCP connection [RFC1122]. This recommendation 1567 is intended to be similar to how IPsec would handle those messages, 1568 with an additional default assumed [RFC4301]. 1570 10. Obsoleting TCP MD5 and Legacy Interactions 1572 TCP-AO obsoletes TCP MD5. As we have noted earlier: 1574 >> TCP implementations that support TCP MD5 MUST support TCP-AO. 1576 Systems implementing TCP MD5 only are considered legacy, and ought to 1577 be upgraded when possible. In order to support interoperation with 1578 such legacy systems until upgrades are available: 1580 >> TCP MD5 SHOULD be supported where interactions with legacy systems 1581 is needed. 1583 >> A system that supports both TCP-AO and TCP MD5 MUST use TCP-AO for 1584 connections unless not supported by its peer, at which point it MAY 1585 use TCP MD5 instead. 1587 >> A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for a 1588 particular TCP connection, but MAY support TCP-AO and TCP MD5 1589 simultaneously for different connections (notably to support legacy 1590 use of TCP MD5). 1592 The Kind value explicitly indicates whether TCP-AO or TCP MD5 is used 1593 for a particular connection in TCP segments. 1595 It is possible that MKTs could be augmented to support TCP MD5, 1596 although use of MKTs is not described in RFC2385. 1598 It is possible to require TCP-AO for a connection or TCP MD5, but it 1599 is not possible to require 'either'. When an endpoint is configured 1600 to require TCP MD5 for a connection, it must be added to all outgoing 1601 segments and validated on all incoming segments [RFC2385]. TCP MD5's 1602 requirements prohibit the speculative use of both options for a given 1603 connection, e.g., to be decided by the other end of the connection. 1605 11. Interactions with Middleboxes 1607 TCP-AO may interact with middleboxes, depending on their behavior 1608 [RFC3234]. Some middleboxes either alter TCP options (such as TCP-AO) 1609 directly or alter the information TCP-AO includes in its MAC 1610 calculation. TCP-AO may interfere with these devices, exactly where 1611 the device modifies information TCP-AO is designed to protect. 1613 11.1. Interactions with non-NAT/NAPT Middleboxes 1615 TCP-AO supports middleboxes that do not change the IP addresses or 1616 ports of segments. Such middleboxes may modify some TCP options, in 1617 which case TCP-AO would need to be configured to ignore all options 1618 in the MAC calculation on connections traversing that element. 1620 Note that ignoring TCP options may provide less protection, i.e., TCP 1621 options could be modified in transit, and such modifications could be 1622 used by an attacker. Depending on the modifications, TCP could have 1623 compromised efficiency (e.g., timestamp changes), or could cease 1624 correct operation (e.g., window scale changes). These vulnerabilities 1625 affect only the TCP connections for which TCP-AO is configured to 1626 ignore TCP options. 1628 11.2. Interactions with NAT/NAPT Devices 1630 TCP-AO cannot interoperate natively across NAT/NAPT devices, which 1631 modify the IP addresses and/or port numbers. We anticipate that 1632 traversing such devices may require variants of existing NAT/NAPT 1633 traversal mechanisms, e.g., encapsulation of the TCP-AO-protected 1634 segment in another transport segment (e.g., UDP), as is done in IPsec 1635 [RFC2663][RFC3947]. Such variants can be adapted for use with TCP-AO, 1636 or IPsec with NAT traversal can be used instead of TCP-AO in such 1637 cases [RFC3947]. 1639 An alternate proposal for accommodating NATs extends TCP-AO 1640 independently of this specification [To10]. 1642 12. Evaluation of Requirements Satisfaction 1644 TCP-AO satisfies all the current requirements for a revision to TCP 1645 MD5, as summarized below [Be07]. 1647 1. Protected Elements 1649 A solution to revising TCP MD5 should protect (authenticate) the 1650 following elements. 1652 This is supported - see Section 7.1. 1654 a. IP pseudoheader, including IPv4 and IPv6 versions. 1656 Note that we do not allow optional coverage because IP 1657 addresses define a connection. If they can be coordinated 1658 across a NAT/NAPT, the sender can compute the MAC based on the 1659 received values; if not, a tunnel is required, as noted in 1660 Section 11.2. 1662 b. TCP header. 1664 Note that we do not allow optional port coverage because ports 1665 define a connection. If they can be coordinated across a 1666 NAT/NAPT, the sender can compute the MAC based on the received 1667 values; if not, a tunnel is required, as noted in Section 1668 11.2. 1670 c. TCP options. 1672 Note that TCP-AO allows exclusion of TCP options from 1673 coverage, to enable use with middleboxes that modify options 1674 (except when they modify TCP-AO itself). See Section 11. 1676 d. TCP payload data. 1678 2. Option Structure Requirements 1680 A solution to revising TCP MD5 should use an option with the 1681 following structural requirements. 1683 This is supported - see Section 7.1. 1685 a. Privacy. 1687 The option should not unnecessarily expose information about 1688 the TCP-AO mechanism. The additional protection afforded by 1689 keeping this information private may be of little value, but 1690 also helps keep the option size small. 1692 TCP-AO exposes only the MKT IDs, MAC, and overall option 1693 length on the wire. Note that short MACs could be obscured by 1694 using longer option lengths but specifying a short MAC length 1695 (this is equivalent to a different MAC algorithm, and is 1696 specified in the MKT). See Section 4.2. 1698 b. Allow optional per connection. 1700 The option should not be required on every connection; it 1701 should be optional on a per connection basis. 1703 This is supported because the set of MKTs can be installed to 1704 match some connections and not others. Connections not 1705 matching any MKT do not require TCP-AO. Further, incoming 1706 segments with TCP-AO are not discarded solely because they 1707 include the option, provided they do not match any MKT. 1709 c. Require non-optional. 1711 The option should be able to be specified as required for a 1712 given connection. 1714 This is supported because the set of MKTs can be installed to 1715 match some connections and not others. Connections matching 1716 any MKT require TCP-AO. 1718 d. Standard parsing. 1720 The option should be easily parseable, i.e., without 1721 conditional parsing, and follow the standard RFC 793 option 1722 format. 1724 This is supported - see Section 4.2. 1726 e. Compatible with Large Windows and SACK. 1728 The option should be compatible with the use of the Large 1729 Windows and SACK options. 1731 This is supported - see Section 9.6. The size of the option is 1732 intended to allow use with Large Windows and SACK. See also 1733 Section 3.2, which indicates that TCP-AO is 2 bytes shorter 1734 than TCP MD5 in the default case, assuming a 96-bit MAC. 1736 3. Cryptography requirements 1738 A solution to revising TCP MD5 should support modern cryptography 1739 capabilities. 1741 a. Baseline defaults. 1743 The option should have a default that is required in all 1744 implementations. 1746 TCP-AO uses a default required algorithm as specified in 1747 [Le09], as noted in Section 7.1. 1749 b. Good algorithms. 1751 The option should use algorithms considered accepted by the 1752 security community, which are considered appropriately safe. 1753 The use of non-standard or unpublished algorithms should be 1754 avoided. 1756 TCP-AO uses MACs as indicated in [Le09]. The KDF is also 1757 specified in [Le09]. The KDF input string follows the typical 1758 design (see [Le09]). 1760 c. Algorithm agility. 1762 The option should support algorithms other than the default, 1763 to allow agility over time. 1765 TCP-AO allows any desired algorithm, subject to TCP option 1766 space limitations, as noted in Section 4.2. The use of set of 1767 MKTs allows separate connections to use different algorithms, 1768 both for the MAC and the KDF. 1770 d. Order-independent processing. 1772 The option should be processed independently of the proper 1773 order, i.e., they should allow processing of TCP segments in 1774 the order received, without requiring reordering. This avoids 1775 the need for reordering prior to processing, and avoids the 1776 impact of misordered segments on the option. 1778 This is supported - see Sections 9.3, 9.4, and 9.5. Note that 1779 pre-TCP processing is further required, because TCP segments 1780 cannot be discarded solely based on a combination of 1781 connection state and out-of-window checks; many such segments, 1782 although discarded, cause a host to respond with a replay of 1783 the last valid ACK, e.g. [RFC793]. See also the derivation of 1784 the SNE, which is reconstituted at the receiver using a 1785 demonstration algorithm that avoids the need for reordering 1786 (in Section 8.2). 1788 e. Security parameter changes require key changes. 1790 The option should require that the MKT change whenever the 1791 security parameters change. This avoids the need for 1792 coordinating option state during a connection, which is 1793 typical for TCP options. This also helps allow "bump in the 1794 stack" implementations that are not integrated with endpoint 1795 TCP implementations. 1797 Parameters change only when a new MKT is used. See Section 5. 1799 4. Keying requirements. 1801 A solution to revising TCP MD5 should support manual keying, and 1802 should support the use of an external automated key management 1803 system (e.g., a protocol or other mechanism). 1805 Note that TCP-AO does not specify a MKT management system. 1807 a. Intraconnection rekeying. 1809 The option should support rekeying during a connection, to 1810 avoid the impact of long-duration connections. 1812 This is supported by the use of IDs and multiple MKTs; see 1813 Section 5. 1815 b. Efficient rekeying. 1817 The option should support rekeying during a connection without 1818 the need to expend undue computational resources. In 1819 particular, the options should avoid the need to try multiple 1820 keys on a given segment. 1822 This is supported by the use of the KeyID. See Section 8.1. 1824 c. Automated and manual keying. 1826 The option should support both automated and manual keying. 1828 The use of MKTs allows external automated and manual keying. 1829 See Section 5. This capability is enhanced by the generation 1830 of unique per-connection keys, which enables use of manual 1831 MKTs with automatically generated traffic keys as noted in 1832 Section 7.2. 1834 d. Key management agnostic. 1836 The option should not assume or require a particular key 1837 management solution. 1839 This is supported by use of a set of MKTs. See Section 5. 1841 5. Expected Constraints 1843 A solution to revising TCP MD5 should also abide by typical safe 1844 security practices. 1846 a. Silent failure. 1848 Receipt of segments failing authentication must result in no 1849 visible external action and must not modify internal state, 1850 and those events should be logged. 1852 This is supported - see Sections 9.3, 9.4, and 9.5. 1854 b. At most one such option per segment. 1856 Only one authentication option can be permitted per segment. 1858 This is supported by the protocol requirements - see Section 1859 4.2. 1861 c. Outgoing all or none. 1863 Segments out of a TCP connection are either all authenticated 1864 or all not authenticated. 1866 This is supported - see Section 9.4. 1868 d. Incoming all checked. 1870 Segments into a TCP connection are always checked to determine 1871 whether their authentication should be present and valid. 1873 This is supported - see Section 9.5. 1875 e. Non-interaction with TCP MD5. 1877 The use of this option for a given connection should not 1878 preclude the use of TCP MD5, e.g., for legacy use, for other 1879 connections. 1881 This is supported - see Section 9.7. 1883 f. "Hard" ICMP discard. 1885 The option should allow certain ICMPs to be discarded, notably 1886 Type 3 (destination unreachable), Codes 2-4 (transport 1887 protocol unreachable, port unreachable, or fragmentation 1888 needed and IP DF field set), i.e., the ones indicating the 1889 failure of the endpoint to communicate. 1891 This is supported - see Section 13. 1893 g. Maintain TCP connection semantics, in which the socket pair 1894 alone defines a TCP association and all its security 1895 parameters. 1897 This is supported - see Sections 5 and 11. 1899 13. Security Considerations 1901 Use of TCP-AO, like use of TCP MD5 or IPsec, will impact host 1902 performance. Connections that are known to use TCP-AO can be attacked 1903 by transmitting segments with invalid MACs. Attackers would need to 1904 know only the TCP connection ID and TCP-AO Length value to 1905 substantially impact the host's processing capacity. This is similar 1906 to the susceptibility of IPsec to on-path attacks, where the IP 1907 addresses and SPI would be visible. For IPsec, the entire SPI space 1908 (32 bits) is arbitrary, whereas for routing protocols typically only 1909 the source port (16 bits) is arbitrary (typically with less than 16 1910 bits of randomness [La09]). As a result, it would be easier for an 1911 off-path attacker to spoof a TCP-AO segment that could cause receiver 1912 validation effort. However, we note that between Internet routers 1913 both ports could be arbitrary (i.e., determined a-priori out of 1914 band), which would constitute roughly the same off-path antispoofing 1915 protection of an arbitrary SPI. 1917 TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets 1918 typically occur after peer crashes, either in response to new 1919 connection attempts or when data is sent on stale connections; in 1920 either case, the recovering endpoint may lack the connection key 1921 required (e.g., if lost during the crash). This may result in time- 1922 outs, rather than more responsive recovery after such a crash. 1923 Recommendations for mitigating this effect are discussed in Section 1924 9.7. 1926 TCP-AO does not include a fast decline capability, e.g., where a SYN- 1927 ACK is received without an expected TCP-AO and the connection is 1928 quickly reset or aborted. Normal TCP operation will retry and 1929 timeout, which is what should be expected when the intended receiver 1930 is not capable of the TCP variant required anyway. Backoff is not 1931 optimized because it would present an opportunity for attackers on 1932 the wire to abort authenticated connection attempts by sending 1933 spoofed SYN-ACKs without TCP-AO. 1935 TCP-AO is intended to provide similar protections to IPsec, but is 1936 not intended to replace the use of IPsec or IKE either for more 1937 robust security or more sophisticated security management. TCP-AO is 1938 intended to protect the TCP protocol itself from attacks that TLS, 1939 sBGP/soBGP, and other data stream protection mechanism cannot. Like 1940 IPsec, TCP-AO does not address the overall issue of ICMP attacks on 1941 TCP, but does limit the impact of ICMPs, as noted in Section 9.8. 1943 TCP-AO includes the TCP connection ID (the socket pair) in the MAC 1944 calculation. This prevents different concurrent connections using the 1945 same MKT (for whatever reason) from potentially enabling a traffic- 1946 crossing attack, in which segments to one socket pair are diverted to 1947 attack a different socket pair. When multiple connections use the 1948 same MKT, it would be useful to know that segments intended for one 1949 ID could not be (maliciously or otherwise) modified in transit and 1950 end up being authenticated for the other ID. That requirement would 1951 place an additional burden of uniqueness on MKTs within endsystems, 1952 and potentially across endsystems. Although the resulting attack is 1953 low probability, the protection afforded by including the received ID 1954 warrants its inclusion in the MAC, and does not unduly increase the 1955 MAC calculation or MKT management. 1957 The use of any security algorithm can present an opportunity for a 1958 CPU DOS attack, where the attacker sends false, random segments that 1959 the receiver under attack expends substantial CPU effort to reject. 1960 In IPsec, such attacks are reduced by the use of a large Security 1961 Parameter Index (SPI) and Sequence Number fields to partly validate 1962 segments before CPU cycles are invested validated the Integrity Check 1963 Value (ICV). In TCP-AO, the socket pair performs most of the function 1964 of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay 1965 attacks, isn't needed due to TCP's Sequence Number, which is used to 1966 reorder received segments (provided the sequence number doesn't wrap 1967 around, which is why TCP-AO adds the SNE in Section 8.2). TCP already 1968 protects itself from replays of authentic segment data as well as 1969 authentic explicit TCP control (e.g., SYN, FIN, ACK bits, but even 1970 authentic replays could affect TCP congestion control [Sa99]. TCP-AO 1971 does not protect TCP congestion control from this last form of attack 1972 due to the cumbersome nature of layering a windowed security sequence 1973 number within TCP in addition to TCP's own sequence number; when such 1974 protection is desired, users are encouraged to apply IPsec instead. 1976 Further, it is not useful to validate TCP's Sequence Number before 1977 performing a TCP-AO authentication calculation, because out-of-window 1978 segments can still cause valid TCP protocol actions (e.g., ACK 1979 retransmission) [RFC793]. It is similarly not useful to add a 1980 separate Sequence Number field to TCP-AO, because doing so could 1981 cause a change in TCP's behavior even when segments are valid. 1983 14. IANA Considerations 1985 [Paragraphs below in braces should be removed by the RFC Editor upon 1986 publication] 1988 [TCP-AO requires that IANA allocate a value from the TCP option Kind 1989 namespace, to be replaced for TCP-IANA-KIND throughout this 1990 document.] 1992 [The entry for the TCP MD5 option should be listed as "Obsoleted by 1993 TCP-AO in IANA tables.] 1995 The TCP Authentication Option (TCP-AO) was assigned TCP option TCP- 1996 IANA-KIND by IANA action. 1998 This document defines no new namespaces. 2000 To specify MAC and KDF algorithms, TCP-AO refers to a separate 2001 document that may involve IANA actions [Le09]. 2003 15. References 2005 15.1. Normative References 2007 [Le09] Lebovitz, G., E. Rescorla, "Cryptographic Algorithms for 2008 TCP's Authentication Option, TCP-AO", draft-ietf-tcpm-tcp- 2009 ao-crypto-02, Oct. 2009. 2011 [RFC793] Postel, J., "Transmission Control Protocol," STD-7, 2012 RFC-793, Standard, Sept. 1981. 2014 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 2015 Communication Layers," RFC-1122, Oct. 1989. 2017 [RFC2018] Mathis, M., J. Mahdavi, S. Floyd, A. Romanow, "TCP 2018 Selective Acknowledgement Options", RFC-2018, Proposed 2019 Standard, April 1996. 2021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2022 Requirement Levels", BCP-14, RFC-2119, Best Current 2023 Practice, March 1997. 2025 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 2026 Signature Option," RFC-2385, Proposed Standard, Aug. 1998. 2028 [RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP 2029 and AH," RFC-2403, Proposed Standard, Nov. 1998. 2031 [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6 2032 (IPv6) Specification," RFC-2460, Proposed Standard, Dec. 2033 1998. 2035 [RFC2883] Floyd, S., J. Mahdavi, M. Mathis, M. Podolsky, "An 2036 Extension to the Selective Acknowledgement (SACK) Option 2037 for TCP", RFC-2883, Proposed Standard, July 2000. 2039 [RFC3517] Blanton, E., M. Allman, K. Fall, L. Wang, "A Conservative 2040 Selective Acknowledgment (SACK)-based Loss Recovery 2041 Algorithm for TCP", RFC-3517, Proposed Standard, April 2042 2003. 2044 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," 2045 RFC-4306, Proposed Standard, Dec. 2005. 2047 [RFC4724] Sangli, S., E. Chen, R. Fernando, J. Scudder, Y. Rekhter, 2048 "Graceful Restart Mechanism for BGP," RFC-4724, Jan. 2007. 2050 [RFC4271] Rekhter, Y, T. Li, S. Hares, "A Border Gateway Protocol 4 2051 (BGP-4)," RFC-4271, Jan. 2006. 2053 [RFC4781] Rekhter, Y., R. Aggarwal, "Graceful Restart Mechanism for 2054 BGP with MPLS," RFC-4781, Jan. 2007. 2056 15.2. Informative References 2058 [Ba09] Bashyam, M., M. Jethanandani,, A. Ramaiah "Clarification of 2059 sender behaviour in persist condition," draft-ananth-tcpm- 2060 persist-02, (work in progress), Jan. 2010. 2062 [Be07] Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem 2063 Statement and Requirements for a TCP Authentication 2064 Option," draft-bellovin-tcpsec-01, (work in progress), Jul. 2065 2007. 2067 [Bo07] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler, 2068 "Authentication for TCP-based Routing and Management 2069 Protocols," draft-bonica-tcp-auth-06, (work in progress), 2070 Feb. 2007. 2072 [Bo09] Borman, D., "TCP Options and MSS," draft-ietf-tcpm-tcpmss- 2073 02, Jul. 2009. 2075 [La09] Larsen, M., F. Gont, "Port Randomization," draft-ietf- 2076 tsvwg-port-randomization-06, Feb. 2010. 2078 [Go09] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- 2079 attacks-11, (work in progress), Feb. 2010. 2081 [Le09] Lepinski, M., S. Kent, "An Infrastructure to Support Secure 2082 Internet Routing," draft-ietf-sidr-arch-09, (work in 2083 progress), Oct. 2009. 2085 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, 2086 Informational, April 1992. 2088 [RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for 2089 High Performance," RFC-1323, May 1992. 2091 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks," 2092 RFC-1948, Informational, May 1996. 2094 [RFC2104] Krawczyk, H., M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 2095 for Message Authentication," RFC-2104, Informational, Feb. 2096 1997. 2098 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 2099 Translator (NAT) Terminology and Considerations", RFC 2663, 2100 August 1999. 2102 [RFC3234] Carpenter, B., S. Brim, "Middleboxes: Taxonomy and Issues," 2103 RFC-3234, Informational, Feb. 2002. 2105 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 2106 Signature Option," RFC-3562, Informational, July 2003. 2108 [RFC3947] Kivinen, T., B. Swander, A. Huttunen, V. Volpe, 2109 "Negotiation of NAT-Traversal in the IKE," RFC-3947, 2110 Proposed Standard, Jan. 2005. 2112 [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet 2113 Protocol," RFC-4301, Proposed Standard, Dec. 2005. 2115 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5," 2116 RFC-4808, Informational, Mar. 2007. 2118 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks," 2119 RFC-4953, Informational, Jul. 2007. 2121 [RFC5246] Dierks, T., E. Rescorla, "The Transport Layer Security 2122 (TLS) Protocol Version 1.2," RFC-5246, Aug. 2008. 2124 [Sa99] Savage, S., N. Cardwell, D. Wetherall, T. Anderson, "TCP 2125 Congestion Control with a Misbehaving Receiver," ACM 2126 Computer Communications Review, V29, N5, pp71-78, October 2127 1999. 2129 [SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4)," 2130 Specification SDN.401, Revision 1.2, July 12, 1988. 2132 [To06] Touch, J., A. Mankin, "The TCP Simple Authentication 2133 Option," draft-touch-tcpm-tcp-simple-auth-03, (expired work 2134 in progress), Oct. 2006. 2136 [To10] Touch, J., "A TCP Authentication Option NAT Extension," 2137 draft-touch-tcp-ao-nat-01, Jan. 2010. 2139 [Wa05] Wang, X., H. Yu, "How to break MD5 and other hash 2140 functions," Proc. IACR Eurocrypt 2005, Denmark, pp.19-35. 2142 [We05] Weis, B., "TCP Message Authentication Code Option," draft- 2143 weis-tcp-mac-option-00, (expired work in progress), Dec. 2144 2005. 2146 16. Acknowledgments 2148 Alfred Hoenes, Charlie Kaufman, Adam Langley, and numerous other 2149 members of the TCPM WG provided substantial feedback on this 2150 document. 2152 This document was prepared using 2-Word-v2.0.template.dot. 2154 Authors' Addresses 2156 Joe Touch 2157 USC/ISI 2158 4676 Admiralty Way 2159 Marina del Rey, CA 90292-6695 2160 U.S.A. 2162 Phone: +1 (310) 448-9151 2163 Email: touch@isi.edu 2164 URL: http://www.isi.edu/touch 2166 Allison Mankin 2167 Johns Hopkins Univ. 2168 Washington, DC 2169 U.S.A. 2171 Phone: 1 301 728 7199 2172 Email: mankin@psg.com 2173 URL: http://www.psg.com/~mankin/ 2175 Ronald P. Bonica 2176 Juniper Networks 2177 2251 Corporate Park Drive 2178 Herndon, VA 20171 2179 U.S.A. 2181 Email: rbonica@juniper.net