idnits 2.17.1 draft-ietf-tcpm-tcp-auth-opt-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The 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 923 has weird spacing: '...fic_key r-I...' == Line 925 has weird spacing: '...fic_key r-IP ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2009) is 5410 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) ** 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 (-12) exists of draft-ietf-tcpm-icmp-attacks-05 -- Unexpected draft version: The latest known version of draft-mahesh-persist-timeout is -02, but you're referring to -03. -- 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 2766 (Obsoleted by RFC 4966) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 8 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: January 2010 R. Bonica 6 Juniper Networks 7 July 3, 2009 9 The TCP Authentication Option 10 draft-ietf-tcpm-tcp-auth-opt-05.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on January 3, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document specifies the TCP Authentication Option (TCP-AO), which 49 obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO 50 specifies the use of stronger Message Authentication Codes (MACs), 51 protects against replays even for long-lived TCP connections, and 52 provides more details on the association of security with TCP 53 connections than TCP MD5. TCP-AO is compatible with either static 54 master key tuple (MKT) configuration or an external, out-of-band MKT 55 management mechanism; in either case, TCP-AO also protects 56 connections when using the same MKT across repeated instances of a 57 connection, using traffic keys derived from the MKT, and coordinates 58 MKT changes between endpoints. The result is intended to support 59 current infrastructure uses of TCP MD5, such as to protect long-lived 60 connections (as used, e.g., in BGP and LDP), and to support a larger 61 set of MACs with minimal other system and operational changes. TCP-AO 62 uses its own option identifier, even though used mutually exclusive 63 of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is 64 fully compatible with the requirements for the replacement of TCP 65 MD5. 67 Table of Contents 69 1. Contributors...................................................3 70 2. Introduction...................................................3 71 2.1. Executive Summary.........................................4 72 2.2. Changes from Previous Versions............................6 73 2.2.1. New in draft-ietf-tcp-auth-opt-05....................6 74 3. Conventions used in this document..............................7 75 4. The TCP Authentication Option..................................7 76 4.1. Review of TCP MD5 Option..................................8 77 4.2. The TCP-AO Option.........................................8 78 5. TCP-AO Keys and Their Properties..............................10 79 5.1. Master Key Tuple.........................................10 80 5.2. Traffic Keys.............................................12 81 5.3. MKT Properties...........................................13 82 6. Per-Connection TCP-AO Parameters..............................14 83 7. Cryptographic Algorithms......................................15 84 7.1. MAC Algorithms...........................................15 85 7.2. Key Derivation Functions.................................18 86 7.3. Traffic Key Establishment and Duration Issues............22 87 7.3.1. MKT Reuse Across Socket Pairs.......................22 88 7.3.2. MKTs Use Within a Long-lived Connection.............23 89 8. Additional Security Mechanisms................................23 90 8.1. Coordinating MKT Changes.................................23 91 8.2. Preventing replay attacks within long-lived connections..24 93 9. TCP-AO Interaction with TCP...................................26 94 9.1. TCP User Interface.......................................27 95 9.2. TCP States and Transitions...............................28 96 9.3. TCP Segments.............................................28 97 9.4. Sending TCP Segments.....................................28 98 9.5. Receiving TCP Segments...................................30 99 9.6. Impact on TCP Header Size................................32 100 10. Obsoleting TCP MD5 and Legacy Interactions...................33 101 11. Interactions with Middleboxes................................33 102 11.1. Interactions with non-NAT/NAPT Middleboxes..............34 103 11.2. Interactions with NAT/NAPT Devices......................34 104 12. Evaluation of Requirements Satisfaction......................34 105 13. Security Considerations......................................40 106 14. IANA Considerations..........................................42 107 15. References...................................................43 108 15.1. Normative References....................................43 109 15.2. Informative References..................................44 110 16. Acknowledgments..............................................45 112 1. Contributors 114 This document evolved as the result of collaboration of the TCP 115 Authentication Design team (tcp-auth-dt), whose members were 116 (alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy, 117 Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy 118 Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus 119 Westerlund. The text of this document is derived from a proposal by 120 Joe Touch and Allison Mankin [To06] (originally from June 2006), 121 which was both inspired by and intended as a counterproposal to the 122 revisions to TCP MD5 suggested in a document by Ron Bonica, Brian 123 Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07] 124 (originally from Sept. 2005) and in a document by Brian Weis [We05]. 126 Russ Housley suggested L4/application layer management of the master 127 key tuples. Steve Bellovin motivated the KeyID field. Eric Rescorla 128 suggested the use of ISNs in the traffic key computation and SNEs to 129 avoid replay attacks, and Brian Weis extended the computation to 130 incorporate the entire connection ID and provided the details of the 131 traffic key computation. Mark Allman, Wes Eddy, Lars Eggert, Ted 132 Faber, Russ Housley, Gregory Lebovitz, Tim Polk, Eric Rescorla, Joe 133 Touch, and Brian Weis developed the master key coordination 134 mechanism. 136 2. Introduction 138 The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates 139 TCP segments, including the TCP IPv4 pseudoheader, TCP header, and 140 TCP data. It was developed to protect BGP sessions from spoofed TCP 141 segments which could affect BGP data or the robustness of the TCP 142 connection itself [RFC2385][RFC4953]. 144 There have been many recent concerns about TCP MD5. Its use of a 145 simple keyed hash for authentication is problematic because there 146 have been escalating attacks on the algorithm itself [Wa05]. TCP MD5 147 also lacks both key management and algorithm agility. This document 148 adds the latter, and provides a simple key coordination mechanism 149 giving the ability to move from one key to another within the same 150 connection. It does not however provide for complete cryptographic 151 key management to be handled in-band of TCP, because TCP SYN segments 152 lack sufficient remaining space to handle such a negotiation (see 153 Section 9.6). This document obsoletes the TCP MD5 option with a more 154 general TCP Authentication Option (TCP-AO), to support the use of 155 other, stronger hash functions, provide replay protection for long- 156 lived connections and across repeated instances of a single 157 connection, coordinate key changes between endpoints, and to provide 158 a more structured recommendation on external key management. The 159 result is compatible with IPv6, and is fully compatible with 160 requirements under development for a replacement for TCP MD5 [Be07]. 162 This document is not intended to replace the use of the IPsec suite 163 (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In 164 fact, we recommend the use of IPsec and IKE, especially where IKE's 165 level of existing support for parameter negotiation, session key 166 negotiation, or rekeying are desired. TCP-AO is intended for use only 167 where the IPsec suite would not be feasible, e.g., as has been 168 suggested is the case to support some routing protocols, or in cases 169 where keys need to be tightly coordinated with individual transport 170 sessions [Be07]. 172 Note that TCP-AO obsoletes TCP MD5, although a particular 173 implementation may support both mechanisms for backward 174 compatibility. For a given connection, only one can be in use. TCP 175 MD5-protected connections cannot be migrated to TCP-AO because TCP 176 MD5 does not support any changes to a connection's security algorithm 177 once established. 179 2.1. Executive Summary 181 This document replaces TCP MD5 as follows [RFC2385]: 183 o TCP-AO uses a separate option Kind for TCP-AO (TBD-IANA-KIND). 185 o TCP-AO allows TCP MD5 to continue to be used concurrently for 186 legacy connections. 188 o TCP-AO replaces MD5's single MAC algorithm with MACs specified in 189 a separate document and can be extended to include other MACs. 191 o TCP-AO allows rekeying during a TCP connection, assuming that an 192 out-of-band protocol or manual mechanism provides the new keys. 193 The option includes a key ID which allows the efficient concurrent 194 use of multiple keys, and a key coordination mechanism using a 195 next key ID manages the key change within a connection. Note that 196 TCP MD5 does not preclude rekeying during a connection, but does 197 not require its support either. Further, TCP-AO supports key 198 changes with zero packet loss, whereas key changes in TCP MD5 can 199 lose packets in transit during the changeover or require trying 200 multiple keys on each received segment during key use overlap 201 because it lacks an explicit key ID. 203 o TCP-AO provides automatic replay protection for long-lived 204 connections using sequence number extensions. 206 o TCP-AO ensures per-connection traffic keys as unique as the TCP 207 connection itself, using TCP's initial sequence numbers (ISNs) for 208 differentiation, even when static master key tuples are used 209 across repeated instances of connections on a single socket pair. 211 o TCP-AO specifies the details of how this option interacts with 212 TCP's states, event processing, and user interface. 214 o The TCP-AO option is 2 bytes shorter than TCP MD5 (16 bytes 215 overall, rather than 18) in the initially specified default case 216 (using a 96-bit MAC). 218 This document differs from an IPsec/IKE solution in that TCP-AO as 219 follows [RFC4301][RFC4306]: 221 o TCP-AO does not support dynamic parameter negotiation. 223 o TCP-AO uses TCP's socket pair (source address, destination 224 address, source port, destination port) as a security parameter 225 index, rather than using a separate field as an index (IPsec's 226 SPI). 228 o TCP-AO forces a change of computed MACs when a connection 229 restarts, even when reusing a TCP socket pair (IP addresses and 230 port numbers) [Be07]. 232 o TCP-AO does not support encryption. 234 o TCP-AO does not authenticate ICMP messages (some ICMP messages may 235 be authenticated when using IPsec, depending on the 236 configuration). 238 2.2. Changes from Previous Versions 240 [NOTE: to be omitted upon final publication as RFC] 242 2.2.1. New in draft-ietf-tcp-auth-opt-05 244 o Summary of changes: 246 o Remove TSAD; replace with discussion of MKTs directly. 248 o Change most references of IDs to refer to MKTs directly. 250 o Update and minimize interface to [crypto-ao]. 252 o Removed "what's new" going back more than one version (full 253 changelist available from the authors) 255 o Issue tracker responses (http://tools.ietf.org/wg/tcpm/): 257 o 1 Confusion between master & traffic keys, and key-ids. Done. 259 o 2 Clarify relationship between master and traffic keys - use 260 diagram given. Done. 262 o 3 TSAD concept - Removed. 264 o 4 Option flag description - Removed 0/1 values. 266 o 5 TAPD details - TAPD removed. 268 o 6 KeyId versus master key - Current_key now points to a MKT, 269 not an ID. 271 o 7 ESN versus SNE - Used "sequence number extension" rather 272 than "extended sequence number". 274 o 8 "typically" in traffic key storage - Replaced with 'can be'. 276 o 9 MAC truncation & padding - Removed / refers only to existing 277 components of [crypto-ao]. 279 o 10 SYN traffic keys - explain directionality and that typically 280 only one is needed. Done. 282 o 11 Master key for LISTEN - (TAPD issue) Removed with TAPD 283 removal. 285 o 15 Text clarifying traffic keys (related to issues 1,2) - 286 Done in Section 5.2. 288 o 16 Text for key coordination - Not inserted, since based on 289 behavior that was decided against in the WG meeting (e.g., 290 that installing keys makes them preferred, that 2MSL forces 291 keys out of use altogether, and that endpoints sync key 292 changes). 294 o Items from SFO IETF meeting 296 o 1. TCP-AO key coordination allows 'backup' 298 o 2. Clarify names for key entities (issues 1,2) 300 o 3. Address the timers (part of bugtrack item 5) 302 o 4. Move TAPD to the appendix (issues 3, 5) - removed. 304 o Other issues raised on the list: 306 o ICMP handling - already does as IPsec does. No changes made. 308 3. Conventions used in this document 310 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 311 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 312 document are to be interpreted as described in RFC-2119 [RFC2119]. 314 In this document, these words will appear with that interpretation 315 only when in ALL CAPS. Lower case uses of these words are not to be 316 interpreted as carrying RFC-2119 significance. 318 In this document, the characters ">>" proceeding an indented line(s) 319 indicates a compliance requirement statement using the key words 320 listed above. This convention aids reviewers in quickly identifying 321 or finding this RFC's explicit compliance requirements. 323 4. The TCP Authentication Option 325 The TCP Authentication Option (TCP-AO) uses a TCP option Kind value 326 of TBD-IANA-KIND. 328 4.1. Review of TCP MD5 Option 330 For review, the TCP MD5 option is shown in Figure 1. 332 +---------+---------+-------------------+ 333 | Kind=19 |Length=18| MD5 digest... | 334 +---------+---------+-------------------+ 335 | | 336 +---------------------------------------+ 337 | | 338 +---------------------------------------+ 339 | | 340 +-------------------+-------------------+ 341 | | 342 +-------------------+ 344 Figure 1 The TCP MD5 Option [RFC2385] 346 In the TCP MD5 option, the length is fixed, and the MD5 digest 347 occupies 16 bytes following the Kind and Length fields, using the 348 full MD5 digest of 128 bits [RFC1321]. 350 The TCP MD5 option specifies the use of the MD5 digest calculation 351 over the following values in the following order: 353 1. The TCP pseudoheader (IP source and destination addresses, 354 protocol number, and segment length). 356 2. The TCP header excluding options and checksum. 358 3. The TCP data payload. 360 4. A key. 362 4.2. The TCP-AO Option 364 The new TCP-AO option provides a superset of the capabilities of TCP 365 MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new 366 Kind field, and similar Length field to TCP MD5, a KeyID field, and a 367 NextKeyID field as shown in Figure 2. 369 +-----------+-----------+-----------+-----------+ 370 | Kind | Length | KeyID | NextKeyID | 371 +-----------+-----------+-----------+-----------+ 372 | MAC ... 373 +-----------------------------------... 375 ...-----------------+ 376 ... MAC (con't) | 377 ...-----------------+ 379 Figure 2 The TCP-AO Option 381 The TCP-AO defines the following fields: 383 o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP- 384 AO uses a new Kind value of TBD-IANA-KIND. 386 >> An endpoint MUST NOT use TCP-AO for the same connection in 387 which TCP MD5 is used. 389 >> A single TCP segment MUST NOT have more than one TCP-AO option. 391 o Length: An unsigned 1-byte field indicating the length of the TCP- 392 AO option in bytes, including the Kind, Length, KeyID, NextKeyID, 393 and MAC fields. 395 >> The Length value MUST be greater than or equal to 4. 397 >> The Length value MUST be consistent with the TCP header length; 398 this is a consistency check and avoids overrun/underrun abuse. 400 Values of 4 and other small values larger than 4 (e.g., indicating 401 MACs of very short length) are of dubious utility but are not 402 specifically prohibited. 404 o KeyID: An unsigned 1-byte field used to support efficient key 405 changes during a connection and/or to help with key coordination 406 during connection establishment, to be discussed further in 407 Section 8.1. Note that the KeyID has no cryptographic properties - 408 it need not be random, nor are there any reserved values. 410 o NextKeyID: An unsigned 1-byte field used to support efficient key 411 change coordination, to be discussed further in Section 8.1. Note 412 that the NextKeyID has no cryptographic properties - it need not 413 be random, nor are there any reserved values. 415 o MAC: Message Authentication Code. Its contents are determined by 416 the particulars of the security association. Typical MACs are 96- 417 128 bits (12-16 bytes), but any length that fits in the header of 418 the segment being authenticated is allowed. The MAC computation is 419 described further in Section 7.1. 421 >> Required support for TCP-AO MACs as defined in [ao-crypto]; 422 other MACs MAY be supported. 424 The TCP-AO option fields do not indicate the MAC algorithm either 425 implicitly (as with TCP MD5) or explicitly. The particular algorithm 426 used is considered part of the configuration state of the 427 connection's security and is managed separately (see Section 5). 429 The remainder of this document explains how the TCP-AO option is 430 handled and its relationship to TCP. 432 5. TCP-AO Keys and Their Properties 434 TCP-AO relies on a two sets of keys to authenticate incoming and 435 outgoing segments: master key tuples (MKTs) and traffic keys. MKTs 436 are used to derive unique traffic keys, and include the keying 437 material used to generate those traffic keys, as well as indicating 438 the associated parameters under which traffic keys are used. Such 439 parameters include whether TCP options are authenticated, and 440 indicators of the algorithms used for traffic key derivation and MAC 441 calculation. Traffic keys are the keying material used to compute the 442 MAC of individual TCP segments. 444 5.1. Master Key Tuple 446 A Master Key Tuple (MKT) describes TCP-AO properties to be associated 447 with one or more connections. It is composed of the following: 449 o TCP connection identifier. A TCP socket pair, i.e., a local IP 450 address, a remote IP address, a TCP local port, and a TCP remote 451 port. Values can be partially specified using ranges (e.g., 2-30), 452 masks (e.g., 0xF0), wildcards (e.g., "*"), or any other suitable 453 indication. 455 o TCP option flag. This flag indicates whether TCP options other 456 than TCP-AO are included in the MAC calculation. When options are 457 included, the content of all options, in the order present, are 458 included in the MAC, with TCP-AO's MAC field zeroed out. When the 459 options are not included, all options other than TCP-AO are 460 excluded from all MAC calculations (skipped over, not zeroed). 461 Note that TCP-AO, with its MAC field zeroed out, is always 462 included in the MAC calculation, regardless of the setting of this 463 flag; this protects the indication of the MAC length as well as 464 the key ID fields (KeyID, NextKeyID). The option flag applies to 465 TCP options in both directions (incoming and outgoing segments). 467 o IDs. The values used in the KeyID or NextKeyID of a TCP-AO option; 468 used to differentiate MKTs in concurrent use, as well as to 469 indicate when MKTs are ready for use. 471 Each MKT has two IDs - a SendID and a RecvID. The SendID is 472 inserted as the KeyID of the TCP-OP option of outgoing segments, 473 and the RecvID is matched against the KeyID of the TCP-AO option 474 of incoming segments. These and other uses of these two IDs are 475 described further in Section 9.4 and 9.5. 477 >> MKT IDs MUST support any value, 0-255 inclusive. There are no 478 reserved ID values. 480 ID values are assigned arbitrarily. They can be assigned in 481 sequence, or based on any method mutually agreed by the connection 482 endpoints (e.g., using an external MKT management mechanism). 484 >> IDs MUST NOT be assumed to be randomly assigned. 486 o Master key. A byte sequence used for generating traffic keys, this 487 may be derived from a separate shared key by an external protocol 488 over a separate channel. This sequence is used in the traffic key 489 generation algorithm described in Section 7.2. 491 Implementations are advised to keep master key values in a 492 private, protected area of memory or other storage. 494 o Key Derivation Function (KDF). Indicates the key derivation 495 function and its parameters, as used to generate traffic keys from 496 master keys. Explained further in Section 7.1 [ao-crypto]. 498 o Message Authentication Code (MAC) algorithm. Indicates the MAC 499 algorithm and its parameters as used for this connection, 500 explained further in Section 7.1 [ao-crypto]. 502 >> Components of a MKT MUST NOT change during a connection. 504 MKT component values cannot change during a connection because TCP 505 state is coordinated during connection establishment. TCP lacks a 506 handshake for modifying that state after a connection has been 507 established. 509 >> The set of MKTs MAY change during a connection. 511 MKT parameters are not changed. Instead, new MKTs can be installed, 512 and a connection can change which MKT it uses. 514 >> The IDs of MKTs MUST NOT overlap where their TCP connection 515 identifiers overlap. 517 This document does not address how MKTs are created by users or 518 processes. It is presumed that a MKT affecting a particular 519 connection cannot be destroyed during an active connection - or, 520 equivalently, that its parameters are copied to an area local to the 521 connection (i.e., instantiated) and so changes would affect only new 522 connections. The MKTs can be managed by a separate application 523 protocol. 525 5.2. Traffic Keys 527 A traffic key is a key derived from the MKT and the properties of a 528 connection. For established connections, these properties include the 529 socket pair (local IP address, local TCP port, remote IP address, 530 remote port), and the TCP Initial Sequence Numbers (ISNs) in each 531 direction. Segments exchanged before a connection is established use 532 the same information, substituting zero for unknown values (e.g., 533 ISNs not yet coordinated). 535 A single MKT derives four different MKTs: 537 o Send_SYN_traffic_key 539 o Receive_SYN_traffic_key 541 o Send_other_traffic_key 543 o Receive_other_traffic_key 545 Note that the keys are directional. A given connection typically uses 546 only three of these keys, because only one of the SYN keys is 547 typically used. All four are used only when a connection goes through 548 'simultaneous open' [RFC793]. 550 The relationship between MKTs and traffic keys is shown in Figure 551 Figure 3. Traffic keys are indicated with a "*". Note that every MKT 552 derives all four traffic keys, regardless of whether all four are 553 needed for a given connection. Section 7.2 provides further details 554 on how traffic keys are derived. 556 MKT-A MKT-B 557 +---------------------+ +------------------------+ 558 | SendID = 1 | | SendID = 5 | 559 | RecvID = 2 | | RecvID = 6 | 560 | MAC = HMAC-SHA1 | | MAC = AES-CMAC | 561 | KDF = KDF-HMAC-SHA1 | | KDF = KDF-AES-128-CMAC | 562 +---------------------+ +------------------------+ 563 | | 564 +----------+----------+ | 565 | | | 566 v v v 567 Connection 1 Connection 2 Connection 3 568 +------------------+ +------------------+ +------------------+ 569 | * Send_SYN_key | | * Send_SYN_key | | * Send_SYN_key | 570 | * Recv_SYN_key | | * Recv_SYN_key | | * Recv_SYN_key | 571 | * Send_Other_key | | * Send_Other_key | | * Send_Other_key | 572 | * Send_Other_key | | * Send_Other_key | | * Send_Other_key | 573 +------------------+ +------------------+ +------------------+ 575 Figure 3 Relationship between MKTs and traffic keys 577 5.3. MKT Properties 579 TCP-AO requires that every protected TCP segment match exactly one 580 MKT. When an outgoing segment matches an MKT, TCP-AO is used. When no 581 match occurs, TCP-AO is not used. Multiple MKTs may match a single 582 outgoing segment, e.g., when MKTs are being changed. Those MKTs 583 cannot have conflicting IDs (as noted elsewhere), and some mechanism 584 must determine which MKT to use for each given outgoing segment. 586 >> An outgoing TCP segment MUST match at most one desired MKT, 587 indicated by the segment's socket pair. The segment MAY match 588 multiple MKTs, provided that exactly one MKT is indicated as desired. 589 Other information in the segment MAY be used to determine the desired 590 MKT when multiple MKTs match; such information MUST NOT include 591 values in TCP option fields. 593 We recommend that the mechanism used to select from among multiple 594 MKTs use only information that TCP-AO would authenticate. Because 595 MKTs may indicate that non-TCP-AO options are ignored in the MAC 596 calculation, we recommend that TCP options should not be used to 597 determine MKTs. 599 >> An incoming TCP segment containing the TCP-AO option MUST match at 600 exactly one MKT, indicated solely by the segment's socket pair and 601 its TCP-AO KeyID. 603 Incoming segments include an indicator in the TCP-AO option to select 604 from among multiple matching MKTs - the KeyID field. TCP-AO requires 605 that the KeyID alone be used to differentiate multiple matching MKTs, 606 so that MKT changes can be coordinated using the TCP-AO key change 607 coordination mechanism. 609 >> When an outgoing TCP segment matches no MKTs, TCP-AO is not used. 611 TCP-AO is always used when outgoing segments match an MKT, and is not 612 used otherwise. 614 6. Per-Connection TCP-AO Parameters 616 TCP-AO uses a small number of parameters associated with each 617 connection that uses the TCP-AO option, once instantiated. These 618 values can be stored in the Transport Control Block (TCP) [RFC793]. 619 These values are explained in subsequent sections of this document as 620 noted; they include: 622 1. Current_key - the MKT currently used to authenticate outgoing 623 segments, whose SendID is inserted in outgoing segments as KeyID 624 (see Section 9.4, step 5). Incoming segments are authenticated 625 using the MKT corresponding to the segment and the KeyID in its 626 TCP-AO header (see Section 9.5, step 5), as matched against the 627 MKT TCP connection identifier and the MKT RecvID. There is only 628 one current_key at any given time on a particular connection. 630 >> Every TCP connection in a non-IDLE state MUST have at most one 631 current_key specified. 633 2. Next_key -the MKT currently preferred for future use, whose RecvID 634 is inserted in outgoing segments as NextKeyID (see Section 9.5, 635 step 5). 637 >> Each TCP connection in a non-IDLE state MUST have at most one 638 next_key specified. 640 3. A pair of Sequence Numbers Extensions (SNEs). SNEs are used to 641 prevent replay attacks, as described in Section 8.2. Each SNE is 642 initialized to zero upon connection establishment. Its use in the 643 MAC calculation is described in Section 7.1. 645 4. One or more MKTs. These are the MKTs that match this connection's 646 socket pair. 648 MKTs are used, together with other parameters of a connection, to 649 create traffic keys unique to each connection, as described in 650 Section 7.2. These traffic keys can be cached after computation, and 651 can be stored in the TCB with the corresponding MKT information. They 652 can be considered part of the per-connection parameters. 654 7. Cryptographic Algorithms 656 TCP-AO also uses cryptographic algorithms to compute the MAC (Message 657 Authentication Code) used to authenticate a segment and its headers; 658 these are called MAC algorithms and are specified in a separate 659 document to facilitate updating the algorithm requirements 660 independently from the protocol [ao-crypto]. TCP-AO also uses 661 cryptographic algorithms to convert MKTs, which can be shared across 662 connections, into unique traffic keys for each connection. These are 663 called Key Derivation Functions (KDFs), and are specified [ao- 664 crypto]. This section describes how these algorithms are used by TCP- 665 AO. 667 7.1. MAC Algorithms 669 MAC algorithms take a variable-length input and a key and output a 670 fixed-length number. This number is used to determine whether the 671 input comes from a source with that same key, and whether the input 672 has been tampered in transit. MACs for TCP-AO have the following 673 interface: 675 INPUT: MAC_alg, MAC_truncation, traffic_key, data_block 677 OUTPUT: MAC 679 where: 681 o MAC_alg - MAC algorithm used for this computation 683 o MAC_truncation - the number of bytes to truncate the output of the 684 MAC to. This is indicated by the MAC algorithm, as specified in 685 [ao-crypto]. 687 o Traffic_key - traffic key used for this computation. This is 688 computed from the connection's current MKT as described in Section 689 7.2. 691 o Data_block - input data over which the MAC is computed. In TCP-AO, 692 this is the TCP segment prepended by the TCP pseudoheader and TCP 693 header options, as described in Section 7.1. 695 o MAC - the fixed-length output of the MAC algorithm, given the 696 parameters provided. 698 At the time of this writing, the algorithms' definitions for use in 699 TCP-AO, as described in [ao-crypto] are each truncated to 96 bits. 700 Though the algorithms each output a larger MAC, 96 bits provides a 701 reasonable tradeoff between security and message size, for fitting 702 into the TCP-AO header. Though could change in the future, so TCP-AO 703 header sizes should not be assumed as fixed length. 705 The MAC algorithm employed for the MAC computation on a connection is 706 done so by definition in the MKT, per [ao-crypto]'s definitions. 708 The mandatory-to-implement MAC algorithms for use with TCP-AO are 709 described in a separate RFC [ao-crypto]. This allows the TCP-AO 710 specification to proceed along the standards track even if changes 711 are needed to its associated algorithms and their labels (as might be 712 used in a user interface or automated MKT management protocol) as a 713 result of the ever evolving world of cryptography. 715 >> Additional algorithms, beyond those mandated for TCP-AO, MAY be 716 supported. 718 The data input to the MAC is the following fields in the following 719 sequence, interpreted in network-standard byte order: 721 1. The sequence number extension (SNE), in network-standard byte 722 order, as follows (described further in Section 8.2): 724 +--------+--------+--------+--------+ 725 | SNE | 726 +--------+--------+--------+--------+ 728 Figure 4 Sequence number extension 730 The SNE for transmitted segments is maintained locally in the 731 SND.SNE value; for received segments, a local RCV.SNE value is 732 used. The details of how these values are maintained and used is 733 described in Sections 8.2, 9.4, and 9.5. 735 2. The TCP pseudoheader: IP source and destination addresses, 736 protocol number and segment length, all in network byte order, 737 prepended to the TCP header below. The pseudoheader is exactly as 738 used for the TCP checksum in either IPv4 or IPv6 739 [RFC793][RFC2460]: 741 +--------+--------+--------+--------+ 742 | Source Address | 743 +--------+--------+--------+--------+ 744 | Destination Address | 745 +--------+--------+--------+--------+ 746 | zero | Proto | TCP Length | 747 +--------+--------+--------+--------+ 749 Figure 5 TCP IPv4 pseudoheader [RFC793] 751 +--------+--------+--------+--------+ 752 | | 753 + + 754 | | 755 + Source Address + 756 | | 757 + + 758 | | 759 + + 760 +--------+--------+--------+--------+ 761 | | 762 + + 763 | | 764 + Destination Address + 765 | | 766 + + 767 | | 768 +--------+--------+--------+--------+ 769 | Upper-Layer Packet Length | 770 +--------+--------+--------+--------+ 771 | zero | Next Header | 772 +--------+--------+--------+--------+ 774 Figure 6 TCP IPv6 pseudoheader [RFC2460] 776 3. The TCP header, by default including options, and where the TCP 777 checksum and TCP-AO MAC fields are set to zero, all in network 778 byte order. 780 The TCP option flag of the MKT indicates whether the TCP options 781 are included in the MAC. When included, only the TCP-AO MAC field 782 is zeroed. 784 When TCP options are not included, all TCP options except for TCP- 785 AO are omitted from MAC processing. Again, the TCP-AO MAC field is 786 zeroed for the MAC processing. 788 4. The TCP data, i.e., the payload of the TCP segment. 790 Note that the traffic key is not included as part of the data; the 791 MAC algorithm indicates how to use the traffic key, e.g., as HMACs do 792 [RFC2104][RFC2403]. The traffic key is derived from the current MKT 793 as described in Sections 7.2. 795 7.2. Key Derivation Functions 797 TCP-AO's traffic keys are derived from the MKTs using Key Derivation 798 Functions (KDFs). The KDFs used in TCP-AO have the following 799 interface: 801 INPUT: PRF_alg, master_key, output_length, data_block 803 OUTPUT: traffic_key 805 where: 807 o PRF_alg - the specific pseudorandom function (PRF) that is the 808 basic building block used in constructing the given KDF, as 809 indicated in the MKT. This is specified by the KDF as described in 810 [ao-crypto]. 812 o Master_key - The master_key string, as will be stored into the 813 associated MKT. 815 o Output_length - The desired output length of the KDF, i.e., the 816 length to which the KDF's output will be truncated. In TCP-AO, the 817 output_length is the PRF_truncation value of the MKT. This is 818 specified by the KDF as described in [ao-crypto]. 820 o Data_block - The data block used as input in constructing the KDF. 821 The data block provided by TCP-AO is used as the "context" as 822 specified in [ao-crypto]. The specific way this context is used, 823 in conjunction with other information, to create the raw input to 824 the PRF is also explained further in [ao-crypto]. 826 The data used as input to the KDF combines TCP socket pair with the 827 endpoint initial sequence numbers (ISNs) of a connection. This 828 provides context unique to each TCP connection instance, which 829 enables TCP-AO to generate unique traffic keys for that connection, 830 even from a MKT used across many different connections or across 831 repeated connections that share a socket pair. Unique traffic keys 832 are generated without relying on external key management properties. 833 This data block is defined in Figure 7 and Figure 8. 835 +--------+--------+--------+--------+ 836 | Source Address | 837 +--------+--------+--------+--------+ 838 | Destination Address | 839 +--------+--------+--------+--------+ 840 | Source Port | Dest. Port | 841 +--------+--------+--------+--------+ 842 | Source ISN | 843 +--------+--------+--------+--------+ 844 | Dest. ISN | 845 +--------+--------+--------+--------+ 847 Figure 7 Data block for an IPv4 connection 848 +--------+--------+--------+--------+ 849 | | 850 + + 851 | | 852 + Source Address + 853 | | 854 + + 855 | | 856 + + 857 +--------+--------+--------+--------+ 858 | | 859 + + 860 | | 861 + Destination Address + 862 | | 863 + + 864 | | 865 +--------+--------+--------+--------+ 866 | Source Port | Dest. Port | 867 +--------+--------+--------+--------+ 868 | Source ISN | 869 +--------+--------+--------+--------+ 870 | Dest. ISN | 871 +--------+--------+--------+--------+ 873 Figure 8 Data block for an IPv6 connection 875 Traffic keys are directional, so "source" and "destaination" are 876 interpreted differently for incoming and outgoing segments. For 877 incoming packets, source is the remote side, whereas for outgoing 878 packets source is the local side. This further ensures that 879 connection keys generated for each direction are unique. 881 For SYN segments (segments with the SYN set, but the ACK not set), 882 the destination ISN is not known. For these segments, the connection 883 key is computed using the connection block shown above, in which the 884 Destination ISN value is zero. For all other segments, the ISN pair 885 is used when known. If the ISN pair is not known, e.g., when sending 886 a RST after a reboot, the segment should be sent without 887 authentication; if authentication was required, the segment cannot 888 have been MAC'd properly anyway and would have been dropped on 889 receipt. 891 >> TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination 892 ISN of zero (whether sent or received); all other segments use the 893 known ISN pair. 895 Overall, this means that each connection will use up to four distinct 896 traffic keys for each MKT: 898 o Send_SYN_traffic_key - the traffic key used to authenticate 899 outgoing SYNs. The source ISN known (the TCP connection's local 900 ISN), and the destination (remote) ISN is unknown (and so the 901 value 0 is used). 903 o Receive_SYN_traffic_key - the traffic key used to authenticate 904 incoming SYNs. The source ISN known (the TCP connection's remote 905 ISN), and the destination (remote) ISN is unknown (and so the 906 value 0 is used). 908 o Send_other_traffic_key - the traffic key used to authenticate all 909 other outgoing TCP segments. 911 o Receive_other_traffic_key - the traffic key used to authenticate 912 all other incoming TCP segments. 914 The following table describes how each of these traffic keys is 915 computed, where the TCP-AO algorithms refer to source (S) and 916 destination (D) values of the IP address, TCP port, and ISN, and each 917 segment (incoming or outgoing) has a values that refer to the local 918 side of the connection (l) and remote side (r): 920 S-IP S-port S-ISN D-IP D-port D-ISN 921 ---------------------------------------------------------------- 922 Send_SYN_traffic_key l-IP l-port l-ISN r-IP r-port 0 923 Receive_SYN_traffic_key r-IP r-port r-ISN l-IP l-port 0 924 Send_other_traffic_key l-IP l-port l-ISN r-IP r-port r-ISN 925 Receive_other_traffic_key r-IP r-port r-ISN l-IP l-port l-ISN 927 The use of both ISNs in the traffic key computations ensures that 928 segments cannot be replayed across repeated connections reusing the 929 same socket pair (provided the ISN pair does not repeat, which is 930 unlikely because both endpoints should select ISNs pseudorandomly 931 [RFC1948], their 32-bit space avoids repeated use except under 932 reboot, and reuse assumes both sides repeat their use on the same 933 connection). 935 A SYN is authenticated using a destination ISN of zero (whether sent 936 or received), and all other segments would be authenticated using the 937 ISN pair for the connection. There are other cases in which the 938 destination ISN is not known, but segments are emitted, such as after 939 an endpoint reboots, when is possible that the two endpoints would 940 not have enough information to authenticate segments. In such cases, 941 TCP's timeout mechanism will allow old state to be cleared to enable 942 new connections, except where the user timeout is disabled; it is 943 important that implementations are capable of detecting excesses of 944 TCP connections in such a configuration and can clear them out if 945 needed to protect its memory usage [Je07]. 947 7.3. Traffic Key Establishment and Duration Issues 949 The TCP-AO option does not provide a mechanism for traffic key 950 negotiation or parameter negotiation (MAC algorithm, length, or use 951 of the TCP-AO option), or for coordinating rekeying during a 952 connection. We assume out-of-band mechanisms for MKT establishment, 953 parameter negotiation, and rekeying. This separation of MKT use from 954 MKT management is similar to that in the IPsec security suite 955 [RFC4301][RFC4306]. 957 We encourage users of TCP-AO to apply known techniques for generating 958 appropriate MKTs, including the use of reasonable master key lengths, 959 limited traffic key sharing, and limiting the duration of MKT use 960 [RFC3562]. This also includes the use of per-connection nonces, as 961 suggested in Section 7.2. 963 TCP-AO supports rekeying in which new MKTs are negotiated and 964 coordinated out-of-band, either via a protocol or a manual procedure 965 [RFC4808]. New MKT use is coordinated using the out-of-band mechanism 966 to update both TCP endpoints. When only a single MKT is used at a 967 time, the temporary use of invalid MKTs could result in packets being 968 dropped; although TCP is already robust to such drops, TCP-AO uses 969 the KeyID field to avoid such drops. A given connection can have 970 multiple matching MKTs, where the KeyID field is used to identify the 971 MKT that corresponds to the traffic key used for a segment, to avoid 972 the need for expensive trial-and-error testing of MKTs in sequence. 974 TCP-AO provides an explicit MKT coordination mechanism, described in 975 Section 8.1. Such a mechanism is useful when new MKTs are installed, 976 or when MKTs are changed, to determine when to commence using 977 installed MKTs. 979 Users are advised to manage MKTs following the spirit of the advice 980 for key management when using TCP MD5 [RFC3562], notably to use 981 appropriate key lengths (12-24 bytes) and to avoid sharing MKTs among 982 multiple BGP peering arrangements. 984 7.3.1. MKT Reuse Across Socket Pairs 986 MKTs can be reused across different socket pairs within a host, or 987 across different instances of a socket pair within a host. In either 988 case, replay protection is maintained. 990 MKTs reused across different socket pairs cannot enable replay 991 attacks because the TCP socket pair is included in the MAC, as well 992 as in the generation of the traffic key. MKTs reused across repeated 993 instances of a given socket pair cannot enable replay attacks because 994 the connection ISNs are included in the traffic key generation 995 algorithm, and ISN pairs are unlikely to repeat over useful periods. 997 7.3.2. MKTs Use Within a Long-lived Connection 999 TCP-AO uses sequence number extensions (SNEs) to prevent replay 1000 attacks within long-lived connections. Explicit MKT rollover, 1001 accomplished by external means and indexed using the KeyID field, can 1002 be used to change keying material for various reasons (e.g., 1003 personnel turnover), but is not required to support long-lived 1004 connections. 1006 8. Additional Security Mechanisms 1008 TCP-AO adds mechanisms to support efficient use, especially in 1009 environments where only manual keying is available. These include the 1010 previously described mechanisms for supporting multiple concurrent 1011 MKTs (via the KeyID field) and for generating unique per-connection 1012 traffic keys (via the KDF). This section describes additional 1013 mechanisms to coordinate MKT changes and to prevent replay attacks 1014 when a traffic key is not changed for long periods of time. 1016 8.1. Coordinating MKT Changes 1018 At any given time, a single TCP connection may have multiple MKTs 1019 specified for each segment direction (incoming, outgoing). TCP-AO 1020 provides a mechanism to indicate when a new MKT is ready, to allow 1021 the sender to commence use of that new MKT. This supported by using 1022 two ID fields in the header: 1024 o KeyID 1026 o NextKeyID 1028 KeyID represents the outgoing MKT information used by the segment 1029 sender to create the segment's MAC (outgoing), and the corresponding 1030 incoming keying information used by the segment receiver to validate 1031 that MAC. It contains the SendID of the MKT in active use in that 1032 direction. 1034 NextKeyID represents the preferred MKT information to be used for 1035 subsequent segments. I.e., it is a way for the segment sender to 1036 indicate a ready incoming MKT for future segments it receives, so 1037 that the segment receiver can know when to switch MKTs (and thus 1038 their KeyIDs and associated traffic keys). It indicates the RecvID of 1039 the MKT desired to for incoming segments. 1041 There are two pointers kept by each side of a connection, as noted in 1042 the per-connection information (see Section 6): 1044 o Currently active outgoing MKT (Current_key) 1046 o Current preference for incoming MKT (Next_key) 1048 Current_key indicates a MKT that is used to authenticate outgoing 1049 segments. Upon connection establishment, it points to the first MKT 1050 selected for use. 1052 Next_key points to an incoming MKT that is ready and preferred for 1053 use. Upon connection establishment, this points to the currently 1054 active incoming MKT. It can be changed when new MKTs are installed 1055 (e.g., either by automatic MKT management protocol operation or by 1056 user manual selection). 1058 Next_key is changed only by manual user intervention or MKT 1059 management protocol operation. It is not manipulated by TCP-AO. 1060 Current_key is updated by TCP-AO when processing received TCP 1061 segments as discussed in the segment processing description in 1062 Section 9.5. Note that the algorithm allows the current_key to change 1063 to a new MKT, then change back to a previously used MKT (known as 1064 "backing up"). This can occur during a MKT change when segments are 1065 received out of order, and is considered a feature of TCP-AO, because 1066 reordering does not result in drops. The only way to avoid reuse of 1067 previously used MKTs is to remove the MKT when it is no longer 1068 considered permitted. 1070 8.2. Preventing replay attacks within long-lived connections 1072 TCP uses a 32-bit sequence number which may, for long-lived 1073 connections, roll over and repeat. This could result in TCP segments 1074 being intentionally and legitimately replayed within a connection. 1075 TCP-AO prevents replay attacks, and thus requires a way to 1076 differentiate these legitimate replays from each other, and so it 1077 adds a 32-bit sequence number extension (SNE) for transmitted and 1078 received segments. 1080 The SNE extends TCP's sequence number so that segments within a 1081 single connection are always unique. When TCP's sequence number rolls 1082 over, there is a chance that a segment could be repeated in total; 1083 using an SNE differentiates even identical segments sent with 1084 identical sequence numbers at different times in a connection. TCP-AO 1085 emulates a 64-bit sequence number space by inferring when to 1086 increment the high-order 32-bit portion (the SNE) based on 1087 transitions in the low-order portion (the TCP sequence number). 1089 TCP-AO thus maintains SND.SNE for transmitted segments, and RCV.SNE 1090 for received segments, both initialized as zero when a connection 1091 begins. The intent of these SNEs is, together with TCP's 32-bit 1092 sequence numbers, to provide a 64-bit overall sequence number space. 1094 For transmitted segments SND.SNE can be implemented by extending 1095 TCP's sequence number to 64-bits; SND.SNE would be the top (high- 1096 order) 32 bits of that number. For received segments, TCP-AO needs to 1097 emulate the use of a 64-bit number space, and correctly infer the 1098 appropriate high-order 32-bits of that number as RCV.SNE from the 1099 received 32-bit sequence number and the current connection context. 1101 The implementation of SNEs is not specified in this document, but one 1102 possible way is described here that can be used for either RCV.SNE, 1103 SND.SNE, or both. 1105 Consider an implementation with two SNEs as required (SND.SNE, RCV. 1106 SNE), and additional variables as listed below, all initialized to 1107 zero, as well as a current TCP segment field (SEG.SEQ): 1109 o SND.PREV_SEQ, needed to detect rollover of SND.SEQ 1111 o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ 1113 o SND.SNE_FLAG, which indicates when to increment the SND.SNE 1115 o RCV.SNE_FLAG, which indicates when to increment the RCV.SNE 1117 When a segment is received, the following algorithm (written in C) 1118 computes the SNE used in the MAC; an equivalent algorithm can be 1119 applied to the "SND" side: 1121 /* set the flag when the SEG.SEQ first rolls over */ 1122 if ((RCV.SNE_FLAG == 0) 1123 && (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) { 1124 RCV.SNE = RCV.SNE + 1; 1125 RCV.SNE_FLAG = 1; 1126 } 1127 /* decide which SNE to use after incremented */ 1128 if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) { 1129 SNE = RCV.SNE - 1; # use the pre-increment value 1130 } else { 1131 SNE = RCV.SNE; # use the current value 1132 } 1133 /* reset the flag in the *middle* of the window */ 1134 if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) { 1135 RCV.SNE_FLAG = 0; 1136 } 1137 /* save the current SEQ for the next time through the code */ 1138 RCV.PREV_SEQ = SEG.SEQ; 1140 In the above code, the first line when the sequence number first 1141 rolls over, i.e., when the new number is low (in the bottom half of 1142 the number space) and the old number is high (in the top half of the 1143 number space). The first time this happens, the SNE is incremented 1144 and a flag is set. 1146 If the flag is set and a high number is seen, it must be a reordered 1147 packet, so use the pre-increment SNE, otherwise use the current SNE. 1148 The flag will be cleared by the time the number rolls all the way 1149 around. 1151 The flag prevents the SNE from being incremented again until the flag 1152 is reset, which happens in the middle of the window (when the old 1153 number is in the bottom half and the new is in the top half). Because 1154 the receive window is never larger than half of the number space, it 1155 is impossible to both set and reset the flag at the same time - 1156 outstanding packets, regardless of reordering, cannot straddle both 1157 regions simultaneously. 1159 9. TCP-AO Interaction with TCP 1161 The following is a description of how TCP-AO affects various TCP 1162 states, segments, events, and interfaces. This description is 1163 intended to augment the description of TCP as provided in RFC-793, 1164 and its presentation mirrors that of RFC-793 as a result [RFC793]. 1166 9.1. TCP User Interface 1168 The TCP user interface supports active and passive OPEN, SEND, 1169 RECEIVE, CLOSE, STATUS and ABORT commands. TCP-AO does not alter this 1170 interface as it applies to TCP, but some commands or command 1171 sequences of the interface need to be modified to support TCP-AO. 1172 TCP-AO does not specify the details of how this is achieved. 1174 TCP-AO requires the TCP user interface be extended to allow the MKTs 1175 to be configured, as well as to allow an ongoing connection to manage 1176 which MKTs are active. The MKTs need to be configured prior to 1177 connection establishment, and the set of MKTs may change during a 1178 connection: 1180 >> TCP OPEN, or the sequence of commands that configure a connection 1181 to be in the active or passive OPEN state, MUST be augmented so that 1182 a MKT can be configured. 1184 >> A TCP-AO implmentation MUST allow the set of MKTs for ongoing TCP 1185 connections (i.e., not in the CLOSED state) to be modified. 1187 The MKTs associated with a connection needs to be available for 1188 confirmation; this includes the ability to read the MKTs: 1190 >> TCP STATUS SHOULD be augmented to allow the MKTs of a current or 1191 pending connection to be read (for confirmation). 1193 Senders may need to be able to determine when the outgoing MKT 1194 changes (KeyID) or when a new preferred MKT (NextKeyID) is indicated; 1195 these changes immediately affect all subsequent outgoing segments: 1197 >> TCP SEND, or a sequence of commands resulting in a SEND, MUST be 1198 augmented so that the preferred outgoing MKT (Current_key) and/or the 1199 preferred incoming MKT Next_key of a connection can be indicated. 1201 It may be useful to change the outgoing active MKT (Current_key) even 1202 when no data is being sent, which can be achieved by sending a zero- 1203 length buffer or by using a non-send interface (e.g., socket options 1204 in Unix), depending on the implementation. 1206 It is also useful to indicate recent segment KeyID and NextKeyID 1207 values received; although there could be a number of such values, 1208 they are not expected to change quickly so any recent sample should 1209 be sufficient: 1211 >> TCP RECEIVE, or the sequence of commands resulting in a RECEIVE, 1212 MUST be augmented so that the KeyID and NextKeyID of a recently 1213 received segment is available to the user out-of-band (e.g., as an 1214 additional parameter to RECEIVE, or via a STATUS call). 1216 9.2. TCP States and Transitions 1218 TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, 1219 FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and 1220 CLOSED. 1222 >> A MKT MAY be associated with any TCP state. 1224 9.3. TCP Segments 1226 TCP includes control (at least one of SYN, FIN, RST flags set) and 1227 data (none of SYN, FIN, or RST flags set) segments. Note that some 1228 control segments can include data (e.g., SYN). 1230 >> All TCP segments MUST be checked against the set of MKTs for 1231 matching TCP connection identifiers. 1233 >> TCP segments whose TCP-AO option does not validate MUST be 1234 silently discarded. 1236 >> TCP segments with TCP-AO but not matching an MKT MUST be silently 1237 accepted; this is required for equivalent function with TCPs not 1238 implementing TCP-AO. 1240 >> Silent discard events SHOULD be signaled to the user as a warning, 1241 and silent accept events MAY be signaled to the user as a warning. 1242 Both warnings, if available, MUST be accessible via the STATUS 1243 interface. Either signal MAY be asynchronous, but if so they MUST be 1244 rate-limited. Either signal MAY be logged; logging SHOULD allow rate- 1245 limiting as well. 1247 All TCP-AO processing occurs between the interface of TCP and IP; for 1248 incoming segments, this occurs after validation of the TCP checksum. 1249 For outgoing segments, this occurs before computation of the TCP 1250 checksum. 1252 Note that the TCP-AO option is not negotiated. It is the 1253 responsibility of the receiver to determine when TCP-AO is required 1254 and to enforce that requirement. 1256 9.4. Sending TCP Segments 1258 The following procedure describes the modifications to TCP to support 1259 TCP-AO when a segment departs. 1261 >> Note that TCP-AO MUST be the last TCP option processed on outgoing 1262 segments, because its MAC calculation may include the values of other 1263 TCP options. 1265 1. Find the per-connection parameters for the segment: 1267 a. If the segment is a SYN, then this is the first segment of a 1268 new connection. Find the matching MKT for this segment based 1269 on the segment's socket pair. 1271 i. If there is no matching MKT, omit the TCP-AO option. 1272 Proceed with transmitting the segment. 1274 ii. If there is a matching MKT, then set the per-connection 1275 parameters as needed (see Section 6). Proceed with the 1276 step 2. 1278 b. If the segment is not a SYN, then determine whether TCP-AO is 1279 being used for the connection and use the MKT as indicated by 1280 the current_key value from the per-connection parameters (see 1281 Section 6) and proceed with the step 2. 1283 2. Using the per-connection parameters: 1285 a. Augment the TCP header with the TCP-AO, inserting the 1286 appropriate Length and KeyID based on the MKT indicated by 1287 current_key (using the current_key MKT's SendID as the TCP-AO 1288 KeyID). Update the TCP header length accordingly. 1290 b. Determine SND.SNE as described in Section 8.2. 1292 c. Determine the appropriate traffic key, i.e., as pointed to by 1293 current_key (as noted in Section 8.1, and as probably cached 1294 in the TCB). I.e., use the send_SYN_traffic_key for SYN 1295 segments, and the send_other_traffic_key for other segments. 1297 d. Determine the NextKeyID as indicated by the Next_key pointer, 1298 and insert it in the TCP-AO option (using the next_key MKT's 1299 RecvID as the TCP-AO KeyID) (as noted in Section 8.1). 1301 e. Compute the MAC using the MKT (and cached traffic key) and 1302 data from the segment as specified in Section 7.1. 1304 f. Insert the MAC in the TCP-AO MAC field. 1306 g. Proceed with transmitting the segment. 1308 9.5. Receiving TCP Segments 1310 The following procedure describes the modifications to TCP to support 1311 TCP-AO when a segment arrives. 1313 >> Note that TCP-AO MUST be the first TCP option processed on 1314 incoming segments, because its MAC calculation may include the values 1315 of other TCP options which could change during TCP option processing. 1316 This also protects the behavior of all other TCP options from the 1317 impact of spoofed segments or modified header information. 1319 >> Note that TCP-AO checks MUST be performed for all incoming SYNs to 1320 avoid accepting SYNs lacking the TCP-AO option where required. Other 1321 segments can cache whether TCP-AO is needed in the TCB. 1323 1. Find the per-connection parameters for the segment: 1325 a. If the segment is a SYN, then this is the first segment of a 1326 new connection. Find the matching MKT for this segment, using 1327 the segment's socket pair and its TCP-AO KeyID, matched 1328 against the MKT's TCP connection identifier and the MKT's 1329 RecvID. 1331 i. If there is no matching MKT, omit the TCP-AO option. 1332 Proceed with further TCP handling of the segment. 1334 ii. If there is a matching MKT, then set the per-connection 1335 parameters as needed (see Section 6). Proceed with the 1336 step 2. 1338 2. Using the per-connection parameters: 1340 a. Check that the segment's TCP-AO Length matches the length 1341 indicated by the MKT. 1343 i. If lengths differ, silently discard the segment. Log 1344 and/or signal the event as indicated in Section 9.3. 1346 b. Determine the segment's RCV.SNE as described in Section 8.2. 1348 c. Determine the segment's traffic key from the MKT as described 1349 in Section 7.1 (and as likely cached in the TCB). I.e., use 1350 the receive_SYN_traffic_key for SYN segments, and the 1351 receive_other_traffic_key for other segments. 1353 d. Compute the segment's MAC using the MKT (and its derived 1354 traffic key) and portions of the segment as indicated in 1355 Section 7.1. 1357 i. If the computed MAC differs from the TCP-AO MAC field 1358 value, silently discard the segment. Log and/or signal 1359 the event as indicated in Section 9.3. 1361 e. Compare the received NextKeyID value to the currently active 1362 outgoing KeyID value (Current_key MKT's SendID). 1364 i. If they match, no further action is required. 1366 ii. If they differ, determine whether the NextKeyID MKT is 1367 ready. 1369 1. If the MKT corresponding to the segment's socket 1370 pair and NextKeyID is not available, no action is 1371 required (NextKeyID of a received segment needs to 1372 match the MKT's SendID). 1374 2. If the matching MKT corresponding to the segment's 1375 socket pair and NextKeyID is available: 1377 a. Optionally, set a timer on the MKT indicated by 1378 the current_key and segment socket pair to 1379 ensure that the MKT cannot be deleted for 2*MSL. 1380 If a timer has already been set, reset the 1381 timer. 1383 This timer is advisory only. Removing MKTs with 1384 unexpired timers can result in a user-level 1385 warning, but is not prohibited. Implementation 1386 of timers is not required. 1388 b. Set Current_key to the NextKeyID MKT. 1390 f. Proceed with TCP processing of the segment. 1392 It is suggested that TCP-AO implementations validate a segment's 1393 Length field before computing a MAC, to reduce the overhead incurred 1394 by spoofed segments with invalid TCP-AO fields. 1396 Additional reductions in MAC validation overhead can be supported in 1397 the MAC algorithms, e.g., by using a computation algorithm that 1398 prepends a fixed value to the computed portion and a corresponding 1399 validation algorithm that verifies the fixed value before investing 1400 in the computed portion. Such optimizations would be contained in the 1401 MAC algorithm specification, and thus are not specified in TCP-AO 1402 explicitly. Note that the KeyID cannot be used for connection 1403 validation per se, because it is not assumed random. 1405 9.6. Impact on TCP Header Size 1407 The TCP-AO option typically uses a total of 17-19 bytes of TCP header 1408 space. TCP-AO is no larger than and typically 3 bytes smaller than 1409 the TCP MD5 option (assuming a 96-bit MAC). 1411 Note that TCP option space is most critical in SYN segments, because 1412 flags in those segments could potentially increase the option space 1413 area in other segments. Because TCP ignores unknown segments, 1414 however, it is not possible to extend the option space of SYNs 1415 without breaking backward-compatibility. 1417 TCP's 4-bit data offset requires that the options end 60 bytes (15 1418 32-bit words) after the header begins, including the 20-byte header. 1419 This leaves 40 bytes for options, of which 15 are expected in current 1420 implementations (listed below), leaving at most 25 for other uses. 1421 Assuming a 96-bit MAC, TCP-AO consumes 16 bytes, leaving up to 9 1422 bytes for additional SYN options (depending on implementation 1423 dependant alignment padding, which could consume another 2 bytes at 1424 most). 1426 o SACK permitted (2 bytes) [RFC2018][RFC3517] 1428 o Timestamps (10 bytes) [RFC1323] 1430 o Window scale (3 bytes) [RFC1323] 1432 After a SYN, the following options are expected in current 1433 implementations of TCP: 1435 o SACK (10bytes) [RFC2018][RFC3517] (18 bytes if D-SACK [RFC2883] 1437 o Timestamps (10 bytes) [RFC1323] 1439 TCP-AO continues to consume 16 bytes in non-SYN segments, leaving a 1440 total of 24 bytes for other options, of which the timestamp consumes 1441 10. This leaves 14 bytes, of which 10 are used for a single SACK 1442 block. When two SACK blocks are used, such as to handle D-SACK, a 1443 smaller TCP-AO MAC would be required to make room for the additional 1444 SACK block (i.e., to leave 18 bytes for the D-SACK variant of the 1445 SACK option) [RFC2883]. Note that D-SACK is not supportable in TCP- 1446 MD5 in the presence of timestamps, because TCP MD5's MAC length is 1447 fixed and too large to leave sufficient option space. 1449 Although TCP option space is limited, we believe TCP-AO is consistent 1450 with the desire to authenticate TCP at the connection level for 1451 similar uses as were intended by TCP MD5. 1453 10. Obsoleting TCP MD5 and Legacy Interactions 1455 TCP-AO obsoletes TCP MD5. As we have noted earlier: 1457 >> TCP implementations MUST support TCP-AO. 1459 Systems implementing TCP MD5 only are considered legacy, and ought to 1460 be upgraded when possible. In order to support interoperation with 1461 such legacy systems until upgrades are available: 1463 >> TCP MD5 SHOULD be supported where interactions with legacy systems 1464 is needed. 1466 >> A system that supports both TCP-AO and TCP MD5 MUST use TCP-AO for 1467 connections unless not supported by its peer, at which point it MAY 1468 use TCP MD5 instead. 1470 >> A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for a 1471 particular TCP connection, but MAY support TCP-AO and TCP MD5 1472 simultaneously for different connections (notably to support legacy 1473 use of TCP MD5). 1475 The Kind value explicitly indicates whether TCP-AO or TCP MD5 is used 1476 for a particular connection in TCP segments. 1478 It is possible that MKTs could be augmented to support TCP MD5, 1479 although use of MKTs is not described in RFC2385. 1481 It is possible to require TCP-AO for a connection or TCP MD5, but it 1482 is not possible to require 'either'. When an endpoint is configured 1483 to require TCP MD5 for a connection, it must be added to all outgoing 1484 segments and validated on all incoming segments [RFC2385]. TCP MD5's 1485 requirements prohibit the speculative use of both options for a given 1486 connection, e.g., to be decided by the other end of the connection. 1488 11. Interactions with Middleboxes 1490 TCP-AO may interact with middleboxes, depending on their behavior 1491 [RFC3234]. Some middleboxes either alter TCP options (such as TCP-AO) 1492 directly or alter the information TCP-AO includes in its MAC 1493 calculation. TCP-AO may interfere with these devices, exactly where 1494 the device modifies information TCP-AO is designed to protect. 1496 11.1. Interactions with non-NAT/NAPT Middleboxes 1498 TCP-AO supports middleboxes that do not change the IP addresses or 1499 ports of segments. Such middleboxes may modify some TCP options, in 1500 which case TCP-AO would need to be configured to ignore all options 1501 in the MAC calculation on connections traversing that element. 1503 Note that ignoring TCP options may provide less protection, i.e., TCP 1504 options could be modified in transit, and such modifications could be 1505 used by an attacker. Depending on the modifications, TCP could have 1506 compromised efficiency (e.g., timestamp changes), or could cease 1507 correct operation (e.g., window scale changes). These vulnerabilities 1508 affect only the TCP connections for which TCP-AO is configured to 1509 ignore TCP options. 1511 11.2. Interactions with NAT/NAPT Devices 1513 TCP-AO cannot interoperate natively across NAT/NAPT devices, which 1514 modify the IP addresses and/or port numbers. We anticipate that 1515 traversing such devices will require variants of existing NAT/NAPT 1516 traversal mechanisms, e.g., encapsulation of the TCP-AO-protected 1517 segment in another transport segment (e.g., UDP), as is done in IPsec 1518 [RFC2766][RFC3947]. Such variants can be adapted for use with TCP-AO, 1519 or IPsec NAT traversal can be used instead in such cases [RFC3947]. 1521 12. Evaluation of Requirements Satisfaction 1523 TCP-AO satisfies all the current requirements for a revision to TCP 1524 MD5, as summarized below [Be07]. 1526 1. Protected Elements 1528 A solution to revising TCP MD5 should protect (authenticate) the 1529 following elements. 1531 This is supported - see Section 7.1. 1533 a. TCP pseudoheader, including IPv4 and IPv6 versions. 1535 Note that we do not allow optional coverage because IP 1536 addresses define a connection. If they can be coordinated 1537 across a NAT/NAPT, the sender can compute the MAC based on the 1538 received values; if not, a tunnel is required, as noted in 1539 Section 11.2. 1541 b. TCP header. 1543 Note that we do not allow optional port coverage because ports 1544 define a connection. If they can be coordinated across a 1545 NAT/NAPT, the sender can compute the MAC based on the received 1546 values; if not, a tunnel is required, as noted in Section 1547 11.2. 1549 c. TCP options. 1551 Note that TCP-AO allows exclusion of TCP options from 1552 coverage, to enable use with middleboxes that modify options 1553 (except when they modify TCP-AO itself). See Section 11. 1555 d. TCP payload data. 1557 2. Option Structure Requirements 1559 A solution to revising TCP MD5 should use an option with the 1560 following structural requirements. 1562 This is supported - see Section 7.1. 1564 a. Privacy. 1566 The option should not unnecessarily expose information about 1567 the TCP-AO mechanism. The additional protection afforded by 1568 keeping this information private may be of little value, but 1569 also helps keep the option size small. 1571 TCP-AO exposes only the MKT IDs, MAC, and overall option 1572 length on the wire. Note that short MACs could be obscured by 1573 using longer option lengths but specifying a short MAC length 1574 (this is equivalent to a different MAC algorithm, and is 1575 specified in the TAPD entry). See Section 4.2. 1577 b. Allow optional per connection. 1579 The option should not be required on every connection; it 1580 should be optional on a per connection basis. 1582 This is supported because the set of MKTs can be installed to 1583 match some connections and not others. Connections not 1584 matching any MKT do not require TCP-AO. Further, incoming 1585 segments containing the TCP-AO option are not discarded solely 1586 because they include the option, provided they do not match 1587 any MKT. 1589 c. Require non-optional. 1591 The option should be able to be specified as required for a 1592 given connection. 1594 This is supported because the set of MKTs can be installed to 1595 match some connections and not others. Connections matching 1596 any MKT require TCP-AO. 1598 d. Standard parsing. 1600 The option should be easily parseable, i.e., without 1601 conditional parsing, and follow the standard RFC 793 option 1602 format. 1604 This is supported - see Section 4.2. 1606 e. Compatible with Large Windows and SACK. 1608 The option should be compatible with the use of the Large 1609 Windows and SACK options. 1611 This is supported - see Section 9.6. The size of the option is 1612 intended to allow use with Large Windows and SACK. See also 1613 Section 2.1, which indicates that TCP-AO is 3 bytes shorter 1614 than TCP MD5 in the default case, assuming a 96-bit MAC. 1616 3. Cryptography requirements 1618 A solution to revising TCP MD5 should support modern cryptography 1619 capabilities. 1621 a. Baseline defaults. 1623 The option should have a default that is required in all 1624 implementations. 1626 TCP-AO uses a default required algorithm as specified in [ao- 1627 crypto], as noted in Section 7.1. 1629 b. Good algorithms. 1631 The option should use algorithms considered accepted by the 1632 security community, which are considered appropriately safe. 1633 The use of non-standard or unpublished algorithms should be 1634 avoided. 1636 TCP-AO uses MACs as indicated in [ao-crypto]. The PRF is also 1637 specified in [ao-crypto]. The PRF input string follows the 1638 typical design (see [ao-crypto]). 1640 c. Algorithm agility. 1642 The option should support algorithms other than the default, 1643 to allow agility over time. 1645 TCP-AO allows any desired algorithm, subject to TCP option 1646 space limitations, as noted in Section 4.2. The use of set of 1647 MKTs allows separate connections to use different algorithms, 1648 both for the MAC and the PRF. 1650 d. Order-independent processing. 1652 The option should be processed independently of the proper 1653 order, i.e., they should allow processing of TCP segments in 1654 the order received, without requiring reordering. This avoids 1655 the need for reordering prior to processing, and avoids the 1656 impact of misordered segments on the option. 1658 This is supported - see Sections 9.3, 9.4, and 9.5. Note that 1659 pre-TCP processing is further required, because TCP segments 1660 cannot be discarded solely based on a combination of 1661 connection state and out-of-window checks; many such segments, 1662 although discarded, cause a host to respond with a replay of 1663 the last valid ACK, e.g. [RFC793]. See also the derivation of 1664 the SNE, which is reconstituted at the receiver using a 1665 demonstration algorithm that avoids the need for reordering 1666 (in Section 8.2). 1668 e. Security parameter changes require key changes. 1670 The option should require that the MKT change whenever the 1671 security parameters change. This avoids the need for 1672 coordinating option state during a connection, which is 1673 typical for TCP options. This also helps allow "bump in the 1674 stack" implementations that are not integrated with endpoint 1675 TCP implementations. 1677 Parameters change only when a new MKT is used. See Section 5. 1679 4. Keying requirements. 1681 A solution to revising TCP MD5 should support manual keying, and 1682 should support the use of an external automated key management 1683 system (e.g., a protocol or other mechanism). 1685 Note that TCP-AO does not specify a MKT management system. 1687 a. Intraconnection rekeying. 1689 The option should support rekeying during a connection, to 1690 avoid the impact of long-duration connections. 1692 This is supported by the use of IDs and multiple MKTs; see 1693 Section 5. 1695 b. Efficient rekeying. 1697 The option should support rekeying during a connection without 1698 the need to expend undue computational resources. In 1699 particular, the options should avoid the need to try multiple 1700 keys on a given segment. 1702 This is supported by the use of the KeyID. See Section 8.1. 1704 c. Automated and manual keying. 1706 The option should support both automated and manual keying. 1708 The use of MKTs allows external automated and manual keying. 1709 See Section 5. This capability is enhanced by the generation 1710 of unique per-connection keys, which enables use of manual 1711 MKTs with automatically generated traffic keys as noted in 1712 Section 7.2. 1714 d. Key management agnostic. 1716 The option should not assume or require a particular key 1717 management solution. 1719 This is supported by use of a set of MKTs. See Section 5. 1721 5. Expected Constraints 1723 A solution to revising TCP MD5 should also abide by typical safe 1724 security practices. 1726 a. Silent failure. 1728 Receipt of segments failing authentication must result in no 1729 visible external action and must not modify internal state, 1730 and those events should be logged. 1732 This is supported - see Sections 9.3, 9.4, and 9.5. 1734 b. At most one such option per segment. 1736 Only one authentication option can be permitted per segment. 1738 This is supported by the protocol requirements - see Section 1739 4.2. 1741 c. Outgoing all or none. 1743 Segments out of a TCP connection are either all authenticated 1744 or all not authenticated. 1746 This is supported - see Section 9.4. 1748 d. Incoming all checked. 1750 Segments into a TCP connection are always checked to determine 1751 whether their authentication should be present and valid. 1753 This is supported - see Section 9.5. 1755 e. Non-interaction with TCP MD5. 1757 The use of this option for a given connection should not 1758 preclude the use of TCP MD5, e.g., for legacy use, for other 1759 connections. 1761 This is supported - see Section 10. 1763 f. Optional ICMP discard. 1765 The option should allow certain ICMPs to be discarded, notably 1766 Type 3 (destination unreachable), Codes 2-4 (transport 1767 protocol unreachable, port unreachable, or fragmentation 1768 needed and IP DF field set), i.e., the ones indicating the 1769 failure of the endpoint to communicate. 1771 This is supported - see Section 13. 1773 g. Maintain TCP connection semantics, in which the socket pair 1774 alone defines a TCP association and all its security 1775 parameters. 1777 This is supported - see Sections 5 and 11. 1779 13. Security Considerations 1781 Use of TCP-AO, like use of TCP MD5 or IPsec, will impact host 1782 performance. Connections that are known to use TCP-AO can be attacked 1783 by transmitting segments with invalid MACs. Attackers would need to 1784 know only the TCP connection ID and TCP-AO Length value to 1785 substantially impact the host's processing capacity. This is similar 1786 to the susceptibility of IPsec to on-path attacks, where the IP 1787 addresses and SPI would be visible. For IPsec, the entire SPI space 1788 (32 bits) is arbitrary, whereas for routing protocols typically only 1789 the source port (16 bits) is arbitrary. As a result, it would be 1790 easier for an off-path attacker to spoof a TCP-AO segment that could 1791 cause receiver validation effort. However, we note that between 1792 Internet routers both ports could be arbitrary (i.e., determined a- 1793 priori out of band), which would constitute roughly the same off-path 1794 antispoofing protection of an arbitrary SPI. 1796 TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets 1797 typically occur after peer crashes, either in response to new 1798 connection attempts or when data is sent on stale connections; in 1799 either case, the recovering endpoint may lack the connection key 1800 required (e.g., if lost during the crash). This may result in time- 1801 outs, rather than more responsive recovery after such a crash. As 1802 noted in Section 7.2, such cases may also result in persistent TCP 1803 state for old connections that cannot be cleared, and so 1804 implementations should be capable of detecting an excess of such 1805 connections and clearing their state if needed to protect memory 1806 utilization [Je07]. 1808 TCP-AO does not include a fast decline capability, e.g., where a SYN- 1809 ACK is received without an expected TCP-AO option and the connection 1810 is quickly reset or aborted. Normal TCP operation will retry and 1811 timeout, which is what should be expected when the intended receiver 1812 is not capable of the TCP variant required anyway. Backoff is not 1813 optimized because it would present an opportunity for attackers on 1814 the wire to abort authenticated connection attempts by sending 1815 spoofed SYN-ACKs without the TCP-AO option. 1817 TCP-AO is intended to provide similar protections to IPsec, but is 1818 not intended to replace the use of IPsec or IKE either for more 1819 robust security or more sophisticated security management. 1821 TCP-AO does not address the issue of ICMP attacks on TCP. IPsec makes 1822 recommendations regarding dropping ICMPs in certain contexts, or 1823 requiring that they are endpoint authenticated in others [RFC4301]. 1824 There are other mechanisms proposed to reduce the impact of ICMP 1825 attacks by further validating ICMP contents and changing the effect 1826 of some messages based on TCP state, but these do not provide the 1827 level of authentication for ICMP that TCP-AO provides for TCP [Go07]. 1829 >> A TCP-AO implementation MUST allow the system administrator to 1830 configure whether TCP will ignore incoming ICMP messages of Type 3 1831 (destination unreachable) Codes 2-4 (protocol unreachable, port 1832 unreachable, and fragmentation needed - 'hard errors') intended for 1833 connections that match MKTs. An implementation SHOULD allow ignored 1834 ICMPs to be logged. 1836 This control affects only ICMPs that currently require 'hard errors', 1837 which would abort the TCP connection [RFC1122]. This recommendation 1838 is intended to be similar to how IPsec would handle those messages 1839 [RFC4301]. 1841 TCP-AO includes the TCP connection ID (the socket pair) in the MAC 1842 calculation. This prevents different concurrent connections using the 1843 same MKT (for whatever reason) from potentially enabling a traffic- 1844 crossing attack, in which segments to one socket pair are diverted to 1845 attack a different socket pair. When multiple connections use the 1846 same MKT, it would be useful to know that packets intended for one ID 1847 could not be (maliciously or otherwise) modified in transit and end 1848 up being authenticated for the other ID. That requirement would place 1849 an additional burden of uniqueness on MKTs within endsystems, and 1850 potentially across endsystems. Although the resulting attack is low 1851 probability, the protection afforded by including the received ID 1852 warrants its inclusion in the MAC, and does not unduly increase the 1853 MAC calculation or MKT management. 1855 The use of any security algorithm can present an opportunity for a 1856 CPU DOS attack, where the attacker sends false, random segments that 1857 the receiver under attack expends substantial CPU effort to reject. 1858 In IPsec, such attacks are reduced by the use of a large Security 1859 Parameter Index (SPI) and Sequence Number fields to partly validate 1860 segments before CPU cycles are invested validated the Integrity Check 1861 Value (ICV). In TCP-AO, the socket pair performs most of the function 1862 of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay 1863 attacks, isn't needed due to TCP's Sequence Number, which is used to 1864 reorder received segments (provided the sequence number doesn't wrap 1865 around, which is why TCP-AO adds the SNE in Section 8.2). TCP already 1866 protects itself from replays of authentic segment data as well as 1867 authentic explicit TCP control (e.g., SYN, FIN, ACK bits, but even 1868 authentic replays could affect TCP congestion control [Sa99]. TCP-AO 1869 does not protect TCP congestion control from this last form of attack 1870 due to the cumbersome nature of layering a windowed security sequence 1871 number within TCP in addition to TCP's own sequence number; when such 1872 protection is desired, users are encouraged to apply IPsec instead. 1874 Further, it is not useful to validate TCP's Sequence Number before 1875 performing a TCP-AO authentication calculation, because out-of-window 1876 segments can still cause valid TCP protocol actions (e.g., ACK 1877 retransmission) [RFC793]. It is similarly not useful to add a 1878 separate Sequence Number field to the TCP-AO option, because doing so 1879 could cause a change in TCP's behavior even when segments are valid. 1881 14. IANA Considerations 1883 [NOTE: This section be removed prior to publication as an RFC] 1885 The TCP-AO option defines no new namespaces. 1887 The TCP-AO option requires that IANA allocate a value from the TCP 1888 option Kind namespace, to be replaced for TCP-IANA-KIND throughout 1889 this document. 1891 To specify MAC and PRF algorithms, TCP-AO refers to a separate 1892 document that may involve IANA actions [ao-crypto]. 1894 15. References 1896 15.1. Normative References 1898 [RFC793] Postel, J., "Transmission Control Protocol," STD-7, 1899 RFC-793, Standard, Sept. 1981. 1901 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 1902 Communication Layers," RFC-1122, Oct. 1989. 1904 [RFC2018] Mathis, M., J. Mahdavi, S. Floyd, A. Romanow, "TCP 1905 Selective Acknowledgement Options", RFC-2018, Proposed 1906 Standard, April 1996. 1908 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1909 Requirement Levels", BCP-14, RFC-2119, Best Current 1910 Practice, March 1997. 1912 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1913 Signature Option," RFC-2385, Proposed Standard, Aug. 1998. 1915 [RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP 1916 and AH," RFC-2403, Proposed Standard, Nov. 1998. 1918 [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6 1919 (IPv6) Specification," RFC-2460, Proposed Standard, Dec. 1920 1998. 1922 [RFC2883] Floyd, S., J. Mahdavi, M. Mathis, M. Podolsky, "An 1923 Extension to the Selective Acknowledgement (SACK) Option 1924 for TCP", RFC-2883, Proposed Standard, July 2000. 1926 [RFC3517] Blanton, E., M. Allman, K. Fall, L. Wang, "A Conservative 1927 Selective Acknowledgment (SACK)-based Loss Recovery 1928 Algorithm for TCP", RFC-3517, Proposed Standard, April 1929 2003. 1931 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," 1932 RFC-4306, Proposed Standard, Dec. 2005. 1934 [ao-crypto] Lebovitz, G., "Cryptographic Algorithms, Use, & 1935 Implementation Requirments for TCP Authentication Option", 1936 draft-lebovitz-ietf-tcpm-tcp-ao-crypto, Mar. 2009. 1938 15.2. Informative References 1940 [Be07] Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem 1941 Statement and Requirements for a TCP Authentication 1942 Option," draft-bellovin-tcpsec-01, (work in progress), Jul. 1943 2007. 1945 [Bo07] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler, 1946 "Authentication for TCP-based Routing and Management 1947 Protocols," draft-bonica-tcp-auth-06, (work in progress), 1948 Feb. 2007. 1950 [Go07] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- 1951 attacks-05, (work in progress), Jun. 2009. 1953 [Je07] Jethanandani, M., M. Bashyam, "TCP Robustness in Persist 1954 Condition," draft-mahesh-persist-timeout-03, (work in 1955 progress), Oct. 2007. 1957 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, 1958 Informational, April 1992. 1960 [RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for 1961 High Performance," RFC-1323, May 1992. 1963 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks," 1964 RFC-1948, Informational, May 1996. 1966 [RFC2104] Krawczyk, H., M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 1967 for Message Authentication," RFC-2104, Informational, Feb. 1968 1997. 1970 [RFC2766] Tsirtsis, G., P. Srisuresh, "Network Address Translation - 1971 Protocol Translation (NAT-PT)," RFC-2766, Proposed 1972 Standard, Feb. 2000. 1974 [RFC3234] Carpenter, B., S. Brim, "Middleboxes: Taxonomy and Issues," 1975 RFC-3234, Informational, Feb. 2002. 1977 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 1978 Signature Option," RFC-3562, Informational, July 2003. 1980 [RFC3947] Kivinen, T., B. Swander, A. Huttunen, V. Volpe, 1981 "Negotiation of NAT-Traversal in the IKE," RFC-3947, 1982 Proposed Standard, Jan. 2005. 1984 [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet 1985 Protocol," RFC-4301, Proposed Standard, Dec. 2005. 1987 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5," 1988 RFC-4808, Informational, Mar. 2007. 1990 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks," 1991 RFC-4953, Informational, Jul. 2007. 1993 [Sa99] Savage, S., N. Cardwell, D. Wetherall, T. Anderson, "TCP 1994 Congestion Control with a Misbehaving Receiver," ACM 1995 Computer Communications Review, V29, N5, pp71-78, October 1996 1999. 1998 [SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4)," 1999 Specification SDN.401, Revision 1.2, July 12, 1988. 2001 [To06] Touch, J., A. Mankin, "The TCP Simple Authentication 2002 Option," draft-touch-tcpm-tcp-simple-auth-03, (expired work 2003 in progress), Oct. 2006. 2005 [Wa05] Wang, X., H. Yu, "How to break MD5 and other hash 2006 functions," Proc. IACR Eurocrypt 2005, Denmark, pp.19-35. 2008 [We05] Weis, B., "TCP Message Authentication Code Option," draft- 2009 weis-tcp-mac-option-00, (expired work in progress), Dec. 2010 2005. 2012 16. Acknowledgments 2014 Alfred Hoenes, Charlie Kaufman, and Adam Langley provided substantial 2015 feedback on this document. 2017 This document was prepared using 2-Word-v2.0.template.dot. 2019 Authors' Addresses 2021 Joe Touch 2022 USC/ISI 2023 4676 Admiralty Way 2024 Marina del Rey, CA 90292-6695 2025 U.S.A. 2027 Phone: +1 (310) 448-9151 2028 Email: touch@isi.edu 2029 URL: http://www.isi.edu/touch 2030 Allison Mankin 2031 Johns Hopkins Univ. 2032 Washington, DC 2033 U.S.A. 2035 Phone: 1 301 728 7199 2036 Email: mankin@psg.com 2037 URL: http://www.psg.com/~mankin/ 2039 Ronald P. Bonica 2040 Juniper Networks 2041 2251 Corporate Park Drive 2042 Herndon, VA 20171 2043 U.S.A. 2045 Email: rbonica@juniper.net