idnits 2.17.1 draft-ietf-tcpm-tcp-auth-opt-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 915 has weird spacing: '...fic_key r-I...' == Line 917 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 (October 26, 2009) is 5289 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 (-05) exists of draft-ietf-tcpm-tcpmss-02 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-06 == Outdated reference: A later version (-02) exists of draft-ananth-tcpm-persist-01 -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 6 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: April 2010 R. Bonica 6 Juniper Networks 7 October 26, 2009 9 The TCP Authentication Option 10 draft-ietf-tcpm-tcp-auth-opt-07.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 April 26, 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 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the BSD License. 50 Abstract 52 This document specifies the TCP Authentication Option (TCP-AO), which 53 obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO 54 specifies the use of stronger Message Authentication Codes (MACs), 55 protects against replays even for long-lived TCP connections, and 56 provides more details on the association of security with TCP 57 connections than TCP MD5. TCP-AO is compatible with either static 58 master key tuple (MKT) configuration or an external, out-of-band MKT 59 management mechanism; in either case, TCP-AO also protects 60 connections when using the same MKT across repeated instances of a 61 connection, using traffic keys derived from the MKT, and coordinates 62 MKT changes between endpoints. The result is intended to support 63 current infrastructure uses of TCP MD5, such as to protect long-lived 64 connections (as used, e.g., in BGP and LDP), and to support a larger 65 set of MACs with minimal other system and operational changes. TCP-AO 66 uses its own option identifier, even though used mutually exclusive 67 of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is 68 fully compatible with the requirements for the replacement of TCP 69 MD5. 71 Table of Contents 73 1. Contributors...................................................3 74 2. Introduction...................................................4 75 2.1. Executive Summary.........................................4 76 2.2. Changes from Previous Version.............................6 77 2.2.1. New in draft-ietf-tcp-auth-opt-07....................6 78 2.2.2. New in draft-ietf-tcp-auth-opt-06....................6 79 3. Conventions used in this document..............................7 80 4. The TCP Authentication Option..................................7 81 4.1. Review of TCP MD5 Option..................................7 82 4.2. The TCP-AO Option.........................................8 83 5. TCP-AO Keys and Their Properties..............................10 84 5.1. Master Key Tuple.........................................10 85 5.2. Traffic Keys.............................................12 86 5.3. MKT Properties...........................................13 87 6. Per-Connection TCP-AO Parameters..............................14 88 7. Cryptographic Algorithms......................................15 89 7.1. MAC Algorithms...........................................15 90 7.2. Key Derivation Functions.................................18 91 7.3. Traffic Key Establishment and Duration Issues............22 92 7.3.1. MKT Reuse Across Socket Pairs.......................22 93 7.3.2. MKTs Use Within a Long-lived Connection.............23 94 8. Additional Security Mechanisms................................23 95 8.1. Coordinating Use of New MKTs.............................23 96 8.2. Preventing replay attacks within long-lived connections..24 97 9. TCP-AO Interaction with TCP...................................26 98 9.1. TCP User Interface.......................................27 99 9.2. TCP States and Transitions...............................28 100 9.3. TCP Segments.............................................28 101 9.4. Sending TCP Segments.....................................29 102 9.5. Receiving TCP Segments...................................30 103 9.6. Impact on TCP Header Size................................32 104 10. Obsoleting TCP MD5 and Legacy Interactions...................33 105 11. Interactions with Middleboxes................................33 106 11.1. Interactions with non-NAT/NAPT Middleboxes..............34 107 11.2. Interactions with NAT/NAPT Devices......................34 108 12. Evaluation of Requirements Satisfaction......................34 109 13. Security Considerations......................................40 110 14. IANA Considerations..........................................42 111 15. References...................................................43 112 15.1. Normative References....................................43 113 15.2. Informative References..................................44 114 16. Acknowledgments..............................................45 116 1. Contributors 118 This document evolved as the result of collaboration of the TCP 119 Authentication Design team (tcp-auth-dt), whose members were 120 (alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy, 121 Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy 122 Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus 123 Westerlund. The text of this document is derived from a proposal by 124 Joe Touch and Allison Mankin [To06] (originally from June 2006), 125 which was both inspired by and intended as a counterproposal to the 126 revisions to TCP MD5 suggested in a document by Ron Bonica, Brian 127 Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07] 128 (originally from Sept. 2005) and in a document by Brian Weis [We05]. 130 Russ Housley suggested L4/application layer management of the master 131 key tuples. Steve Bellovin motivated the KeyID field. Eric Rescorla 132 suggested the use of ISNs in the traffic key computation and SNEs to 133 avoid replay attacks, and Brian Weis extended the computation to 134 incorporate the entire connection ID and provided the details of the 135 traffic key computation. Mark Allman, Wes Eddy, Lars Eggert, Ted 136 Faber, Russ Housley, Gregory Lebovitz, Tim Polk, Eric Rescorla, Joe 137 Touch, and Brian Weis developed the master key coordination 138 mechanism. 140 2. Introduction 142 The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates 143 TCP segments, including the TCP IPv4 pseudoheader, TCP header, and 144 TCP data. It was developed to protect BGP sessions from spoofed TCP 145 segments which could affect BGP data or the robustness of the TCP 146 connection itself [RFC2385][RFC4953]. 148 There have been many recent concerns about TCP MD5. Its use of a 149 simple keyed hash for authentication is problematic because there 150 have been escalating attacks on the algorithm itself [Wa05]. TCP MD5 151 also lacks both key management and algorithm agility. This document 152 adds the latter, and provides a simple key coordination mechanism 153 giving the ability to move from one key to another within the same 154 connection. It does not however provide for complete cryptographic 155 key management to be handled in-band of TCP, because TCP SYN segments 156 lack sufficient remaining space to handle such a negotiation (see 157 Section 9.6). This document obsoletes the TCP MD5 option with a more 158 general TCP Authentication Option (TCP-AO), to support the use of 159 other, stronger hash functions, provide replay protection for long- 160 lived connections and across repeated instances of a single 161 connection, coordinate key changes between endpoints, and to provide 162 a more structured recommendation on external key management. The 163 result is compatible with IPv6, and is fully compatible with 164 requirements under development for a replacement for TCP MD5 [Be07]. 166 This document is not intended to replace the use of the IPsec suite 167 (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In 168 fact, we recommend the use of IPsec and IKE, especially where IKE's 169 level of existing support for parameter negotiation, session key 170 negotiation, or rekeying are desired. TCP-AO is intended for use only 171 where the IPsec suite would not be feasible, e.g., as has been 172 suggested is the case to support some routing protocols, or in cases 173 where keys need to be tightly coordinated with individual transport 174 sessions [Be07]. 176 Note that TCP-AO obsoletes TCP MD5, although a particular 177 implementation may support both mechanisms for backward 178 compatibility. For a given connection, only one can be in use. TCP 179 MD5-protected connections cannot be migrated to TCP-AO because TCP 180 MD5 does not support any changes to a connection's security algorithm 181 once established. 183 2.1. Executive Summary 185 This document replaces TCP MD5 as follows [RFC2385]: 187 o TCP-AO uses a separate option Kind for TCP-AO (TBD-IANA-KIND). 189 o TCP-AO allows TCP MD5 to continue to be used concurrently for 190 legacy connections. 192 o TCP-AO replaces MD5's single MAC algorithm with MACs specified in 193 a separate document and can be extended to include other MACs. 195 o TCP-AO allows rekeying during a TCP connection, assuming that an 196 out-of-band protocol or manual mechanism provides the new keys. 197 The option includes a key ID which allows the efficient concurrent 198 use of multiple keys, and a key coordination mechanism using a 199 next key ID manages the key change within a connection. Note that 200 TCP MD5 does not preclude rekeying during a connection, but does 201 not require its support either. Further, TCP-AO supports key 202 changes with zero packet loss, whereas key changes in TCP MD5 can 203 lose packets in transit during the changeover or require trying 204 multiple keys on each received segment during key use overlap 205 because it lacks an explicit key ID. 207 o TCP-AO provides automatic replay protection for long-lived 208 connections using sequence number extensions. 210 o TCP-AO ensures per-connection traffic keys as unique as the TCP 211 connection itself, using TCP's initial sequence numbers (ISNs) for 212 differentiation, even when static master key tuples are used 213 across repeated instances of connections on a single socket pair. 215 o TCP-AO specifies the details of how this option interacts with 216 TCP's states, event processing, and user interface. 218 o The TCP-AO option is 2 bytes shorter than TCP MD5 (16 bytes 219 overall, rather than 18) in the initially specified default case 220 (using a 96-bit MAC). 222 This document differs from an IPsec/IKE solution in that TCP-AO as 223 follows [RFC4301][RFC4306]: 225 o TCP-AO does not support dynamic parameter negotiation. 227 o TCP-AO uses TCP's socket pair (source address, destination 228 address, source port, destination port) as a security parameter 229 index, rather than using a separate field as an index (IPsec's 230 SPI). 232 o TCP-AO forces a change of computed MACs when a connection 233 restarts, even when reusing a TCP socket pair (IP addresses and 234 port numbers) [Be07]. 236 o TCP-AO does not support encryption. 238 o TCP-AO does not authenticate ICMP messages (some ICMP messages may 239 be authenticated when using IPsec, depending on the 240 configuration). 242 2.2. Changes from Previous Version 244 [NOTE: to be omitted upon final publication as RFC; full changelist 245 available from the authors] 247 2.2.1. New in draft-ietf-tcp-auth-opt-07 249 o Change PRF to KDF throughout to coordinate with ao-crypto 251 2.2.2. New in draft-ietf-tcp-auth-opt-06 253 o Items from Stockholm IETF meeting 255 o Unify MAC and KDF function notation with ao-crypto. 257 o Clarify that options are not included in TCP's advertised MSS. 259 o Clarify that segments not matching MKTs should be silently 260 accepted. See Section 9.5 for details. 262 o Clarify that MKTs can be used to derive 4 traffic keys, not 263 that all are always actually derived. 265 o Emphasize that the KeyIDs MAY be the same in both directions. 267 o Change nextkeyID to rnextkeyID, to clarify that it refers to 268 the KeyID in the opposite (receive) direction. Updated 269 descriptions of the header fields in Section 4.2 to clarify 270 this issue. 272 o Clarified that the key coordination mechanism is for 273 performance enhancement on when to start using a new MKT, but 274 that when to stop using an MKT would be a key management 275 protocol issue. Removed previous timers used as hints. 277 3. Conventions used in this document 279 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 280 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 281 document are to be interpreted as described in RFC-2119 [RFC2119]. 283 In this document, these words will appear with that interpretation 284 only when in ALL CAPS. Lower case uses of these words are not to be 285 interpreted as carrying RFC-2119 significance. 287 In this document, the characters ">>" proceeding an indented line(s) 288 indicates a compliance requirement statement using the key words 289 listed above. This convention aids reviewers in quickly identifying 290 or finding the explicit compliance requirements of this RFC. 292 4. The TCP Authentication Option 294 The TCP Authentication Option (TCP-AO) uses a TCP option Kind value 295 of TBD-IANA-KIND. 297 4.1. Review of TCP MD5 Option 299 For review, the TCP MD5 option is shown in Figure 1. 301 +---------+---------+-------------------+ 302 | Kind=19 |Length=18| MD5 digest... | 303 +---------+---------+-------------------+ 304 | | 305 +---------------------------------------+ 306 | | 307 +---------------------------------------+ 308 | | 309 +-------------------+-------------------+ 310 | | 311 +-------------------+ 313 Figure 1 The TCP MD5 Option [RFC2385] 315 In the TCP MD5 option, the length is fixed, and the MD5 digest 316 occupies 16 bytes following the Kind and Length fields, using the 317 full MD5 digest of 128 bits [RFC1321]. 319 The TCP MD5 option specifies the use of the MD5 digest calculation 320 over the following values in the following order: 322 1. The TCP pseudoheader (IP source and destination addresses, 323 protocol number, and segment length). 325 2. The TCP header excluding options and checksum. 327 3. The TCP data payload. 329 4. A key. 331 4.2. The TCP-AO Option 333 The new TCP-AO option provides a superset of the capabilities of TCP 334 MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new 335 Kind field, and similar Length field to TCP MD5, a KeyID field, and a 336 RNextKeyID field as shown in Figure 2. 338 +------------+------------+------------+------------+ 339 | Kind | Length | KeyID | RNextKeyID | 340 +------------+------------+------------+------------+ 341 | MAC ... 342 +-----------------------------------... 344 ...-----------------+ 345 ... MAC (con't) | 346 ...-----------------+ 348 Figure 2 The TCP-AO Option 350 The TCP-AO defines the following fields: 352 o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP- 353 AO uses a new Kind value of TBD-IANA-KIND. 355 >> An endpoint MUST NOT use TCP-AO for the same connection in 356 which TCP MD5 is used. 358 >> A single TCP segment MUST NOT have more than one TCP-AO option. 360 o Length: An unsigned 1-byte field indicating the length of the TCP- 361 AO option in bytes, including the Kind, Length, KeyID, RNextKeyID, 362 and MAC fields. 364 >> The Length value MUST be greater than or equal to 4. 366 >> The Length value MUST be consistent with the TCP header length; 367 this is a consistency check and avoids overrun/underrun abuse. 369 Values of 4 and other small values larger than 4 (e.g., indicating 370 MAC fields of very short length) are of dubious utility but are 371 not specifically prohibited. 373 o KeyID: An unsigned 1-byte field indicating the MKT used to 374 generate the traffic keys which were used to generate the MAC that 375 authenticates this segment. 377 It supports efficient key changes during a connection and/or to 378 help with key coordination during connection establishment, to be 379 discussed further in Section 8.1. Note that the KeyID has no 380 cryptographic properties - it need not be random, nor are there 381 any reserved values. 383 >> KeyID values MAY be the same in both directions of a 384 connection, but do not have to be and there is no special meaning 385 when they are. 387 o RNextKeyID: An unsigned 1-byte field indicating the MKT that the 388 sender is ready use to receive authenticated packets, i.e., the 389 desired 'receive next' keyID. 391 It supports efficient key change coordination, to be discussed 392 further in Section 8.1. Note that the RNextKeyID has no 393 cryptographic properties - it need not be random, nor are there 394 any reserved values. 396 o MAC: Message Authentication Code. Its contents are determined by 397 the particulars of the security association. Typical MACs are 96- 398 128 bits (12-16 bytes), but any length that fits in the header of 399 the segment being authenticated is allowed. The MAC computation is 400 described further in Section 7.1. 402 >> Required support for TCP-AO MACs as defined in [ao-crypto]; 403 other MACs MAY be supported. 405 The TCP-AO option fields do not indicate the MAC algorithm either 406 implicitly (as with TCP MD5) or explicitly. The particular algorithm 407 used is considered part of the configuration state of the 408 connection's security and is managed separately (see Section 5). 410 Please note that the use of TCP-AO does not affect TCP's advertised 411 maximum segment size (MSS), as is the case for all TCP options 412 [Bo09]. 414 The remainder of this document explains how the TCP-AO option is 415 handled and its relationship to TCP. 417 5. TCP-AO Keys and Their Properties 419 TCP-AO relies on two sets of keys to authenticate incoming and 420 outgoing segments: master key tuples (MKTs) and traffic keys. MKTs 421 are used to derive unique traffic keys, and include the keying 422 material used to generate those traffic keys, as well as indicating 423 the associated parameters under which traffic keys are used. Such 424 parameters include whether TCP options are authenticated, and 425 indicators of the algorithms used for traffic key derivation and MAC 426 calculation. Traffic keys are the keying material used to compute the 427 MAC of individual TCP segments. 429 5.1. Master Key Tuple 431 A Master Key Tuple (MKT) describes TCP-AO properties to be associated 432 with one or more connections. It is composed of the following: 434 o TCP connection identifier. A TCP socket pair, i.e., a local IP 435 address, a remote IP address, a TCP local port, and a TCP remote 436 port. Values can be partially specified using ranges (e.g., 2-30), 437 masks (e.g., 0xF0), wildcards (e.g., "*"), or any other suitable 438 indication. 440 o TCP option flag. This flag indicates whether TCP options other 441 than TCP-AO are included in the MAC calculation. When options are 442 included, the content of all options, in the order present, are 443 included in the MAC, with TCP-AO's MAC field zeroed out. When the 444 options are not included, all options other than TCP-AO are 445 excluded from all MAC calculations (skipped over, not zeroed). 446 Note that TCP-AO, with its MAC field zeroed out, is always 447 included in the MAC calculation, regardless of the setting of this 448 flag; this protects the indication of the MAC length as well as 449 the key ID fields (KeyID, RNextKeyID). The option flag applies to 450 TCP options in both directions (incoming and outgoing segments). 452 o IDs. The values used in the KeyID or RNextKeyID of a TCP-AO 453 option; used to differentiate MKTs in concurrent use, as well as 454 to indicate when MKTs are ready for use. 456 Each MKT has two IDs - a SendID and a RecvID. The SendID is 457 inserted as the KeyID of the TCP-OP option of outgoing segments, 458 and the RecvID is matched against the KeyID of the TCP-AO option 459 of incoming segments. These and other uses of these two IDs are 460 described further in Section 9.4 and 9.5. 462 >> MKT IDs MUST support any value, 0-255 inclusive. There are no 463 reserved ID values. 465 ID values are assigned arbitrarily. They can be assigned in 466 sequence, or based on any method mutually agreed by the connection 467 endpoints (e.g., using an external MKT management mechanism). 469 >> IDs MUST NOT be assumed to be randomly assigned. 471 o Master key. A byte sequence used for generating traffic keys, this 472 may be derived from a separate shared key by an external protocol 473 over a separate channel. This sequence is used in the traffic key 474 generation algorithm described in Section 7.2. 476 Implementations are advised to keep master key values in a 477 private, protected area of memory or other storage. 479 o Key Derivation Function (KDF). Indicates the key derivation 480 function and its parameters, as used to generate traffic keys from 481 master keys. Explained further in Section 7.1 [ao-crypto]. 483 o Message Authentication Code (MAC) algorithm. Indicates the MAC 484 algorithm and its parameters as used for this connection, 485 explained further in Section 7.1 [ao-crypto]. 487 >> Components of a MKT MUST NOT change during a connection. 489 MKT component values cannot change during a connection because TCP 490 state is coordinated during connection establishment. TCP lacks a 491 handshake for modifying that state after a connection has been 492 established. 494 >> The set of MKTs MAY change during a connection. 496 MKT parameters are not changed. Instead, new MKTs can be installed, 497 and a connection can change which MKT it uses. 499 >> The IDs of MKTs MUST NOT overlap where their TCP connection 500 identifiers overlap. 502 This document does not address how MKTs are created by users or 503 processes. It is presumed that a MKT affecting a particular 504 connection cannot be destroyed during an active connection - or, 505 equivalently, that its parameters are copied to an area local to the 506 connection (i.e., instantiated) and so changes would affect only new 507 connections. The MKTs can be managed by a separate application 508 protocol. 510 5.2. Traffic Keys 512 A traffic key is a key derived from the MKT and the properties of a 513 connection. For established connections, these properties include the 514 socket pair (local IP address, local TCP port, remote IP address, 515 remote port), and the TCP Initial Sequence Numbers (ISNs) in each 516 direction. Segments exchanged before a connection is established use 517 the same information, substituting zero for unknown values (e.g., 518 ISNs not yet coordinated). 520 A single MKT derives four different MKTs: 522 o Send_SYN_traffic_key 524 o Receive_SYN_traffic_key 526 o Send_other_traffic_key 528 o Receive_other_traffic_key 530 Note that the keys are directional. A given connection typically uses 531 only three of these keys, because only one of the SYN keys is 532 typically used. All four are used only when a connection goes through 533 'simultaneous open' [RFC793]. 535 The relationship between MKTs and traffic keys is shown in Figure 536 Figure 3. Traffic keys are indicated with a "*". Note that every MKT 537 can be used to derive any of the four traffic keys, but only the keys 538 actually needed to handle the segments of a connection need to be 539 computed. Section 7.2 provides further details on how traffic keys 540 are derived. 542 MKT-A MKT-B 543 +---------------------+ +------------------------+ 544 | SendID = 1 | | SendID = 5 | 545 | RecvID = 2 | | RecvID = 6 | 546 | MAC = HMAC-SHA1 | | MAC = AES-CMAC | 547 | KDF = KDF-HMAC-SHA1 | | KDF = KDF-AES-128-CMAC | 548 +---------------------+ +------------------------+ 549 | | 550 +----------+----------+ | 551 | | | 552 v v v 553 Connection 1 Connection 2 Connection 3 554 +------------------+ +------------------+ +------------------+ 555 | * Send_SYN_key | | * Send_SYN_key | | * Send_SYN_key | 556 | * Recv_SYN_key | | * Recv_SYN_key | | * Recv_SYN_key | 557 | * Send_Other_key | | * Send_Other_key | | * Send_Other_key | 558 | * Send_Other_key | | * Send_Other_key | | * Send_Other_key | 559 +------------------+ +------------------+ +------------------+ 561 Figure 3 Relationship between MKTs and traffic keys 563 5.3. MKT Properties 565 TCP-AO requires that every protected TCP segment match exactly one 566 MKT. When an outgoing segment matches an MKT, TCP-AO is used. When no 567 match occurs, TCP-AO is not used. Multiple MKTs may match a single 568 outgoing segment, e.g., when MKTs are being changed. Those MKTs 569 cannot have conflicting IDs (as noted elsewhere), and some mechanism 570 must determine which MKT to use for each given outgoing segment. 572 >> An outgoing TCP segment MUST match at most one desired MKT, 573 indicated by the segment's socket pair. The segment MAY match 574 multiple MKTs, provided that exactly one MKT is indicated as desired. 575 Other information in the segment MAY be used to determine the desired 576 MKT when multiple MKTs match; such information MUST NOT include 577 values in TCP option fields. 579 We recommend that the mechanism used to select from among multiple 580 MKTs use only information that TCP-AO would authenticate. Because 581 MKTs may indicate that non-TCP-AO options are ignored in the MAC 582 calculation, we recommend that TCP options should not be used to 583 determine MKTs. 585 >> An incoming TCP segment containing the TCP-AO option MUST match at 586 exactly one MKT, indicated solely by the segment's socket pair and 587 its TCP-AO KeyID. 589 Incoming segments include an indicator in the TCP-AO option to select 590 from among multiple matching MKTs - the KeyID field. TCP-AO requires 591 that the KeyID alone be used to differentiate multiple matching MKTs, 592 so that MKT changes can be coordinated using the TCP-AO key change 593 coordination mechanism. 595 >> When an outgoing TCP segment matches no MKTs, TCP-AO is not used. 597 TCP-AO is always used when outgoing segments match an MKT, and is not 598 used otherwise. 600 6. Per-Connection TCP-AO Parameters 602 TCP-AO uses a small number of parameters associated with each 603 connection that uses the TCP-AO option, once instantiated. These 604 values can be stored in the Transport Control Block (TCP) [RFC793]. 605 These values are explained in subsequent sections of this document as 606 noted; they include: 608 1. Current_key - the MKT currently used to authenticate outgoing 609 segments, whose SendID is inserted in outgoing segments as KeyID 610 (see Section 9.4, step 5). Incoming segments are authenticated 611 using the MKT corresponding to the segment and the KeyID in its 612 TCP-AO header (see Section 9.5, step 5), as matched against the 613 MKT TCP connection identifier and the MKT RecvID. There is only 614 one current_key at any given time on a particular connection. 616 >> Every TCP connection in a non-IDLE state MUST have at most one 617 current_key specified. 619 2. Rnext_key -the MKT currently preferred for incoming (received) 620 segments, whose RecvID is inserted in outgoing segments as 621 RNextKeyID (see Section 9.5, step 5). 623 >> Each TCP connection in a non-IDLE state MUST have at most one 624 rnext_key specified. 626 3. A pair of Sequence Numbers Extensions (SNEs). SNEs are used to 627 prevent replay attacks, as described in Section 8.2. Each SNE is 628 initialized to zero upon connection establishment. Its use in the 629 MAC calculation is described in Section 7.1. 631 4. One or more MKTs. These are the MKTs that match this connection's 632 socket pair. 634 MKTs are used, together with other parameters of a connection, to 635 create traffic keys unique to each connection, as described in 636 Section 7.2. These traffic keys can be cached after computation, and 637 can be stored in the TCB with the corresponding MKT information. They 638 can be considered part of the per-connection parameters. 640 7. Cryptographic Algorithms 642 TCP-AO also uses cryptographic algorithms to compute the MAC (Message 643 Authentication Code) used to authenticate a segment and its headers; 644 these are called MAC algorithms and are specified in a separate 645 document to facilitate updating the algorithm requirements 646 independently from the protocol [ao-crypto]. TCP-AO also uses 647 cryptographic algorithms to convert MKTs, which can be shared across 648 connections, into unique traffic keys for each connection. These are 649 called Key Derivation Functions (KDFs), and are specified [ao- 650 crypto]. This section describes how these algorithms are used by TCP- 651 AO. 653 7.1. MAC Algorithms 655 MAC algorithms take a variable-length input and a key and output a 656 fixed-length number. This number is used to determine whether the 657 input comes from a source with that same key, and whether the input 658 has been tampered in transit. MACs for TCP-AO have the following 659 interface: 661 MAC = MAC_alg(traffic_key, data_block) 663 INPUT: MAC_alg, traffic_key, data_block 665 OUTPUT: MAC 667 where: 669 o MAC_alg - the specific MAC algorithm used for this computation. 670 The MAC algorithm specifies the output length, so no separate 671 output length parameter is required. This is specified as 672 described in [ao-crypto]. 674 o Traffic_key - traffic key used for this computation. This is 675 computed from the connection's current MKT as described in Section 676 7.2. 678 o Data_block - input data over which the MAC is computed. In TCP-AO, 679 this is the TCP segment prepended by the TCP pseudoheader and TCP 680 header options, as described in Section 7.1. 682 o MAC - the fixed-length output of the MAC algorithm, given the 683 parameters provided. 685 At the time of this writing, the algorithms' definitions for use in 686 TCP-AO, as described in [ao-crypto] are each truncated to 96 bits. 687 Though the algorithms each output a larger MAC, 96 bits provides a 688 reasonable tradeoff between security and message size, for fitting 689 into the TCP-AO header. Though could change in the future, so TCP-AO 690 header sizes should not be assumed as fixed length. 692 The MAC algorithm employed for the MAC computation on a connection is 693 done so by definition in the MKT, per [ao-crypto]'s definitions. 695 The mandatory-to-implement MAC algorithms for use with TCP-AO are 696 described in a separate RFC [ao-crypto]. This allows the TCP-AO 697 specification to proceed along the standards track even if changes 698 are needed to its associated algorithms and their labels (as might be 699 used in a user interface or automated MKT management protocol) as a 700 result of the ever evolving world of cryptography. 702 >> Additional algorithms, beyond those mandated for TCP-AO, MAY be 703 supported. 705 The data input to the MAC is the following fields in the following 706 sequence, interpreted in network-standard byte order: 708 1. The sequence number extension (SNE), in network-standard byte 709 order, as follows (described further in Section 8.2): 711 +--------+--------+--------+--------+ 712 | SNE | 713 +--------+--------+--------+--------+ 715 Figure 4 Sequence number extension 717 The SNE for transmitted segments is maintained locally in the 718 SND.SNE value; for received segments, a local RCV.SNE value is 719 used. The details of how these values are maintained and used is 720 described in Sections 8.2, 9.4, and 9.5. 722 2. The TCP pseudoheader: IP source and destination addresses, 723 protocol number and segment length, all in network byte order, 724 prepended to the TCP header below. The pseudoheader is exactly as 725 used for the TCP checksum in either IPv4 or IPv6 726 [RFC793][RFC2460]: 728 +--------+--------+--------+--------+ 729 | Source Address | 730 +--------+--------+--------+--------+ 731 | Destination Address | 732 +--------+--------+--------+--------+ 733 | zero | Proto | TCP Length | 734 +--------+--------+--------+--------+ 736 Figure 5 TCP IPv4 pseudoheader [RFC793] 738 +--------+--------+--------+--------+ 739 | | 740 + + 741 | | 742 + Source Address + 743 | | 744 + + 745 | | 746 + + 747 +--------+--------+--------+--------+ 748 | | 749 + + 750 | | 751 + Destination Address + 752 | | 753 + + 754 | | 755 +--------+--------+--------+--------+ 756 | Upper-Layer Packet Length | 757 +--------+--------+--------+--------+ 758 | zero | Next Header | 759 +--------+--------+--------+--------+ 761 Figure 6 TCP IPv6 pseudoheader [RFC2460] 763 3. The TCP header, by default including options, and where the TCP 764 checksum and TCP-AO MAC fields are set to zero, all in network 765 byte order. 767 The TCP option flag of the MKT indicates whether the TCP options 768 are included in the MAC. When included, only the TCP-AO MAC field 769 is zeroed. 771 When TCP options are not included, all TCP options except for TCP- 772 AO are omitted from MAC processing. Again, the TCP-AO MAC field is 773 zeroed for the MAC processing. 775 4. The TCP data, i.e., the payload of the TCP segment. 777 Note that the traffic key is not included as part of the data; the 778 MAC algorithm indicates how to use the traffic key, e.g., as HMACs do 779 [RFC2104][RFC2403]. The traffic key is derived from the current MKT 780 as described in Sections 7.2. 782 7.2. Key Derivation Functions 784 TCP-AO's traffic keys are derived from the MKTs using Key Derivation 785 Functions (KDFs). The KDFs used in TCP-AO have the following 786 interface: 788 traffic_key = KDF_alg(master_key, data_block, output_length) 790 INPUT: KDF_alg, master_key, data_block, output_length 792 OUTPUT: traffic_key 794 where: 796 o KDF_alg - the specific key derivation function (KDF) that is the 797 basic building block used in constructing the traffic key, as 798 indicated in the MKT. This is specified as described in [ao- 799 crypto]. 801 o Master_key - The master_key string, as will be stored into the 802 associated MKT. 804 o Data_block - The data block used as input in constructing the 805 traffic_key. The data block provided by TCP-AO is used as the 806 "context" as specified in [ao-crypto]. The specific way this 807 context is used, in conjunction with other information, to create 808 the raw input to the KDF is also explained further in [ao-crypto]. 810 o Output_length - The desired output length of the KDF, i.e., the 811 length to which the KDF's output will be truncated. This is 812 specified as described in [ao-crypto]. 814 o Traffic_key - The desired output of the KDF, of length 815 output_length, to be used as input to the MAC algorithm, as 816 described in Section 7.1. 818 The data used as input to the KDF combines TCP socket pair with the 819 endpoint initial sequence numbers (ISNs) of a connection. This 820 provides context unique to each TCP connection instance, which 821 enables TCP-AO to generate unique traffic keys for that connection, 822 even from a MKT used across many different connections or across 823 repeated connections that share a socket pair. Unique traffic keys 824 are generated without relying on external key management properties. 825 This data block is defined in Figure 7 and Figure 8. 827 +--------+--------+--------+--------+ 828 | Source Address | 829 +--------+--------+--------+--------+ 830 | Destination Address | 831 +--------+--------+--------+--------+ 832 | Source Port | Dest. Port | 833 +--------+--------+--------+--------+ 834 | Source ISN | 835 +--------+--------+--------+--------+ 836 | Dest. ISN | 837 +--------+--------+--------+--------+ 839 Figure 7 Data block for an IPv4 connection 840 +--------+--------+--------+--------+ 841 | | 842 + + 843 | | 844 + Source Address + 845 | | 846 + + 847 | | 848 + + 849 +--------+--------+--------+--------+ 850 | | 851 + + 852 | | 853 + Destination Address + 854 | | 855 + + 856 | | 857 +--------+--------+--------+--------+ 858 | Source Port | Dest. Port | 859 +--------+--------+--------+--------+ 860 | Source ISN | 861 +--------+--------+--------+--------+ 862 | Dest. ISN | 863 +--------+--------+--------+--------+ 865 Figure 8 Data block for an IPv6 connection 867 Traffic keys are directional, so "source" and "destaination" are 868 interpreted differently for incoming and outgoing segments. For 869 incoming packets, source is the remote side, whereas for outgoing 870 packets source is the local side. This further ensures that 871 connection keys generated for each direction are unique. 873 For SYN segments (segments with the SYN set, but the ACK not set), 874 the destination ISN is not known. For these segments, the connection 875 key is computed using the connection block shown above, in which the 876 Destination ISN value is zero. For all other segments, the ISN pair 877 is used when known. If the ISN pair is not known, e.g., when sending 878 a RST after a reboot, the segment should be sent without 879 authentication; if authentication was required, the segment cannot 880 have been MAC'd properly anyway and would have been dropped on 881 receipt. 883 >> TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination 884 ISN of zero (whether sent or received); all other segments use the 885 known ISN pair. 887 Overall, this means that each connection will use up to four distinct 888 traffic keys for each MKT: 890 o Send_SYN_traffic_key - the traffic key used to authenticate 891 outgoing SYNs. The source ISN known (the TCP connection's local 892 ISN), and the destination (remote) ISN is unknown (and so the 893 value 0 is used). 895 o Receive_SYN_traffic_key - the traffic key used to authenticate 896 incoming SYNs. The source ISN known (the TCP connection's remote 897 ISN), and the destination (remote) ISN is unknown (and so the 898 value 0 is used). 900 o Send_other_traffic_key - the traffic key used to authenticate all 901 other outgoing TCP segments. 903 o Receive_other_traffic_key - the traffic key used to authenticate 904 all other incoming TCP segments. 906 The following table describes how each of these traffic keys is 907 computed, where the TCP-AO algorithms refer to source (S) and 908 destination (D) values of the IP address, TCP port, and ISN, and each 909 segment (incoming or outgoing) has a values that refer to the local 910 side of the connection (l) and remote side (r): 912 S-IP S-port S-ISN D-IP D-port D-ISN 913 ---------------------------------------------------------------- 914 Send_SYN_traffic_key l-IP l-port l-ISN r-IP r-port 0 915 Receive_SYN_traffic_key r-IP r-port r-ISN l-IP l-port 0 916 Send_other_traffic_key l-IP l-port l-ISN r-IP r-port r-ISN 917 Receive_other_traffic_key r-IP r-port r-ISN l-IP l-port l-ISN 919 The use of both ISNs in the traffic key computations ensures that 920 segments cannot be replayed across repeated connections reusing the 921 same socket pair (provided the ISN pair does not repeat, which is 922 unlikely because both endpoints should select ISNs pseudorandomly 923 [RFC1948], their 32-bit space avoids repeated use except under 924 reboot, and reuse assumes both sides repeat their use on the same 925 connection). 927 A SYN is authenticated using a destination ISN of zero (whether sent 928 or received), and all other segments would be authenticated using the 929 ISN pair for the connection. There are other cases in which the 930 destination ISN is not known, but segments are emitted, such as after 931 an endpoint reboots, when is possible that the two endpoints would 932 not have enough information to authenticate segments. In such cases, 933 TCP's timeout mechanism will allow old state to be cleared to enable 934 new connections, except where the user timeout is disabled; it is 935 important that implementations are capable of detecting excesses of 936 TCP connections in such a configuration and can clear them out if 937 needed to protect its memory usage [Ba09]. 939 7.3. Traffic Key Establishment and Duration Issues 941 The TCP-AO option does not provide a mechanism for traffic key 942 negotiation or parameter negotiation (MAC algorithm, length, or use 943 of the TCP-AO option), or for coordinating rekeying during a 944 connection. We assume out-of-band mechanisms for MKT establishment, 945 parameter negotiation, and rekeying. This separation of MKT use from 946 MKT management is similar to that in the IPsec security suite 947 [RFC4301][RFC4306]. 949 We encourage users of TCP-AO to apply known techniques for generating 950 appropriate MKTs, including the use of reasonable master key lengths, 951 limited traffic key sharing, and limiting the duration of MKT use 952 [RFC3562]. This also includes the use of per-connection nonces, as 953 suggested in Section 7.2. 955 TCP-AO supports rekeying in which new MKTs are negotiated and 956 coordinated out-of-band, either via a protocol or a manual procedure 957 [RFC4808]. New MKT use is coordinated using the out-of-band mechanism 958 to update both TCP endpoints. When only a single MKT is used at a 959 time, the temporary use of invalid MKTs could result in packets being 960 dropped; although TCP is already robust to such drops, TCP-AO uses 961 the KeyID field to avoid such drops. A given connection can have 962 multiple matching MKTs, where the KeyID field is used to identify the 963 MKT that corresponds to the traffic key used for a segment, to avoid 964 the need for expensive trial-and-error testing of MKTs in sequence. 966 TCP-AO provides an explicit MKT coordination mechanism, described in 967 Section 8.1. Such a mechanism is useful when new MKTs are installed, 968 or when MKTs are changed, to determine when to commence using 969 installed MKTs. 971 Users are advised to manage MKTs following the spirit of the advice 972 for key management when using TCP MD5 [RFC3562], notably to use 973 appropriate key lengths (12-24 bytes) and to avoid sharing MKTs among 974 multiple BGP peering arrangements. 976 7.3.1. MKT Reuse Across Socket Pairs 978 MKTs can be reused across different socket pairs within a host, or 979 across different instances of a socket pair within a host. In either 980 case, replay protection is maintained. 982 MKTs reused across different socket pairs cannot enable replay 983 attacks because the TCP socket pair is included in the MAC, as well 984 as in the generation of the traffic key. MKTs reused across repeated 985 instances of a given socket pair cannot enable replay attacks because 986 the connection ISNs are included in the traffic key generation 987 algorithm, and ISN pairs are unlikely to repeat over useful periods. 989 7.3.2. MKTs Use Within a Long-lived Connection 991 TCP-AO uses sequence number extensions (SNEs) to prevent replay 992 attacks within long-lived connections. Explicit MKT rollover, 993 accomplished by external means and indexed using the KeyID field, can 994 be used to change keying material for various reasons (e.g., 995 personnel turnover), but is not required to support long-lived 996 connections. 998 8. Additional Security Mechanisms 1000 TCP-AO adds mechanisms to support efficient use, especially in 1001 environments where only manual keying is available. These include the 1002 previously described mechanisms for supporting multiple concurrent 1003 MKTs (via the KeyID field) and for generating unique per-connection 1004 traffic keys (via the KDF). This section describes additional 1005 mechanisms to coordinate MKT changes and to prevent replay attacks 1006 when a traffic key is not changed for long periods of time. 1008 8.1. Coordinating Use of New MKTs 1010 At any given time, a single TCP connection may have multiple MKTs 1011 specified for each segment direction (incoming, outgoing). TCP-AO 1012 provides a mechanism to indicate when a new MKT is ready, to allow 1013 the sender to commence use of that new MKT. This mechanism allows new 1014 MKT use to be coordinated, to avoid unnecessary loss due to sender 1015 authentication using a MKT not yet ready at the receiver. 1017 Note that this is intended as an optimization. Deciding when to start 1018 using a key is a performance issue. Deciding when to remove an MKT is 1019 a security issue. Invalid MKTs are expected to be removed. TCP-AO 1020 provides no mechanism to coordinate their removal, as we consider 1021 this a key management operation. 1023 New MKT use is coordinated through two ID fields in the header: 1025 o KeyID 1027 o RNextKeyID 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 RNextKeyID represents the preferred MKT information to be used for 1035 subsequent received segments ('receive next'). I.e., it is a way for 1036 the segment sender to indicate a ready incoming MKT for future 1037 segments it receives, so that the segment receiver can know when to 1038 switch MKTs (and thus their KeyIDs and associated traffic keys). It 1039 indicates the RecvID of 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 (RNext_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. 1076 TCP-AO prevents replay attacks, and thus requires a way to 1077 differentiate these legitimate replays from each other, and so it 1078 adds a 32-bit sequence number extension (SNE) for transmitted and 1079 received segments. 1081 The SNE extends TCP's sequence number so that segments within a 1082 single connection are always unique. When TCP's sequence number rolls 1083 over, there is a chance that a segment could be repeated in total; 1084 using an SNE differentiates even identical segments sent with 1085 identical sequence numbers at different times in a connection. TCP-AO 1086 emulates a 64-bit sequence number space by inferring when to 1087 increment the high-order 32-bit portion (the SNE) based on 1088 transitions in the low-order portion (the TCP sequence number). 1090 TCP-AO thus maintains SND.SNE for transmitted segments, and RCV.SNE 1091 for received segments, both initialized as zero when a connection 1092 begins. The intent of these SNEs is, together with TCP's 32-bit 1093 sequence numbers, to provide a 64-bit overall sequence number space. 1095 For transmitted segments SND.SNE can be implemented by extending 1096 TCP's sequence number to 64-bits; SND.SNE would be the top (high- 1097 order) 32 bits of that number. For received segments, TCP-AO needs to 1098 emulate the use of a 64-bit number space, and correctly infer the 1099 appropriate high-order 32-bits of that number as RCV.SNE from the 1100 received 32-bit sequence number and the current connection context. 1102 The implementation of SNEs is not specified in this document, but one 1103 possible way is described here that can be used for either RCV.SNE, 1104 SND.SNE, or both. 1106 Consider an implementation with two SNEs as required (SND.SNE, RCV. 1107 SNE), and additional variables as listed below, all initialized to 1108 zero, as well as a current TCP segment field (SEG.SEQ): 1110 o SND.PREV_SEQ, needed to detect rollover of SND.SEQ 1112 o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ 1114 o SND.SNE_FLAG, which indicates when to increment the SND.SNE 1116 o RCV.SNE_FLAG, which indicates when to increment the RCV.SNE 1118 When a segment is received, the following algorithm (in C-like 1119 pseudocode) computes the SNE used in the MAC; an equivalent algorithm 1120 can be applied to the "SND" side: 1122 /* set the flag when the SEG.SEQ first rolls over */ 1123 if ((RCV.SNE_FLAG == 0) 1124 && (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) { 1125 RCV.SNE = RCV.SNE + 1; 1126 RCV.SNE_FLAG = 1; 1127 } 1128 /* decide which SNE to use after incremented */ 1129 if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) { 1130 SNE = RCV.SNE - 1; # use the pre-increment value 1131 } else { 1132 SNE = RCV.SNE; # use the current value 1133 } 1134 /* reset the flag in the *middle* of the window */ 1135 if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) { 1136 RCV.SNE_FLAG = 0; 1137 } 1138 /* save the current SEQ for the next time through the code */ 1139 RCV.PREV_SEQ = SEG.SEQ; 1141 In the above code, the first line when the sequence number first 1142 rolls over, i.e., when the new number is low (in the bottom half of 1143 the number space) and the old number is high (in the top half of the 1144 number space). The first time this happens, the SNE is incremented 1145 and a flag is set. 1147 If the flag is set and a high number is seen, it must be a reordered 1148 packet, so use the pre-increment SNE, otherwise use the current SNE. 1149 The flag will be cleared by the time the number rolls all the way 1150 around. 1152 The flag prevents the SNE from being incremented again until the flag 1153 is reset, which happens in the middle of the window (when the old 1154 number is in the bottom half and the new is in the top half). Because 1155 the receive window is never larger than half of the number space, it 1156 is impossible to both set and reset the flag at the same time - 1157 outstanding packets, regardless of reordering, cannot straddle both 1158 regions simultaneously. 1160 9. TCP-AO Interaction with TCP 1162 The following is a description of how TCP-AO affects various TCP 1163 states, segments, events, and interfaces. This description is 1164 intended to augment the description of TCP as provided in RFC-793, 1165 and its presentation mirrors that of RFC-793 as a result [RFC793]. 1167 9.1. TCP User Interface 1169 The TCP user interface supports active and passive OPEN, SEND, 1170 RECEIVE, CLOSE, STATUS and ABORT commands. TCP-AO does not alter this 1171 interface as it applies to TCP, but some commands or command 1172 sequences of the interface need to be modified to support TCP-AO. 1173 TCP-AO does not specify the details of how this is achieved. 1175 TCP-AO requires the TCP user interface be extended to allow the MKTs 1176 to be configured, as well as to allow an ongoing connection to manage 1177 which MKTs are active. The MKTs need to be configured prior to 1178 connection establishment, and the set of MKTs may change during a 1179 connection: 1181 >> TCP OPEN, or the sequence of commands that configure a connection 1182 to be in the active or passive OPEN state, MUST be augmented so that 1183 a MKT can be configured. 1185 >> A TCP-AO implmentation MUST allow the set of MKTs for ongoing TCP 1186 connections (i.e., not in the CLOSED state) to be modified. 1188 The MKTs associated with a connection needs to be available for 1189 confirmation; this includes the ability to read the MKTs: 1191 >> TCP STATUS SHOULD be augmented to allow the MKTs of a current or 1192 pending connection to be read (for confirmation). 1194 Senders may need to be able to determine when the outgoing MKT 1195 changes (KeyID) or when a new preferred MKT (RNextKeyID) is 1196 indicated; these changes immediately affect all subsequent outgoing 1197 segments: 1199 >> TCP SEND, or a sequence of commands resulting in a SEND, MUST be 1200 augmented so that the preferred outgoing MKT (Current_key) and/or the 1201 preferred incoming MKT Next_key of a connection can be indicated. 1203 It may be useful to change the outgoing active MKT (Current_key) even 1204 when no data is being sent, which can be achieved by sending a zero- 1205 length buffer or by using a non-send interface (e.g., socket options 1206 in Unix), depending on the implementation. 1208 It is also useful to indicate recent segment KeyID and RNextKeyID 1209 values received; although there could be a number of such values, 1210 they are not expected to change quickly so any recent sample should 1211 be sufficient: 1213 >> TCP RECEIVE, or the sequence of commands resulting in a RECEIVE, 1214 MUST be augmented so that the KeyID and RNextKeyID of a recently 1215 received segment is available to the user out-of-band (e.g., as an 1216 additional parameter to RECEIVE, or via a STATUS call). 1218 9.2. TCP States and Transitions 1220 TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, 1221 FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and 1222 CLOSED. 1224 >> A MKT MAY be associated with any TCP state. 1226 9.3. TCP Segments 1228 TCP includes control (at least one of SYN, FIN, RST flags set) and 1229 data (none of SYN, FIN, or RST flags set) segments. Note that some 1230 control segments can include data (e.g., SYN). 1232 >> All TCP segments MUST be checked against the set of MKTs for 1233 matching TCP connection identifiers. 1235 >> TCP segments whose TCP-AO option does not validate MUST be 1236 silently discarded. 1238 >> A TCP-AO implementation MUST allow for configuration of the 1239 behavior of segments with the TCP-AO option but that do not match an 1240 MKT. The initial default of this configuration SHOULD be to silently 1241 accept such connections. If this is not the desired case, an MKT can 1242 be included to match such connections, or the connection can indicate 1243 that TCP-AO is required. Alternately, the configuration can be 1244 changed to discard segments with the AO option not matching an MKT. 1246 >> Silent discard events SHOULD be signaled to the user as a warning, 1247 and silent accept events MAY be signaled to the user as a warning. 1248 Both warnings, if available, MUST be accessible via the STATUS 1249 interface. Either signal MAY be asynchronous, but if so they MUST be 1250 rate-limited. Either signal MAY be logged; logging SHOULD allow rate- 1251 limiting as well. 1253 All TCP-AO processing occurs between the interface of TCP and IP; for 1254 incoming segments, this occurs after validation of the TCP checksum. 1255 For outgoing segments, this occurs before computation of the TCP 1256 checksum. 1258 Note that the TCP-AO option is not negotiated. It is the 1259 responsibility of the receiver to determine when TCP-AO is required 1260 and to enforce that requirement. 1262 9.4. Sending TCP Segments 1264 The following procedure describes the modifications to TCP to support 1265 TCP-AO when a segment departs. 1267 >> Note that TCP-AO MUST be the last TCP option processed on outgoing 1268 segments, because its MAC calculation may include the values of other 1269 TCP options. 1271 1. Find the per-connection parameters for the segment: 1273 a. If the segment is a SYN, then this is the first segment of a 1274 new connection. Find the matching MKT for this segment based 1275 on the segment's socket pair. 1277 i. If there is no matching MKT, omit the TCP-AO option. 1278 Proceed with transmitting the segment. 1280 ii. If there is a matching MKT, then set the per-connection 1281 parameters as needed (see Section 6). Proceed with the 1282 step 2. 1284 b. If the segment is not a SYN, then determine whether TCP-AO is 1285 being used for the connection and use the MKT as indicated by 1286 the current_key value from the per-connection parameters (see 1287 Section 6) and proceed with the step 2. 1289 2. Using the per-connection parameters: 1291 a. Augment the TCP header with the TCP-AO, inserting the 1292 appropriate Length and KeyID based on the MKT indicated by 1293 current_key (using the current_key MKT's SendID as the TCP-AO 1294 KeyID). Update the TCP header length accordingly. 1296 b. Determine SND.SNE as described in Section 8.2. 1298 c. Determine the appropriate traffic key, i.e., as pointed to by 1299 current_key (as noted in Section 8.1, and as probably cached 1300 in the TCB). I.e., use the send_SYN_traffic_key for SYN 1301 segments, and the send_other_traffic_key for other segments. 1303 d. Determine the RNextKeyID as indicated by the Rnext_key 1304 pointer, and insert it in the TCP-AO option (using the 1305 next_key MKT's RecvID as the TCP-AO KeyID) (as noted in 1306 Section 8.1). 1308 e. Compute the MAC using the MKT (and cached traffic key) and 1309 data from the segment as specified in Section 7.1. 1311 f. Insert the MAC in the TCP-AO MAC field. 1313 g. Proceed with transmitting the segment. 1315 9.5. Receiving TCP Segments 1317 The following procedure describes the modifications to TCP to support 1318 TCP-AO when a segment arrives. 1320 >> Note that TCP-AO MUST be the first TCP option processed on 1321 incoming segments, because its MAC calculation may include the values 1322 of other TCP options which could change during TCP option processing. 1323 This also protects the behavior of all other TCP options from the 1324 impact of spoofed segments or modified header information. 1326 >> Note that TCP-AO checks MUST be performed for all incoming SYNs to 1327 avoid accepting SYNs lacking the TCP-AO option where required. Other 1328 segments can cache whether TCP-AO is needed in the TCB. 1330 1. Find the per-connection parameters for the segment: 1332 a. If the segment is a SYN, then this is the first segment of a 1333 new connection. Find the matching MKT for this segment, using 1334 the segment's socket pair and its TCP-AO KeyID, matched 1335 against the MKT's TCP connection identifier and the MKT's 1336 RecvID. 1338 i. If there is no matching MKT, remove the TCP-AO option 1339 from the segment. Proceed with further TCP handling of 1340 the segment. 1342 NOTE: this presumes that connections that do not match 1343 any MKT should be silently accepted, as noted in Sec 9.3. 1345 ii. If there is a matching MKT, then set the per-connection 1346 parameters as needed (see Section 6). Proceed with the 1347 step 2. 1349 2. Using the per-connection parameters: 1351 a. Check that the segment's TCP-AO Length matches the length 1352 indicated by the MKT. 1354 i. If lengths differ, silently discard the segment. Log 1355 and/or signal the event as indicated in Section 9.3. 1357 b. Determine the segment's RCV.SNE as described in Section 8.2. 1359 c. Determine the segment's traffic key from the MKT as described 1360 in Section 7.1 (and as likely cached in the TCB). I.e., use 1361 the receive_SYN_traffic_key for SYN segments, and the 1362 receive_other_traffic_key for other segments. 1364 d. Compute the segment's MAC using the MKT (and its derived 1365 traffic key) and portions of the segment as indicated in 1366 Section 7.1. 1368 i. If the computed MAC differs from the TCP-AO MAC field 1369 value, silently discard the segment. Log and/or signal 1370 the event as indicated in Section 9.3. 1372 e. Compare the received RNextKeyID value to the currently active 1373 outgoing KeyID value (Current_key MKT's SendID). 1375 i. If they match, no further action is required. 1377 ii. If they differ, determine whether the RNextKeyID MKT is 1378 ready. 1380 1. If the MKT corresponding to the segment's socket 1381 pair and RNextKeyID is not available, no action is 1382 required (RNextKeyID of a received segment needs to 1383 match the MKT's SendID). 1385 2. If the matching MKT corresponding to the segment's 1386 socket pair and RNextKeyID is available: 1388 a. Set Current_key to the RNextKeyID 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 may 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 [RFC2663][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 An alternate proposal for accommodating NATs extends TCP-AO 1522 independently of this specification [ao-nat]. 1524 12. Evaluation of Requirements Satisfaction 1526 TCP-AO satisfies all the current requirements for a revision to TCP 1527 MD5, as summarized below [Be07]. 1529 1. Protected Elements 1531 A solution to revising TCP MD5 should protect (authenticate) the 1532 following elements. 1534 This is supported - see Section 7.1. 1536 a. TCP pseudoheader, including IPv4 and IPv6 versions. 1538 Note that we do not allow optional coverage because IP 1539 addresses define a connection. If they can be coordinated 1540 across a NAT/NAPT, the sender can compute the MAC based on the 1541 received values; if not, a tunnel is required, as noted in 1542 Section 11.2. 1544 b. TCP header. 1546 Note that we do not allow optional port coverage because ports 1547 define a connection. If they can be coordinated across a 1548 NAT/NAPT, the sender can compute the MAC based on the received 1549 values; if not, a tunnel is required, as noted in Section 1550 11.2. 1552 c. TCP options. 1554 Note that TCP-AO allows exclusion of TCP options from 1555 coverage, to enable use with middleboxes that modify options 1556 (except when they modify TCP-AO itself). See Section 11. 1558 d. TCP payload data. 1560 2. Option Structure Requirements 1562 A solution to revising TCP MD5 should use an option with the 1563 following structural requirements. 1565 This is supported - see Section 7.1. 1567 a. Privacy. 1569 The option should not unnecessarily expose information about 1570 the TCP-AO mechanism. The additional protection afforded by 1571 keeping this information private may be of little value, but 1572 also helps keep the option size small. 1574 TCP-AO exposes only the MKT IDs, MAC, and overall option 1575 length on the wire. Note that short MACs could be obscured by 1576 using longer option lengths but specifying a short MAC length 1577 (this is equivalent to a different MAC algorithm, and is 1578 specified in the TAPD entry). See Section 4.2. 1580 b. Allow optional per connection. 1582 The option should not be required on every connection; it 1583 should be optional on a per connection basis. 1585 This is supported because the set of MKTs can be installed to 1586 match some connections and not others. Connections not 1587 matching any MKT do not require TCP-AO. Further, incoming 1588 segments containing the TCP-AO option are not discarded solely 1589 because they include the option, provided they do not match 1590 any MKT. 1592 c. Require non-optional. 1594 The option should be able to be specified as required for a 1595 given connection. 1597 This is supported because the set of MKTs can be installed to 1598 match some connections and not others. Connections matching 1599 any MKT require TCP-AO. 1601 d. Standard parsing. 1603 The option should be easily parseable, i.e., without 1604 conditional parsing, and follow the standard RFC 793 option 1605 format. 1607 This is supported - see Section 4.2. 1609 e. Compatible with Large Windows and SACK. 1611 The option should be compatible with the use of the Large 1612 Windows and SACK options. 1614 This is supported - see Section 9.6. The size of the option is 1615 intended to allow use with Large Windows and SACK. See also 1616 Section 2.1, which indicates that TCP-AO is 3 bytes shorter 1617 than TCP MD5 in the default case, assuming a 96-bit MAC. 1619 3. Cryptography requirements 1621 A solution to revising TCP MD5 should support modern cryptography 1622 capabilities. 1624 a. Baseline defaults. 1626 The option should have a default that is required in all 1627 implementations. 1629 TCP-AO uses a default required algorithm as specified in [ao- 1630 crypto], as noted in Section 7.1. 1632 b. Good algorithms. 1634 The option should use algorithms considered accepted by the 1635 security community, which are considered appropriately safe. 1636 The use of non-standard or unpublished algorithms should be 1637 avoided. 1639 TCP-AO uses MACs as indicated in [ao-crypto]. The KDF is also 1640 specified in [ao-crypto]. The KDF input string follows the 1641 typical design (see [ao-crypto]). 1643 c. Algorithm agility. 1645 The option should support algorithms other than the default, 1646 to allow agility over time. 1648 TCP-AO allows any desired algorithm, subject to TCP option 1649 space limitations, as noted in Section 4.2. The use of set of 1650 MKTs allows separate connections to use different algorithms, 1651 both for the MAC and the KDF. 1653 d. Order-independent processing. 1655 The option should be processed independently of the proper 1656 order, i.e., they should allow processing of TCP segments in 1657 the order received, without requiring reordering. This avoids 1658 the need for reordering prior to processing, and avoids the 1659 impact of misordered segments on the option. 1661 This is supported - see Sections 9.3, 9.4, and 9.5. Note that 1662 pre-TCP processing is further required, because TCP segments 1663 cannot be discarded solely based on a combination of 1664 connection state and out-of-window checks; many such segments, 1665 although discarded, cause a host to respond with a replay of 1666 the last valid ACK, e.g. [RFC793]. See also the derivation of 1667 the SNE, which is reconstituted at the receiver using a 1668 demonstration algorithm that avoids the need for reordering 1669 (in Section 8.2). 1671 e. Security parameter changes require key changes. 1673 The option should require that the MKT change whenever the 1674 security parameters change. This avoids the need for 1675 coordinating option state during a connection, which is 1676 typical for TCP options. This also helps allow "bump in the 1677 stack" implementations that are not integrated with endpoint 1678 TCP implementations. 1680 Parameters change only when a new MKT is used. See Section 5. 1682 4. Keying requirements. 1684 A solution to revising TCP MD5 should support manual keying, and 1685 should support the use of an external automated key management 1686 system (e.g., a protocol or other mechanism). 1688 Note that TCP-AO does not specify a MKT management system. 1690 a. Intraconnection rekeying. 1692 The option should support rekeying during a connection, to 1693 avoid the impact of long-duration connections. 1695 This is supported by the use of IDs and multiple MKTs; see 1696 Section 5. 1698 b. Efficient rekeying. 1700 The option should support rekeying during a connection without 1701 the need to expend undue computational resources. In 1702 particular, the options should avoid the need to try multiple 1703 keys on a given segment. 1705 This is supported by the use of the KeyID. See Section 8.1. 1707 c. Automated and manual keying. 1709 The option should support both automated and manual keying. 1711 The use of MKTs allows external automated and manual keying. 1712 See Section 5. This capability is enhanced by the generation 1713 of unique per-connection keys, which enables use of manual 1714 MKTs with automatically generated traffic keys as noted in 1715 Section 7.2. 1717 d. Key management agnostic. 1719 The option should not assume or require a particular key 1720 management solution. 1722 This is supported by use of a set of MKTs. See Section 5. 1724 5. Expected Constraints 1726 A solution to revising TCP MD5 should also abide by typical safe 1727 security practices. 1729 a. Silent failure. 1731 Receipt of segments failing authentication must result in no 1732 visible external action and must not modify internal state, 1733 and those events should be logged. 1735 This is supported - see Sections 9.3, 9.4, and 9.5. 1737 b. At most one such option per segment. 1739 Only one authentication option can be permitted per segment. 1741 This is supported by the protocol requirements - see Section 1742 4.2. 1744 c. Outgoing all or none. 1746 Segments out of a TCP connection are either all authenticated 1747 or all not authenticated. 1749 This is supported - see Section 9.4. 1751 d. Incoming all checked. 1753 Segments into a TCP connection are always checked to determine 1754 whether their authentication should be present and valid. 1756 This is supported - see Section 9.5. 1758 e. Non-interaction with TCP MD5. 1760 The use of this option for a given connection should not 1761 preclude the use of TCP MD5, e.g., for legacy use, for other 1762 connections. 1764 This is supported - see Section 10. 1766 f. Optional ICMP discard. 1768 The option should allow certain ICMPs to be discarded, notably 1769 Type 3 (destination unreachable), Codes 2-4 (transport 1770 protocol unreachable, port unreachable, or fragmentation 1771 needed and IP DF field set), i.e., the ones indicating the 1772 failure of the endpoint to communicate. 1774 This is supported - see Section 13. 1776 g. Maintain TCP connection semantics, in which the socket pair 1777 alone defines a TCP association and all its security 1778 parameters. 1780 This is supported - see Sections 5 and 11. 1782 13. Security Considerations 1784 Use of TCP-AO, like use of TCP MD5 or IPsec, will impact host 1785 performance. Connections that are known to use TCP-AO can be attacked 1786 by transmitting segments with invalid MACs. Attackers would need to 1787 know only the TCP connection ID and TCP-AO Length value to 1788 substantially impact the host's processing capacity. This is similar 1789 to the susceptibility of IPsec to on-path attacks, where the IP 1790 addresses and SPI would be visible. For IPsec, the entire SPI space 1791 (32 bits) is arbitrary, whereas for routing protocols typically only 1792 the source port (16 bits) is arbitrary. As a result, it would be 1793 easier for an off-path attacker to spoof a TCP-AO segment that could 1794 cause receiver validation effort. However, we note that between 1795 Internet routers both ports could be arbitrary (i.e., determined a- 1796 priori out of band), which would constitute roughly the same off-path 1797 antispoofing protection of an arbitrary SPI. 1799 TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets 1800 typically occur after peer crashes, either in response to new 1801 connection attempts or when data is sent on stale connections; in 1802 either case, the recovering endpoint may lack the connection key 1803 required (e.g., if lost during the crash). This may result in time- 1804 outs, rather than more responsive recovery after such a crash. As 1805 noted in Section 7.2, such cases may also result in persistent TCP 1806 state for old connections that cannot be cleared, and so 1807 implementations should be capable of detecting an excess of such 1808 connections and clearing their state if needed to protect memory 1809 utilization [Ba09]. 1811 TCP-AO does not include a fast decline capability, e.g., where a SYN- 1812 ACK is received without an expected TCP-AO option and the connection 1813 is quickly reset or aborted. Normal TCP operation will retry and 1814 timeout, which is what should be expected when the intended receiver 1815 is not capable of the TCP variant required anyway. Backoff is not 1816 optimized because it would present an opportunity for attackers on 1817 the wire to abort authenticated connection attempts by sending 1818 spoofed SYN-ACKs without the TCP-AO option. 1820 TCP-AO is intended to provide similar protections to IPsec, but is 1821 not intended to replace the use of IPsec or IKE either for more 1822 robust security or more sophisticated security management. 1824 TCP-AO does not address the issue of ICMP attacks on TCP. IPsec makes 1825 recommendations regarding dropping ICMPs in certain contexts, or 1826 requiring that they are endpoint authenticated in others [RFC4301]. 1827 There are other mechanisms proposed to reduce the impact of ICMP 1828 attacks by further validating ICMP contents and changing the effect 1829 of some messages based on TCP state, but these do not provide the 1830 level of authentication for ICMP that TCP-AO provides for TCP [Go09]. 1832 >> A TCP-AO implementation MUST allow the system administrator to 1833 configure whether TCP will ignore incoming ICMP messages of Type 3 1834 (destination unreachable) Codes 2-4 (protocol unreachable, port 1835 unreachable, and fragmentation needed - 'hard errors') intended for 1836 connections that match MKTs. An implementation SHOULD allow ignored 1837 ICMPs to be logged. 1839 This control affects only ICMPs that currently require 'hard errors', 1840 which would abort the TCP connection [RFC1122]. This recommendation 1841 is intended to be similar to how IPsec would handle those messages 1842 [RFC4301]. 1844 TCP-AO includes the TCP connection ID (the socket pair) in the MAC 1845 calculation. This prevents different concurrent connections using the 1846 same MKT (for whatever reason) from potentially enabling a traffic- 1847 crossing attack, in which segments to one socket pair are diverted to 1848 attack a different socket pair. When multiple connections use the 1849 same MKT, it would be useful to know that packets intended for one ID 1850 could not be (maliciously or otherwise) modified in transit and end 1851 up being authenticated for the other ID. That requirement would place 1852 an additional burden of uniqueness on MKTs within endsystems, and 1853 potentially across endsystems. Although the resulting attack is low 1854 probability, the protection afforded by including the received ID 1855 warrants its inclusion in the MAC, and does not unduly increase the 1856 MAC calculation or MKT management. 1858 The use of any security algorithm can present an opportunity for a 1859 CPU DOS attack, where the attacker sends false, random segments that 1860 the receiver under attack expends substantial CPU effort to reject. 1861 In IPsec, such attacks are reduced by the use of a large Security 1862 Parameter Index (SPI) and Sequence Number fields to partly validate 1863 segments before CPU cycles are invested validated the Integrity Check 1864 Value (ICV). In TCP-AO, the socket pair performs most of the function 1865 of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay 1866 attacks, isn't needed due to TCP's Sequence Number, which is used to 1867 reorder received segments (provided the sequence number doesn't wrap 1868 around, which is why TCP-AO adds the SNE in Section 8.2). TCP already 1869 protects itself from replays of authentic segment data as well as 1870 authentic explicit TCP control (e.g., SYN, FIN, ACK bits, but even 1871 authentic replays could affect TCP congestion control [Sa99]. TCP-AO 1872 does not protect TCP congestion control from this last form of attack 1873 due to the cumbersome nature of layering a windowed security sequence 1874 number within TCP in addition to TCP's own sequence number; when such 1875 protection is desired, users are encouraged to apply IPsec instead. 1877 Further, it is not useful to validate TCP's Sequence Number before 1878 performing a TCP-AO authentication calculation, because out-of-window 1879 segments can still cause valid TCP protocol actions (e.g., ACK 1880 retransmission) [RFC793]. It is similarly not useful to add a 1881 separate Sequence Number field to the TCP-AO option, because doing so 1882 could cause a change in TCP's behavior even when segments are valid. 1884 14. IANA Considerations 1886 [NOTE: This section be removed prior to publication as an RFC] 1888 The TCP-AO option defines no new namespaces. 1890 The TCP-AO option requires that IANA allocate a value from the TCP 1891 option Kind namespace, to be replaced for TCP-IANA-KIND throughout 1892 this document. 1894 To specify MAC and KDF algorithms, TCP-AO refers to a separate 1895 document that may involve IANA actions [ao-crypto]. 1897 15. References 1899 15.1. Normative References 1901 [RFC793] Postel, J., "Transmission Control Protocol," STD-7, 1902 RFC-793, Standard, Sept. 1981. 1904 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 1905 Communication Layers," RFC-1122, Oct. 1989. 1907 [RFC2018] Mathis, M., J. Mahdavi, S. Floyd, A. Romanow, "TCP 1908 Selective Acknowledgement Options", RFC-2018, Proposed 1909 Standard, April 1996. 1911 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1912 Requirement Levels", BCP-14, RFC-2119, Best Current 1913 Practice, March 1997. 1915 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1916 Signature Option," RFC-2385, Proposed Standard, Aug. 1998. 1918 [RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP 1919 and AH," RFC-2403, Proposed Standard, Nov. 1998. 1921 [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6 1922 (IPv6) Specification," RFC-2460, Proposed Standard, Dec. 1923 1998. 1925 [RFC2883] Floyd, S., J. Mahdavi, M. Mathis, M. Podolsky, "An 1926 Extension to the Selective Acknowledgement (SACK) Option 1927 for TCP", RFC-2883, Proposed Standard, July 2000. 1929 [RFC3517] Blanton, E., M. Allman, K. Fall, L. Wang, "A Conservative 1930 Selective Acknowledgment (SACK)-based Loss Recovery 1931 Algorithm for TCP", RFC-3517, Proposed Standard, April 1932 2003. 1934 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," 1935 RFC-4306, Proposed Standard, Dec. 2005. 1937 [ao-crypto] Lebovitz, G., "Cryptographic Algorithms, Use, & 1938 Implementation Requirments for TCP Authentication Option", 1939 draft-ietf-tcpm-tcp-ao-crypto-01, Oct. 2009. 1941 15.2. Informative References 1943 [ao-nat] Touch, J., "A TCP Authentication Option NAT Extension," 1944 draft-touch-tcp-ao-nat-00, Oct. 2009. 1946 [Be07] Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem 1947 Statement and Requirements for a TCP Authentication 1948 Option," draft-bellovin-tcpsec-01, (work in progress), Jul. 1949 2007. 1951 [Bo07] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler, 1952 "Authentication for TCP-based Routing and Management 1953 Protocols," draft-bonica-tcp-auth-06, (work in progress), 1954 Feb. 2007. 1956 [Bo09] Borman, D., "TCP Options and MSS," draft-ietf-tcpm-tcpmss- 1957 02, Jul. 2009. 1959 [Go09] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- 1960 attacks-06, (work in progress), Aug. 2009. 1962 [Ba09] Bashyam, M., M. Jethanandani,, A. Ramaiah "Clarification of 1963 sender behaviour in persist condition," draft-ananth-tcpm- 1964 persist-01, (work in progress), Jul. 2009. 1966 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, 1967 Informational, April 1992. 1969 [RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for 1970 High Performance," RFC-1323, May 1992. 1972 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks," 1973 RFC-1948, Informational, May 1996. 1975 [RFC2104] Krawczyk, H., M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 1976 for Message Authentication," RFC-2104, Informational, Feb. 1977 1997. 1979 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1980 Translator (NAT) Terminology and Considerations", RFC 2663, 1981 August 1999. 1983 [RFC3234] Carpenter, B., S. Brim, "Middleboxes: Taxonomy and Issues," 1984 RFC-3234, Informational, Feb. 2002. 1986 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 1987 Signature Option," RFC-3562, Informational, July 2003. 1989 [RFC3947] Kivinen, T., B. Swander, A. Huttunen, V. Volpe, 1990 "Negotiation of NAT-Traversal in the IKE," RFC-3947, 1991 Proposed Standard, Jan. 2005. 1993 [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet 1994 Protocol," RFC-4301, Proposed Standard, Dec. 2005. 1996 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5," 1997 RFC-4808, Informational, Mar. 2007. 1999 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks," 2000 RFC-4953, Informational, Jul. 2007. 2002 [Sa99] Savage, S., N. Cardwell, D. Wetherall, T. Anderson, "TCP 2003 Congestion Control with a Misbehaving Receiver," ACM 2004 Computer Communications Review, V29, N5, pp71-78, October 2005 1999. 2007 [SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4)," 2008 Specification SDN.401, Revision 1.2, July 12, 1988. 2010 [To06] Touch, J., A. Mankin, "The TCP Simple Authentication 2011 Option," draft-touch-tcpm-tcp-simple-auth-03, (expired work 2012 in progress), Oct. 2006. 2014 [Wa05] Wang, X., H. Yu, "How to break MD5 and other hash 2015 functions," Proc. IACR Eurocrypt 2005, Denmark, pp.19-35. 2017 [We05] Weis, B., "TCP Message Authentication Code Option," draft- 2018 weis-tcp-mac-option-00, (expired work in progress), Dec. 2019 2005. 2021 16. Acknowledgments 2023 Alfred Hoenes, Charlie Kaufman, and Adam Langley provided substantial 2024 feedback on this document. 2026 This document was prepared using 2-Word-v2.0.template.dot. 2028 Authors' Addresses 2030 Joe Touch 2031 USC/ISI 2032 4676 Admiralty Way 2033 Marina del Rey, CA 90292-6695 2034 U.S.A. 2036 Phone: +1 (310) 448-9151 2037 Email: touch@isi.edu 2038 URL: http://www.isi.edu/touch 2040 Allison Mankin 2041 Johns Hopkins Univ. 2042 Washington, DC 2043 U.S.A. 2045 Phone: 1 301 728 7199 2046 Email: mankin@psg.com 2047 URL: http://www.psg.com/~mankin/ 2049 Ronald P. Bonica 2050 Juniper Networks 2051 2251 Corporate Park Drive 2052 Herndon, VA 20171 2053 U.S.A. 2055 Email: rbonica@juniper.net