idnits 2.17.1 draft-ietf-tcpm-tcp-auth-opt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1348. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2008) is 5766 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IESG' is mentioned on line 216, but not defined == Missing Reference: 'SAAG' is mentioned on line 218, but not defined == Missing Reference: 'TCPM' is mentioned on line 221, but not defined == Missing Reference: 'EDITORS TO-DO' is mentioned on line 231, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3517 (Obsoleted by RFC 6675) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-03 -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 9 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 R. Bonica 5 Expires: January 2009 Juniper Networks 6 July 14, 2008 8 The TCP Authentication Option 9 draft-ietf-tcpm-tcp-auth-opt-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on January 14, 2009. 37 Abstract 39 This document specifies a TCP Authentication Option (TCP-AO) which is 40 intended to replace the TCP MD5 Signature option of RFC-2385 (TCP 41 MD5). TCP-AO specifies the use of stronger Message Authentication 42 Codes (MACs) and provides more details on the association of security 43 associations with TCP connections. TCP-AO assumes an external, out- 44 of-band mechanism (manual or via a separate protocol) for session key 45 establishment, parameter negotiation, and rekeying, replicating the 46 separation of key management and key use as in the IPsec suite. The 47 result is intended to be a simple modification to support current 48 infrastructure uses of TCP MD5, such as to protect BGP and LDP, and 49 to support a larger set of MACs with minimal other system and 50 operational changes. TCP-AO uses a new option identifier, even though 51 it is intended to be mutually exclusive with TCP MD5 on a given TCP 52 connection. It supports IPv6, and is fully compatible with 53 requirements under development for an update to TCP MD5. 55 Table of Contents 57 1. Introduction...................................................3 58 1.1. Executive Summary.........................................3 59 1.2. List of TBD Items.........................................5 60 1.3. List of currently pending issues and to-do items..........5 61 1.4. Changes from Previous Versions............................6 62 1.4.1. New in draft-ietf-tcp-auth-opt-01....................6 63 1.4.2. New in draft-ietf-tcp-auth-opt-00....................6 64 1.4.3. New in draft-touch-tcp-simple-auth-03................7 65 1.4.4. New in draft-touch-tcp-simple-auth-02................7 66 1.4.5. New in draft-touch-tcp-simple-auth-01................7 67 1.5. Summary of RFC-2119 Requirements..........................8 68 2. Conventions used in this document..............................8 69 3. The TCP Simple Authentication Option...........................8 70 3.1. Review of TCP MD5 Option..................................8 71 3.2. TCP-AO Option.............................................9 72 4. Security Association Management...............................12 73 5. TCP-AO Interaction with TCP...................................14 74 5.1. User Interface...........................................14 75 5.2. TCP States and Transitions...............................15 76 5.3. TCP Segments.............................................15 77 5.4. Sending TCP Segments.....................................16 78 5.5. Receiving TCP Segments...................................17 79 5.6. Impact on TCP Header Size................................18 80 6. Key Establishment and Duration Issues.........................18 81 6.1. Implementing the TSAD as an External Database............19 82 7. Interactions with TCP MD5.....................................20 83 8. Interactions with NAT/NAPT Devices............................21 84 9. Evaluation of Requirements Satisfaction.......................21 85 10. Security Considerations......................................24 86 11. IANA Considerations..........................................26 87 12. Acknowledgments..............................................26 88 13. References...................................................26 89 13.1. Normative References....................................26 90 13.2. Informative References..................................27 92 1. Introduction 94 The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates 95 TCP segments, including the TCP IPv4 pseudoheader, TCP header, and 96 TCP data. It was developed to protect BGP sessions from spoofed TCP 97 segments which could affect BGP data or the robustness of the TCP 98 connection itself [RFC2385][RFC4953]. 100 There have been many recently-documented concerns about TCP MD5. Its 101 use of a simple keyed hash for authentication is problematic because 102 there have been escalating attacks on the algorithm itself [Be05] 103 [Bu06]. TCP MD5 also lacks both key management and algorithm agility. 104 This document proposes to add the latter, but suggests that TCP 105 should not be the framework for cryptographic key management. This 106 document replaces the TCP MD5 option to become a more general TCP 107 Authentication Option (TCP-AO), to support the use of other, stronger 108 hash functions and to provide a more structured recommendation on 109 external key management. The result is compatible with IPv6, and is 110 fully compatible with requirements under development for an update to 111 TCP MD5 [Be07]. 113 This document is not intended to replace the use of the IPsec suite 114 (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In 115 fact, we recommend the use of IPsec and IKE, especially where IKE's 116 level of existing support for parameter negotiation, session key 117 negotiation, or rekeying are desired. TCP-AO is intended for use only 118 where the IPsec suite would not be feasible, e.g., as has been 119 suggested is the case for some routing protocols, or in cases where 120 keys need to be tightly coordinated with individual transport 121 sessions [Be07]. 123 Note that this option is intended to obsolete the use of TCP MD5, 124 although a particular implementation may support both for backward 125 compatibility. For a given connection, only one can be in use. TCP 126 MD5-protected connections cannot be migrated to TCP-AO, since TCP MD5 127 does not support any changes to a connection's security configuration 128 once established. 130 1.1. Executive Summary 132 This document replaces TCP MD5 as follows [RFC2385]: 134 o Uses a separate option Kind for TCP-AO (TBD-IANA-KIND). 136 o Allows TCP MD5 to continue to be used for other connections. 138 o Replaces MD5's one implicit MAC algorithm with two prespecified 139 MACs (TBD-WG-MACS), and allows other MACs at the implementer's 140 discretion. 142 o Allows rekeying during a TCP connection, assuming that an out-of- 143 band protocol or manual mechanism coordinates the change of key 144 and that incorrectly keyed segments are ignored. In such cases, a 145 key ID makes key selection more efficient. 147 o Provides more detail in how this option interacts with TCP's 148 states, event processing, and user interface. 150 o Proposed option is 3 bytes shorter (15 bytes overall, rather than 151 18) in the default case (assuming a 96-bit MAC, TBD-WG-MACLEN). 153 This document differs from other proposals to update TCP MD5 in that 154 TCP-AO: [Bo07][We05][We07]: 156 o Is fully compatible with requirements currently under development. 158 o Does not support dynamic parameter negotiation. 160 o Does not support in-band session key negotiation. 162 o Does not support in-band session rekeying. 164 o Does not require additional timers. 166 o Always authenticates the the segment pseudoheader, header, and 167 data. 169 o Provides more detail in how this option interacts with TCP's 170 states, event processing, and user interface. 172 o Is shorter than TCP MD5 in the default case. 174 o Does not expose the MAC algorithm in the header. 176 o Requires a key ID. 178 o Supports TCP over either IPv4 or IPv6. 180 This document differs from an IPsec/IKE solution in that TCP-AO 181 [RFC4301][RFC4306]: 183 o Does not support dynamic parameter negotiation. 185 o Does not require a key ID (SPI), but does allow one. 187 o Does not protect from replay attacks. 189 o Forces a change of connection key when a connection restarts, even 190 when reusing a TCP socket pair (IP addresses and port numbers) 191 [Be07]. 193 o Does not support encryption. 195 o Does not authenticate ICMP messages (some may be authenticated in 196 IPsec, depending on the configuration). 198 1.2. List of TBD Items 200 [NOTE: to be omitted upon final publication as RFC] 202 The following items are to be determined (TBD) prior to publication. 203 Once a value is chosen, it should be replaced for the notation below 204 throughout this document and the item removed from this list. 206 TBD-IANA-KIND new TCP option Kind for TCP-AO, assigned by IANA 208 TBD-WG-MACS list of default required MAC algorithms 210 TBD-WG-MACLEN default length of MAC used in the TCP-AO MAF 212 1.3. List of currently pending issues and to-do items 214 [NOTE: to be omitted upon final publication as an RFC] 216 o [IESG] Should this document deprecate TCP MD5? 218 o [SAAG] Which two MAC algorithms should be required as default? 219 Should one be set as the primary default? 221 o [TCPM] Should TCP-AO include a negotiation protocol with a 222 backoff, i.e., to allow non-TCP-AO endpoints to connect more 223 quickly (or is this a security problem)? Note that this would be 224 useful only where a rapid failure is useful, or where the TCP 225 might backoff and use another mode (e.g., TCP MD5 or no 226 authentication). 228 o [EDITORS TO-DO] Add a discussion of the use with manual keys, esp. 229 for connections with dynamic source ports. 231 o [EDITORS TO-DO] Review need for LISTEN instructions. 233 1.4. Changes from Previous Versions 235 [NOTE: to be omitted upon final publication as RFC] 237 1.4.1. New in draft-ietf-tcp-auth-opt-01 239 o Require KeyID in all versions. Remove odd/even indicator of KeyID 240 usage. 242 o Relax restrictions on key reuse: requiring an algorithm for nonce 243 introduction based on ISNs, and suggest key rollover every 2^31 244 bytes (rather than using an extended sequence number, which 245 introduces new state to the TCP connection). 247 o Clarify NAT interaction; currently does not support omitting the 248 IP addresses or TCP ports, both of which would be required to 249 support NATs without any coordination. This appears to present a 250 problem for key management - if the key manager knows the received 251 addrs and ports, it should coordinate them (as indicated in Sec 252 8). 254 o Options are included or excluded all-or-none. Excluded options are 255 deleted, not just zeroed, to avoid the impact of reordering or 256 length changes of such options. 258 o Clarified key words to exclude lower case usage. 260 1.4.2. New in draft-ietf-tcp-auth-opt-00 262 o List of TBD values, and indication of how each is determined. 264 o Changed TCP-SA to TCP-AO (removed 'simple' throughout). 266 o Removed proposed NAT mechanism; cited RFC-3947 NAT-T as 267 appropriate approach instead. 269 o Made several changes coordinated in the TCP-AUTH-DT as follow: 271 o Added R. Bonica as co-author. 273 o Use new TCP option Kind in the core doc. 275 o Addresses the impact of explicit declines on security. 277 o Add limits to TSAD size (2 <= TSAD <= 256). 279 o Allow 0 as a legitimate KeyID. 281 o Allow the WG to determine the two appropriate required MAC 282 algorithms. 284 o Add TO-DO items. 286 o Added discussion at end of Introduction as to why TCP MD5 287 connections cannot be upgraded to TCP-AO. 289 1.4.3. New in draft-touch-tcp-simple-auth-03 291 o Added support for NAT/NAPT. 293 o Added support for IPv6. 295 o Added discussion of how this proposal satisfies requirements under 296 development, including those indicated in [Be07]. 298 o Clarified the byte order of all data used in the MAC. 300 o Changed the TCP option exclusion bit from a bit to a list. 302 1.4.4. New in draft-touch-tcp-simple-auth-02 304 o Add reference to Bellovin's need-for-TCP-auth doc [Be07]. 306 o Add reference to SP4 [SDNS88]. 308 o Added notes that TSAD to be externally implemented; this was 309 compatible with the TSAD described in the previous version. 311 o Augmented the protocol to allow a KeyID, required to support 312 efficient overlapping keys during rekeying, and potentially useful 313 during connection establishment. Accommodated by redesigning the 314 TSAD. 316 o Added the odd/even indicator for the KeyID. 318 o Allow for the exclusion of all TCP options in the MAC calculation. 320 1.4.5. New in draft-touch-tcp-simple-auth-01 322 o Allows intra-session rekeying, assuming out-of-band coordination. 324 o MUST allow TSAD entries to change, enabling rekeying within a TCP 325 connection. 327 o Omits discussion of the impact of connection reestablishment on 328 BGP, because added support for rekeying renders this point moot. 330 o Adds further discussion on the need for rekeying. 332 1.5. Summary of RFC-2119 Requirements 334 [NOTE: a summary will be placed here prior to last call] 336 2. Conventions used in this document 338 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 339 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 340 document are to be interpreted as described in RFC-2119 [RFC2119]. 342 In this document, these words will appear with that interpretation 343 only when in ALL CAPS. Lower case uses of these words are not to be 344 interpreted as carrying RFC-2119 significance. 346 3. The TCP Simple Authentication Option 348 The TCP Simple Authentication Option (TCP-AO) uses a new TCP option 349 Kind value, (TBD-IANA-KIND). 351 3.1. Review of TCP MD5 Option 353 For review, the TCP MD5 option is shown in Figure 1. 355 +---------+---------+-------------------+ 356 | Kind=19 |Length=18| MD5 digest... | 357 +---------+---------+-------------------+ 358 | | 359 +---------------------------------------+ 360 | | 361 +---------------------------------------+ 362 | | 363 +-------------------+-------------------+ 364 | | 365 +-------------------+ 367 Figure 1 Current TCP MD5 Option [RFC2385] 369 In the current TCP MD5 option, the length is fixed, and the MD5 370 digest occupies 16 bytes following the Kind and Length fields, using 371 the full MD5 digest of 128 bits [RFC1321]. 373 The current TCP MD5 option specifies the use of the MD5 digest 374 calculation over the following values in the following order: 376 1. the TCP pseudoheader (IP source and destination addresses, 377 protocol number, and segment length) 379 2. TCP header excluding options and checksum 381 3. TCP data 383 4. connection key 385 3.2. TCP-AO Option 387 The new TCP-AO option is intended to be a superset of the TCP MD5 388 capability, and to be minimal in the spirit of SP4 [SDNS88]. TCP-AO 389 uses a new Kind field, and similar Length field to TCP MD5, and is 390 shown in Figure 2. 392 +---------------------+---------+-------------------+ 393 | Kind= TBD-IANA-KIND | Len=var | MAC | 394 +---------------------+---------+-------------------+ 395 | MAC (con't) ... 396 +-------------------------------------... 398 ...-----------------+---------+ 399 ... MAC (con't) | KeyID | 400 ...-----------------+---------+ 402 Figure 2 Proposed TCP-AO Option 404 The TCP-AO defines the following fields: 406 o Kind: An unsigned field indicating the TCP-AO Option. TCP-AO uses 407 a new Kind value=TBD-IANA-KIND. Because of how keys are managed 408 (see Section 4), an endpoint will not use TCP-AO for the same 409 connection where TCP MD5 is used. 411 o Length: An unsigned 8-bit field indicating the length of the TCP- 412 AO option in bytes, including the Kind, Length, and KeyID fields. 414 >> The Length MUST be greater than or equal to 3. 416 >> The Length value MUST be consistent with the TCP header length; 417 this is a consistency check and to avoid overrun/underrun abuse. 419 Values of 3 and other small values are of dubious utility (e.g., 420 for MAC=NONE, or for very short MACs) but not specifically 421 prohibited. 423 o MAC: Message Authentication Field. Its contents are determined by 424 the particulars of the security association. Typical MACs are 96- 425 128 bits (12-16 bytes), but any length that fits in the header of 426 the segment being authenticated is allowed. Because the KeyID is 427 one byte, it may be useful to have odd-length MACs (e.g., to 428 select an odd number of bytes of a computed even-length MAC). 430 o KeyID: The last byte of the option is a KeyID field. The KeyID is 431 used to support efficient key rollover during a connection and/or 432 to help with key coordination during connection establishment, and 433 will be discussed further in Sections 4. 435 >> TCP-AO MUST support TBD-WG-MACS; other MACs MAY be supported 436 [RFC2403]. 438 >> A single TCP segment MUST NOT have more than one TCP-AO option. 440 The MAC is computed over the following fields in the following order: 442 1. the TCP pseudoheader: IP source and destination addresses, 443 protocol number and segment length, all in network byte order, 444 prepended to the TCP header below. The pseudoheader is exactly as 445 used for the TCP checksum in either IPv4 or IPv6 446 [RFC793][RFC2460]: 448 +--------+--------+--------+--------+ 449 | Source Address | 450 +--------+--------+--------+--------+ 451 | Destination Address | 452 +--------+--------+--------+--------+ 453 | zero | Proto | TCP Length | 454 +--------+--------+--------+--------+ 456 Figure 3 TCP IPv4 pseudoheader [RFC793] 457 +--------+--------+--------+--------+ 458 | | 459 + + 460 | | 461 + Source Address + 462 | | 463 + + 464 | | 465 + + 466 +--------+--------+--------+--------+ 467 | | 468 + + 469 | | 470 + Destination Address + 471 | | 472 + + 473 | | 474 +--------+--------+--------+--------+ 475 | Upper-Layer Packet Length | 476 +--------+--------+--------+--------+ 477 | zero | Next Header | 478 +--------+--------+--------+--------+ 480 Figure 4 TCP IPv6 pseudoheader [RFC2460] 482 2. the TCP header, by default including options, and where the TCP 483 checksum and TCP-AO MAC fields are set to zero, all in network 484 byte order 486 3. TCP data, in network byte order 488 Note that the connection key is not included here; we expect that the 489 MAC algorithm will indicate how to use the key, e.g., as HMACs do in 490 general [RFC2104][RFC2403]. 492 TCP-AO by default includes the TCP options because these options are 493 intended to be end-to-end and some are required for proper TCP 494 operation (e.g., SACK, timestamp, large windows). Middleboxes that 495 alter TCP options en-route are a kind of attack and would be 496 successfully detected by TCP-AO. In cases where the configuration of 497 the connection's security association state indicates otherwise, the 498 TCP options can be excluded from the MAC calculation. When options 499 are excluded, all options - including TCP-AO - are skipped over 500 during the MAC calculation (rather than being zeroed). 502 The TCP-AO option does not indicate the MAC algorithm either 503 implicitly (as with TCP MD5) or explicitly. The particular algorithm 504 used is considered part of the configuration state of the 505 connection's security association and is managed separately (see 506 Section 4). 508 MACs typically benefit from a per-connection nonce, notably in 509 avoiding the impact of key reuse. The presence of TCP's pair of 510 Initial Sequence Numbers presents a nonce that may be useful in that 511 case. Such a nonce could be computed as the concatenation of the ISNs 512 (initiator, responder), and the socket pair (addresses, ports): 514 o Nonce = ISN_i, ISN_r, IP_address_i, IP_address_r, port_i, port_r 516 The initial SYN would not know ISN_r, so that packet's nonce would 517 use ISN_r = 0. Use of these nonces avoids the need to avoid key reuse 518 on a per connection basis. 520 >> ISN and socket pair nonces MUST be used to generate unique per- 521 session keys. 523 4. Security Association Management 525 TCP-AO relies on a TCP Security Association Database (TSAD). TSAD 526 entries are assumed to exist at the endpoints where TCP-AO is used, 527 in advance of the connection: 529 1. TCP connection identifier (ID), i.e., socket pair - IP source 530 address, IP destination address, TCP source port, and TCP 531 destination port [RFC793]. TSAD entries are uniquely determined by 532 their TCP connection ID, which is used to index those entries. 534 >> There MUST be no more than one matching TSAD entry per 535 direction for a TCP connection ID. 537 2. For each of inbound (for received TCP segments) and outbound (for 538 sent TCP segments) directions for this connection (except as 539 noted): 541 a. TCP option exclusion flag. When 0, this flag allows default 542 operation, i.e., TCP options are When 1, all options 543 (including TCP-AO) are excluded from all MAC calculations 544 (skipped over, not simply zeroed). 546 >> The TCP option exclusion flag MUST default to 0 (i.e., 547 options not excluded). 549 >> The TCP option flag list MUST NOT change during a TCP 550 connection. 552 b. An ordered list of zero or more connection key tuples. Each 553 tuple is defined as the set as follows: 556 >> TSAD key tuple components MUST NOT change during a 557 connection. 559 >> The set of TSAD key tuples MAY change during a connection, 560 but KeyIDs of those tuples MUST NOT overlap. I.e., tuple 561 parameter changes MUST be accompanied by key changes. 563 i. KeyID. A single byte used to differentiate overlapping 564 Connection keys. 566 >> A TSAD implementation MUST support at least two KeyIDs 567 per connection per direction, and MAY support up to 256. 569 >> A KeyID MAY have any value, 0-255 inclusive. 571 ii. MAC type. Indicates the MAC used for this connection, as 572 per IKEv2 Transform Type 3 [RFC4306]. This includes the 573 MAC algorithm (e.g., HMAC-MD5, HMAC-SHA1, UMAC, etc.) and 574 the length of the MAC as truncated to (e.g., 96, 128, 575 etc.). 577 >> A MAC type of "NONE" MUST be supported, to indicate 578 that authentication is not used in this direction; this 579 allows asymmetric use of TCP-AO. 581 >> At least one direction (inbound/outbound) SHOULD have 582 a non-"NONE" MAC in practice, but this MUST NOT be 583 strictly required by an implementation. 585 >> When the outbound MAC is set to values other than 586 "NONE", TCP-AO MUST occur in every outbound TCP segment 587 for that connection; when set to NONE or when no tuple 588 exists, TCP-AO MUST NOT occur in those segments. 590 >> When the inbound MAC is set to values other than 591 "NONE", TCP-AO MUST occur in every inbound TCP segment 592 for that connection; when set to "NONE" or when no tuple 593 exists, TCP-AO SHOULD NOT be added to those segments, but 594 MAY occur and MUST be ignored. 596 iii. Key length. A byte indicating the length of the 597 connection key in bytes. 599 iv. Connection key. A byte sequence used for connection 600 keying, this may be derived from a separate shared key by 601 an external protocol over a separate channel. This 602 sequence is used in network standard byte order in MAC 603 calculations. 605 It is anticipated that TSAD entries for TCP connections in states 606 other than CLOSED can be stored in the TCP Control Block (TCB) or in 607 a separate database (see Section 6.1 for notes on the latter); TSAD 608 entries for pending connections (in passive or active OPEN) may be 609 stored in a separate database. This means that in a single host there 610 should be only a single database which is consulted by all pending 611 connections, the same way that there is only one set of TCBs. 612 Multiple databases could be used to support virtual hosts, i.e., 613 groups of interfaces. 615 Note that the TCP-AO fields omit an explicit algorithm ID; that 616 algorithm is already specified by the TCP connection ID and stored in 617 the TSAD. 619 Also note that this document does not address how TSAD entries are 620 created by users/processes; it specifies how they must be destroyed 621 corresponding to connection states, but users/processes may destroy 622 entries as well. It is presumed that a TSAD entry affecting a 623 particular connection cannot be destroyed during an active connection 624 - or, equivalently, that its parameters are copied to TSAD entries 625 local to the connection (i.e., instantiated) and so changes would 626 affect only new connections. The TSAD could be managed by a separate 627 application protocol, and can be stored in a separate database if 628 desired. 630 5. TCP-AO Interaction with TCP 632 The following is a description of how TCP-AO affects various TCP 633 states, segments, events, and interfaces. This description is 634 intended to augment the description of TCP as provided in RFC793 635 [RFC793]. 637 5.1. User Interface 639 The TCP user interface supports active and passive OPEN, SEND, 640 RECEIVE, CLOSE, STATUS and ABORT commands. 642 >> TCP OPEN, or the sequence of commands that configure a connection 643 to be in the active or passive OPEN state, MUST be augmented so that 644 a TSAD entry can be configured. 646 Users are advised to not inappropriately reuse keys [RFC3562]. As 647 noted in Section 3.2, this is accomplished in TCP-AO by the use of 648 unique per-connection nonces in conjunction with conventional keys. 650 >> TCP STATUS SHOULD be augmented to allow the TSAD entry of a 651 current or pending connection to be read (for confirmation). 653 >> A TCP-AO implmentation MUST allow TSAD entries for ongoing TCP 654 connections (i.e., not in the CLOSED state) to be modified. 655 Parameters not used to index a connection MAY be modified; parameters 656 used to index a connection MUST NOT be modified. 658 TSAD entries for TCP connections not in the CLOSED state are deleted 659 indirectly using the CLOSE or ABORT commands. 661 TCP SEND and RECEIVE are not affected by TCP-AO. 663 5.2. TCP States and Transitions 665 TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, 666 FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and 667 CLOSED. 669 >> A TSAD entry MAY be associated with any TCP state. 671 >> A TSAD entry MAY underspecify the TCP connection for the LISTEN 672 state. Such an entry MUST NOT be used for more than one connection 673 progressing out of the LISTEN state. 675 5.3. TCP Segments 677 TCP includes control (at least one of SYN, FIN, RST flags set) and 678 data (none of SYN, FIN, or RST flags set) segments. Note that some 679 control segments can include data (e.g., SYN). 681 >> All TCP segments MUST be checked against the TSAD for matching TCP 682 connection IDs. 684 >> TCP segments matching TSAD entries with non-NULL MACs without TCP- 685 AO, or with TCP-AO and whose MACs and KeyIDs do not validate MUST be 686 silently discarded. 688 >> TCP segments with TCP-AO but not matching TSAD entries MUST be 689 silently accepted; this is required for equivalent function with TCPs 690 not implementing TCP-AO. 692 >> Silent discard events SHOULD be signaled to the user as a warning, 693 and silent accept events MAY be signaled to the user as a warning. 694 Both warnings, if available, MUST be accessible via the STATUS 695 interface. Either signal MAY be asynchronous, but if so they MUST be 696 rate-limited. Either signal MAY be logged; logging SHOULD allow rate- 697 limiting as well. 699 All TCP-AO processing occurs between the interface of TCP and IP; for 700 incoming segments, this occurs after validation of the TCP checksum. 701 For outgoing segments, this occurs before computation of the TCP 702 checksum. 704 Note that the TCP-AO option is not negotiated. It is the 705 responsibility of the receiver to determine when TCP-AO is required 706 and to enforce that requirement. 708 5.4. Sending TCP Segments 710 The following procedure describes the modifications to TCP to support 711 TCP-AO when a segment departs. 713 1. Check the segment's TCP connection ID against the TSAD 715 2. If there is NO TSAD entry, omit the TCP-AO option. Proceed with 716 computing the TCP checksum and transmit the segment. 718 3. If there is a TSAD entry with zero key tuples, omit the TCP-AO 719 option. Proceed with computing the TCP checksum and transmit the 720 segment. 722 4. If there is a TSAD entry and a key tuple and the outgoing MAC is 723 NONE, omit the TCP-AO option. Proceed with computing the TCP 724 checksum and transmit the segment. 726 5. If there is a TSAD entry and a key tuple and the outgoing MAC is 727 not NONE: 729 a. Augment the TCP header with the TCP-AO, inserting the 730 appropriate Length and KeyID based on the indexed TSAD entry. 731 Update the TCP header length accordingly. 733 b. Compute the MAC using the indexed TSAD entry and data from the 734 segment as specified in Section 3.2, including the TCP 735 pseudoheader and TCP header. Include or exclude the options as 736 indicated by the TSAD entry's TCP option exclusion flag. 738 c. Insert the MAC in the TCP-AO field. 740 d. Proceed with computing the TCP checksum on the outgoing packet 741 and transmit the segment. 743 5.5. Receiving TCP Segments 745 The following procedure describes the modifications to TCP to support 746 TCP-AO when a segment arrives. 748 1. Check the segment's TCP connection ID against the TSAD. 750 2. If there is NO TSAD entry, proceed with TCP processing. 752 3. If there is a TSAD entry with zero key tuples, proceed with TCP 753 processing. 755 4. If there is a TSAD entry with a key tuple and the incoming MAC is 756 NONE, proceed with TCP processing. 758 5. If there is a TSAD entry with a key tuple and the incoming MAC is 759 not NONE: 761 a. Check that the segment's TCP-AO Length matches the length 762 indicated by the indexed TSAD. 764 i. If Lengths differ, silently discard the segment. Log 765 and/or signal the event as indicated in Section 5.3. 767 b. Use the KeyID value to index the appropriate key for this 768 connection. 770 i. If the TSAD has no entry corresponding to the segment's 771 KeyID, silently discard the segment. 773 c. Compute the segment's MAC using the indexed TSAD entry and 774 portions of the segment as indicated in Section 3.2. 776 Again, if options are excluded (as per the TCP option 777 exclusion flag), they are skipped over (rather than zeroed) 778 when used as input to the MAC calculation. 780 i. If the computed MAC differs from the TCP-AO MAC field 781 value, silently discard the segment. Log and/or signal 782 the event as indicated in Section 5.3. 784 d. Proceed with TCP processing of the segment. 786 It is suggested that TCP-AO implementations validate a segment's 787 Length field before computing a MAC, to reduce the overhead incurred 788 by spoofed segments with invalid TCP-AO fields. 790 5.6. Impact on TCP Header Size 792 The TCP-AO option typically uses a total of 17-19 bytes of TCP header 793 space. TCP-AO is no larger than and typically 3 bytes smaller than 794 the TCP MD5 option (assuming a 96-bit MAC). Although TCP option space 795 is limited, we believe TCP-AO is consistent with the desire to 796 authenticate TCP at the connection level for similar uses as were 797 intended by TCP MD5. 799 6. Key Establishment and Duration Issues 801 The TCP-AO option does not provide a mechanism for connection key 802 negotiation or parameter negotiation (MAC algorithm, length, or use 803 of the TCP-AO option) or rekeying during a connection. We assume out- 804 of-band mechanisms for key establishment, parameter negotiation, and 805 rekeying. This separation of key use from key management is similar 806 to that in the IPsec security suite [RFC4301][RFC4306]. 808 We encourage users of TCP-AO to apply known techniques for generating 809 appropriate keys, including the use of reasonable connection key 810 lengths, limited connection key sharing, and limiting the duration of 811 connection key use [RFC3562]. This also includes the use of per- 812 connection nonces, as suggested in Section 3.2. 814 TCP-AO supports rekeying in which new keys are negotiated out-of- 815 band, either via a protocol or a manual procedure [RFC4808]. New keys 816 use is coordinated using the out-of-band mechanism to update the TSAD 817 at both TCP endpoints. In the default case, where only a single key 818 is used at a time, the temporary use of invalid keys would result in 819 packets being dropped; TCP is already robust to such drops. Such 820 drops may affect TCP's throughput temporarily, as a result TCP-AO 821 benefits from the use of congestion control support for temporary 822 path outages. 824 >> TCP-AO SHOULD be deployed in conjunction with support for 825 selective acknowledgement (SACK), including support for multiple lost 826 segments in the same round trip [RFC2018][RFC3517]. 828 Note that TCP-AO's support for rekeying is designed to be minimal in 829 the default case. Segments carry only enough context to identify the 830 security association [RFC4301][RFC4306]. In TCP-AO, this context is 831 provided by the socket pair (IP addresses and ports for source and 832 destination). The TSAD can contain multiple concurrent keys, where 833 the KeyID field is used to identify the key that corresponds to a 834 segment, to avoid the need for expensive trial-and-error testing of 835 keys in sequence. 837 The KeyID field is also useful in coordinating keys for new 838 connections. A TSAD may be configured that matches the unbound source 839 port, which would return a set of possible keys. The KeyID would then 840 indicate which key, allowing more efficient connection establishment; 841 otherwise, the keys could have been tried in sequence. See also 842 Section 6.1. 844 Implementations are encouraged to keep keys in a suitably private 845 area. Users of TCP-AO are encouraged to use different keys for 846 inbound and outbound MACs on a given TCP connection. 848 6.1. Implementing the TSAD as an External Database 850 The TSAD implementation is considered external to TCP-AO. When an 851 external database is used, it would be useful to consider the 852 interface between TCP-AO and the TSAD. The following is largely a 853 restatement of information in Section 4. 855 The TSAD API is accessed during a connection as follows: 857 o TCP connection identifier (ID) (The socket pair, sent as 4 byte IP 858 source address, 4 byte IP destination address, 2 byte TCP source 859 port, 2 byte TCP destination port). 861 o Direction indicator (sent as a single byte, 0x00 = inbound, 0x01 = 862 outbound) 864 o Number of bytes to be sent/received (two bytes); this is used on 865 the send side to trigger bytecount-based KeyID changes, and on the 866 receive side only for statistics or length-sensitive KeyID 867 selection. 869 >> TCP-AO implementations SHOULD change keys for a connection at 870 least every 2^31 bytes, to avoid resending segments with the same 871 TCP sequence number, data, and length under the same key. 873 o KeyID (single byte); this is provided only by a receiver (i.e., 874 matching the KeyID of the received segment), where a sender would 875 leave this unspecified (and the call would return the appropriate 876 KeyID to use). 878 The call passes the number of bytes sent/received, and an indication 879 of the direction (send/receive), to enable traffic-based key 880 rollover. 882 The source port can be 'unbound', indicated by the value 0x0000. In 883 this case, the source port is considered a wildcard, and all 884 corresponding TSAD entries (indexed by the KeyID) are returned as a 885 list. This feature is used during connection establishment. 887 TSAD calls return the following parameters: 889 o TCP option exclusion flag (one byte, with 0x00 having the meaning 890 "exclude none" and 0x01 meaning "exclude all"). 892 o An ordered list of zero or more connection key tuples: 893 895 o KeyID (one byte) 897 o MAC type (four bytes, an IKEv2 Transform Type 3 ID [RFC4306]) 899 o Key length (one byte) 901 o Connection key (byte sequence, indicating the key value) 903 When the TSAD returns zero keys, it is indicating that there are no 904 currently valid keys for the connection. 906 7. Interactions with TCP MD5 908 TCP-AO is intended to be deployed without regard for existing TCP MD5 909 option support. 911 >> A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for a 912 particular TCP connection, but MAY support TCP-AO and TCP MD5 913 simultaneously for different connections. 915 The Kind value explicitly indicates which of TCP-AO or TCP MD5 is 916 used for a particular connection in TCP segments. 918 It is possible that the TSAD could be augmented to support TCP MD5, 919 although use of a TSAD-like system is not described in RFC2385. 921 It is possible to require TCP-AO for a connection or TCP MD5, but it 922 is not possible to require 'either'. Note that when TCP MD5 is 923 required on for a connection, it must be used [RFC2385]. This 924 prevents combined use of the two options for a given connection, to 925 be determined by the other end of the connection. 927 8. Interactions with NAT/NAPT Devices 929 TCP-AO can interoperate across NAT/NAPT devices, which modify the IP 930 addresses, and may also modify TCP port numbers and/or TCP options. 931 TCP options can be excluded on a per-connection basis. 933 IP addresses and port numbers would preferably be coordinated across 934 a NAT/NAPT device, such that the sender and receiver both know the IP 935 address and TCP port numbers of the received packet. In that case, 936 the sender computes the packet as it would be received, i.e., using 937 the receiver's version of the IP pseudoheader and TCP header. 939 Where such knowledge of the address and port translations are not 940 known, NAT/NAPT traversal can be handled in similar ways to IPsec 941 [RFC2766][RFC3947]. I.e., traversing such a device using a tunnel to 942 avoid the NAT/NAPT from translating fields in the TCP and IP headers 943 TCP-AO uses in its MAC calculation. Such a tunnel may need to 944 coincide with the channel over which keys are exchanged, as in IPsec 945 NAT traversal [RFC3947]. 947 9. Evaluation of Requirements Satisfaction 949 TCP-AO satisfies all the current requirements for a revision to TCP 950 MD5, as indicated in [Be07] and under current developemt. This should 951 not be a surprise, as the majority of the evolving requirements are 952 derived from its design. The following is a summary of those 953 requirements and notes where relevant. 955 1. Protected Elements - see Section 3.2. 957 a. TCP pseudoheader, including IPv4 and IPv6 versions. Note that 958 we do not allow optional coverage because IP addresses define 959 a connection. If they can be coordinated across a NAT/NAPT, 960 the sender can compute the MAC based on the received values; 961 if not, a tunnel is required. 963 b. TCP header. Note that we do not allow optional port coverage 964 because ports define a connection. If they can be coordinated 965 across a NAT/NAPT, the sender can compute the MAC based on the 966 received values; if not, a tunnel is required. 968 c. TCP options. Allows exclusion of TCP options from coverage, as 969 required. 971 d. TCP data. Done. 973 2. Option structure requirements 975 a. Privacy. TCP-AO exposes only the key index, MAC, and overall 976 option length. Note that short MACs could be obscured by using 977 longer option lengths but specifying a short MAC length (this 978 is equivalent to a different MAC algorithm, and is specified 979 in the TSAD entry). See Section 3.2. 981 b. Allow optional per connection. Done - see Sections 5.3, 5.4, 982 and 5.5. 984 c. Require non-optional. Done - see Sections 5.3, 5.4, and 5.5. 986 d. Standard parsing. Done - see Section 3.2. 988 e. Compatible with Large Windows. Done - see Section 3.2. The 989 size of the option is intended to allow use with Large Windows 990 and SACK. See also Section 1.1, which indicates that TCP-AO is 991 4 bytes shorter than TCP MD5 in the default case, assuming a 992 96-bit MAC. 994 f. Compatible with SACK. Done - see Section 3.2. The size of the 995 option is intended to allow use with Large Windows and SACK. 996 See also Section 6 regarding key management. See also Section 997 1.1, which indicates that TCP-AO is 4 bytes shorter than TCP 998 MD5 in the default case. 1000 3. Cryptography requirements 1002 a. Baseline defaults. TCP-AO uses TBD-WG-MACS as the default, as 1003 noted in Section 3.2. 1005 b. Good algorithms. TCP-AO uses TBD-WG-MACS as the default, but 1006 does not otherwise specify the algorithms used. That would be 1007 specified in the key management protocol, and should be 1008 limited there. 1010 c. Algorithm agility. TCP-AO allows any desired algorithm, 1011 subject to TCP option space limitations, as noted in Section 1012 3.2. The TSAD allows separate connections to use different 1013 algorithms. 1015 d. Pre-TCP processing. Done - see Sections 5.3, 5.4, and 5.5. 1016 Note that pre-TCP processing is required, because TCP segments 1017 cannot be discarded solely based on a combination of 1018 connection state and out-of-window checks; many such segments, 1019 although discarded, cause a host to respond with a replay of 1020 the last valid ACK, e.g. [RFC793]. 1022 e. Parameter changes require key changes. TSAD parameters that 1023 should not change during a connection (TCP connection ID, 1024 receiver TCP connection ID, TCP option exclusion list) cannot 1025 change. Other parameters change only when a key is changed, 1026 using the key tuple mechanism in the TSAD. See Section 4. 1028 4. Keying requirements. TCP-AO does not specify a key management 1029 system, but does indicate a proposed interface to the TSAD, 1030 allowing a completely separate key system. 1032 a. Intraconnection rekeying. Supported by the KeyID and multiple 1033 key tuples in a TSAD entry; see Section 4. 1035 b. Efficient rekeying. Supported by the KeyID. See Section 6. 1037 c. Automated and manual keying. Supported by the TSAD interface. 1038 See Section 6. 1040 d. Key management agnostic. Supported by the TSAD interface. See 1041 Section 6.1. 1043 5. Expected constraints 1045 a. Silent failure. Done - see Sections 5.3, 5.4, and 5.5. 1047 b. At most one such option per segment. Done - see Section 3.2. 1049 c. Outgoing all or none. Done - see Section 5.4. 1051 d. Incoming all checked. Done - see Section 5.5. 1053 e. Non-interaction with TCP MD5. Done - see Section 7. 1055 f. Optional ICMP discard. Done - see Section 10. 1057 g. Allows use of NAT/NAPT devices. Done - see Section 8. 1059 h. Maintain TCP connection semantics, in which only the socket 1060 pair defines a TCP association and all its security 1061 parameters. Done - see Sections 4 and 8. 1063 i. Try to avoid creating a CPU DOS attack opportunity. Done - see 1064 Section 10. 1066 10. Security Considerations 1068 Use of TCP-AO, like use of TCP MD5 or IPsec, will impact host 1069 performance. Connections that are known to use TCP-AO can be attacked 1070 by transmitting segments with invalid MACs. Attackers would need to 1071 know only the TCP connection ID and TCP-AO Length value to 1072 substantially impact the host's processing capacity. This is similar 1073 to the susceptibility of IPsec to on-path attacks, where the IP 1074 addresses and SPI would be visible. For IPsec, the entire SPI space 1075 (32 bits) is arbitrary, whereas for routing protocols typically only 1076 the source port (16 bits) is arbitrary. As a result, it would be 1077 easier for an off-path attacker to spoof a TCP-AO segment that could 1078 cause receiver validation effort. However, we note that between 1079 Internet routers both ports could be arbitrary (i.e., determined a- 1080 priori out of band), which would constitute roughly the same off-path 1081 antispoofing protection of an arbitrary SPI. 1083 TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets 1084 typically occur after peer crashes, either in response to new 1085 connection attempts or when data is sent on stale connections; in 1086 either case, the recovering endpoint may lack the connection key 1087 required (e.g., if lost during the crash). This may result in time- 1088 outs, rather than more responsive recovery after such a crash. 1090 TCP-AO does not include a fast decline capability, e.g., where a SYN- 1091 ACK is received without an expected TCP-AO option and the connection 1092 is quickly reset or aborted. Normal TCP operation will retry and 1093 timeout, which is what should be expected when the intended receiver 1094 is not capable of the TCP variant required anyway. Backoff is not 1095 optimized because it would present an opportunity for attackers on 1096 the wire to abort authenticated connection attempts by sending 1097 spoofed SYN-ACKs without the TCP-AO option. 1099 TCP-AO does not expose the MAC algorithm used to authenticate a 1100 particular connection; that information is kept in the TSAD at the 1101 endpoints, and is not indicated in the header. 1103 TCP-AO is intended to provide similar protections to IPsec, but is 1104 not intended to replace the use of IPsec or IKE either for more 1105 robust security or more sophisticated security management. 1107 TCP-AO does not address the issue of ICMP attacks on TCP. IPsec makes 1108 recommendations regarding dropping ICMPs in certain contexts, or 1109 requiring that they are endpoint authenticated in others [RFC4301]. 1111 There are other mechanisms proposed to reduce the impact of ICMP 1112 attacks by further validating ICMP contents and changing the effect 1113 of some messages based on TCP state, but these do not provide the 1114 level of authentication for ICMP that TCP-AO provides for TCP [Go07]. 1116 >> A TCP-AO implementation MUST allow the system administrator to 1117 configure whether TCP will ignore incoming ICMP messages of Type 3 1118 Codes 2-4 intended for connections that match TSAD entries with non- 1119 NONE inbound MACs. An implementation SHOULD allow ignored ICMPs to be 1120 logged. 1122 This control affects only ICMPs that currently require 'hard errors' 1123 which would abort the TCP connection. This recommendation is intended 1124 to be similar to how IPsec would handle those messages [RFC4301]. 1126 TCP-AO includes the TCP connection ID in the MAC calculation. This 1127 prevents connections using the same key (for whatever reason) from 1128 potentially enabling a traffic-crossing attack, in which segments to 1129 one socket pair are diverted to attack a different socket pair. When 1130 multiple connections use the same key, it would be useful to know 1131 that packets intended for one ID could not be (maliciously or 1132 otherwise) modified in transit and end up being authenticated for the 1133 other ID. The ID cannot be zeroed, because to do so would require 1134 that the TSAD index was unique in both directions (ID->key and key- 1135 >ID). That requirement would place an additional burden of uniqueness 1136 on keys within endsystems, and potentially across endsystems. 1137 Although the resulting attack is low probability, the protection 1138 afforded by including the received ID warrants its inclusion in the 1139 MAC, and does not unduly increase the MAC calculation or key 1140 management system. 1142 The use of any security algorithm can present an opportunity for a 1143 CPU DOS attack, where the attacker sends false, random segments that 1144 the receiver under attack expends substantial CPU effort to reject. 1145 In IPsec, such attacks are reduced by the use of a large Security 1146 Parameter Index (SPI) and Sequence Number fields to partly validate 1147 segments before CPU cycles are invested validated the Integrity Check 1148 Value (ICV). In TCP-AO, the socket pair performs most of the function 1149 of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay 1150 attacks, isn't needed due to TCP's Sequence Number, which is used to 1151 reorder received segments. Unfortunately, it is not useful to 1152 validate TCP's Sequence Number before performing a TCP-AO 1153 authentication calculation, because out-of-window segments can still 1154 cause TCP protocol actions (e.g., ACK retransmission) [RFC793]. It is 1155 similarly not useful to add a separate Sequence Number field to the 1156 TCP-AO option, because doing so could cause a change in TCP's 1157 behavior even when segments are valid. 1159 11. IANA Considerations 1161 The TCP-AO option defines no new namespaces. 1163 The TCP-AO option uses the TCP option Kind value TCP-IANA-KIND, 1164 allocated by IANA from the TCP option Kind namespace. 1166 To specify MAC algorithms, TCP-AO uses the 4-byte namespace of IKEv2 1167 Transform Type 3 IDs [RFC4306]. 1169 [NOTE: The following to be removed prior to publication as an RFC] 1171 The TCP-AO option requires that IANA allocate a value from the TCP 1172 option Kind namespace, to be replaced for TCP-IANA-KIND throughout 1173 this document. 1175 12. Acknowledgments 1177 This document was inspired by the revisions to TCP MD5 suggested by 1178 Brian Weis and Ron Bonica [Bo07][We05]. Russ Housley suggested 1179 L4/application layer management of the TSAD. The KeyID field was 1180 motivated by Steve Bellovin. Eric Rescorla suggested the use of ISNs 1181 as nonces, and Brian Weis extended the nonce to incorporate the 1182 entire connection ID. Alfred Hoenes, Charlie Kaufman, and Adam 1183 Langley provided substantial feedback. The document is the result of 1184 collaboration with the TCP Authentication Design team (tcp-auth-dt). 1186 This document was prepared using 2-Word-v2.0.template.dot. 1188 13. References 1190 13.1. Normative References 1192 [RFC793] Postel, J., "Transmission Control Protocol," STD 007, RFC 1193 793, Standard, Sept. 1981. 1195 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP 1196 Selective Acknowledgement Options", RFC 2018, Proposed 1197 Standard, April 1996. 1199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1200 Requirement Levels", BCP 14, RFC 2119, Best Current 1201 Practice, March 1997. 1203 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1204 Signature Option," RFC 2385, Proposed Standard, Aug. 1998. 1206 [RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP 1207 and AH," RFC 2403, Proposed Standard, Nov. 1998. 1209 [RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 1210 (IPv6) Specification," RFC 2460, Proposed Standard, Dec. 1211 1998. 1213 [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A 1214 Conservative Selective Acknowledgment (SACK)-based Loss 1215 Recovery Algorithm for TCP", RFC 3517, Proposed Standard, 1216 April 2003. 1218 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," RFC 1219 4306, Proposed Standard, Dec. 2005. 1221 13.2. Informative References 1223 [Be05] Bellovin, S., E. Rescorla, "Deploying a New Hash 1224 Algorithm," presented at the First NIST Cryptographic Hash 1225 Workshop, Oct. 2005. 1226 http://csrc.nist.gov/pki/HashWorkshop/2005/program.htm 1228 [Be07] Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem 1229 Statement and Requirements for a TCP Authentication 1230 Option," draft-bellovin-tcpsec-01, (work in progress), Jul. 1231 2007. 1233 [Bu06] Burr, B., "NIST Cryptographic Standards Status Report," 1234 Invited talk at Internet 2 5th Annual PKI R&D Workshop, 1235 April 2006. 1236 http://middleware.internet2.edu/pki06/proceedings/ 1238 [Bo07] Bonica, R., et. al, "Authentication for TCP-based Routing 1239 and Management Protocols," draft-bonica-tcp-auth-06 , 1240 (work in progress), Feb. 2007. 1242 [Go07] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- 1243 attacks-03, (work in progress), Mar. 2008. 1245 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, 1246 Informational, April 1992. 1248 [RFC2104] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed- 1249 Hashing for Message Authentication," RFC 2104, 1250 Informational, Feb. 1997. 1252 [RFC2766] Tsirtsis, G., Srisuresh, P., "Network Address Translation - 1253 Protocol Translation (NAT-PT)," RFC 2766, Proposed 1254 Standard, Feb. 2000. 1256 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 1257 Signature Option," RFC 3562, Informational, July 2003. 1259 [RFC3947] Kivinen, T., B. Swander, A. Huttunen, V. Volpe, 1260 "Negotiation of NAT-Traversal in the IKE," RFC 3947, Jan. 1261 2005. 1263 [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet 1264 Protocol," RFC 4301, Proposed Standard, Dec. 2005. 1266 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5," RFC 1267 4808, Informational, Mar. 2007. 1269 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks," 1270 RFC4953, Jul. 2007. 1272 [SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4)," 1273 Specification SDN.401, Revision 1.2, July 12, 1988. 1275 [We05] Weis, B., "TCP Message Authentication Code Option," draft- 1276 weis-tcp-mac-option-00, (expired work in progress), Dec. 1277 2005. 1279 [We07] Weis, B., et al., "Automated key selection extension for 1280 the TCP Authentication Option," draft-weis-tcp-auth-auto- 1281 ks-03, (work in progress), Oct. 2007. 1283 Author's Addresses 1285 Joe Touch 1286 USC/ISI 1287 4676 Admiralty Way 1288 Marina del Rey, CA 90292-6695 1289 U.S.A. 1291 Phone: +1 (310) 448-9151 1292 Email: touch@isi.edu 1293 URL: http://www.isi.edu/touch 1294 Allison Mankin 1295 Washington, DC 1296 U.S.A. 1298 Phone: 1 301 728 7199 1299 Email: mankin@psg.com 1300 URL: http://www.psg.com/~mankin/ 1302 Ronald P. Bonica 1303 Juniper Networks 1304 2251 Corporate Park Drive 1305 Herndon, VA 20171 1306 U.S.A. 1308 Email: rbonica@juniper.net 1310 Full Copyright Statement 1312 Copyright (C) The IETF Trust (2008). 1314 This document is subject to the rights, licenses and restrictions 1315 contained in BCP 78, and except as set forth therein, the authors 1316 retain all their rights. 1318 This document and the information contained herein are provided on an 1319 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1320 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1321 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1322 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1323 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1324 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1326 Intellectual Property Statement 1328 The IETF takes no position regarding the validity or scope of any 1329 Intellectual Property Rights or other rights that might be claimed to 1330 pertain to the implementation or use of the technology described in 1331 this document or the extent to which any license under such rights 1332 might or might not be available; nor does it represent that it has 1333 made any independent effort to identify any such rights. Information 1334 on the procedures with respect to rights in RFC documents can be 1335 found in BCP 78 and BCP 79. 1337 Copies of IPR disclosures made to the IETF Secretariat and any 1338 assurances of licenses to be made available, or the result of an 1339 attempt made to obtain a general license or permission for the use of 1340 such proprietary rights by implementers or users of this 1341 specification can be obtained from the IETF on-line IPR repository at 1342 http://www.ietf.org/ipr. 1344 The IETF invites any interested party to bring to its attention any 1345 copyrights, patents or patent applications, or other proprietary 1346 rights that may cover technology that may be required to implement 1347 this standard. Please address the information to the IETF at 1348 ietf-ipr@ietf.org.