< draft-ietf-tcpm-tcp-auth-opt-10.txt   draft-ietf-tcpm-tcp-auth-opt-11.txt >
TCPM WG J. Touch TCPM WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Obsoletes: 2385 A. Mankin Obsoletes: 2385 A. Mankin
Intended status: Proposed Standard Johns Hopkins Univ. Intended status: Proposed Standard Johns Hopkins Univ.
Expires: July 2010 R. Bonica Expires: September 2010 R. Bonica
Juniper Networks Juniper Networks
January 31, 2010 March 23, 2010
The TCP Authentication Option The TCP Authentication Option
draft-ietf-tcpm-tcp-auth-opt-10.txt draft-ietf-tcpm-tcp-auth-opt-11.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
skipping to change at page 1, line 46 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 31, 2010. This Internet-Draft will expire on September 23, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 44 skipping to change at page 2, line 44
connections (as used, e.g., in BGP and LDP), and to support a larger connections (as used, e.g., in BGP and LDP), and to support a larger
set of MACs with minimal other system and operational changes. TCP-AO set of MACs with minimal other system and operational changes. TCP-AO
uses a different option identifier than TCP MD5, even though TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO
and TCP MD5 are never permitted to be used simultaneously. TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO
supports IPv6, and is fully compatible with the proposed requirements supports IPv6, and is fully compatible with the proposed requirements
for the replacement of TCP MD5. for the replacement of TCP MD5.
Table of Contents Table of Contents
1. Contributors...................................................3 1. Contributors...................................................3
2. Introduction...................................................4 2. Conventions used in this document..............................4
2.1. Applicability Statement...................................5 3. Introduction...................................................4
2.2. Executive Summary.........................................5 3.1. Applicability Statement...................................5
3. Conventions used in this document..............................7 3.2. Executive Summary.........................................6
4. The TCP Authentication Option..................................7 4. The TCP Authentication Option..................................7
4.1. Review of TCP MD5 Option..................................7 4.1. Review of TCP MD5 Option..................................7
4.2. The TCP-AO Option.........................................8 4.2. The TCP Authentication Option Format......................8
5. TCP-AO Keys and Their Properties..............................10 5. TCP-AO Keys and Their Properties..............................10
5.1. Master Key Tuple.........................................10 5.1. Master Key Tuple.........................................10
5.2. Traffic Keys.............................................12 5.2. Traffic Keys.............................................12
5.3. MKT Properties...........................................13 5.3. MKT Properties...........................................13
6. Per-Connection TCP-AO Parameters..............................14 6. Per-Connection TCP-AO Parameters..............................14
7. Cryptographic Algorithms......................................15 7. Cryptographic Algorithms......................................15
7.1. MAC Algorithms...........................................15 7.1. MAC Algorithms...........................................15
7.2. Traffic Key Derivation Functions.........................18 7.2. Traffic Key Derivation Functions.........................19
7.3. Traffic Key Establishment and Duration Issues............22 7.3. Traffic Key Establishment and Duration Issues............22
7.3.1. MKT Reuse Across Socket Pairs.......................22 7.3.1. MKT Reuse Across Socket Pairs.......................23
7.3.2. MKTs Use Within a Long-lived Connection.............23 7.3.2. MKTs Use Within a Long-lived Connection.............23
8. Additional Security Mechanisms................................23 8. Additional Security Mechanisms................................23
8.1. Coordinating Use of New MKTs.............................23 8.1. Coordinating Use of New MKTs.............................24
8.2. Preventing replay attacks within long-lived connections..24 8.2. Preventing replay attacks within long-lived connections..25
9. TCP-AO Interaction with TCP...................................26 9. TCP-AO Interaction with TCP...................................27
9.1. TCP User Interface.......................................27 9.1. TCP User Interface.......................................27
9.2. TCP States and Transitions...............................28 9.2. TCP States and Transitions...............................28
9.3. TCP Segments.............................................28 9.3. TCP Segments.............................................28
9.4. Sending TCP Segments.....................................29 9.4. Sending TCP Segments.....................................29
9.5. Receiving TCP Segments...................................30 9.5. Receiving TCP Segments...................................30
9.6. Impact on TCP Header Size................................32 9.6. Impact on TCP Header Size................................32
9.7. Connectionless Resets....................................33 9.7. Connectionless Resets....................................33
9.8. ICMP Handling............................................34 9.8. ICMP Handling............................................34
10. Obsoleting TCP MD5 and Legacy Interactions...................34 10. Obsoleting TCP MD5 and Legacy Interactions...................35
11. Interactions with Middleboxes................................35 11. Interactions with Middleboxes................................36
11.1. Interactions with non-NAT/NAPT Middleboxes..............35 11.1. Interactions with non-NAT/NAPT Middleboxes..............36
11.2. Interactions with NAT/NAPT Devices......................36 11.2. Interactions with NAT/NAPT Devices......................36
12. Evaluation of Requirements Satisfaction......................36 12. Evaluation of Requirements Satisfaction......................36
13. Security Considerations......................................42 13. Security Considerations......................................42
14. IANA Considerations..........................................43 14. IANA Considerations..........................................44
15. References...................................................44 15. References...................................................45
15.1. Normative References....................................44 15.1. Normative References....................................45
15.2. Informative References..................................45 15.2. Informative References..................................46
16. Acknowledgments..............................................47 16. Acknowledgments..............................................48
1. Contributors 1. Contributors
This document evolved as the result of collaboration of the TCP This document evolved as the result of collaboration of the TCP
Authentication Design team (tcp-auth-dt), whose members were Authentication Design team (tcp-auth-dt), whose members were
(alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy, (alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy,
Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy
Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus
Westerlund. The text of this document is derived from a proposal by Westerlund. The text of this document is derived from a proposal by
Joe Touch and Allison Mankin [To06] (originally from June 2006), Joe Touch and Allison Mankin [To06] (originally from June 2006),
which was both inspired by and intended as a counterproposal to the which was both inspired by and intended as a counterproposal to the
revisions to TCP MD5 suggested in a document by Ron Bonica, Brian revisions to TCP MD5 suggested in a document by Ron Bonica, Brian
Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07] Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07]
(originally from Sept. 2005) and in a document by Brian Weis [We05]. (originally from Sept. 2005) and in a document by Brian Weis [We05].
Russ Housley suggested L4/application layer management of the master Russ Housley suggested L4/application layer management of the master
key tuples. Steve Bellovin motivated the KeyID field. Eric Rescorla key tuples. Steve Bellovin motivated the KeyID field. Eric Rescorla
suggested the use of ISNs in the traffic key computation and SNEs to suggested the use of TCP's initial sequence numbers (ISNs) in the
avoid replay attacks, and Brian Weis extended the computation to traffic key computation and SNEs to avoid replay attacks, and Brian
incorporate the entire connection ID and provided the details of the Weis extended the computation to incorporate the entire connection ID
traffic key computation. Mark Allman, Wes Eddy, Lars Eggert, Ted and provided the details of the traffic key computation. Mark Allman,
Faber, Russ Housley, Gregory Lebovitz, Tim Polk, Eric Rescorla, Joe Wes Eddy, Lars Eggert, Ted Faber, Russ Housley, Gregory Lebovitz, Tim
Touch, and Brian Weis developed the master key coordination Polk, Eric Rescorla, Joe Touch, and Brian Weis developed the master
mechanism. key coordination mechanism.
2. Introduction 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
In this document, the characters ">>" preceeding an indented line(s)
indicates a compliance requirement statement using the key words
listed above. This convention aids reviewers in quickly identifying
or finding the explicit compliance requirements of this RFC.
3. Introduction
The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates
TCP segments, including the TCP IPv4 pseudoheader, TCP header, and TCP segments, including the TCP IPv4 pseudoheader, TCP header, and
TCP data. It was developed to protect BGP sessions from spoofed TCP TCP data. It was developed to protect BGP sessions from spoofed TCP
segments which could affect BGP data or the robustness of the TCP segments which could affect BGP data or the robustness of the TCP
connection itself [RFC2385][RFC4953]. connection itself [RFC2385][RFC4953].
There have been many recent concerns about TCP MD5. Its use of a There have been many recent concerns about TCP MD5. Its use of a
simple keyed hash for authentication is problematic because there simple keyed hash for authentication is problematic because there
have been escalating attacks on the algorithm itself [Wa05]. TCP MD5 have been escalating attacks on the algorithm itself [Wa05]. TCP MD5
also lacks both key management and algorithm agility. This document also lacks both key management and algorithm agility. This document
adds the latter, and provides a simple key coordination mechanism adds the latter, and provides a simple key coordination mechanism
giving the ability to move from one key to another within the same giving the ability to move from one key to another within the same
connection. It does not however provide for complete cryptographic connection. It does not however provide for complete cryptographic
key management to be handled in-band of TCP, because TCP SYN segments key management to be handled in-band of TCP, because TCP SYN segments
lack sufficient remaining space to handle such a negotiation (see lack sufficient remaining space to handle such a negotiation (see
Section 9.6). This document obsoletes the TCP MD5 option with a more Section 9.6). This document obsoletes the TCP MD5 option with a more
general TCP Authentication Option (TCP-AO), to support the use of general TCP Authentication Option (TCP-AO). This new option supports
other, stronger hash functions, provide replay protection for long- the use of other, stronger hash functions, provides replay protection
lived connections and across repeated instances of a single for long-lived connections and across repeated instances of a single
connection, coordinate key changes between endpoints, and to provide connection, coordinates key changes between endpoints, and provides a
a more structured recommendation on external key management. The more explicit recommendation for external key management. The result
result is compatible with IPv6, and is fully compatible with proposed is compatible with IPv6, and is fully compatible with proposed
requirements for a replacement for TCP MD5 [Be07]. requirements for a replacement for TCP MD5 [Be07].
TCP-AO obsoletes TCP MD5, although a particular implementation may TCP-AO obsoletes TCP MD5, although a particular implementation may
support both mechanisms for backward compatibility. For a given support both mechanisms for backward compatibility. For a given
connection, only one can be in use. TCP MD5-protected connections connection, only one can be in use. TCP MD5-protected connections
cannot be migrated to TCP-AO because TCP MD5 does not support any cannot be migrated to TCP-AO because TCP MD5 does not support any
changes to a connection's security algorithm once established. changes to a connection's security algorithm once established.
2.1. Applicability Statement 3.1. Applicability Statement
TCP-AO is intended to support current uses of TCP MD5, such as to TCP-AO is intended to support current uses of TCP MD5, such as to
protect long-lived connections for routing protocols, such as BGP and protect long-lived connections for routing protocols, such as BGP and
LDP. It is also intended to provide similar protection to any long- LDP. It is also intended to provide similar protection to any long-
lived TCP connection, as might be used between proxy caches, e.g., lived TCP connection, as might be used between proxy caches, e.g.,
and is not designed solely or primarily for routing protocol uses. and is not designed solely or primarily for routing protocol uses.
TCP-AO is intended to replace (and thus obsolete) the use of TCP MD5. TCP-AO is intended to replace (and thus obsolete) the use of TCP MD5.
TCP-AO enhances the capabilities of TCP MD5 as summarized in Section TCP-AO enhances the capabilities of TCP MD5 as summarized in Section
2.2. 3.2. This document recommends overall that:
TCP-AO not intended to replace the use of the IPsec suite (IPsec and >> TCP implementations that support TCP MD5 MUST support TCP-AO.
IKE) to protect TCP connections [RFC4301][RFC4306]. Specific
differences are noted in Section 2.2. In fact, we recommend the use >> TCP-AO SHOULD be implemented where the protection afforded by TCP
authentiation is needed, either because IPsec is not supported, or
because TCP-AO's particular properties are needed (e.g., per-
connection keys).
>> TCP-AO MAY be implemented elsewhere.
TCP-AO is not intended to replace the use of the IPsec suite (IPsec
and IKE) to protect TCP connections [RFC4301][RFC4306]. Specific
differences are noted in Section 3.2. In fact, we recommend the use
of IPsec and IKE, especially where IKE's level of existing support of IPsec and IKE, especially where IKE's level of existing support
for parameter negotiation, session key negotiation, or rekeying are for parameter negotiation, session key negotiation, or rekeying are
desired. TCP-AO is intended for use only where the IPsec suite would desired. TCP-AO is intended for use only where the IPsec suite would
not be feasible, e.g., as has been suggested is the case to support not be feasible, e.g., as has been suggested is the case to support
some routing protocols [RFC4953], or in cases where keys need to be some routing protocols [RFC4953], or in cases where keys need to be
tightly coordinated with individual transport sessions [Be07]. tightly coordinated with individual transport sessions [Be07].
TCP-AO is not intended to replace the use of Transport Layer Security TCP-AO is not intended to replace the use of Transport Layer Security
(TLS) [RFC5246], sBGP or soBGP [Le09], or any other mechanisms that (TLS) [RFC5246], sBGP or soBGP [Le09], or any other mechanisms that
protect only the TCP data stream. TCP-AO protects the transport protect only the TCP data stream. TCP-AO protects the transport
layer, preventing attacks from disabling the TCP connection itself layer, preventing attacks from disabling the TCP connection itself
[RFC4953]. Data stream mechanisms protect only the contents of the [RFC4953]. Data stream mechanisms protect only the contents of the
TCP segments, and can be disrupted when the connection is affected. TCP segments, and can be disrupted when the connection is affected.
Some of these data protection protocols - notably TLS - offer a Some of these data protection protocols - notably TLS - offer a
richer set of key management and authentication mechanisms than TCP- richer set of key management and authentication mechanisms than TCP-
AO, and thus protect the data stream in a different way. TCP-AO may AO, and thus protect the data stream in a different way. TCP-AO may
be used together with these data stream protections to complement be used together with these data stream protections to complement
each others' strengths. each others' strengths.
2.2. Executive Summary 3.2. Executive Summary
This document replaces TCP MD5 as follows [RFC2385]: This document replaces TCP MD5 as follows [RFC2385]:
o TCP-AO uses a separate option Kind for TCP-AO (TBD-IANA-KIND). o TCP-AO uses a separate option Kind (TBD-IANA-KIND).
o TCP-AO allows TCP MD5 to continue to be used concurrently for o TCP-AO allows TCP MD5 to continue to be used concurrently for
legacy connections. legacy connections.
o TCP-AO replaces MD5's single MAC algorithm with MACs specified in o TCP-AO replaces TCP MD5's single MAC algorithm with MACs specified
a separate document and can be extended to include other MACs. in a separate document and can be extended to include other MACs.
o TCP-AO allows rekeying during a TCP connection, assuming that an o TCP-AO allows rekeying during a TCP connection, assuming that an
out-of-band protocol or manual mechanism provides the new keys. out-of-band protocol or manual mechanism provides the new keys.
The option includes a 'key ID' which allows the efficient The option includes a 'key ID' which allows the efficient
concurrent use of multiple keys, and a key coordination mechanism concurrent use of multiple keys, and a key coordination mechanism
using a 'receive next key ID' manages the key change within a using a 'receive next key ID' manages the key change within a
connection. Note that TCP MD5 does not preclude rekeying during a connection. Note that TCP MD5 does not preclude rekeying during a
connection, but does not require its support either. Further, connection, but does not require its support either. Further,
TCP-AO supports key changes with zero segment loss, whereas key TCP-AO supports key changes with zero segment loss, whereas key
changes in TCP MD5 can lose segments in transit during the changes in TCP MD5 can lose segments in transit during the
skipping to change at page 6, line 30 skipping to change at page 7, line 5
connections using sequence number extensions. connections using sequence number extensions.
o TCP-AO ensures per-connection traffic keys as unique as the TCP o TCP-AO ensures per-connection traffic keys as unique as the TCP
connection itself, using TCP's initial sequence numbers (ISNs) for connection itself, using TCP's initial sequence numbers (ISNs) for
differentiation, even when static master key tuples are used differentiation, even when static master key tuples are used
across repeated instances of connections on a single socket pair. across repeated instances of connections on a single socket pair.
o TCP-AO specifies the details of how this option interacts with o TCP-AO specifies the details of how this option interacts with
TCP's states, event processing, and user interface. TCP's states, event processing, and user interface.
o The TCP-AO option is 2 bytes shorter than TCP MD5 (16 bytes o TCP-AO is 2 bytes shorter than TCP MD5 (16 bytes overall, rather
overall, rather than 18) in the initially specified default case than 18) in the initially specified default case (using a 96-bit
(using a 96-bit MAC). MAC).
This document differs from an IPsec/IKE solution in that TCP-AO as TCP-AO differs from an IPsec/IKE solution in as follows
follows [RFC4301][RFC4306]: [RFC4301][RFC4306]:
o TCP-AO does not support dynamic parameter negotiation. o TCP-AO does not support dynamic parameter negotiation.
o TCP-AO uses TCP's socket pair (source address, destination o TCP-AO includes TCP's socket pair (source address, destination
address, source port, destination port) as a security parameter address, source port, destination port) as a security parameter
index, rather than using a separate field as an index (IPsec's index (together with the KeyID), rather than using a separate
SPI). field as an index (IPsec's SPI).
o TCP-AO forces a change of computed MACs when a connection o TCP-AO forces a change of computed MACs when a connection
restarts, even when reusing a TCP socket pair (IP addresses and restarts, even when reusing a TCP socket pair (IP addresses and
port numbers) [Be07]. port numbers) [Be07].
o TCP-AO does not support encryption. o TCP-AO does not support encryption.
o TCP-AO does not authenticate ICMP messages (some ICMP messages may o TCP-AO does not authenticate ICMP messages (some ICMP messages may
be authenticated when using IPsec, depending on the be authenticated when using IPsec, depending on the
configuration). configuration).
3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
In this document, the characters ">>" proceeding an indented line(s)
indicates a compliance requirement statement using the key words
listed above. This convention aids reviewers in quickly identifying
or finding the explicit compliance requirements of this RFC.
4. The TCP Authentication Option 4. The TCP Authentication Option
The TCP Authentication Option (TCP-AO) uses a TCP option Kind value The TCP Authentication Option (TCP-AO) uses a TCP option Kind value
of TBD-IANA-KIND. of TBD-IANA-KIND. The following sections describe TCP-AO and provide
a review of TCP MD5 for comparison.
4.1. Review of TCP MD5 Option 4.1. Review of TCP MD5 Option
For review, the TCP MD5 option is shown in Figure 1. For review, the TCP MD5 option is shown in Figure 1.
+---------+---------+-------------------+ +---------+---------+-------------------+
| Kind=19 |Length=18| MD5 digest... | | Kind=19 |Length=18| MD5 digest... |
+---------+---------+-------------------+ +---------+---------+-------------------+
| ...digest (con't)... | | ...digest (con't)... |
+---------------------------------------+ +---------------------------------------+
skipping to change at page 8, line 17 skipping to change at page 8, line 21
1. The IP pseudoheader (IP source and destination addresses, protocol 1. The IP pseudoheader (IP source and destination addresses, protocol
number, and segment length). number, and segment length).
2. The TCP header excluding options and checksum. 2. The TCP header excluding options and checksum.
3. The TCP data payload. 3. The TCP data payload.
4. A key. 4. A key.
4.2. The TCP-AO Option 4.2. The TCP Authentication Option Format
The new TCP-AO option provides a superset of the capabilities of TCP TCP-AO provides a superset of the capabilities of TCP MD5, and is
MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new Kind field,
Kind field, and similar Length field to TCP MD5, a KeyID field, and a and similar Length field to TCP MD5, a KeyID field, and a RNextKeyID
RNextKeyID field as shown in Figure 2. field as shown in Figure 2.
+------------+------------+------------+------------+ +------------+------------+------------+------------+
| Kind | Length | KeyID | RNextKeyID | | Kind | Length | KeyID | RNextKeyID |
+------------+------------+------------+------------+ +------------+------------+------------+------------+
| MAC ... | MAC ...
+-----------------------------------... +-----------------------------------...
...-----------------+ ...-----------------+
... MAC (con't) | ... MAC (con't) |
...-----------------+ ...-----------------+
Figure 2 The TCP-AO Option Figure 2 The TCP Authentication Option (TCP-AO)
The TCP-AO defines the fields as follows: TCP-AO defines these fields as follows:
o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP- o Kind: An unsigned 1-byte field indicating TCP-AO. TCP-AO uses a
AO uses a new Kind value of TBD-IANA-KIND. new Kind value of TBD-IANA-KIND.
>> An endpoint MUST NOT use TCP-AO for the same connection in >> An endpoint MUST NOT use TCP-AO for the same connection in
which TCP MD5 is used. When both options appear, TCP MUST silently which TCP MD5 is used. When both options appear, TCP MUST silently
discard the segment. discard the segment.
>> A single TCP segment MUST NOT have more than one TCP-AO option. >> A single TCP segment MUST NOT have more than one TCP-AO in its
When multiple TCP-AO options appear, TCP MUST discard the segment. options sequence. When multiple TCP-AOs appear, TCP MUST discard
the segment.
o Length: An unsigned 1-byte field indicating the length of the TCP- o Length: An unsigned 1-byte field indicating the length of the
AO option in bytes, including the Kind, Length, KeyID, RNextKeyID, option in bytes, including the Kind, Length, KeyID, RNextKeyID,
and MAC fields. and MAC fields.
>> The Length value MUST be greater than or equal to 4. When the >> The Length value MUST be greater than or equal to 4. When the
Length value is less than 4, TCP MUST discard the segment. Length value is less than 4, TCP MUST discard the segment.
>> The Length value MUST be consistent with the TCP header length; >> The Length value MUST be consistent with the TCP header length.
this is a consistency check and avoids overrun/underrun abuse.
When the Length value is invalid, TCP MUST discard the segment. When the Length value is invalid, TCP MUST discard the segment.
This Length check implies that the sum of the sizes of all
options, when added to the size of the base TCP header (5 words),
matches the TCP Offset field exactly. This full verification can
be computed because RFC 793 specifies the size of the required
options, and RFC 1122 requires that all new options follow a
common format with a fixed length field location
[RFC793][RFC1122]. A partial verification can be limited to check
only TCP-AO, so that the TCP-AO length, when added to the TCP-AO
offset from start of the TCP header, does not exceed the TCP
header size as indicated in the TCP header Offset field.
Values of 4 and other small values larger than 4 (e.g., indicating Values of 4 and other small values larger than 4 (e.g., indicating
MAC fields of very short length) are of dubious utility but are MAC fields of very short length) are of dubious utility but are
not specifically prohibited. not specifically prohibited.
o KeyID: An unsigned 1-byte field indicating the MKT used to o KeyID: An unsigned 1-byte field indicating the master key tuple
generate the traffic keys which were used to generate the MAC that (MKT, as defined in Section 5.1) used to generate the traffic keys
authenticates this segment. which were used to generate the MAC that authenticates this
segment.
It supports efficient key changes during a connection and/or to It supports efficient key changes during a connection and/or to
help with key coordination during connection establishment, to be help with key coordination during connection establishment, to be
discussed further in Section 8.1. Note that the KeyID has no discussed further in Section 8.1. Note that the KeyID has no
cryptographic properties - it need not be random, nor are there cryptographic properties - it need not be random, nor are there
any reserved values. any reserved values.
>> KeyID values MAY be the same in both directions of a >> KeyID values MAY be the same in both directions of a
connection, but do not have to be and there is no special meaning connection, but do not have to be and there is no special meaning
when they are. when they are.
o RNextKeyID: An unsigned 1-byte field indicating the MKT that the This allows MKTs to be installed on a set of devices without
sender is ready use to receive authenticated segments, i.e., the coordinating the KeyIDs across an entire in advance, and allows
desired 'receive next' keyID. new devices to be added to the set using a group of MKTs later
without requiring renumbering of KeyIDs. These two capabilities
are particularly important when used with wildcards in the TCP
socket pair of the MKT, i.e., when a MKT is used among a set of
devices specified by a pattern (as noted in Section 5.1).
o RNextKeyID: An unsigned 1-byte field indicating the MKT that is
ready at the sender to be used to authenticate received segments,
i.e., the desired 'receive next' keyID.
It supports efficient key change coordination, to be discussed It supports efficient key change coordination, to be discussed
further in Section 8.1. Note that the RNextKeyID has no further in Section 8.1. Note that the RNextKeyID has no
cryptographic properties - it need not be random, nor are there cryptographic properties - it need not be random, nor are there
any reserved values. any reserved values.
o MAC: Message Authentication Code. Its contents are determined by o MAC: Message Authentication Code. Its contents are determined by
the particulars of the security association. Typical MACs are 96- the particulars of the security association. Typical MACs are 96-
128 bits (12-16 bytes), but any length that fits in the header of 128 bits (12-16 bytes), but any length that fits in the header of
the segment being authenticated is allowed. The MAC computation is the segment being authenticated is allowed. The MAC computation is
described further in Section 7.1. described further in Section 7.1.
>> Required support for TCP-AO MACs are defined in [Le09]; other >> Required support for TCP-AO MACs are defined in [Le09]; other
MACs MAY be supported. MACs MAY be supported.
The TCP-AO option fields do not indicate the MAC algorithm either TCP-AO fields do not indicate the MAC algorithm either implicitly (as
implicitly (as with TCP MD5) or explicitly. The particular algorithm with TCP MD5) or explicitly. The particular algorithm used is
used is considered part of the configuration state of the considered part of the configuration state of the connection's
connection's security and is managed separately (see Section 5). security and is managed separately (see Section 5).
Please note that the use of TCP-AO does not affect TCP's advertised Please note that the use of TCP-AO does not affect TCP's advertised
maximum segment size (MSS), as is the case for all TCP options maximum segment size (MSS), as is the case for all TCP options
[Bo09]. [Bo09].
The remainder of this document explains how the TCP-AO option is The remainder of this document explains how TCP-AO is handled and its
handled and its relationship to TCP. relationship to TCP.
5. TCP-AO Keys and Their Properties 5. TCP-AO Keys and Their Properties
TCP-AO relies on two sets of keys to authenticate incoming and TCP-AO relies on two sets of keys to authenticate incoming and
outgoing segments: master key tuples (MKTs) and traffic keys. MKTs outgoing segments: master key tuples (MKTs) and traffic keys. MKTs
are used to derive unique traffic keys, and include the keying are used to derive unique traffic keys, and include the keying
material used to generate those traffic keys, as well as indicating material used to generate those traffic keys, as well as indicating
the associated parameters under which traffic keys are used. Such the associated parameters under which traffic keys are used. Such
parameters include whether TCP options are authenticated, and parameters include whether TCP options are authenticated, and
indicators of the algorithms used for traffic key derivation and MAC indicators of the algorithms used for traffic key derivation and MAC
skipping to change at page 11, line 5 skipping to change at page 11, line 23
included, the content of all options, in the order present, are included, the content of all options, in the order present, are
included in the MAC, with TCP-AO's MAC field zeroed out. When the included in the MAC, with TCP-AO's MAC field zeroed out. When the
options are not included, all options other than TCP-AO are options are not included, all options other than TCP-AO are
excluded from all MAC calculations (skipped over, not zeroed). excluded from all MAC calculations (skipped over, not zeroed).
Note that TCP-AO, with its MAC field zeroed out, is always Note that TCP-AO, with its MAC field zeroed out, is always
included in the MAC calculation, regardless of the setting of this included in the MAC calculation, regardless of the setting of this
flag; this protects the indication of the MAC length as well as flag; this protects the indication of the MAC length as well as
the key ID fields (KeyID, RNextKeyID). The option flag applies to the key ID fields (KeyID, RNextKeyID). The option flag applies to
TCP options in both directions (incoming and outgoing segments). TCP options in both directions (incoming and outgoing segments).
o IDs. The values used in the KeyID or RNextKeyID of a TCP-AO o IDs. The values used in the KeyID or RNextKeyID of TCP-AO; used to
option; used to differentiate MKTs in concurrent use (KeyID), as differentiate MKTs in concurrent use (KeyID), as well as to
well as to indicate when MKTs are ready for use in the opposite indicate when MKTs are ready for use in the opposite direction
direction (RNextKeyID). (RNextKeyID).
Each MKT has two IDs - a SendID and a RecvID. The SendID is Each MKT has two IDs - a SendID and a RecvID. The SendID is
inserted as the KeyID of the TCP-OP option of outgoing segments, inserted as the KeyID of the TCP-OP option of outgoing segments,
and the RecvID is matched against the KeyID of the TCP-AO option and the RecvID is matched against the TCP-AO KeyID of incoming
of incoming segments. These and other uses of these two IDs are segments. These and other uses of these two IDs are described
described further in Section 9.4 and 9.5. further in Section 9.4 and 9.5.
>> MKT IDs MUST support any value, 0-255 inclusive. There are no >> MKT IDs MUST support any value, 0-255 inclusive. There are no
reserved ID values. reserved ID values.
ID values are assigned arbitrarily. They can be assigned in ID values are assigned arbitrarily, i.e., the values are not
sequence, or based on any method mutually agreed by the connection monotonically increasing, have no reserved values, and are
endpoints (e.g., using an external MKT management mechanism). otherwise not meaningful. They can be assigned in sequence, or
based on any method mutually agreed by the connection endpoints
(e.g., using an external MKT management mechanism).
>> IDs MUST NOT be assumed to be randomly assigned. >> IDs MUST NOT be assumed to be randomly assigned.
o Master key. A byte sequence used for generating traffic keys, this o Master key. A byte sequence used for generating traffic keys, this
may be derived from a separate shared key by an external protocol may be derived from a separate shared key by an external protocol
over a separate channel. This sequence is used in the traffic key over a separate channel. This sequence is used in the traffic key
generation algorithm described in Section 7.2. generation algorithm described in Section 7.2.
Implementations are advised to keep master key values in a Implementations are advised to keep master key values in a
private, protected area of memory or other storage. private, protected area of memory or other storage.
skipping to change at page 12, line 32 skipping to change at page 13, line 4
IP address pairs and TCP port numbers, and, for established IP address pairs and TCP port numbers, and, for established
connections, the TCP Initial Sequence Numbers (ISNs) in each connections, the TCP Initial Sequence Numbers (ISNs) in each
direction. Segments exchanged before a connection is established use direction. Segments exchanged before a connection is established use
the same information, substituting zero for unknown values (e.g., the same information, substituting zero for unknown values (e.g.,
ISNs not yet coordinated). ISNs not yet coordinated).
A single MKT can be used to derive any of four different traffic A single MKT can be used to derive any of four different traffic
keys: keys:
o Send_SYN_traffic_key o Send_SYN_traffic_key
o Receive_SYN_traffic_key o Receive_SYN_traffic_key
o Send_other_traffic_key o Send_other_traffic_key
o Receive_other_traffic_key o Receive_other_traffic_key
Note that the keys are unidirectional. A given connection typically Note that the keys are unidirectional. A given connection typically
uses only three of these keys, because only one of the SYN keys is uses only three of these keys, because only one of the SYN keys is
typically used. All four are used only when a connection goes through typically used. All four are used only when a connection goes through
'simultaneous open' [RFC793]. 'simultaneous open' [RFC793].
The relationship between MKTs and traffic keys is shown in Figure The relationship between MKTs and traffic keys is shown in Figure 3.
Figure 3. Traffic keys are indicated with a "*". Note that every MKT Traffic keys are indicated with a "*". Note that every MKT can be
can be used to derive any of the four traffic keys, but only the keys used to derive any of the four traffic keys, but only the keys
actually needed to handle the segments of a connection need to be actually needed to handle the segments of a connection need to be
computed. Section 7.2 provides further details on how traffic keys computed. Section 7.2 provides further details on how traffic keys
are derived. are derived.
MKT-A MKT-B MKT-A MKT-B
+---------------------+ +------------------------+ +---------------------+ +------------------------+
| SendID = 1 | | SendID = 5 | | SendID = 1 | | SendID = 5 |
| RecvID = 2 | | RecvID = 6 | | RecvID = 2 | | RecvID = 6 |
| MAC = HMAC-SHA1 | | MAC = AES-CMAC | | MAC = HMAC-SHA1 | | MAC = AES-CMAC |
| KDF = KDF-HMAC-SHA1 | | KDF = KDF-AES-128-CMAC | | KDF = KDF-HMAC-SHA1 | | KDF = KDF-AES-128-CMAC |
+---------------------+ +------------------------+ +---------------------+ +------------------------+
| | | |
+----------+----------+ | +----------+----------+ |
| | | | | |
v v v v v v
Connection 1 Connection 2 Connection 3 Connection 1 Connection 2 Connection 3
+------------------+ +------------------+ +------------------+ +------------------+ +------------------+ +------------------+
| * Send_SYN_key | | * Send_SYN_key | | * Send_SYN_key | | * Send_SYN_key | | * Send_SYN_key | | * Send_SYN_key |
| * Recv_SYN_key | | * Recv_SYN_key | | * Recv_SYN_key | | * Recv_SYN_key | | * Recv_SYN_key | | * Recv_SYN_key |
| * Send_Other_key | | * Send_Other_key | | * Send_Other_key | | * Send_Other_key | | * Send_Other_key | | * Send_Other_key |
| * Send_Other_key | | * Send_Other_key | | * Send_Other_key | | * Recv_Other_key | | * Recv_Other_key | | * Recv_Other_key |
+------------------+ +------------------+ +------------------+ +------------------+ +------------------+ +------------------+
Figure 3 Relationship between MKTs and traffic keys Figure 3 Relationship between MKTs and traffic keys
5.3. MKT Properties 5.3. MKT Properties
TCP-AO requires that every protected TCP segment match exactly one TCP-AO requires that every protected TCP segment match exactly one
MKT. When an outgoing segment matches an MKT, TCP-AO is used. When no MKT. When an outgoing segment matches an MKT, TCP-AO is used. When no
match occurs, TCP-AO is not used. Multiple MKTs may match a single match occurs, TCP-AO is not used. Multiple MKTs may match a single
outgoing segment, e.g., when MKTs are being changed. Those MKTs outgoing segment, e.g., when MKTs are being changed. Those MKTs
skipping to change at page 13, line 44 skipping to change at page 14, line 14
>> An outgoing TCP segment MUST match at most one desired MKT, >> An outgoing TCP segment MUST match at most one desired MKT,
indicated by the segment's socket pair. The segment MAY match indicated by the segment's socket pair. The segment MAY match
multiple MKTs, provided that exactly one MKT is indicated as desired. multiple MKTs, provided that exactly one MKT is indicated as desired.
Other information in the segment MAY be used to determine the desired Other information in the segment MAY be used to determine the desired
MKT when multiple MKTs match; such information MUST NOT include MKT when multiple MKTs match; such information MUST NOT include
values in any TCP option fields. values in any TCP option fields.
We recommend that the mechanism used to select from among multiple We recommend that the mechanism used to select from among multiple
MKTs use only information that TCP-AO would authenticate. Because MKTs use only information that TCP-AO would authenticate. Because
MKTs may indicate that non-TCP-AO options are ignored in the MAC MKTs may indicate that options other than TCP-AO are ignored in the
calculation, we recommend that TCP options should not be used to MAC calculation, we recommend that TCP options should not be used to
determine MKTs. determine MKTs.
>> An incoming TCP segment containing the TCP-AO option MUST match at >> An incoming TCP segment including TCP-AO MUST match exactly one
exactly one MKT, indicated solely by the segment's socket pair and MKT, indicated solely by the segment's socket pair and its TCP-AO
its TCP-AO KeyID. KeyID.
Incoming segments include an indicator in the TCP-AO option to select Incoming segments include an indicator inside TCP-AO to select from
from among multiple matching MKTs - the KeyID field. TCP-AO requires among multiple matching MKTs - the KeyID field. TCP-AO requires that
that the KeyID alone be used to differentiate multiple matching MKTs, the KeyID alone be used to differentiate multiple matching MKTs, so
so that MKT changes can be coordinated using the TCP-AO key change that MKT changes can be coordinated using the TCP-AO key change
coordination mechanism. coordination mechanism.
>> When an outgoing TCP segment matches no MKTs, TCP-AO is not used. >> When an outgoing TCP segment matches no MKTs, TCP-AO is not used.
TCP-AO is always used when outgoing segments match an MKT, and is not TCP-AO is always used when outgoing segments match an MKT, and is not
used otherwise. used otherwise.
6. Per-Connection TCP-AO Parameters 6. Per-Connection TCP-AO Parameters
TCP-AO uses a small number of parameters associated with each TCP-AO uses a small number of parameters associated with each
connection that uses the TCP-AO option, once instantiated. These connection that uses TCP-AO, once instantiated. These values can be
values can be stored in the Transport Control Block (TCP) [RFC793]. stored in the Transport Control Block (TCP) [RFC793]. These values
These values are explained in subsequent sections of this document as are explained in subsequent sections of this document as noted; they
noted; they include: include:
1. Current_key - the MKT currently used to authenticate outgoing 1. Current_key - the MKT currently used to authenticate outgoing
segments, whose SendID is inserted in outgoing segments as KeyID segments, whose SendID is inserted in outgoing segments as KeyID
(see Section 9.4, step 5). Incoming segments are authenticated (see Section 9.4, step 5). Incoming segments are authenticated
using the MKT corresponding to the segment and the KeyID in its using the MKT corresponding to the segment and its TCP-AO KeyID
TCP-AO header (see Section 9.5, step 5), as matched against the (see Section 9.5, step 5), as matched against the MKT TCP
MKT TCP connection identifier and the MKT RecvID. There is only connection identifier and the MKT RecvID. There is only one
one current_key at any given time on a particular connection. current_key at any given time on a particular connection.
>> Every TCP connection in a non-IDLE state MUST have at most one >> Every TCP connection in a non-IDLE state MUST have at most one
current_key specified. current_key specified.
2. Rnext_key -the MKT currently preferred for incoming (received) 2. Rnext_key -the MKT currently preferred for incoming (received)
segments, whose RecvID is inserted in outgoing segments as segments, whose RecvID is inserted in outgoing segments as
RNextKeyID (see Section 9.5, step 5). RNextKeyID (see Section 9.5, step 5).
>> Each TCP connection in a non-IDLE state MUST have at most one >> Each TCP connection in a non-IDLE state MUST have at most one
rnext_key specified. rnext_key specified.
skipping to change at page 15, line 10 skipping to change at page 15, line 28
socket pair. socket pair.
MKTs are used, together with other parameters of a connection, to MKTs are used, together with other parameters of a connection, to
create traffic keys unique to each connection, as described in create traffic keys unique to each connection, as described in
Section 7.2. These traffic keys can be cached after computation, and Section 7.2. These traffic keys can be cached after computation, and
can be stored in the TCB with the corresponding MKT information. They can be stored in the TCB with the corresponding MKT information. They
can be considered part of the per-connection parameters. can be considered part of the per-connection parameters.
7. Cryptographic Algorithms 7. Cryptographic Algorithms
TCP-AO also uses cryptographic algorithms to compute the MAC (Message TCP-AO uses cryptographic algorithms to compute the MAC (Message
Authentication Code) used to authenticate a segment and its headers; Authentication Code) that is used to authenticate a segment and its
these are called MAC algorithms and are specified in a separate headers; these are called MAC algorithms and are specified in a
document to facilitate updating the algorithm requirements separate document to facilitate updating the algorithm requirements
independently from the protocol [Le09]. TCP-AO also uses independently from the protocol [Le09]. TCP-AO also uses
cryptographic algorithms to convert MKTs, which can be shared across cryptographic algorithms to convert MKTs, which can be shared across
connections, into unique traffic keys for each connection. These are connections, into unique traffic keys for each connection. These are
called Key Derivation Functions (KDFs), and are specified [Le09]. called Key Derivation Functions (KDFs), and are specified [Le09].
This section describes how these algorithms are used by TCP-AO. This section describes how these algorithms are used by TCP-AO.
7.1. MAC Algorithms 7.1. MAC Algorithms
MAC algorithms take a variable-length input and a key and output a MAC algorithms take a variable-length input and a key and output a
fixed-length number. This number is used to determine whether the fixed-length number. This number is used to determine whether the
skipping to change at page 16, line 8 skipping to change at page 16, line 26
o Message - input data over which the MAC is computed. In TCP-AO, o Message - input data over which the MAC is computed. In TCP-AO,
this is the TCP segment prepended by the IP pseudoheader and TCP this is the TCP segment prepended by the IP pseudoheader and TCP
header options, as described in Section 7.1. header options, as described in Section 7.1.
o MAC - the fixed-length output of the MAC algorithm, given the o MAC - the fixed-length output of the MAC algorithm, given the
parameters provided. parameters provided.
At the time of this writing, the algorithms' definitions for use in At the time of this writing, the algorithms' definitions for use in
TCP-AO, as described in [Le09] are each truncated to 96 bits. Though TCP-AO, as described in [Le09] are each truncated to 96 bits. Though
the algorithms each output a larger MAC, 96 bits provides a the algorithms each output a larger MAC, 96 bits provides a
reasonable tradeoff between security and message size, for fitting reasonable tradeoff between security and message size. Though could
into the TCP-AO header. Though could change in the future, so TCP-AO change in the future, so TCP-AO size should not be assumed as fixed
header sizes should not be assumed as fixed length. length.
The MAC algorithm employed for the MAC computation on a connection is The MAC algorithm employed for the MAC computation on a connection is
done so by definition in the MKT, per [Le09]'s definitions. done so by definition in the MKT, per [Le09]'s definitions.
The mandatory-to-implement MAC algorithms for use with TCP-AO are The mandatory-to-implement MAC algorithms for use with TCP-AO are
described in a separate RFC [Le09]. This allows the TCP-AO described in a separate RFC [Le09]. This allows the TCP-AO
specification to proceed along the standards track even if changes specification to proceed along the IETF standards track even if
are needed to its associated algorithms and their labels (as might be changes are needed to its associated algorithms and their labels (as
used in a user interface or automated MKT management protocol) as a might be used in a user interface or automated MKT management
result of the ever evolving world of cryptography. protocol) as a result of the ever evolving world of cryptography.
>> Additional algorithms, beyond those mandated for TCP-AO, MAY be >> Additional algorithms, beyond those mandated for TCP-AO, MAY be
supported. supported.
The data input to the MAC is the following fields in the following The data input to the MAC is the following fields in the following
sequence, interpreted in network-standard byte order: sequence, interpreted in network-standard byte order:
1. The sequence number extension (SNE), in network-standard byte 1. The sequence number extension (SNE), in network-standard byte
order, as follows (described further in Section 8.2): order, as follows (described further in Section 8.2):
skipping to change at page 21, line 49 skipping to change at page 22, line 24
same socket, their 32-bit space avoids repeated use except under same socket, their 32-bit space avoids repeated use except under
reboot, and reuse assumes both sides repeat their use on the same reboot, and reuse assumes both sides repeat their use on the same
connection). We do expect that: connection). We do expect that:
>> Endpoints should select ISNs pseudorandomly, e.g., as in [RFC1948] >> Endpoints should select ISNs pseudorandomly, e.g., as in [RFC1948]
A SYN is authenticated using a destination ISN of zero (whether sent A SYN is authenticated using a destination ISN of zero (whether sent
or received), and all other segments would be authenticated using the or received), and all other segments would be authenticated using the
ISN pair for the connection. There are other cases in which the ISN pair for the connection. There are other cases in which the
destination ISN is not known, but segments are emitted, such as after destination ISN is not known, but segments are emitted, such as after
an endpoint reboots, when is possible that the two endpoints would an endpoint reboots, when it is possible that the two endpoints would
not have enough information to authenticate segments. This is not have enough information to authenticate segments. This is
addressed further in Section 9.7. addressed further in Section 9.7.
7.3. Traffic Key Establishment and Duration Issues 7.3. Traffic Key Establishment and Duration Issues
The TCP-AO option does not provide a mechanism for traffic key TCP-AO does not provide a mechanism for traffic key negotiation or
negotiation or parameter negotiation (MAC algorithm, length, or use parameter negotiation (MAC algorithm, length, or use of TCP-AO on a
of the TCP-AO option), or for coordinating rekeying during a connection), or for coordinating rekeying during a connection. We
connection. We assume out-of-band mechanisms for MKT establishment, assume out-of-band mechanisms for MKT establishment, parameter
parameter negotiation, and rekeying. This separation of MKT use from negotiation, and rekeying. This separation of MKT use from MKT
MKT management is similar to that in the IPsec security suite management is similar to that in the IPsec security suite
[RFC4301][RFC4306]. [RFC4301][RFC4306].
We encourage users of TCP-AO to apply known techniques for generating We encourage users of TCP-AO to apply known techniques for generating
appropriate MKTs, including the use of reasonable master key lengths, appropriate MKTs, including the use of reasonable master key lengths,
limited traffic key sharing, and limiting the duration of MKT use limited traffic key sharing, and limiting the duration of MKT use
[RFC3562]. This also includes the use of per-connection nonces, as [RFC3562]. This also includes the use of per-connection nonces, as
suggested in Section 7.2. suggested in Section 7.2.
TCP-AO supports rekeying in which new MKTs are negotiated and TCP-AO supports rekeying in which new MKTs are negotiated and
coordinated out-of-band, either via a protocol or a manual procedure coordinated out-of-band, either via a protocol or a manual procedure
skipping to change at page 27, line 23 skipping to change at page 27, line 41
TCP-AO requires the TCP user interface be extended to allow the MKTs TCP-AO requires the TCP user interface be extended to allow the MKTs
to be configured, as well as to allow an ongoing connection to manage to be configured, as well as to allow an ongoing connection to manage
which MKTs are active. The MKTs need to be configured prior to which MKTs are active. The MKTs need to be configured prior to
connection establishment, and the set of MKTs may change during a connection establishment, and the set of MKTs may change during a
connection: connection:
>> TCP OPEN, or the sequence of commands that configure a connection >> TCP OPEN, or the sequence of commands that configure a connection
to be in the active or passive OPEN state, MUST be augmented so that to be in the active or passive OPEN state, MUST be augmented so that
a MKT can be configured. a MKT can be configured.
>> A TCP-AO implmentation MUST allow the set of MKTs for ongoing TCP >> A TCP-AO implementation MUST allow the set of MKTs for ongoing TCP
connections (i.e., not in the CLOSED state) to be modified. connections (i.e., not in the CLOSED state) to be modified.
The MKTs associated with a connection needs to be available for The MKTs associated with a connection needs to be available for
confirmation; this includes the ability to read the MKTs: confirmation; this includes the ability to read the MKTs:
>> TCP STATUS SHOULD be augmented to allow the MKTs of a current or >> TCP STATUS SHOULD be augmented to allow the MKTs of a current or
pending connection to be read (for confirmation). pending connection to be read (for confirmation).
Senders may need to be able to determine when the outgoing MKT Senders may need to be able to determine when the outgoing MKT
changes (KeyID) or when a new preferred MKT (RNextKeyID) is changes (KeyID) or when a new preferred MKT (RNextKeyID) is
skipping to change at page 28, line 27 skipping to change at page 28, line 43
9.3. TCP Segments 9.3. TCP Segments
TCP includes control (at least one of SYN, FIN, RST flags set) and TCP includes control (at least one of SYN, FIN, RST flags set) and
data (none of SYN, FIN, or RST flags set) segments. Note that some data (none of SYN, FIN, or RST flags set) segments. Note that some
control segments can include data (e.g., SYN). control segments can include data (e.g., SYN).
>> All TCP segments MUST be checked against the set of MKTs for >> All TCP segments MUST be checked against the set of MKTs for
matching TCP connection identifiers. matching TCP connection identifiers.
>> TCP segments whose TCP-AO option does not validate MUST be >> TCP segments whose TCP-AO does not validate MUST be silently
silently discarded. discarded.
>> A TCP-AO implementation MUST allow for configuration of the >> A TCP-AO implementation MUST allow for configuration of the
behavior of segments with the TCP-AO option but that do not match an behavior of segments with TCP-AO but that do not match an MKT. The
MKT. The initial default of this configuration SHOULD be to silently initial default of this configuration SHOULD be to silently accept
accept such connections. If this is not the desired case, an MKT can such connections. If this is not the desired case, an MKT can be
be included to match such connections, or the connection can indicate included to match such connections, or the connection can indicate
that TCP-AO is required. Alternately, the configuration can be that TCP-AO is required. Alternately, the configuration can be
changed to discard segments with the AO option not matching an MKT. changed to discard segments with the AO option not matching an MKT.
>> Silent discard events SHOULD be signaled to the user as a warning, >> Silent discard events SHOULD be signaled to the user as a warning,
and silent accept events MAY be signaled to the user as a warning. and silent accept events MAY be signaled to the user as a warning.
Both warnings, if available, MUST be accessible via the STATUS Both warnings, if available, MUST be accessible via the STATUS
interface. Either signal MAY be asynchronous, but if so they MUST be interface. Either signal MAY be asynchronous, but if so they MUST be
rate-limited. Either signal MAY be logged; logging SHOULD allow rate- rate-limited. Either signal MAY be logged; logging SHOULD allow rate-
limiting as well. limiting as well.
All TCP-AO processing occurs between the interface of TCP and IP; for All TCP-AO processing occurs between the interface of TCP and IP; for
incoming segments, this occurs after validation of the TCP checksum. incoming segments, this occurs after validation of the TCP checksum.
For outgoing segments, this occurs before computation of the TCP For outgoing segments, this occurs before computation of the TCP
checksum. checksum.
Note that use of the TCP-AO option is not negotiated within TCP. It Note that use of TCP-AO on a connection not negotiated within TCP. It
is the responsibility of the receiver to determine when TCP-AO is is the responsibility of the receiver to determine when TCP-AO is
required via other means (e.g., out of band, manually or with an key required via other means (e.g., out of band, manually or with an key
management protocol) and to enforce that requirement. management protocol) and to enforce that requirement.
9.4. Sending TCP Segments 9.4. Sending TCP Segments
The following procedure describes the modifications to TCP to support The following procedure describes the modifications to TCP to support
TCP-AO when a segment departs. inserting TCP-AO when a segment departs.
>> Note that TCP-AO MUST be the last TCP option processed on outgoing >> Note that TCP-AO MUST be the last TCP option processed on outgoing
segments, because its MAC calculation may include the values of other segments, because its MAC calculation may include the values of other
TCP options. TCP options.
1. Find the per-connection parameters for the segment: 1. Find the per-connection parameters for the segment:
a. If the segment is a SYN, then this is the first segment of a a. If the segment is a SYN, then this is the first segment of a
new connection. Find the matching MKT for this segment based new connection. Find the matching MKT for this segment based
on the segment's socket pair. on the segment's socket pair.
i. If there is no matching MKT, omit the TCP-AO option. i. If there is no matching MKT, omit TCP-AO. Proceed with
Proceed with transmitting the segment. transmitting the segment.
ii. If there is a matching MKT, then set the per-connection ii. If there is a matching MKT, then set the per-connection
parameters as needed (see Section 6). Proceed with the parameters as needed (see Section 6). Proceed with the
step 2. step 2.
b. If the segment is not a SYN, then determine whether TCP-AO is b. If the segment is not a SYN, then determine whether TCP-AO is
being used for the connection and use the MKT as indicated by being used for the connection and use the MKT as indicated by
the current_key value from the per-connection parameters (see the current_key value from the per-connection parameters (see
Section 6) and proceed with the step 2. Section 6) and proceed with the step 2.
2. Using the per-connection parameters: 2. Using the per-connection parameters:
a. Augment the TCP header with the TCP-AO, inserting the a. Augment the TCP header with TCP-AO, inserting the appropriate
appropriate Length and KeyID based on the MKT indicated by Length and KeyID based on the MKT indicated by current_key
current_key (using the current_key MKT's SendID as the TCP-AO (using the current_key MKT's SendID as the TCP-AO KeyID).
KeyID). Update the TCP header length accordingly. Update the TCP header length accordingly.
b. Determine SND.SNE as described in Section 8.2. b. Determine SND.SNE as described in Section 8.2.
c. Determine the appropriate traffic key, i.e., as pointed to by c. Determine the appropriate traffic key, i.e., as pointed to by
current_key (as noted in Section 8.1, and as probably cached current_key (as noted in Section 8.1, and as probably cached
in the TCB). I.e., use the send_SYN_traffic_key for SYN in the TCB). I.e., use the send_SYN_traffic_key for SYN
segments, and the send_other_traffic_key for other segments. segments, and the send_other_traffic_key for other segments.
d. Determine the RNextKeyID as indicated by the rnext_key d. Determine the RNextKeyID as indicated by the rnext_key
pointer, and insert it in the TCP-AO option (using the pointer, and insert it in the TCP-AO RNextKeyID field (using
rnext_key MKT's RecvID as the TCP-AO KeyID) (as noted in the rnext_key MKT's RecvID as the TCP-AO KeyID) (as noted in
Section 8.1). Section 8.1).
e. Compute the MAC using the MKT (and cached traffic key) and e. Compute the MAC using the MKT (and cached traffic key) and
data from the segment as specified in Section 7.1. data from the segment as specified in Section 7.1.
f. Insert the MAC in the TCP-AO MAC field. f. Insert the MAC in the TCP-AO MAC field.
g. Proceed with transmitting the segment. g. Proceed with transmitting the segment.
9.5. Receiving TCP Segments 9.5. Receiving TCP Segments
skipping to change at page 30, line 29 skipping to change at page 30, line 43
The following procedure describes the modifications to TCP to support The following procedure describes the modifications to TCP to support
TCP-AO when a segment arrives. TCP-AO when a segment arrives.
>> Note that TCP-AO MUST be the first TCP option processed on >> Note that TCP-AO MUST be the first TCP option processed on
incoming segments, because its MAC calculation may include the values incoming segments, because its MAC calculation may include the values
of other TCP options which could change during TCP option processing. of other TCP options which could change during TCP option processing.
This also protects the behavior of all other TCP options from the This also protects the behavior of all other TCP options from the
impact of spoofed segments or modified header information. impact of spoofed segments or modified header information.
>> Note that TCP-AO checks MUST be performed for all incoming SYNs to >> Note that TCP-AO checks MUST be performed for all incoming SYNs to
avoid accepting SYNs lacking the TCP-AO option where required. Other avoid accepting SYNs lacking TCP-AO where required. Other segments
segments can cache whether TCP-AO is needed in the TCB. can cache whether TCP-AO is needed in the TCB.
1. Find the per-connection parameters for the segment: 1. Find the per-connection parameters for the segment:
a. If the segment is a SYN, then this is the first segment of a a. If the segment is a SYN, then this is the first segment of a
new connection. Find the matching MKT for this segment, using new connection. Find the matching MKT for this segment, using
the segment's socket pair and its TCP-AO KeyID, matched the segment's socket pair and its TCP-AO KeyID, matched
against the MKT's TCP connection identifier and the MKT's against the MKT's TCP connection identifier and the MKT's
RecvID. RecvID.
i. If there is no matching MKT, remove the TCP-AO option i. If there is no matching MKT, remove TCP-AO from the
from the segment. Proceed with further TCP handling of segment. Proceed with further TCP handling of the
the segment. segment.
NOTE: this presumes that connections that do not match NOTE: this presumes that connections that do not match
any MKT should be silently accepted, as noted in Sec 9.3. any MKT should be silently accepted, as noted in Sec 9.3.
ii. If there is a matching MKT, then set the per-connection ii. If there is a matching MKT, then set the per-connection
parameters as needed (see Section 6). Proceed with the parameters as needed (see Section 6). Proceed with the
step 2. step 2.
2. Using the per-connection parameters: 2. Using the per-connection parameters:
skipping to change at page 32, line 13 skipping to change at page 32, line 32
the MAC algorithms, e.g., by using a computation algorithm that the MAC algorithms, e.g., by using a computation algorithm that
prepends a fixed value to the computed portion and a corresponding prepends a fixed value to the computed portion and a corresponding
validation algorithm that verifies the fixed value before investing validation algorithm that verifies the fixed value before investing
in the computed portion. Such optimizations would be contained in the in the computed portion. Such optimizations would be contained in the
MAC algorithm specification, and thus are not specified in TCP-AO MAC algorithm specification, and thus are not specified in TCP-AO
explicitly. Note that the KeyID cannot be used for connection explicitly. Note that the KeyID cannot be used for connection
validation per se, because it is not assumed random. validation per se, because it is not assumed random.
9.6. Impact on TCP Header Size 9.6. Impact on TCP Header Size
The TCP-AO option, using the initially required 96-bit MACs, uses a TCP-AO, using the initially required 96-bit MACs, uses a total of 16
total of 16 bytes of TCP header space [Le09]. TCP-AO is thus 2 bytes bytes of TCP header space [Le09]. TCP-AO is thus 2 bytes smaller than
smaller than the TCP MD5 option (18 bytes). the TCP MD5 option (18 bytes).
Note that TCP option space is most critical in SYN segments, because Note that TCP option space is most critical in SYN segments, because
flags in those segments could potentially increase the option space flags in those segments could potentially increase the option space
area in other segments. Because TCP ignores unknown segments, area in other segments. Because TCP ignores unknown segments,
however, it is not possible to extend the option space of SYNs however, it is not possible to extend the option space of SYNs
without breaking backward-compatibility. without breaking backward-compatibility.
TCP's 4-bit data offset requires that the options end 60 bytes (15 TCP's 4-bit data offset requires that the options end 60 bytes (15
32-bit words) after the header begins, including the 20-byte header. 32-bit words) after the header begins, including the 20-byte header.
This leaves 40 bytes for options, of which 15 are expected in current This leaves 40 bytes for options, of which 15 are expected in current
skipping to change at page 33, line 28 skipping to change at page 33, line 46
thus its traffic keys. thus its traffic keys.
It is important that implementations are capable of detecting It is important that implementations are capable of detecting
excesses of TCP connections in such a configuration and can clear excesses of TCP connections in such a configuration and can clear
them out if needed to protect its memory usage [Ba09]. To protect them out if needed to protect its memory usage [Ba09]. To protect
against such state from accumulating and not being cleared out, a against such state from accumulating and not being cleared out, a
number of recommendations are made: number of recommendations are made:
>> Connections using TCP-AO SHOULD also use TCP keepalives [RFC1122]. >> Connections using TCP-AO SHOULD also use TCP keepalives [RFC1122].
The use of keepalives ensures that connections whose keys are lost The use of TCP keepalives ensures that connections whose keys are
are terminated after a finite time. Keepalives help ensure the TCP lost are terminated after a finite time; a similar effect can be
state is cleared out in such a case; the alternative, of allowing achieved at the application layer, e.g., with BGP keepalives
[RFC4271]. Either kind of keepalive helps ensure the TCP state is
cleared out in such a case; the alternative, of allowing
unauthenticated RSTs to be received, would allow one of the primary unauthenticated RSTs to be received, would allow one of the primary
vulnerabilities that TCP-AO is intended to protect against. vulnerabilities that TCP-AO is intended to protect against.
Keepalives ensure that connections are dropped across reboots, but Keepalives ensure that connections are dropped across reboots, but
this can have a detrimental effect on some protocols. In specific, this can have a detrimental effect on some protocols. In specific,
BGP reacts poorly to such connection drops; "graceful restart" was BGP reacts poorly to such connection drops, even if caused by the use
introduced to address this effect [RFC4724], and extended to support of BGP keepalives; "graceful restart" was introduced to address this
BGP with MPLS [RFC4781]. As a result: effect [RFC4724], and extended to support BGP with MPLS [RFC4781]. As
a result:
>> BGP connections SHOULD require support for graceful restart when >> BGP connections SHOULD require support for graceful restart when
using TCP-AO. using TCP-AO.
We recognize that support for graceful restart is not always We recognize that support for graceful restart is not always
feasible. As a result: feasible. As a result:
>> When BGP without graceful restart is used with TCP-AO, both sides >> When BGP without graceful restart is used with TCP-AO, both sides
of the connection SHOULD save traffic keys in storage that persists of the connection SHOULD save traffic keys in storage that persists
across reboots and restore them after a reboot, and SHOULD limit any across reboots and restore them after a reboot, and SHOULD limit any
skipping to change at page 34, line 22 skipping to change at page 34, line 42
requires, and these are made possible because TCP-AO operates inside requires, and these are made possible because TCP-AO operates inside
the context of a TCP connection. the context of a TCP connection.
IPsec makes recommendations regarding dropping ICMPs in certain IPsec makes recommendations regarding dropping ICMPs in certain
contexts, or requiring that they are endpoint authenticated in others contexts, or requiring that they are endpoint authenticated in others
[RFC4301]. There are other mechanisms proposed to reduce the impact [RFC4301]. There are other mechanisms proposed to reduce the impact
of ICMP attacks by further validating ICMP contents and changing the of ICMP attacks by further validating ICMP contents and changing the
effect of some messages based on TCP state, but these do not provide effect of some messages based on TCP state, but these do not provide
the level of authentication for ICMP that TCP-AO provides for TCP the level of authentication for ICMP that TCP-AO provides for TCP
[Go09]. As a result, we recommend a conservative approach to [Go09]. As a result, we recommend a conservative approach to
accepting ICMP attacks as summarized in [Go09]: accepting ICMP messages as summarized in [Go09]:
>> A TCP-AO implementation MUST default to ignore incoming ICMP >> A TCP-AO implementation MUST default to ignore incoming ICMPv4
messages of Type 3 (destination unreachable) Codes 2-4 (protocol messages of Type 3 (destination unreachable) Codes 2-4 (protocol
unreachable, port unreachable, and fragmentation needed - 'hard unreachable, port unreachable, and fragmentation needed - 'hard
errors') intended for connections that match MKTs. errors') and ICMPv6 Type 1 (destination unreachable) Code 1
(administratively prohibited) and Code 4 (port unreachable) intended
for connections in synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-
WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT) that match MKTs.
>> A TCP-AO implementation SHOULD allow whether such ICMPs are >> A TCP-AO implementation SHOULD allow whether such ICMPs are
ignored to be configured on a per-connection basis. ignored to be configured on a per-connection basis.
>> A TCP-AO implementation SHOULD implement measures to protect ICMP >> A TCP-AO implementation SHOULD implement measures to protect ICMP
"packet too big" messages, some examples of which are discussed in "packet too big" messages, some examples of which are discussed in
[Go09] [Go09]
>> An implementation SHOULD allow ignored ICMPs to be logged. >> An implementation SHOULD allow ignored ICMPs to be logged.
This control affects only ICMPs that currently require 'hard errors', This control affects only ICMPs that currently require 'hard errors',
which would abort the TCP connection [RFC1122]. This recommendation which would abort the TCP connection [RFC1122]. This recommendation
is intended to be similar to how IPsec would handle those messages, is intended to be similar to how IPsec would handle those messages,
with an additional default assumed [RFC4301]. with an additional default assumed [RFC4301].
10. Obsoleting TCP MD5 and Legacy Interactions 10. Obsoleting TCP MD5 and Legacy Interactions
TCP-AO obsoletes TCP MD5. As we have noted earlier: TCP-AO obsoletes TCP MD5. As we have noted earlier:
>> TCP implementations MUST support TCP-AO. >> TCP implementations that support TCP MD5 MUST support TCP-AO.
Systems implementing TCP MD5 only are considered legacy, and ought to Systems implementing TCP MD5 only are considered legacy, and ought to
be upgraded when possible. In order to support interoperation with be upgraded when possible. In order to support interoperation with
such legacy systems until upgrades are available: such legacy systems until upgrades are available:
>> TCP MD5 SHOULD be supported where interactions with legacy systems >> TCP MD5 SHOULD be supported where interactions with legacy systems
is needed. is needed.
>> A system that supports both TCP-AO and TCP MD5 MUST use TCP-AO for >> A system that supports both TCP-AO and TCP MD5 MUST use TCP-AO for
connections unless not supported by its peer, at which point it MAY connections unless not supported by its peer, at which point it MAY
skipping to change at page 36, line 13 skipping to change at page 36, line 38
ignore TCP options. ignore TCP options.
11.2. Interactions with NAT/NAPT Devices 11.2. Interactions with NAT/NAPT Devices
TCP-AO cannot interoperate natively across NAT/NAPT devices, which TCP-AO cannot interoperate natively across NAT/NAPT devices, which
modify the IP addresses and/or port numbers. We anticipate that modify the IP addresses and/or port numbers. We anticipate that
traversing such devices may require variants of existing NAT/NAPT traversing such devices may require variants of existing NAT/NAPT
traversal mechanisms, e.g., encapsulation of the TCP-AO-protected traversal mechanisms, e.g., encapsulation of the TCP-AO-protected
segment in another transport segment (e.g., UDP), as is done in IPsec segment in another transport segment (e.g., UDP), as is done in IPsec
[RFC2663][RFC3947]. Such variants can be adapted for use with TCP-AO, [RFC2663][RFC3947]. Such variants can be adapted for use with TCP-AO,
or IPsec NAT traversal can be used instead in such cases [RFC3947]. or IPsec with NAT traversal can be used instead of TCP-AO in such
cases [RFC3947].
An alternate proposal for accommodating NATs extends TCP-AO An alternate proposal for accommodating NATs extends TCP-AO
independently of this specification [To10]. independently of this specification [To10].
12. Evaluation of Requirements Satisfaction 12. Evaluation of Requirements Satisfaction
TCP-AO satisfies all the current requirements for a revision to TCP TCP-AO satisfies all the current requirements for a revision to TCP
MD5, as summarized below [Be07]. MD5, as summarized below [Be07].
1. Protected Elements 1. Protected Elements
skipping to change at page 37, line 35 skipping to change at page 38, line 26
specified in the MKT). See Section 4.2. specified in the MKT). See Section 4.2.
b. Allow optional per connection. b. Allow optional per connection.
The option should not be required on every connection; it The option should not be required on every connection; it
should be optional on a per connection basis. should be optional on a per connection basis.
This is supported because the set of MKTs can be installed to This is supported because the set of MKTs can be installed to
match some connections and not others. Connections not match some connections and not others. Connections not
matching any MKT do not require TCP-AO. Further, incoming matching any MKT do not require TCP-AO. Further, incoming
segments containing the TCP-AO option are not discarded solely segments with TCP-AO are not discarded solely because they
because they include the option, provided they do not match include the option, provided they do not match any MKT.
any MKT.
c. Require non-optional. c. Require non-optional.
The option should be able to be specified as required for a The option should be able to be specified as required for a
given connection. given connection.
This is supported because the set of MKTs can be installed to This is supported because the set of MKTs can be installed to
match some connections and not others. Connections matching match some connections and not others. Connections matching
any MKT require TCP-AO. any MKT require TCP-AO.
skipping to change at page 38, line 20 skipping to change at page 39, line 12
This is supported - see Section 4.2. This is supported - see Section 4.2.
e. Compatible with Large Windows and SACK. e. Compatible with Large Windows and SACK.
The option should be compatible with the use of the Large The option should be compatible with the use of the Large
Windows and SACK options. Windows and SACK options.
This is supported - see Section 9.6. The size of the option is This is supported - see Section 9.6. The size of the option is
intended to allow use with Large Windows and SACK. See also intended to allow use with Large Windows and SACK. See also
Section 2.2, which indicates that TCP-AO is 2 bytes shorter Section 3.2, which indicates that TCP-AO is 2 bytes shorter
than TCP MD5 in the default case, assuming a 96-bit MAC. than TCP MD5 in the default case, assuming a 96-bit MAC.
3. Cryptography requirements 3. Cryptography requirements
A solution to revising TCP MD5 should support modern cryptography A solution to revising TCP MD5 should support modern cryptography
capabilities. capabilities.
a. Baseline defaults. a. Baseline defaults.
The option should have a default that is required in all The option should have a default that is required in all
skipping to change at page 42, line 33 skipping to change at page 43, line 23
TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets
typically occur after peer crashes, either in response to new typically occur after peer crashes, either in response to new
connection attempts or when data is sent on stale connections; in connection attempts or when data is sent on stale connections; in
either case, the recovering endpoint may lack the connection key either case, the recovering endpoint may lack the connection key
required (e.g., if lost during the crash). This may result in time- required (e.g., if lost during the crash). This may result in time-
outs, rather than more responsive recovery after such a crash. outs, rather than more responsive recovery after such a crash.
Recommendations for mitigating this effect are discussed in Section Recommendations for mitigating this effect are discussed in Section
9.7. 9.7.
TCP-AO does not include a fast decline capability, e.g., where a SYN- TCP-AO does not include a fast decline capability, e.g., where a SYN-
ACK is received without an expected TCP-AO option and the connection ACK is received without an expected TCP-AO and the connection is
is quickly reset or aborted. Normal TCP operation will retry and quickly reset or aborted. Normal TCP operation will retry and
timeout, which is what should be expected when the intended receiver timeout, which is what should be expected when the intended receiver
is not capable of the TCP variant required anyway. Backoff is not is not capable of the TCP variant required anyway. Backoff is not
optimized because it would present an opportunity for attackers on optimized because it would present an opportunity for attackers on
the wire to abort authenticated connection attempts by sending the wire to abort authenticated connection attempts by sending
spoofed SYN-ACKs without the TCP-AO option. spoofed SYN-ACKs without TCP-AO.
TCP-AO is intended to provide similar protections to IPsec, but is TCP-AO is intended to provide similar protections to IPsec, but is
not intended to replace the use of IPsec or IKE either for more not intended to replace the use of IPsec or IKE either for more
robust security or more sophisticated security management. TCP-AO is robust security or more sophisticated security management. TCP-AO is
intended to protect the TCP protocol itself from attacks that TLS, intended to protect the TCP protocol itself from attacks that TLS,
sBGP/soBGP, and other data stream protection mechanism cannot. Like sBGP/soBGP, and other data stream protection mechanism cannot. Like
IPsec, TCP-AO does not address the overall issue of ICMP attacks on IPsec, TCP-AO does not address the overall issue of ICMP attacks on
TCP, but does limit the impact of ICMPs, as noted in Section 9.8. TCP, but does limit the impact of ICMPs, as noted in Section 9.8.
TCP-AO includes the TCP connection ID (the socket pair) in the MAC TCP-AO includes the TCP connection ID (the socket pair) in the MAC
skipping to change at page 43, line 38 skipping to change at page 44, line 30
authentic replays could affect TCP congestion control [Sa99]. TCP-AO authentic replays could affect TCP congestion control [Sa99]. TCP-AO
does not protect TCP congestion control from this last form of attack does not protect TCP congestion control from this last form of attack
due to the cumbersome nature of layering a windowed security sequence due to the cumbersome nature of layering a windowed security sequence
number within TCP in addition to TCP's own sequence number; when such number within TCP in addition to TCP's own sequence number; when such
protection is desired, users are encouraged to apply IPsec instead. protection is desired, users are encouraged to apply IPsec instead.
Further, it is not useful to validate TCP's Sequence Number before Further, it is not useful to validate TCP's Sequence Number before
performing a TCP-AO authentication calculation, because out-of-window performing a TCP-AO authentication calculation, because out-of-window
segments can still cause valid TCP protocol actions (e.g., ACK segments can still cause valid TCP protocol actions (e.g., ACK
retransmission) [RFC793]. It is similarly not useful to add a retransmission) [RFC793]. It is similarly not useful to add a
separate Sequence Number field to the TCP-AO option, because doing so separate Sequence Number field to TCP-AO, because doing so could
could cause a change in TCP's behavior even when segments are valid. cause a change in TCP's behavior even when segments are valid.
14. IANA Considerations 14. IANA Considerations
[NOTE: This section be removed prior to publication as an RFC] [Paragraphs below in braces should be removed by the RFC Editor upon
publication]
The TCP-AO option defines no new namespaces. [TCP-AO requires that IANA allocate a value from the TCP option Kind
namespace, to be replaced for TCP-IANA-KIND throughout this
document.]
The TCP-AO option requires that IANA allocate a value from the TCP [The entry for the TCP MD5 option should be listed as "Obsoleted by
option Kind namespace, to be replaced for TCP-IANA-KIND throughout TCP-AO in IANA tables.]
this document.
The TCP Authentication Option (TCP-AO) was assigned TCP option TCP-
IANA-KIND by IANA action.
This document defines no new namespaces.
To specify MAC and KDF algorithms, TCP-AO refers to a separate To specify MAC and KDF algorithms, TCP-AO refers to a separate
document that may involve IANA actions [Le09]. document that may involve IANA actions [Le09].
15. References 15. References
15.1. Normative References 15.1. Normative References
[Le09] Lebovitz, G., E. Rescorla, "Cryptographic Algorithms for [Le09] Lebovitz, G., E. Rescorla, "Cryptographic Algorithms for
TCP's Authentication Option, TCP-AO", draft-ietf-tcpm-tcp- TCP's Authentication Option, TCP-AO", draft-ietf-tcpm-tcp-
skipping to change at page 45, line 8 skipping to change at page 46, line 8
Selective Acknowledgment (SACK)-based Loss Recovery Selective Acknowledgment (SACK)-based Loss Recovery
Algorithm for TCP", RFC-3517, Proposed Standard, April Algorithm for TCP", RFC-3517, Proposed Standard, April
2003. 2003.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol,"
RFC-4306, Proposed Standard, Dec. 2005. RFC-4306, Proposed Standard, Dec. 2005.
[RFC4724] Sangli, S., E. Chen, R. Fernando, J. Scudder, Y. Rekhter, [RFC4724] Sangli, S., E. Chen, R. Fernando, J. Scudder, Y. Rekhter,
"Graceful Restart Mechanism for BGP," RFC-4724, Jan. 2007. "Graceful Restart Mechanism for BGP," RFC-4724, Jan. 2007.
[RFC4271] Rekhter, Y, T. Li, S. Hares, "A Border Gateway Protocol 4
(BGP-4)," RFC-4271, Jan. 2006.
[RFC4781] Rekhter, Y., R. Aggarwal, "Graceful Restart Mechanism for [RFC4781] Rekhter, Y., R. Aggarwal, "Graceful Restart Mechanism for
BGP with MPLS," RFC-4781, Jan. 2007. BGP with MPLS," RFC-4781, Jan. 2007.
15.2. Informative References 15.2. Informative References
[Ba09] Bashyam, M., M. Jethanandani,, A. Ramaiah "Clarification of [Ba09] Bashyam, M., M. Jethanandani,, A. Ramaiah "Clarification of
sender behaviour in persist condition," draft-ananth-tcpm- sender behaviour in persist condition," draft-ananth-tcpm-
persist-02, (work in progress), Jan. 2010. persist-02, (work in progress), Jan. 2010.
[Be07] Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem [Be07] Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem
skipping to change at page 45, line 31 skipping to change at page 46, line 34
[Bo07] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler, [Bo07] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler,
"Authentication for TCP-based Routing and Management "Authentication for TCP-based Routing and Management
Protocols," draft-bonica-tcp-auth-06, (work in progress), Protocols," draft-bonica-tcp-auth-06, (work in progress),
Feb. 2007. Feb. 2007.
[Bo09] Borman, D., "TCP Options and MSS," draft-ietf-tcpm-tcpmss- [Bo09] Borman, D., "TCP Options and MSS," draft-ietf-tcpm-tcpmss-
02, Jul. 2009. 02, Jul. 2009.
[La09] Larsen, M., F. Gont, "Port Randomization," draft-ietf- [La09] Larsen, M., F. Gont, "Port Randomization," draft-ietf-
tsvwg-port-randomization-05, Nov. 09. tsvwg-port-randomization-06, Feb. 2010.
[Go09] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- [Go09] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp-
attacks-10, (work in progress), Jan. 2010. attacks-11, (work in progress), Feb. 2010.
[Le09] Lepinski, M., S. Kent, "An Infrastructure to Support Secure [Le09] Lepinski, M., S. Kent, "An Infrastructure to Support Secure
Internet Routing," draft-ietf-sidr-arch-09, (work in Internet Routing," draft-ietf-sidr-arch-09, (work in
progress), Oct. 2009. progress), Oct. 2009.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321,
Informational, April 1992. Informational, April 1992.
[RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for [RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for
High Performance," RFC-1323, May 1992. High Performance," RFC-1323, May 1992.
 End of changes. 84 change blocks. 
198 lines changed or deleted 245 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/