draft-ietf-tcpm-tcp-auth-opt-11.txt   rfc5925.txt 
TCPM WG J. Touch
Internet Draft USC/ISI
Obsoletes: 2385 A. Mankin
Intended status: Proposed Standard Johns Hopkins Univ.
Expires: September 2010 R. Bonica
Juniper Networks
March 23, 2010
The TCP Authentication Option
draft-ietf-tcpm-tcp-auth-opt-11.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Internet Engineering Task Force (IETF) J. Touch
http://www.ietf.org/ietf/1id-abstracts.txt Request for Comments: 5925 USC/ISI
Obsoletes: 2385 A. Mankin
The list of Internet-Draft Shadow Directories can be accessed at Category: Standards Track Johns Hopkins Univ.
http://www.ietf.org/shadow.html ISSN: 2070-1721 R. Bonica
Juniper Networks
This Internet-Draft will expire on September 23, 2010. June 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal The TCP Authentication Option
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract Abstract
This document specifies the TCP Authentication Option (TCP-AO), which This document specifies the TCP Authentication Option (TCP-AO), which
obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO
specifies the use of stronger Message Authentication Codes (MACs), specifies the use of stronger Message Authentication Codes (MACs),
protects against replays even for long-lived TCP connections, and protects against replays even for long-lived TCP connections, and
provides more details on the association of security with TCP provides more details on the association of security with TCP
connections than TCP MD5. TCP-AO is compatible with either static connections than TCP MD5. TCP-AO is compatible with either a static
master key tuple (MKT) configuration or an external, out-of-band MKT Master Key Tuple (MKT) configuration or an external, out-of-band MKT
management mechanism; in either case, TCP-AO also protects management mechanism; in either case, TCP-AO also protects
connections when using the same MKT across repeated instances of a connections when using the same MKT across repeated instances of a
connection, using traffic keys derived from the MKT, and coordinates connection, using traffic keys derived from the MKT, and coordinates
MKT changes between endpoints. The result is intended to support MKT changes between endpoints. The result is intended to support
current infrastructure uses of TCP MD5, such as to protect long-lived current infrastructure uses of TCP MD5, such as to protect long-lived
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-
uses a different option identifier than TCP MD5, even though TCP-AO AO uses a different option identifier than TCP MD5, even though TCP-
and TCP MD5 are never permitted to be used simultaneously. TCP-AO 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 Status of This Memo
1. Contributors...................................................3
2. Conventions used in this document..............................4
3. Introduction...................................................4
3.1. Applicability Statement...................................5
3.2. Executive Summary.........................................6
4. The TCP Authentication Option..................................7
4.1. Review of TCP MD5 Option..................................7
4.2. The TCP Authentication Option Format......................8
5. TCP-AO Keys and Their Properties..............................10 This is an Internet Standards Track document.
5.1. Master Key Tuple.........................................10
5.2. Traffic Keys.............................................12
5.3. MKT Properties...........................................13
6. Per-Connection TCP-AO Parameters..............................14
7. Cryptographic Algorithms......................................15
7.1. MAC Algorithms...........................................15
7.2. Traffic Key Derivation Functions.........................19
7.3. Traffic Key Establishment and Duration Issues............22
7.3.1. MKT Reuse Across Socket Pairs.......................23
7.3.2. MKTs Use Within a Long-lived Connection.............23
8. Additional Security Mechanisms................................23
8.1. Coordinating Use of New MKTs.............................24
8.2. Preventing replay attacks within long-lived connections..25
9. TCP-AO Interaction with TCP...................................27
9.1. TCP User Interface.......................................27
9.2. TCP States and Transitions...............................28
9.3. TCP Segments.............................................28
9.4. Sending TCP Segments.....................................29
9.5. Receiving TCP Segments...................................30
9.6. Impact on TCP Header Size................................32
9.7. Connectionless Resets....................................33
9.8. ICMP Handling............................................34
10. Obsoleting TCP MD5 and Legacy Interactions...................35
11. Interactions with Middleboxes................................36
11.1. Interactions with non-NAT/NAPT Middleboxes..............36
11.2. Interactions with NAT/NAPT Devices......................36
12. Evaluation of Requirements Satisfaction......................36
13. Security Considerations......................................42
14. IANA Considerations..........................................44
15. References...................................................45
15.1. Normative References....................................45
15.2. Informative References..................................46
16. Acknowledgments..............................................48
1. Contributors This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This document evolved as the result of collaboration of the TCP Information about the current status of this document, any errata,
Authentication Design team (tcp-auth-dt), whose members were and how to provide feedback on it may be obtained at
(alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy, http://www.rfc-editor.org/info/rfc5925.
Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy
Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus
Westerlund. The text of this document is derived from a proposal by
Joe Touch and Allison Mankin [To06] (originally from June 2006),
which was both inspired by and intended as a counterproposal to the
revisions to TCP MD5 suggested in a document by Ron Bonica, Brian
Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07]
(originally from Sept. 2005) and in a document by Brian Weis [We05].
Russ Housley suggested L4/application layer management of the master Copyright Notice
key tuples. Steve Bellovin motivated the KeyID field. Eric Rescorla
suggested the use of TCP's initial sequence numbers (ISNs) in the
traffic key computation and SNEs to avoid replay attacks, and Brian
Weis extended the computation to incorporate the entire connection ID
and provided the details of the traffic key computation. Mark Allman,
Wes Eddy, Lars Eggert, Ted Faber, Russ Housley, Gregory Lebovitz, Tim
Polk, Eric Rescorla, Joe Touch, and Brian Weis developed the master
key coordination mechanism.
2. Conventions used in this document Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document is subject to BCP 78 and the IETF Trust's Legal
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Provisions Relating to IETF Documents
document are to be interpreted as described in RFC-2119 [RFC2119]. (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
In this document, these words will appear with that interpretation Table of Contents
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) 1. Introduction ....................................................4
indicates a compliance requirement statement using the key words 1.1. Conventions Used in This Document ..........................4
listed above. This convention aids reviewers in quickly identifying 1.2. Applicability Statement ....................................5
or finding the explicit compliance requirements of this RFC. 1.3. Executive Summary ..........................................6
2. The TCP Authentication Option ...................................7
2.1. Review of TCP MD5 Option ...................................7
2.2. The TCP Authentication Option Format .......................8
3. TCP-AO Keys and Their Properties ...............................10
3.1. Master Key Tuple ..........................................10
3.2. Traffic Keys ..............................................12
3.3. MKT Properties ............................................13
4. Per-Connection TCP-AO Parameters ...............................14
5. Cryptographic Algorithms .......................................15
5.1. MAC Algorithms ............................................15
5.2. Traffic Key Derivation Functions ..........................18
5.3. Traffic Key Establishment and Duration Issues .............22
5.3.1. MKT Reuse Across Socket Pairs ......................22
5.3.2. MKTs Use within a Long-Lived Connection ............23
6. Additional Security Mechanisms .................................23
6.1. Coordinating Use of New MKTs ..............................23
6.2. Preventing Replay Attacks within Long-Lived Connections ...24
7. TCP-AO Interaction with TCP ....................................26
7.1. TCP User Interface ........................................27
7.2. TCP States and Transitions ................................28
7.3. TCP Segments ..............................................28
7.4. Sending TCP Segments ......................................29
7.5. Receiving TCP Segments ....................................30
7.6. Impact on TCP Header Size .................................32
7.7. Connectionless Resets .....................................33
7.8. ICMP Handling .............................................34
8. Obsoleting TCP MD5 and Legacy Interactions .....................35
9. Interactions with Middleboxes ..................................35
9.1. Interactions with Non-NAT/NAPT Middleboxes ................36
9.2. Interactions with NAT/NAPT Devices ........................36
10. Evaluation of Requirements Satisfaction .......................36
11. Security Considerations .......................................42
12. IANA Considerations ...........................................43
13. References ....................................................44
13.1. Normative References .....................................44
13.2. Informative References ...................................45
14. Acknowledgments ...............................................47
3. Introduction 1. 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 7.6). This document obsoletes the TCP MD5 option with a more
general TCP Authentication Option (TCP-AO). This new option supports general TCP Authentication Option (TCP-AO). This new option supports
the use of other, stronger hash functions, provides replay protection the use of other, stronger hash functions, provides replay protection
for long-lived connections and across repeated instances of a single for long-lived connections and across repeated instances of a single
connection, coordinates key changes between endpoints, and provides a connection, coordinates key changes between endpoints, and provides a
more explicit recommendation for external key management. The result more explicit recommendation for external key management. The 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 [Ed07].
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.
3.1. Applicability Statement 1.1. 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. Lowercase 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.
1.2. 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, for
and is not designed solely or primarily for routing protocol uses. example, 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
3.2. This document recommends overall that: 1.3. This document recommends overall that:
>> TCP implementations that support TCP MD5 MUST support TCP-AO. >> TCP implementations that support TCP MD5 MUST support TCP-AO.
>> TCP-AO SHOULD be implemented where the protection afforded by TCP >> TCP-AO SHOULD be implemented where the protection afforded by TCP
authentiation is needed, either because IPsec is not supported, or authentication is needed, because either IPsec is not supported or
because TCP-AO's particular properties are needed (e.g., per- TCP-AO's particular properties are needed (e.g., per-connection
connection keys). keys).
>> TCP-AO MAY be implemented elsewhere. >> TCP-AO MAY be implemented elsewhere.
TCP-AO is not intended to replace the use of the IPsec suite (IPsec TCP-AO is not intended to replace the use of the IPsec suite (IPsec
and IKE) to protect TCP connections [RFC4301][RFC4306]. Specific and Internet Key Exchange Protocol (IKE)) to protect TCP connections
differences are noted in Section 3.2. In fact, we recommend the use [RFC4301][RFC4306]. Specific differences are noted in Section 1.3.
of IPsec and IKE, especially where IKE's level of existing support In fact, we recommend the use of IPsec and IKE, especially where
for parameter negotiation, session key negotiation, or rekeying are IKE's level of existing support for parameter negotiation, session
desired. TCP-AO is intended for use only where the IPsec suite would key negotiation, or rekeying are desired. TCP-AO is intended for use
not be feasible, e.g., as has been suggested is the case to support only where the IPsec suite would not be feasible, e.g., as has been
some routing protocols [RFC4953], or in cases where keys need to be suggested is the case to support some routing protocols [RFC4953], or
tightly coordinated with individual transport sessions [Be07]. in cases where keys need to be tightly coordinated with individual
transport sessions [Ed07].
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], Secure BGP (sBGP) or Secure Origin BGP (soBGP)
protect only the TCP data stream. TCP-AO protects the transport [Le09], or any other mechanisms that protect only the TCP data
layer, preventing attacks from disabling the TCP connection itself stream. TCP-AO protects the transport layer, preventing attacks from
[RFC4953]. Data stream mechanisms protect only the contents of the disabling the TCP connection itself [RFC4953]. Data stream
TCP segments, and can be disrupted when the connection is affected. mechanisms protect only the contents of the TCP segments, and can be
Some of these data protection protocols - notably TLS - offer a disrupted when the connection is affected. Some of these data
richer set of key management and authentication mechanisms than TCP- protection protocols -- notably TLS -- offer a richer set of key
AO, and thus protect the data stream in a different way. TCP-AO may management and authentication mechanisms than TCP-AO, and thus
be used together with these data stream protections to complement protect the data stream in a different way. TCP-AO may be used
each others' strengths. together with these data stream protections to complement each
other's strengths.
3.2. Executive Summary 1.3. 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 (TBD-IANA-KIND). o TCP-AO uses a separate option Kind (29).
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 TCP MD5's single MAC algorithm with MACs specified o TCP-AO replaces TCP MD5's single MAC algorithm with MACs specified
in 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
changeover or require trying multiple keys on each received changeover or require trying multiple keys on each received
segment during key use overlap because it lacks an explicit key segment during key use overlap because it lacks an explicit key
ID. Although TCP recovers lost segments through retransmission, ID. Although TCP recovers lost segments through retransmission,
loss can have a substantial impact on performance. loss can have a substantial impact on performance.
o TCP-AO provides automatic replay protection for long-lived o TCP-AO provides automatic replay protection for long-lived
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 TCP-AO is 2 bytes shorter than TCP MD5 (16 bytes overall, rather o TCP-AO is 2 bytes shorter than TCP MD5 (16 bytes overall, rather
than 18) in the initially specified default case (using a 96-bit than 18) in the initially specified default case (using a 96-bit
MAC). MAC).
TCP-AO differs from an IPsec/IKE solution in as follows TCP-AO differs from an IPsec/IKE solution as 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 includes 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 (together with the KeyID), rather than using a separate index (together with the KeyID), rather than using a separate
field as an index (IPsec's SPI). field as an index (IPsec's Security Parameter Index (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) [Ed07].
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).
4. The TCP Authentication Option 2. 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. The following sections describe TCP-AO and provide of 29. The following sections describe TCP-AO and provide a review
a review of TCP MD5 for comparison. of TCP MD5 for comparison.
4.1. Review of TCP MD5 Option 2.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)... |
+---------------------------------------+ +---------------------------------------+
| ... | | ... |
+---------------------------------------+ +---------------------------------------+
| ... | | ... |
+-------------------+-------------------+ +-------------------+-------------------+
| ...digest (con't) | | ...digest (con't) |
+-------------------+ +-------------------+
Figure 1 The TCP MD5 Option [RFC2385] Figure 1: The TCP MD5 Option [RFC2385]
In the TCP MD5 option, the length is fixed, and the MD5 digest In the TCP MD5 option, the length is fixed, and the MD5 digest
occupies 16 bytes following the Kind and Length fields (each one occupies 16 bytes following the Kind and Length fields (each one
byte), using the full MD5 digest of 128 bits [RFC1321]. byte), using the full MD5 digest of 128 bits [RFC1321].
The TCP MD5 option specifies the use of the MD5 digest calculation The TCP MD5 option specifies the use of the MD5 digest calculation
over the following values in the following order: over the following values in the following order:
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 Authentication Option Format 2.2. The TCP Authentication Option Format
TCP-AO provides a superset of the capabilities of TCP MD5, and is TCP-AO provides a superset of the capabilities of TCP MD5, and is
minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new Kind field, minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new Kind field,
and similar Length field to TCP MD5, a KeyID field, and a RNextKeyID and similar Length field to TCP MD5, a KeyID field, and a RNextKeyID
field as shown in Figure 2. field as shown in Figure 2.
+------------+------------+------------+------------+ +------------+------------+------------+------------+
| Kind | Length | KeyID | RNextKeyID | | Kind=29 | Length | KeyID | RNextKeyID |
+------------+------------+------------+------------+ +------------+------------+------------+------------+
| MAC ... | MAC ...
+-----------------------------------... +-----------------------------------...
...-----------------+ ...-----------------+
... MAC (con't) | ... MAC (con't) |
...-----------------+ ...-----------------+
Figure 2 The TCP Authentication Option (TCP-AO) Figure 2: The TCP Authentication Option (TCP-AO)
TCP-AO defines these fields as follows: TCP-AO defines these fields as follows:
o Kind: An unsigned 1-byte field indicating TCP-AO. TCP-AO uses a o Kind: An unsigned 1-byte field indicating TCP-AO. TCP-AO uses a
new Kind value of TBD-IANA-KIND. new Kind value of 29.
>> 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
discard the segment. silently discard the segment.
>> A single TCP segment MUST NOT have more than one TCP-AO in its >> A single TCP segment MUST NOT have more than one TCP-AO in its
options sequence. When multiple TCP-AOs appear, TCP MUST discard options sequence. When multiple TCP-AOs appear, TCP MUST discard
the segment. the segment.
o Length: An unsigned 1-byte field indicating the length of the o Length: An unsigned 1-byte field indicating the length of the
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.
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 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), options, when added to the size of the base TCP header (5 words),
matches the TCP Offset field exactly. This full verification can matches the TCP Offset field exactly. This full verification can
be computed because RFC 793 specifies the size of the required be computed because RFC 793 specifies the size of the required
options, and RFC 1122 requires that all new options follow a options, and RFC 1122 requires that all new options follow a
common format with a fixed length field location common format with a fixed-length field location
[RFC793][RFC1122]. A partial verification can be limited to check [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 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 offset from the start of the TCP header, does not exceed the TCP
header size as indicated in the TCP header Offset field. 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 master key tuple o KeyID: An unsigned 1-byte field indicating the Master Key Tuple
(MKT, as defined in Section 5.1) used to generate the traffic keys (MKT, as defined in Section 3.1) used to generate the traffic keys
which were used to generate the MAC that authenticates this that were used to generate the MAC that authenticates this
segment. 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 6.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.
This allows MKTs to be installed on a set of devices without This allows MKTs to be installed on a set of devices without
coordinating the KeyIDs across an entire in advance, and allows coordinating the KeyIDs across that entire set in advance, and
new devices to be added to the set using a group of MKTs later allows new devices to be added to that set using a group of MKTs
without requiring renumbering of KeyIDs. These two capabilities later without requiring renumbering of KeyIDs. These two
are particularly important when used with wildcards in the TCP capabilities are particularly important when used with wildcards
socket pair of the MKT, i.e., when a MKT is used among a set of in the TCP socket pair of the MKT, i.e., when an MKT is used among
devices specified by a pattern (as noted in Section 5.1). a set of devices specified by a pattern (as noted in Section 3.1).
o RNextKeyID: An unsigned 1-byte field indicating the MKT that is o RNextKeyID: An unsigned 1-byte field indicating the MKT that is
ready at the sender to be used to authenticate received segments, ready at the sender to be used to authenticate received segments,
i.e., the desired 'receive next' keyID. i.e., the desired 'receive next' key ID.
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 6.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
128 bits (12-16 bytes), but any length that fits in the header of 96-128 bits (12-16 bytes), but any length that fits in the header
the segment being authenticated is allowed. The MAC computation is of the segment being authenticated is allowed. The MAC
described further in Section 7.1. computation is described further in Section 5.1.
>> Required support for TCP-AO MACs are defined in [Le09]; other >> Required support for TCP-AO MACs is defined in [RFC5926]; other
MACs MAY be supported. MACs MAY be supported.
TCP-AO fields do not indicate the MAC algorithm either implicitly (as TCP-AO fields do not indicate the MAC algorithm either implicitly (as
with TCP MD5) or explicitly. The particular algorithm used is with TCP MD5) or explicitly. The particular algorithm used is
considered part of the configuration state of the connection's considered part of the configuration state of the connection's
security and is managed separately (see Section 5). security and is managed separately (see Section 3).
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 TCP-AO is handled and its The remainder of this document explains how TCP-AO is handled and its
relationship to TCP. relationship to TCP.
5. TCP-AO Keys and Their Properties 3. 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
calculation. Traffic keys are the keying material used to compute the calculation. Traffic keys are the keying material used to compute
MAC of individual TCP segments. the MAC of individual TCP segments.
5.1. Master Key Tuple 3.1. Master Key Tuple
A Master Key Tuple (MKT) describes TCP-AO properties to be associated A Master Key Tuple (MKT) describes TCP-AO properties to be associated
with one or more connections. It is composed of the following: with one or more connections. It is composed of the following:
o TCP connection identifier. A TCP socket pair, i.e., a local IP o TCP connection identifier. A TCP socket pair, i.e., a local IP
address, a remote IP address, a TCP local port, and a TCP remote address, a remote IP address, a TCP local port, and a TCP remote
port. Values can be partially specified using ranges (e.g., 2-30), port. Values can be partially specified using ranges (e.g.,
masks (e.g., 0xF0), wildcards (e.g., "*"), or any other suitable 2-30), masks (e.g., 0xF0), wildcards (e.g., "*"), or any other
indication. suitable indication.
o TCP option flag. This flag indicates whether TCP options other o TCP option flag. This flag indicates whether TCP options other
than TCP-AO are included in the MAC calculation. When options are than TCP-AO are included in the MAC calculation. When options are
included, the content of all options, in the order present, are included, the content of all options, in the order present, is
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 TCP-AO; used to o IDs. The values used in the KeyID or RNextKeyID of TCP-AO; used
differentiate MKTs in concurrent use (KeyID), as well as to to differentiate MKTs in concurrent use (KeyID), as well as to
indicate when MKTs are ready for use in the opposite direction indicate when MKTs are ready for use in the opposite 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-AO option of outgoing segments,
and the RecvID is matched against the TCP-AO KeyID of incoming and the RecvID is matched against the TCP-AO KeyID of incoming
segments. These and other uses of these two IDs are described segments. These and other uses of these two IDs are described
further in Section 9.4 and 9.5. further in Sections 7.4 and 7.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, i.e., the values are not ID values are assigned arbitrarily, i.e., the values are not
monotonically increasing, have no reserved values, and are monotonically increasing, have no reserved values, and are
otherwise not meaningful. They can be assigned in sequence, or otherwise not meaningful. They can be assigned in sequence, or
based on any method mutually agreed by the connection endpoints based on any method mutually agreed by the connection endpoints
(e.g., using an external MKT management mechanism). (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,
may be derived from a separate shared key by an external protocol this may be derived from a separate shared key by an external
over a separate channel. This sequence is used in the traffic key protocol over a separate channel. This sequence is used in the
generation algorithm described in Section 7.2. traffic key generation algorithm described in Section 5.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.
o Key Derivation Function (KDF). Indicates the key derivation o Key Derivation Function (KDF). Indicates the key derivation
function and its parameters, as used to generate traffic keys from function and its parameters, as used to generate traffic keys from
master keys. Explained further in Section 7.1 of this document and master keys. It is explained further in Section 5.2 of this
specified in detail in [Le09]. document and specified in detail in [RFC5926].
o Message Authentication Code (MAC) algorithm. Indicates the MAC o Message Authentication Code (MAC) algorithm. Indicates the MAC
algorithm and its parameters as used for this connection, algorithm and its parameters as used for this connection. It is
explained further in Section 7.1 of this document and specified in explained further in Section 5.1 of this document and specified in
detail in [Le09]. detail in [RFC5926].
>> Components of a MKT MUST NOT change during a connection. >> Components of an MKT MUST NOT change during a connection.
MKT component values cannot change during a connection because TCP MKT component values cannot change during a connection because TCP
state is coordinated during connection establishment. TCP lacks a state is coordinated during connection establishment. TCP lacks a
handshake for modifying that state after a connection has been handshake for modifying that state after a connection has been
established. established.
>> The set of MKTs MAY change during a connection. >> The set of MKTs MAY change during a connection.
MKT parameters are not changed. Instead, new MKTs can be installed, MKT parameters are not changed. Instead, new MKTs can be installed,
and a connection can change which MKT it uses. and a connection can change which MKT it uses.
>> The IDs of MKTs MUST NOT overlap where their TCP connection >> The IDs of MKTs MUST NOT overlap where their TCP connection
identifiers overlap. identifiers overlap.
This document does not address how MKTs are created by users or This document does not address how MKTs are created by users or
processes. It is presumed that a MKT affecting a particular processes. It is presumed that an MKT affecting a particular
connection cannot be destroyed during an active connection - or, connection cannot be destroyed during an active connection -- or,
equivalently, that its parameters are copied to an area local to the equivalently, that its parameters are copied to an area local to the
connection (i.e., instantiated) and so changes would affect only new connection (i.e., instantiated) and so changes would affect only new
connections. The MKTs can be managed by a separate application connections. The MKTs can be managed by a separate application
protocol. protocol.
5.2. Traffic Keys 3.2. Traffic Keys
A traffic key is a key derived from the MKT and the local and remote A traffic key is a key derived from the MKT and the local and remote
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
'simultaneous open' [RFC793]. through 'simultaneous open' [RFC793].
The relationship between MKTs and traffic keys is shown in Figure 3. The relationship between MKTs and traffic keys is shown in Figure 3.
Traffic keys are indicated with a "*". Note that every MKT can be Traffic keys are indicated with a "*". Note that every MKT 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 5.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 |
| * Recv_Other_key | | * Recv_Other_key | | * Recv_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 3.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
match occurs, TCP-AO is not used. Multiple MKTs may match a single no match occurs, TCP-AO is not used. Multiple MKTs may match a
outgoing segment, e.g., when MKTs are being changed. Those MKTs single outgoing segment, e.g., when MKTs are being changed. Those
cannot have conflicting IDs (as noted elsewhere), and some mechanism MKTs cannot have conflicting IDs (as noted elsewhere), and some
must determine which MKT to use for each given outgoing segment. mechanism must determine which MKT to use for each given outgoing
segment.
>> 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 options other than TCP-AO are ignored in the MKTs may indicate that options other than TCP-AO are ignored in the
MAC 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 including TCP-AO MUST match exactly one >> An incoming TCP segment including TCP-AO MUST match exactly one
MKT, indicated solely by the segment's socket pair and its TCP-AO MKT, indicated solely by the segment's socket pair and its TCP-AO
KeyID. KeyID.
Incoming segments include an indicator inside TCP-AO to select from Incoming segments include an indicator inside TCP-AO to select from
among multiple matching MKTs - the KeyID field. TCP-AO requires that among multiple matching MKTs -- the KeyID field. TCP-AO requires
the KeyID alone be used to differentiate multiple matching MKTs, so that the KeyID alone be used to differentiate multiple matching MKTs,
that MKT changes can be coordinated using the TCP-AO key change so 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 4. 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 TCP-AO, once instantiated. These values can be connection that uses TCP-AO, once instantiated. These values can be
stored in the Transport Control Block (TCP) [RFC793]. These values stored in the Transport Control Block (TCB) [RFC793]. These values
are explained in subsequent sections of this document as noted; they are explained in subsequent sections of this document as 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 7.4, step 2.f). Incoming segments are authenticated
using the MKT corresponding to the segment and its TCP-AO KeyID using the MKT corresponding to the segment and its TCP-AO KeyID
(see Section 9.5, step 5), as matched against the MKT TCP (see Section 7.5, step 2.c), as matched against the MKT TCP
connection identifier and the MKT RecvID. There is only one connection identifier and the MKT RecvID. There is only 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 7.4, step 2.d).
>> 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.
3. A pair of Sequence Numbers Extensions (SNEs). SNEs are used to 3. A pair of Sequence Number Extensions (SNEs). SNEs are used to
prevent replay attacks, as described in Section 8.2. Each SNE is prevent replay attacks, as described in Section 6.2. Each SNE is
initialized to zero upon connection establishment. Its use in the initialized to zero upon connection establishment. Its use in the
MAC calculation is described in Section 7.1. MAC calculation is described in Section 5.1.
4. One or more MKTs. These are the MKTs that match this connection's 4. One or more MKTs. These are the MKTs that match this connection's
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 5.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.
can be considered part of the per-connection parameters. They can be considered part of the per-connection parameters.
7. Cryptographic Algorithms 5. Cryptographic Algorithms
TCP-AO uses cryptographic algorithms to compute the MAC (Message TCP-AO uses cryptographic algorithms to compute the MAC (Message
Authentication Code) that is used to authenticate a segment and its Authentication Code) that is used to authenticate a segment and its
headers; these are called MAC algorithms and are specified in a headers; these are called MAC algorithms and are specified in a
separate 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 [RFC5926]. 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 [RFC5926].
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 5.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
input comes from a source with that same key, and whether the input input comes from a source with that same key, and whether the input
has been tampered in transit. MACs for TCP-AO have the following has been tampered with in transit. MACs for TCP-AO have the
interface: following interface:
MAC = MAC_alg(traffic_key, message) MAC = MAC_alg(traffic_key, message)
INPUT: MAC_alg, traffic_key, message INPUT: MAC_alg, traffic_key, message
OUTPUT: MAC OUTPUT: MAC
where: where:
o MAC_alg - the specific MAC algorithm used for this computation. o MAC_alg - the specific MAC algorithm used for this computation.
The MAC algorithm specifies the output length, so no separate The MAC algorithm specifies the output length, so no separate
output length parameter is required. This is specified as output length parameter is required. This is specified as
described in [Le09]. described in [RFC5926].
o Traffic_key - traffic key used for this computation. This is o Traffic_key - traffic key used for this computation. This is
computed from the connection's current MKT as described in Section computed from the connection's current MKT as described in Section
7.2. 5.2.
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 5.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 [RFC5926], are each truncated to 96 bits.
the algorithms each output a larger MAC, 96 bits provides a Though the algorithms each output a larger MAC, 96 bits provides a
reasonable tradeoff between security and message size. Though could reasonable trade-off between security and message size. However,
change in the future, so TCP-AO size should not be assumed as fixed this could change in the future, so TCP-AO size should not be assumed
length. as fixed 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 the definition in [RFC5926].
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 [RFC5926]. This allows the TCP-AO
specification to proceed along the IETF standards track even if specification to proceed along the IETF Standards Track even if
changes are needed to its associated algorithms and their labels (as changes are needed to its associated algorithms and their labels (as
might be used in a user interface or automated MKT management might be used in a user interface or automated MKT management
protocol) as a 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 in 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 6.2):
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| SNE | | SNE |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 4 Sequence number extension Figure 4: Sequence Number Extension
The SNE for transmitted segments is maintained locally in the The SNE for transmitted segments is maintained locally in the
SND.SNE value; for received segments, a local RCV.SNE value is SND.SNE value; for received segments, a local RCV.SNE value is
used. The details of how these values are maintained and used is used. The details of how these values are maintained and used are
described in Sections 8.2, 9.4, and 9.5. in Sections 6.2, 7.4, and 7.5.
2. The IP pseudoheader: IP source and destination addresses, protocol 2. The IP pseudoheader: IP source and destination addresses, protocol
number and segment length, all in network byte order, prepended to number, and segment length, all in network byte order, prepended
the TCP header below. The IP pseudoheader is exactly as used for to the TCP header below. The IP pseudoheader is exactly as used
the TCP checksum in either IPv4 or IPv6 [RFC793][RFC2460]: for the TCP checksum in either IPv4 or IPv6 [RFC793][RFC2460]:
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source Address | | Source Address |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Destination Address | | Destination Address |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| zero | Proto | TCP Length | | Zero | Proto | TCP Length |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 5 TCP IPv4 pseudoheader [RFC793] Figure 5: TCP IPv4 Pseudoheader [RFC793]
+--------+--------+--------+--------+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+ +
+--------+--------+--------+--------+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+--------+--------+--------+--------+
| Upper-Layer Payload Length |
+--------+--------+--------+--------+
| zero | Next Header |
+--------+--------+--------+--------+
Figure 6 TCP IPv6 pseudoheader [RFC2460] +--------+--------+--------+--------+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+ +
+--------+--------+--------+--------+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+--------+--------+--------+--------+
| Upper-Layer Payload Length |
+--------+--------+--------+--------+
| Zero | Next Header |
+--------+--------+--------+--------+
Figure 6: TCP IPv6 Pseudoheader [RFC2460]
3. The TCP header, by default including options, and where the TCP 3. The TCP header, by default including options, and where the TCP
checksum and TCP-AO MAC fields are set to zero, all in network checksum and TCP-AO MAC fields are set to zero, all in network-
byte order. byte order.
The TCP option flag of the MKT indicates whether the TCP options The TCP option flag of the MKT indicates whether the TCP options
are included in the MAC. When included, only the TCP-AO MAC field are included in the MAC. When included, only the TCP-AO MAC field
is zeroed. is zeroed.
When TCP options are not included, all TCP options except for TCP- When TCP options are not included, all TCP options except for TCP-
AO are omitted from MAC processing. Again, the TCP-AO MAC field is AO are omitted from MAC processing. Again, the TCP-AO MAC field
zeroed for the MAC processing. is zeroed for the MAC processing.
4. The TCP data, i.e., the payload of the TCP segment. 4. The TCP data, i.e., the payload of the TCP segment.
Note that the traffic key is not included as part of the data; the Note that the traffic key is not included as part of the data; the
MAC algorithm indicates how to use the traffic key, e.g., as HMACs do MAC algorithm indicates how to use the traffic key, for example,
[RFC2104][RFC2403]. The traffic key is derived from the current MKT as HMACs do [RFC2104][RFC2403]. The traffic key is derived from
as described in Sections 7.2. the current MKT as described in Section 5.2.
7.2. Traffic Key Derivation Functions 5.2. Traffic Key Derivation Functions
TCP-AO's traffic keys are derived from the MKTs using Key Derivation TCP-AO's traffic keys are derived from the MKTs using Key Derivation
Functions (KDFs). The KDFs used in TCP-AO have the following Functions (KDFs). The KDFs used in TCP-AO have the following
interface: interface:
traffic_key = KDF_alg(master_key, context, output_length) traffic_key = KDF_alg(master_key, context, output_length)
INPUT: KDF_alg, master_key, context, output_length INPUT: KDF_alg, master_key, context, output_length
OUTPUT: traffic_key OUTPUT: traffic_key
where: where:
o KDF_alg - the specific key derivation function (KDF) that is the o KDF_alg - The specific Key Derivation Function (KDF) that is the
basic building block used in constructing the traffic key, as basic building block used in constructing the traffic key, as
indicated in the MKT. This is specified as described in [Le09]. indicated in the MKT. This is specified as described in
[RFC5926].
o Master_key - The master_key string, as will be stored into the o Master_key - The master_key string, as will be stored into the
associated MKT. associated MKT.
o Context - The context used as input in constructing the o Context - The context used as input in constructing the
traffic_key, as specified in [Le09]. The specific way this context traffic_key, as specified in [RFC5926]. The specific way this
is used, in conjunction with other information, to create the raw context is used, in conjunction with other information, to create
input to the KDF is also explained further in [Le09]. the raw input to the KDF is also explained further in [RFC5926].
o Output_length - The desired output length of the KDF, i.e., the o Output_length - The desired output length of the KDF, i.e., the
length to which the KDF's output will be truncated. This is length to which the KDF's output will be truncated. This is
specified as described in [Le09]. specified as described in [RFC5926].
o Traffic_key - The desired output of the KDF, of length o Traffic_key - The desired output of the KDF, of length
output_length, to be used as input to the MAC algorithm, as output_length, to be used as input to the MAC algorithm, as
described in Section 7.1. described in Section 5.1.
The context used as input to the KDF combines TCP socket pair with
the endpoint initial sequence numbers (ISNs) of a connection. This
data is unique to each TCP connection instance, which enables TCP-AO
to generate unique traffic keys for that connection, even from a MKT
used across many different connections or across repeated connections
that share a socket pair. Unique traffic keys are generated without
relying on external key management properties. The KDF context is
defined in Figure 7 and Figure 8.
+--------+--------+--------+--------+ The context used as input to the KDF combines the TCP socket pair
| Source Address | with the endpoint Initial Sequence Numbers (ISNs) of a connection.
+--------+--------+--------+--------+ This data is unique to each TCP connection instance, which enables
| Destination Address | TCP-AO to generate unique traffic keys for that connection, even from
+--------+--------+--------+--------+ an MKT used across many different connections or across repeated
| Source Port | Dest. Port | connections that share a socket pair. Unique traffic keys are
+--------+--------+--------+--------+ generated without relying on external key management properties. The
| Source ISN | KDF context is defined in Figures 7 and 8.
+--------+--------+--------+--------+
| Dest. ISN |
+--------+--------+--------+--------+
Figure 7 KDF Context for an IPv4 connection +--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| Source Port | Dest. Port |
+--------+--------+--------+--------+
| Source ISN |
+--------+--------+--------+--------+
| Dest. ISN |
+--------+--------+--------+--------+
+--------+--------+--------+--------+ Figure 7: KDF Context for an IPv4 Connection
| | +--------+--------+--------+--------+
+ + | |
| | + +
+ Source Address + | |
| | + Source Address +
+ + | |
| | + +
+ + | |
+--------+--------+--------+--------+ + +
| | +--------+--------+--------+--------+
+ + | |
| | + +
+ Destination Address + | |
| | + Destination Address +
+ + | |
| | + +
+--------+--------+--------+--------+ | |
| Source Port | Dest. Port | +--------+--------+--------+--------+
+--------+--------+--------+--------+ | Source Port | Dest. Port |
| Source ISN | +--------+--------+--------+--------+
+--------+--------+--------+--------+ | Source ISN |
| Dest. ISN | +--------+--------+--------+--------+
+--------+--------+--------+--------+ | Dest. ISN |
+--------+--------+--------+--------+
Figure 8 KDF Context for an IPv6 connection Figure 8: KDF Context for an IPv6 Connection
Traffic keys are directional, so "source" and "destination" are Traffic keys are directional, so "source" and "destination" are
interpreted differently for incoming and outgoing segments. For interpreted differently for incoming and outgoing segments. For
incoming segments, source is the remote side, whereas for outgoing incoming segments, source is the remote side; whereas for outgoing
segments source is the local side. This further ensures that segments, source is the local side. This further ensures that
connection keys generated for each direction are unique. connection keys generated for each direction are unique.
For SYN segments (segments with the SYN set, but the ACK not set), For SYN segments (segments with the SYN set, but the ACK not set),
the destination ISN is not known. For these segments, the connection the destination ISN is not known. For these segments, the connection
key is computed using the context shown above, in which the key is computed using the context shown above, in which the
Destination ISN value is zero. For all other segments, the ISN pair destination ISN value is zero. For all other segments, the ISN pair
is used when known. If the ISN pair is not known, e.g., when sending is used when known. If the ISN pair is not known, e.g., when sending
a RST after a reboot, the segment should be sent without a reset (RST) after a reboot, the segment should be sent without
authentication; if authentication was required, the segment cannot authentication; if authentication was required, the segment cannot
have been MAC'd properly anyway and would have been dropped on have been MAC'd properly anyway and would have been dropped on
receipt. receipt.
>> TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination >> TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination
ISN of zero (whether sent or received); all other segments use the ISN of zero (whether sent or received); all other segments use the
known ISN pair. known ISN pair.
Overall, this means that each connection will use up to four distinct Overall, this means that each connection will use up to four distinct
traffic keys for each MKT: traffic keys for each MKT:
o Send_SYN_traffic_key - the traffic key used to authenticate o Send_SYN_traffic_key - the traffic key used to authenticate
outgoing SYNs. The source ISN known (the TCP connection's local outgoing SYNs. The source ISN is known (the TCP connection's
ISN), and the destination (remote) ISN is unknown (and so the local ISN), and the destination (remote) ISN is unknown (and so
value 0 is used). the value 0 is used).
o Receive_SYN_traffic_key - the traffic key used to authenticate o Receive_SYN_traffic_key - the traffic key used to authenticate
incoming SYNs. The source ISN known (the TCP connection's remote incoming SYNs. The source ISN is known (the TCP connection's
ISN), and the destination (remote) ISN is unknown (and so the remote ISN), and the destination (remote) ISN is unknown (and so
value 0 is used). the value 0 is used).
o Send_other_traffic_key - the traffic key used to authenticate all o Send_other_traffic_key - the traffic key used to authenticate all
other outgoing TCP segments. other outgoing TCP segments.
o Receive_other_traffic_key - the traffic key used to authenticate o Receive_other_traffic_key - the traffic key used to authenticate
all other incoming TCP segments. all other incoming TCP segments.
The following table describes how each of these traffic keys is The following table describes how each of these traffic keys is
computed, where the TCP-AO algorithms refer to source (S) and computed, where the TCP-AO algorithms refer to source (S) and
destination (D) values of the IP address, TCP port, and ISN, and each destination (D) values of the IP address, TCP port, and ISN, and each
segment (incoming or outgoing) has a values that refer to the local segment (incoming or outgoing) has a value that refers to the local
side of the connection (l) and remote side (r): side of the connection (l) and remote side (r):
S-IP S-port S-ISN D-IP D-port D-ISN S-IP S-port S-ISN D-IP D-port D-ISN
---------------------------------------------------------------- ----------------------------------------------------------------
Send_SYN_traffic_key l-IP l-port l-ISN r-IP r-port 0 Send_SYN_traffic_key l-IP l-port l-ISN r-IP r-port 0
Receive_SYN_traffic_key r-IP r-port r-ISN l-IP l-port 0 Receive_SYN_traffic_key r-IP r-port r-ISN l-IP l-port 0
Send_other_traffic_key l-IP l-port l-ISN r-IP r-port r-ISN Send_other_traffic_key l-IP l-port l-ISN r-IP r-port r-ISN
Receive_other_traffic_key r-IP r-port r-ISN l-IP l-port l-ISN Receive_other_traffic_key r-IP r-port r-ISN l-IP l-port l-ISN
The use of both ISNs in the traffic key computations ensures that The use of both ISNs in the traffic key computations ensures that
segments cannot be replayed across repeated connections reusing the segments cannot be replayed across repeated connections reusing the
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 it 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 7.7.
7.3. Traffic Key Establishment and Duration Issues 5.3. Traffic Key Establishment and Duration Issues
TCP-AO does not provide a mechanism for traffic key negotiation or TCP-AO does not provide a mechanism for traffic key negotiation or
parameter negotiation (MAC algorithm, length, or use of TCP-AO on a parameter negotiation (MAC algorithm, length, or use of TCP-AO on a
connection), or for coordinating rekeying during a connection. We connection), or for coordinating rekeying during a connection. We
assume out-of-band mechanisms for MKT establishment, parameter assume out-of-band mechanisms for MKT establishment, parameter
negotiation, and rekeying. This separation of MKT use from MKT negotiation, and rekeying. This separation of MKT use from MKT
management is similar to that in the IPsec security suite management is similar to that in the IPsec 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 5.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
[RFC4808]. New MKT use is coordinated using the out-of-band mechanism [RFC4808]. New MKT use is coordinated using the out-of-band
to update both TCP endpoints. When only a single MKT is used at a mechanism to update both TCP endpoints. When only a single MKT is
time, the temporary use of invalid MKTs could result in segments used at a time, the temporary use of invalid MKTs could result in
being dropped; although TCP is already robust to such drops, TCP-AO segments being dropped; although TCP is already robust to such drops,
uses the KeyID field to avoid such drops. A given connection can have TCP-AO uses the KeyID field to avoid such drops. A given connection
multiple matching MKTs, where the KeyID field is used to identify the can have multiple matching MKTs, where the KeyID field is used to
MKT that corresponds to the traffic key used for a segment, to avoid identify the MKT that corresponds to the traffic key used for a
the need for expensive trial-and-error testing of MKTs in sequence. segment, to avoid the need for expensive trial-and-error testing of
MKTs in sequence.
TCP-AO provides an explicit MKT coordination mechanism, described in TCP-AO provides an explicit MKT coordination mechanism, described in
Section 8.1. Such a mechanism is useful when new MKTs are installed, Section 6.1. Such a mechanism is useful when new MKTs are installed,
or when MKTs are changed, to determine when to commence using or when MKTs are changed, to determine when to commence using
installed MKTs. installed MKTs.
Users are advised to manage MKTs following the spirit of the advice Users are advised to manage MKTs following the spirit of the advice
for key management when using TCP MD5 [RFC3562], notably to use for key management when using TCP MD5 [RFC3562], notably to use
appropriate key lengths (12-24 bytes) and to avoid sharing MKTs among appropriate key lengths (12-24 bytes) and to avoid sharing MKTs among
multiple BGP peering arrangements. multiple BGP peering arrangements.
7.3.1. MKT Reuse Across Socket Pairs 5.3.1. MKT Reuse Across Socket Pairs
MKTs can be reused across different socket pairs within a host, or MKTs can be reused across different socket pairs within a host, or
across different instances of a socket pair within a host. In either across different instances of a socket pair within a host. In either
case, replay protection is maintained. case, replay protection is maintained.
MKTs reused across different socket pairs cannot enable replay MKTs reused across different socket pairs cannot enable replay
attacks because the TCP socket pair is included in the MAC, as well attacks because the TCP socket pair is included in the MAC, as well
as in the generation of the traffic key. MKTs reused across repeated as in the generation of the traffic key. MKTs reused across repeated
instances of a given socket pair cannot enable replay attacks because instances of a given socket pair cannot enable replay attacks because
the connection ISNs are included in the traffic key generation the connection ISNs are included in the traffic key generation
algorithm, and ISN pairs are unlikely to repeat over useful periods. algorithm, and ISN pairs are unlikely to repeat over useful periods.
7.3.2. MKTs Use Within a Long-lived Connection 5.3.2. MKTs Use within a Long-Lived Connection
TCP-AO uses sequence number extensions (SNEs) to prevent replay TCP-AO uses Sequence Number Extensions (SNEs) to prevent replay
attacks within long-lived connections. Explicit MKT rollover, attacks within long-lived connections. Explicit MKT rollover,
accomplished by external means and indexed using the KeyID field, can accomplished by external means and indexed using the KeyID field, can
be used to change keying material for various reasons (e.g., be used to change keying material for various reasons (e.g.,
personnel turnover), but is not required to support long-lived personnel turnover), but is not required to support long-lived
connections. connections.
8. Additional Security Mechanisms 6. Additional Security Mechanisms
TCP-AO adds mechanisms to support efficient use, especially in TCP-AO adds mechanisms to support efficient use, especially in
environments where only manual keying is available. These include the environments where only manual keying is available. These include
previously described mechanisms for supporting multiple concurrent the previously described mechanisms for supporting multiple
MKTs (via the KeyID field) and for generating unique per-connection concurrent MKTs (via the KeyID field) and for generating unique per-
traffic keys (via the KDF). This section describes additional connection traffic keys (via the KDF). This section describes
mechanisms to coordinate MKT changes and to prevent replay attacks additional mechanisms to coordinate MKT changes and to prevent replay
when a traffic key is not changed for long periods of time. attacks when a traffic key is not changed for long periods of time.
8.1. Coordinating Use of New MKTs 6.1. Coordinating Use of New MKTs
At any given time, a single TCP connection may have multiple MKTs At any given time, a single TCP connection may have multiple MKTs
specified for each segment direction (incoming, outgoing). TCP-AO specified for each segment direction (incoming, outgoing). TCP-AO
provides a mechanism to indicate when a new MKT is ready, to allow provides a mechanism to indicate when a new MKT is ready, which
the sender to commence use of that new MKT. This mechanism allows new allows the sender to commence use of that new MKT. This mechanism
MKT use to be coordinated, to avoid unnecessary loss due to sender allows new MKT use to be coordinated, to avoid unnecessary loss due
authentication using a MKT not yet ready at the receiver. to sender authentication using an MKT not yet ready at the receiver.
Note that this is intended as an optimization. Deciding when to start Note that this is intended as an optimization. Deciding when to
using a key is a performance issue. Deciding when to remove an MKT is start using a key is a performance issue. Deciding when to remove an
a security issue. Invalid MKTs are expected to be removed. TCP-AO MKT is a security issue. Invalid MKTs are expected to be removed.
provides no mechanism to coordinate their removal, as we consider TCP-AO provides no mechanism to coordinate their removal, as we
this a key management operation. consider this a key management operation.
New MKT use is coordinated through two ID fields in the header: New MKT use is coordinated through two ID fields in the header:
o KeyID o KeyID
o RNextKeyID o RNextKeyID
KeyID represents the outgoing MKT information used by the segment KeyID represents the outgoing MKT information used by the segment
sender to create the segment's MAC (outgoing), and the corresponding sender to create the segment's MAC (outgoing), and the corresponding
incoming keying information used by the segment receiver to validate incoming keying information used by the segment receiver to validate
that MAC. It contains the SendID of the MKT in active use in that that MAC. It contains the SendID of the MKT in active use in that
direction. direction.
RNextKeyID represents the preferred MKT information to be used for RNextKeyID represents the preferred MKT information to be used for
subsequent received segments ('receive next'). I.e., it is a way for subsequent received segments ('receive next'). That is, it is a way
the segment sender to indicate a ready incoming MKT for future for the segment sender to indicate a ready incoming MKT for future
segments it receives, so that the segment receiver can know when to segments it receives, so that the segment receiver can know when to
switch MKTs (and thus their KeyIDs and associated traffic keys). It switch MKTs (and thus their KeyIDs and associated traffic keys). It
indicates the RecvID of the MKT desired to for incoming segments. indicates the RecvID of the MKT desired for incoming segments.
There are two pointers kept by each side of a connection, as noted in There are two pointers kept by each side of a connection, as noted in
the per-connection information (see Section 6): the per-connection information (see Section 4):
o Currently active outgoing MKT (Current_key) o Currently active outgoing MKT (current_key)
o Current preference for incoming MKT (rnext_key) o Current preference for incoming MKT (rnext_key)
Current_key indicates a MKT that is used to authenticate outgoing Current_key indicates an MKT that is used to authenticate outgoing
segments. Upon connection establishment, it points to the first MKT segments. Upon connection establishment, it points to the first MKT
selected for use. selected for use.
Rnext_key points to an incoming MKT that is ready and preferred for Rnext_key points to an incoming MKT that is ready and preferred for
use. Upon connection establishment, this points to the currently use. Upon connection establishment, this points to the currently
active incoming MKT. It can be changed when new MKTs are installed active incoming MKT. It can be changed when new MKTs are installed
(e.g., either by automatic MKT management protocol operation or by (e.g., by either automatic MKT management protocol operation or user
user manual selection). manual selection).
Rnext_key is changed only by manual user intervention or MKT Rnext_key is changed only by manual user intervention or MKT
management protocol operation. It is not manipulated by TCP-AO. management protocol operation. It is not manipulated by TCP-AO.
Current_key is updated by TCP-AO when processing received TCP Current_key is updated by TCP-AO when processing received TCP
segments as discussed in the segment processing description in segments as discussed in the segment processing description in
Section 9.5. Note that the algorithm allows the current_key to change Section 7.5. Note that the algorithm allows the current_key to
to a new MKT, then change back to a previously used MKT (known as change to a new MKT, then change back to a previously used MKT (known
"backing up"). This can occur during a MKT change when segments are as "backing up"). This can occur during an MKT change when segments
received out of order, and is considered a feature of TCP-AO, because are received out of order, and is considered a feature of TCP-AO,
reordering does not result in drops. The only way to avoid reuse of because reordering does not result in drops. The only way to avoid
previously used MKTs is to remove the MKT when it is no longer reuse of previously used MKTs is to remove the MKT when it is no
considered permitted. longer considered permitted.
8.2. Preventing replay attacks within long-lived connections 6.2. Preventing Replay Attacks within Long-Lived Connections
TCP uses a 32-bit sequence number which may, for long-lived TCP uses a 32-bit sequence number, which may, for long-lived
connections, roll over and repeat. This could result in TCP segments connections, roll over and repeat. This could result in TCP segments
being intentionally and legitimately replayed within a connection. being intentionally and legitimately replayed within a connection.
TCP-AO prevents replay attacks, and thus requires a way to TCP-AO prevents replay attacks, and thus requires a way to
differentiate these legitimate replays from each other, and so it differentiate these legitimate replays from each other, and so it
adds a 32-bit sequence number extension (SNE) for transmitted and adds a 32-bit Sequence Number Extension (SNE) for transmitted and
received segments. received segments.
The SNE extends TCP's sequence number so that segments within a The SNE extends the TCP sequence number so that segments within a
single connection are always unique. When TCP's sequence number rolls single connection are always unique. When the TCP's sequence number
over, there is a chance that a segment could be repeated in total; rolls over, there is a chance that a segment could be repeated in
using an SNE differentiates even identical segments sent with total; using an SNE differentiates even identical segments sent with
identical sequence numbers at different times in a connection. TCP-AO identical sequence numbers at different times in a connection. TCP-
emulates a 64-bit sequence number space by inferring when to AO emulates a 64-bit sequence number space by inferring when to
increment the high-order 32-bit portion (the SNE) based on increment the high-order 32-bit portion (the SNE) based on
transitions in the low-order portion (the TCP sequence number). transitions in the low-order portion (the TCP sequence number).
TCP-AO thus maintains SND.SNE for transmitted segments, and RCV.SNE TCP-AO thus maintains SND.SNE for transmitted segments, and RCV.SNE
for received segments, both initialized as zero when a connection for received segments, both initialized as zero when a connection
begins. The intent of these SNEs is, together with TCP's 32-bit begins. The intent of these SNEs is, together with TCP's 32-bit
sequence numbers, to provide a 64-bit overall sequence number space. sequence numbers, to provide a 64-bit overall sequence number space.
For transmitted segments SND.SNE can be implemented by extending For transmitted segments, SND.SNE can be implemented by extending
TCP's sequence number to 64-bits; SND.SNE would be the top (high- TCP's sequence number to 64 bits; SND.SNE would be the top (high-
order) 32 bits of that number. For received segments, TCP-AO needs to order) 32 bits of that number. For received segments, TCP-AO needs
emulate the use of a 64-bit number space, and correctly infer the to emulate the use of a 64-bit number space and correctly infer the
appropriate high-order 32-bits of that number as RCV.SNE from the appropriate high-order 32-bits of that number as RCV.SNE from the
received 32-bit sequence number and the current connection context. received 32-bit sequence number and the current connection context.
The implementation of SNEs is not specified in this document, but one The implementation of SNEs is not specified in this document, but one
possible way is described here that can be used for either RCV.SNE, possible way is described here that can be used for either RCV.SNE,
SND.SNE, or both. SND.SNE, or both.
Consider an implementation with two SNEs as required (SND.SNE, RCV. Consider an implementation with two SNEs as required (SND.SNE, RCV.
SNE), and additional variables as listed below, all initialized to SNE), and additional variables as listed below, all initialized to
zero, as well as a current TCP segment field (SEG.SEQ): zero, as well as a current TCP segment field (SEG.SEQ):
skipping to change at page 26, line 25 skipping to change at page 26, line 5
o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ
o SND.SNE_FLAG, which indicates when to increment the SND.SNE o SND.SNE_FLAG, which indicates when to increment the SND.SNE
o RCV.SNE_FLAG, which indicates when to increment the RCV.SNE o RCV.SNE_FLAG, which indicates when to increment the RCV.SNE
When a segment is received, the following algorithm (in C-like When a segment is received, the following algorithm (in C-like
pseudocode) computes the SNE used in the MAC; this is the "RCV" side, pseudocode) computes the SNE used in the MAC; this is the "RCV" side,
and an equivalent algorithm can be applied to the "SND" side: and an equivalent algorithm can be applied to the "SND" side:
/* set the flag when the SEG.SEQ first rolls over */ /* set the flag when the SEG.SEQ first rolls over */
if ((RCV.SNE_FLAG == 0) if ((RCV.SNE_FLAG == 0)
&& (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) { && (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) {
RCV.SNE = RCV.SNE + 1; RCV.SNE = RCV.SNE + 1;
RCV.SNE_FLAG = 1; RCV.SNE_FLAG = 1;
} }
/* decide which SNE to use after incremented */ /* decide which SNE to use after incremented */
if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) { if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) {
SNE = RCV.SNE - 1; # use the pre-increment value SNE = RCV.SNE - 1; # use the pre-increment value
} else { } else {
SNE = RCV.SNE; # use the current value SNE = RCV.SNE; # use the current value
} }
/* reset the flag in the *middle* of the window */ /* reset the flag in the *middle* of the window */
if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) { if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) {
RCV.SNE_FLAG = 0; RCV.SNE_FLAG = 0;
} }
/* save the current SEQ for the next time through the code */ /* save the current SEQ for the next time through the code */
RCV.PREV_SEQ = SEG.SEQ; RCV.PREV_SEQ = SEG.SEQ;
In the above code, the first line when the sequence number first In the above code, the first time the sequence number rolls over,
rolls over, i.e., when the new number is low (in the bottom half of i.e., when the new number is low (in the bottom half of the number
the number space) and the old number is high (in the top half of the space) and the old number is high (in the top half of the number
number space). The first time this happens, the SNE is incremented space), the SNE is incremented and a flag is set.
and a flag is set.
If the flag is set and a high number is seen, it must be a reordered If the flag is set and a high number is seen, it must be a reordered
segment, so use the pre-increment SNE, otherwise use the current SNE. segment, so use the pre-increment SNE; otherwise, use the current
SNE.
The flag will be cleared by the time the number rolls all the way The flag will be cleared by the time the number rolls all the way
around. around.
The flag prevents the SNE from being incremented again until the flag The flag prevents the SNE from being incremented again until the flag
is reset, which happens in the middle of the window (when the old is reset, which happens in the middle of the window (when the old
number is in the bottom half and the new is in the top half). Because number is in the bottom half and the new is in the top half).
the receive window is never larger than half of the number space, it Because the receive window is never larger than half of the number
is impossible to both set and reset the flag at the same time - space, it is impossible to both set and reset the flag at the same
outstanding segments, regardless of reordering, cannot straddle both time -- outstanding segments, regardless of reordering, cannot
regions simultaneously. straddle both regions simultaneously.
9. TCP-AO Interaction with TCP 7. TCP-AO Interaction with TCP
The following is a description of how TCP-AO affects various TCP The following is a description of how TCP-AO affects various TCP
states, segments, events, and interfaces. This description is states, segments, events, and interfaces. This description is
intended to augment the description of TCP as provided in RFC-793, intended to augment the description of TCP as provided in RFC 793,
and its presentation mirrors that of RFC-793 as a result [RFC793]. and its presentation mirrors that of RFC 793 as a result [RFC793].
9.1. TCP User Interface 7.1. TCP User Interface
The TCP user interface supports active and passive OPEN, SEND, The TCP user interface supports active and passive OPEN, SEND,
RECEIVE, CLOSE, STATUS and ABORT commands. TCP-AO does not alter this RECEIVE, CLOSE, STATUS, and ABORT commands. TCP-AO does not alter
interface as it applies to TCP, but some commands or command this interface as it applies to TCP, but some commands or command
sequences of the interface need to be modified to support TCP-AO. sequences of the interface need to be modified to support TCP-AO.
TCP-AO does not specify the details of how this is achieved. TCP-AO does not specify the details of how this is achieved.
TCP-AO requires the TCP user interface be extended to allow the MKTs TCP-AO requires that the TCP user interface be extended to allow the
to be configured, as well as to allow an ongoing connection to manage MKTs to be configured, as well as to allow an ongoing connection to
which MKTs are active. The MKTs need to be configured prior to manage which MKTs are active. The MKTs need to be configured prior
connection establishment, and the set of MKTs may change during a to 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. an MKT can be configured.
>> A TCP-AO implementation 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 need 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
indicated; these changes immediately affect all subsequent outgoing indicated; these changes immediately affect all subsequent outgoing
segments: segments:
>> TCP SEND, or a sequence of commands resulting in a SEND, MUST be >> TCP SEND, or a sequence of commands resulting in a SEND, MUST be
augmented so that the preferred outgoing MKT (Current_key) and/or the augmented so that the preferred outgoing MKT (current_key) and/or the
preferred incoming MKT rnext_key of a connection can be indicated. preferred incoming MKT (rnext_key) of a connection can be indicated.
It may be useful to change the outgoing active MKT (Current_key) even It may be useful to change the outgoing active MKT (current_key) even
when no data is being sent, which can be achieved by sending a zero- when no data is being sent, which can be achieved by sending a zero-
length buffer or by using a non-send interface (e.g., socket options length buffer or by using a non-send interface (e.g., socket options
in Unix), depending on the implementation. in Unix), depending on the implementation.
It is also useful to indicate recent segment KeyID and RNextKeyID It is also useful to indicate recent segment KeyID and RNextKeyID
values received; although there could be a number of such values, values received; although there could be a number of such values,
they are not expected to change quickly so any recent sample should they are not expected to change quickly, so any recent sample should
be sufficient: be sufficient:
>> TCP RECEIVE, or the sequence of commands resulting in a RECEIVE, >> TCP RECEIVE, or the sequence of commands resulting in a RECEIVE,
MUST be augmented so that the KeyID and RNextKeyID of a recently MUST be augmented so that the KeyID and RNextKeyID of a recently
received segment is available to the user out-of-band (e.g., as an received segment is available to the user out of band (e.g., as an
additional parameter to RECEIVE, or via a STATUS call). additional parameter to RECEIVE or via a STATUS call).
9.2. TCP States and Transitions 7.2. TCP States and Transitions
TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and
CLOSED. CLOSED.
>> A MKT MAY be associated with any TCP state. >> An MKT MAY be associated with any TCP state.
9.3. TCP Segments 7.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 does not validate MUST be silently >> TCP segments whose TCP-AO does not validate MUST be 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 TCP-AO but that do not match an MKT. The behavior of segments with TCP-AO but that do not match an MKT. The
initial default of this configuration SHOULD be to silently accept initial default of this configuration SHOULD be to silently accept
such connections. If this is not the desired case, an MKT can be such connections. If this is not the desired case, an MKT can 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
rate-limited. Either signal MAY be logged; logging SHOULD allow rate- be rate-limited. Either signal MAY be logged; logging SHOULD allow
limiting as well. rate-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 TCP-AO on a connection not negotiated within TCP. It Note that use of TCP-AO on a connection is not negotiated within TCP.
is the responsibility of the receiver to determine when TCP-AO is It 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 a key
management protocol) and to enforce that requirement. management protocol) and to enforce that requirement.
9.4. Sending TCP Segments 7.4. Sending TCP Segments
The following procedure describes the modifications to TCP to support The following procedure describes the modifications to TCP to support
inserting 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 TCP-AO. Proceed with i. If there is no matching MKT, omit TCP-AO. 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 4). 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 4) and proceed with the step 2.
2. Using the per-connection parameters: 2. Using the per-connection parameters:
a. Augment the TCP header with TCP-AO, inserting the appropriate a. Augment the TCP header with TCP-AO, inserting the appropriate
Length and KeyID based on the MKT indicated by current_key Length and KeyID based on the MKT indicated by current_key
(using the current_key MKT's SendID as the TCP-AO KeyID). (using the current_key MKT's SendID as the TCP-AO 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 6.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 the current_key (as noted in Section 6.1, and as probably
in the TCB). I.e., use the send_SYN_traffic_key for SYN cached in the TCB). That is, use the send_SYN_traffic_key for
segments, and the send_other_traffic_key for other segments. SYN 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 RNextKeyID field (using pointer, and insert it in the TCP-AO RNextKeyID field (using
the 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 6.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 5.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 7.5. Receiving 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 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 that 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 TCP-AO where required. Other segments avoid accepting SYNs lacking TCP-AO where required. Other 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 TCP-AO from the i. If there is no matching MKT, remove TCP-AO from the
segment. Proceed with further TCP handling of the segment. Proceed with further TCP handling of the segment.
segment.
NOTE: this presumes that connections that do not match NOTE: this presumes that connections that do not match any
any MKT should be silently accepted, as noted in Sec 9.3. MKT should be silently accepted, as noted in Section 7.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 4). Proceed with step 2.
step 2.
2. Using the per-connection parameters: 2. Using the per-connection parameters:
a. Check that the segment's TCP-AO Length matches the length a. Check that the segment's TCP-AO Length matches the length
indicated by the MKT. indicated by the MKT.
i. If lengths differ, silently discard the segment. Log i. If the lengths differ, silently discard the segment. Log
and/or signal the event as indicated in Section 9.3. and/or signal the event as indicated in Section 7.3.
b. Determine the segment's RCV.SNE as described in Section 8.2. b. Determine the segment's RCV.SNE as described in Section 6.2.
c. Determine the segment's traffic key from the MKT as described c. Determine the segment's traffic key from the MKT as described
in Section 7.1 (and as likely cached in the TCB). I.e., use in Section 5.1 (and as likely cached in the TCB). That is,
the receive_SYN_traffic_key for SYN segments, and the use the receive_SYN_traffic_key for SYN segments and the
receive_other_traffic_key for other segments. receive_other_traffic_key for other segments.
d. Compute the segment's MAC using the MKT (and its derived d. Compute the segment's MAC using the MKT (and its derived
traffic key) and portions of the segment as indicated in traffic key) and portions of the segment as indicated in
Section 7.1. Section 5.1.
i. If the computed MAC differs from the TCP-AO MAC field i. If the computed MAC differs from the TCP-AO MAC field
value, silently discard the segment. Log and/or signal value, silently discard the segment. Log and/or signal the
the event as indicated in Section 9.3. event as indicated in Section 7.3.
e. Compare the received RNextKeyID value to the currently active e. Compare the received RNextKeyID value to the currently active
outgoing KeyID value (Current_key MKT's SendID). outgoing KeyID value (current_key MKT's SendID).
i. If they match, no further action is required. i. If they match, no further action is required.
ii. If they differ, determine whether the RNextKeyID MKT is ii. If they differ, determine whether the RNextKeyID MKT is
ready. ready.
1. If the MKT corresponding to the segment's socket 1. If the MKT corresponding to the segment's socket pair
pair and RNextKeyID is not available, no action is and RNextKeyID is not available, no action is required
required (RNextKeyID of a received segment needs to (RNextKeyID of a received segment needs to match the
match the MKT's SendID). MKT's SendID).
2. If the matching MKT corresponding to the segment's 2. If the matching MKT corresponding to the segment's
socket pair and RNextKeyID is available: socket pair and RNextKeyID is available:
a. Set Current_key to the RNextKeyID MKT. a. Set current_key to the RNextKeyID MKT.
f. Proceed with TCP processing of the segment. f. Proceed with TCP processing of the segment.
It is suggested that TCP-AO implementations validate a segment's It is suggested that TCP-AO implementations validate a segment's
Length field before computing a MAC, to reduce the overhead incurred Length field before computing a MAC to reduce the overhead incurred
by spoofed segments with invalid TCP-AO fields. by spoofed segments with invalid TCP-AO fields.
Additional reductions in MAC validation overhead can be supported in Additional reductions in MAC validation overhead can be supported in
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
MAC algorithm specification, and thus are not specified in TCP-AO the 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 7.6. Impact on TCP Header Size
TCP-AO, using the initially required 96-bit MACs, uses a total of 16 TCP-AO, using the initially required 96-bit MACs, uses a total of 16
bytes of TCP header space [Le09]. TCP-AO is thus 2 bytes smaller than bytes of TCP header space [RFC5926]. TCP-AO is thus 2 bytes smaller
the TCP MD5 option (18 bytes). than the TCP MD5 option (18 bytes).
Note that TCP option space is most critical in SYN segments, because Note that the TCP option space is most critical in SYN segments,
flags in those segments could potentially increase the option space because flags in those segments could potentially increase the option
area in other segments. Because TCP ignores unknown segments, space 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
implementations (listed below), leaving at most 25 for other uses. implementations (listed below), leaving at most 25 for other uses.
TCP-AO consumes 16 bytes, leaving 9 bytes for additional SYN options TCP-AO consumes 16 bytes, leaving 9 bytes for additional SYN options
(depending on implementation dependant alignment padding, which could (depending on implementation dependant alignment padding, which could
consume another 2 bytes at most). consume another 2 bytes at most).
o SACK permitted (2 bytes) [RFC2018][RFC3517] o SACK permitted (2 bytes) [RFC2018][RFC3517]
skipping to change at page 33, line 17 skipping to change at page 32, line 49
After a SYN, the following options are expected in current After a SYN, the following options are expected in current
implementations of TCP: implementations of TCP:
o SACK (10bytes) [RFC2018][RFC3517] (18 bytes if D-SACK [RFC2883]) o SACK (10bytes) [RFC2018][RFC3517] (18 bytes if D-SACK [RFC2883])
o Timestamps (10 bytes) [RFC1323] o Timestamps (10 bytes) [RFC1323]
TCP-AO continues to consume 16 bytes in non-SYN segments, leaving a TCP-AO continues to consume 16 bytes in non-SYN segments, leaving a
total of 24 bytes for other options, of which the timestamp consumes total of 24 bytes for other options, of which the timestamp consumes
10. This leaves 14 bytes, of which 10 are used for a single SACK 10. This leaves 14 bytes, of which 10 are used for a single SACK
block. When two SACK blocks are used, such as to handle D-SACK, a block. When two SACK blocks are used, such as to handle D-SACK, a
smaller TCP-AO MAC would be required to make room for the additional smaller TCP-AO MAC would be required to make room for the additional
SACK block (i.e., to leave 18 bytes for the D-SACK variant of the SACK block (i.e., to leave 18 bytes for the D-SACK variant of the
SACK option) [RFC2883]. Note that D-SACK is not supportable in TCP SACK option) [RFC2883]. Note that D-SACK is not supportable in TCP
MD5 in the presence of timestamps, because TCP MD5's MAC length is MD5 in the presence of timestamps, because TCP MD5's MAC length is
fixed and too large to leave sufficient option space. fixed and too large to leave sufficient option space.
Although TCP option space is limited, we believe TCP-AO is consistent Although TCP option space is limited, we believe TCP-AO is consistent
with the desire to authenticate TCP at the connection level for with the desire to authenticate TCP at the connection level for
similar uses as were intended by TCP MD5. similar uses as were intended by TCP MD5.
9.7. Connectionless Resets 7.7. Connectionless Resets
TCP-AO allows TCP resets (RSTs) to be exchanged provided both sides TCP-AO allows TCP resets (RSTs) to be exchanged provided both sides
have established valid connection state. After such state is have established valid connection state. After such state is
established, if one side reboots, TCP-AO prevents TCP's RST mechanism established, if one side reboots, TCP-AO prevents TCP's RST mechanism
from clearing out old state on the side that did not reboot. This from clearing out old state on the side that did not reboot. This
happens because the rebooting side has lost its connection state, and happens because the rebooting side has lost its connection state, and
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 [Ba10]. 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 TCP keepalives ensures that connections whose keys are The use of TCP keepalives ensures that connections whose keys are
lost are terminated after a finite time; a similar effect can be lost are terminated after a finite time; a similar effect can be
achieved at the application layer, e.g., with BGP keepalives achieved at the application layer, e.g., with BGP keepalives
[RFC4271]. Either kind of keepalive helps ensure the TCP state is [RFC4271]. Either kind of keepalive helps ensure the TCP state is
cleared out in such a case; the alternative, of allowing 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 prevent.
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. Specifically,
BGP reacts poorly to such connection drops, even if caused by the use BGP reacts poorly to such connection drops, even if caused by the use
of BGP keepalives; "graceful restart" was introduced to address this of BGP keepalives; "graceful restart" was introduced to address this
effect [RFC4724], and extended to support BGP with MPLS [RFC4781]. As effect [RFC4724], and extended to support BGP with MPLS [RFC4781].
a result: 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
performance impacts that result from this storage/restoration. performance impacts that result from this storage/restoration.
9.8. ICMP Handling 7.8. ICMP Handling
TCP can be attacked both in-band, using TCP segments, or out-of-band TCP can be attacked both in band, using TCP segments, or out of band
using ICMP. ICMP packets cannot be protected using TCP-AO mechanisms, using ICMP. ICMP packets cannot be protected using TCP-AO
however; in this way, both TCP-AO and IPsec do not directly solve the mechanisms; however, in this way, both TCP-AO and IPsec do not
need for protected ICMP signaling. TCP-AO does make specific directly solve the need for protected ICMP signaling. TCP-AO does
recommendations on how to handle certain ICMPs, beyond what IPsec make specific recommendations on how to handle certain ICMPs, beyond
requires, and these are made possible because TCP-AO operates inside what IPsec requires, and these are made possible because TCP-AO
the context of a TCP connection. operates inside 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 [Go10]. As a result, we recommend a conservative approach to
accepting ICMP messages as summarized in [Go09]: accepting ICMP messages as summarized in [Go10]:
>> A TCP-AO implementation MUST default to ignore incoming ICMPv4 >> 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') and ICMPv6 Type 1 (destination unreachable) Code 1 errors'), and ICMPv6 Type 1 (destination unreachable), Code 1
(administratively prohibited) and Code 4 (port unreachable) intended (administratively prohibited) and Code 4 (port unreachable) intended
for connections in synchronized states (ESTABLISHED, FIN-WAIT-1, FIN- for connections in synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-
WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT) that match MKTs. 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] [Go10].
>> 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 8. 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 that support TCP MD5 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. are 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
use TCP MD5 instead. use TCP MD5 instead.
>> A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for a >> A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for a
particular TCP connection, but MAY support TCP-AO and TCP MD5 particular TCP connection, but MAY support TCP-AO and TCP MD5
simultaneously for different connections (notably to support legacy simultaneously for different connections (notably to support legacy
use of TCP MD5). use of TCP MD5).
The Kind value explicitly indicates whether TCP-AO or TCP MD5 is used The Kind value explicitly indicates whether TCP-AO or TCP MD5 is used
for a particular connection in TCP segments. for a particular connection in TCP segments.
It is possible that MKTs could be augmented to support TCP MD5, It is possible that MKTs could be augmented to support TCP MD5,
although use of MKTs is not described in RFC2385. although use of MKTs is not described in RFC 2385.
It is possible to require TCP-AO for a connection or TCP MD5, but it It is possible to require TCP-AO for a connection or TCP MD5, but it
is not possible to require 'either'. When an endpoint is configured is not possible to require 'either'. When an endpoint is configured
to require TCP MD5 for a connection, it must be added to all outgoing to require TCP MD5 for a connection, it must be added to all outgoing
segments and validated on all incoming segments [RFC2385]. TCP MD5's segments and validated on all incoming segments [RFC2385]. TCP MD5's
requirements prohibit the speculative use of both options for a given requirements prohibit the speculative use of both options for a given
connection, e.g., to be decided by the other end of the connection. connection, e.g., to be decided by the other end of the connection.
11. Interactions with Middleboxes 9. Interactions with Middleboxes
TCP-AO may interact with middleboxes, depending on their behavior TCP-AO may interact with middleboxes, depending on their behavior
[RFC3234]. Some middleboxes either alter TCP options (such as TCP-AO) [RFC3234]. Some middleboxes either alter TCP options (such as TCP-
directly or alter the information TCP-AO includes in its MAC AO) directly or alter the information TCP-AO includes in its MAC
calculation. TCP-AO may interfere with these devices, exactly where calculation. TCP-AO may interfere with these devices, exactly where
the device modifies information TCP-AO is designed to protect. the device modifies information TCP-AO is designed to protect.
11.1. Interactions with non-NAT/NAPT Middleboxes 9.1. Interactions with Non-NAT/NAPT Middleboxes
TCP-AO supports middleboxes that do not change the IP addresses or TCP-AO supports middleboxes that do not change the IP addresses or
ports of segments. Such middleboxes may modify some TCP options, in ports of segments. Such middleboxes may modify some TCP options, in
which case TCP-AO would need to be configured to ignore all options which case TCP-AO would need to be configured to ignore all options
in the MAC calculation on connections traversing that element. in the MAC calculation on connections traversing that element.
Note that ignoring TCP options may provide less protection, i.e., TCP Note that ignoring TCP options may provide less protection, i.e., TCP
options could be modified in transit, and such modifications could be options could be modified in transit, and such modifications could be
used by an attacker. Depending on the modifications, TCP could have used by an attacker. Depending on the modifications, TCP could have
compromised efficiency (e.g., timestamp changes), or could cease compromised efficiency (e.g., timestamp changes), or could cease
correct operation (e.g., window scale changes). These vulnerabilities correct operation (e.g., window scale changes). These
affect only the TCP connections for which TCP-AO is configured to vulnerabilities affect only the TCP connections for which TCP-AO is
ignore TCP options. configured to ignore TCP options.
11.2. Interactions with NAT/NAPT Devices 9.2. Interactions with NAT/NAPT Devices
TCP-AO cannot interoperate natively across NAT/NAPT devices, which TCP-AO cannot interoperate natively across NAT/NAPT (Network Address
modify the IP addresses and/or port numbers. We anticipate that Port Translation) devices, which modify the IP addresses and/or port
traversing such devices may require variants of existing NAT/NAPT numbers. We anticipate that traversing such devices may require
traversal mechanisms, e.g., encapsulation of the TCP-AO-protected variants of existing NAT/NAPT traversal mechanisms, e.g.,
segment in another transport segment (e.g., UDP), as is done in IPsec encapsulation of the TCP-AO-protected segment in another transport
[RFC2663][RFC3947]. Such variants can be adapted for use with TCP-AO, segment (e.g., UDP), as is done in IPsec [RFC2663][RFC3947]. Such
or IPsec with NAT traversal can be used instead of TCP-AO in such variants can be adapted for use with TCP-AO, or IPsec with NAT
cases [RFC3947]. 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 10. 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 [Ed07].
1. Protected Elements 1. Protected Elements
A solution to revising TCP MD5 should protect (authenticate) the A solution to revising TCP MD5 should protect (authenticate) the
following elements. following elements.
This is supported - see Section 7.1. This is supported -- see Section 5.1.
a. IP pseudoheader, including IPv4 and IPv6 versions. a. IP pseudoheader, including IPv4 and IPv6 versions.
Note that we do not allow optional coverage because IP Note that optional coverage is not allowed because IP addresses
addresses define a connection. If they can be coordinated define a connection. If they can be coordinated across a
across a NAT/NAPT, the sender can compute the MAC based on the NAT/NAPT, the sender can compute the MAC based on the received
received values; if not, a tunnel is required, as noted in values; if not, a tunnel is required, as noted in Section 9.2.
Section 11.2.
b. TCP header. b. TCP header.
Note that we do not allow optional port coverage because ports Note that optional port coverage is not allowed because ports
define a connection. If they can be coordinated across a define a connection. If they can be coordinated across a
NAT/NAPT, the sender can compute the MAC based on the received NAT/NAPT, the sender can compute the MAC based on the received
values; if not, a tunnel is required, as noted in Section values; if not, a tunnel is required, as noted in Section 9.2.
11.2.
c. TCP options. c. TCP options.
Note that TCP-AO allows exclusion of TCP options from Note that TCP-AO allows the exclusion of TCP options from
coverage, to enable use with middleboxes that modify options coverage, to enable use with middleboxes that modify options
(except when they modify TCP-AO itself). See Section 11. (except when they modify TCP-AO itself). See Section 9.
d. TCP payload data. d. TCP payload data.
2. Option Structure Requirements 2. Option Structure Requirements
A solution to revising TCP MD5 should use an option with the A solution to revising TCP MD5 should use an option with the
following structural requirements. following structural requirements.
This is supported - see Section 7.1. This is supported -- see Section 5.1.
a. Privacy. a. Privacy.
The option should not unnecessarily expose information about The option should not unnecessarily expose information about
the TCP-AO mechanism. The additional protection afforded by the TCP-AO mechanism. The additional protection afforded by
keeping this information private may be of little value, but keeping this information private may be of little value, but
also helps keep the option size small. also helps keep the option size small.
TCP-AO exposes only the MKT IDs, MAC, and overall option TCP-AO exposes only the MKT IDs, MAC, and overall option length
length on the wire. Note that short MACs could be obscured by on the wire. Note that short MACs could be obscured by using
using longer option lengths but specifying a short MAC length longer option lengths but specifying a short MAC length (this
(this is equivalent to a different MAC algorithm, and is is equivalent to a different MAC algorithm, and is specified in
specified in the MKT). See Section 4.2. the MKT). See Section 2.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 with TCP-AO are not discarded solely because they segments with TCP-AO are not discarded solely because they
include the option, provided they do not match any MKT. include the option, provided they do not match 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.
d. Standard parsing. d. Standard parsing.
The option should be easily parseable, i.e., without The option should be easily parseable, i.e., without
conditional parsing, and follow the standard RFC 793 option conditional parsing, and follow the standard RFC 793 option
format. format.
This is supported - see Section 4.2. This is supported -- see Section 2.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 7.6. The size of the option
intended to allow use with Large Windows and SACK. See also is intended to allow use with Large Windows and SACK. See also
Section 3.2, which indicates that TCP-AO is 2 bytes shorter Section 1.3, 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
implementations. implementations.
TCP-AO uses a default required algorithm as specified in TCP-AO uses a default required algorithm as specified in
[Le09], as noted in Section 7.1. [RFC5926] and as noted in Section 5.1 of this document.
b. Good algorithms. b. Good algorithms.
The option should use algorithms considered accepted by the The option should use algorithms considered accepted by the
security community, which are considered appropriately safe. security community, which are considered appropriately safe.
The use of non-standard or unpublished algorithms should be The use of non-standard or unpublished algorithms should be
avoided. avoided.
TCP-AO uses MACs as indicated in [Le09]. The KDF is also TCP-AO uses MACs as indicated in [RFC5926]. The KDF is also
specified in [Le09]. The KDF input string follows the typical specified in [RFC5926]. The KDF input string follows the
design (see [Le09]). typical design (see [RFC5926]).
c. Algorithm agility. c. Algorithm agility.
The option should support algorithms other than the default, The option should support algorithms other than the default, to
to allow agility over time. allow agility over time.
TCP-AO allows any desired algorithm, subject to TCP option TCP-AO allows any desired algorithm, subject to TCP option
space limitations, as noted in Section 4.2. The use of set of space limitations, as noted in Section 2.2. The use of a set
MKTs allows separate connections to use different algorithms, of MKTs allows separate connections to use different
both for the MAC and the KDF. algorithms, both for the MAC and the KDF.
d. Order-independent processing. d. Order-independent processing.
The option should be processed independently of the proper The option should be processed independently of the proper
order, i.e., they should allow processing of TCP segments in order, i.e., they should allow processing of TCP segments in
the order received, without requiring reordering. This avoids the order received, without requiring reordering. This avoids
the need for reordering prior to processing, and avoids the the need for reordering prior to processing, and avoids the
impact of misordered segments on the option. impact of misordered segments on the option.
This is supported - see Sections 9.3, 9.4, and 9.5. Note that This is supported -- see Sections 7.3, 7.4, and 7.5. Note that
pre-TCP processing is further required, because TCP segments pre-TCP processing is further required, because TCP segments
cannot be discarded solely based on a combination of cannot be discarded solely based on a combination of connection
connection state and out-of-window checks; many such segments, state and out-of-window checks; many such segments, although
although discarded, cause a host to respond with a replay of discarded, cause a host to respond with a replay of the last
the last valid ACK, e.g. [RFC793]. See also the derivation of valid ACK, e.g., [RFC793]. See also the derivation of the SNE,
the SNE, which is reconstituted at the receiver using a which is reconstituted at the receiver using a demonstration
demonstration algorithm that avoids the need for reordering algorithm that avoids the need for reordering (in Section 6.2).
(in Section 8.2).
e. Security parameter changes require key changes. e. Security parameter changes require key changes.
The option should require that the MKT change whenever the The option should require that the MKT change whenever the
security parameters change. This avoids the need for security parameters change. This avoids the need for
coordinating option state during a connection, which is coordinating option state during a connection, which is typical
typical for TCP options. This also helps allow "bump in the for TCP options. This also helps allow "bump in the stack"
stack" implementations that are not integrated with endpoint implementations that are not integrated with endpoint TCP
TCP implementations. implementations.
Parameters change only when a new MKT is used. See Section 5. Parameters change only when a new MKT is used. See Section 3.
4. Keying requirements. 4. Keying requirements.
A solution to revising TCP MD5 should support manual keying, and A solution to revising TCP MD5 should support manual keying, and
should support the use of an external automated key management should support the use of an external automated key management
system (e.g., a protocol or other mechanism). system (e.g., a protocol or other mechanism).
Note that TCP-AO does not specify a MKT management system. Note that TCP-AO does not specify an MKT management system.
a. Intraconnection rekeying. a. Intraconnection rekeying.
The option should support rekeying during a connection, to The option should support rekeying during a connection, to
avoid the impact of long-duration connections. avoid the impact of long-duration connections.
This is supported by the use of IDs and multiple MKTs; see This is supported by the use of IDs and multiple MKTs; see
Section 5. Section 3.
b. Efficient rekeying. b. Efficient rekeying.
The option should support rekeying during a connection without The option should support rekeying during a connection without
the need to expend undue computational resources. In the need to expend undue computational resources. In
particular, the options should avoid the need to try multiple particular, the options should avoid the need to try multiple
keys on a given segment. keys on a given segment.
This is supported by the use of the KeyID. See Section 8.1. This is supported by the use of the KeyID. See Section 6.1.
c. Automated and manual keying. c. Automated and manual keying.
The option should support both automated and manual keying. The option should support both automated and manual keying.
The use of MKTs allows external automated and manual keying. The use of MKTs allows external automated and manual keying.
See Section 5. This capability is enhanced by the generation See Section 3. This capability is enhanced by the generation
of unique per-connection keys, which enables use of manual of unique per-connection keys, which enables use of manual MKTs
MKTs with automatically generated traffic keys as noted in with automatically generated traffic keys as noted in Section
Section 7.2. 5.2.
d. Key management agnostic. d. Key management agnostic.
The option should not assume or require a particular key The option should not assume or require a particular key
management solution. management solution.
This is supported by use of a set of MKTs. See Section 5. This is supported by use of a set of MKTs. See Section 3.
5. Expected Constraints 5. Expected Constraints
A solution to revising TCP MD5 should also abide by typical safe A solution to revising TCP MD5 should also abide by typical safe
security practices. security practices.
a. Silent failure. a. Silent failure.
Receipt of segments failing authentication must result in no Receipt of segments failing authentication must result in no
visible external action and must not modify internal state, visible external action and must not modify internal state, and
and those events should be logged. those events should be logged.
This is supported - see Sections 9.3, 9.4, and 9.5. This is supported - see Sections 7.3, 7.4, and 7.5.
b. At most one such option per segment. b. At most one such option per segment.
Only one authentication option can be permitted per segment. Only one authentication option can be permitted per segment.
This is supported by the protocol requirements - see Section This is supported by the protocol requirements - see Section
4.2. 2.2.
c. Outgoing all or none. c. Outgoing all or none.
Segments out of a TCP connection are either all authenticated Segments out of a TCP connection are either all authenticated
or all not authenticated. or all not authenticated.
This is supported - see Section 9.4. This is supported - see Section 7.4.
d. Incoming all checked. d. Incoming all checked.
Segments into a TCP connection are always checked to determine Segments into a TCP connection are always checked to determine
whether their authentication should be present and valid. whether their authentication should be present and valid.
This is supported - see Section 9.5. This is supported - see Section 7.5.
e. Non-interaction with TCP MD5. e. Non-interaction with TCP MD5.
The use of this option for a given connection should not The use of this option for a given connection should not
preclude the use of TCP MD5, e.g., for legacy use, for other preclude the use of TCP MD5, e.g., for legacy use, for other
connections. connections.
This is supported - see Section 9.7. This is supported - see Section 8.
f. "Hard" ICMP discard. f. "Hard" ICMP discard.
The option should allow certain ICMPs to be discarded, notably The option should allow certain ICMPs to be discarded, notably
Type 3 (destination unreachable), Codes 2-4 (transport Type 3 (destination unreachable), Codes 2-4 (transport protocol
protocol unreachable, port unreachable, or fragmentation unreachable, port unreachable, or fragmentation needed and IP
needed and IP DF field set), i.e., the ones indicating the DF field set), i.e., the ones indicating the failure of the
failure of the endpoint to communicate. endpoint to communicate.
This is supported - see Section 13. This is supported - see Section 7.8.
g. Maintain TCP connection semantics, in which the socket pair g. Maintain TCP connection semantics, in which the socket pair
alone defines a TCP association and all its security alone defines a TCP association and all its security
parameters. parameters.
This is supported - see Sections 5 and 11. This is supported - see Sections 3 and 9.
13. Security Considerations 11. Security Considerations
Use of TCP-AO, like use of TCP MD5 or IPsec, will impact host Use of TCP-AO, like the use of TCP MD5 or IPsec, will impact host
performance. Connections that are known to use TCP-AO can be attacked performance. Connections that are known to use TCP-AO can be
by transmitting segments with invalid MACs. Attackers would need to attacked by transmitting segments with invalid MACs. Attackers would
know only the TCP connection ID and TCP-AO Length value to need to know only the TCP connection ID and TCP-AO Length value to
substantially impact the host's processing capacity. This is similar substantially impact the host's processing capacity. This is similar
to the susceptibility of IPsec to on-path attacks, where the IP to the susceptibility of IPsec to on-path attacks, where the IP
addresses and SPI would be visible. For IPsec, the entire SPI space addresses and SPI would be visible. For IPsec, the entire SPI space
(32 bits) is arbitrary, whereas for routing protocols typically only (32 bits) is arbitrary, whereas for routing protocols typically only
the source port (16 bits) is arbitrary (typically with less than 16 the source port (16 bits) is arbitrary (typically with less than 16
bits of randomness [La09]). As a result, it would be easier for an bits of randomness [La10]). As a result, it would be easier for an
off-path attacker to spoof a TCP-AO segment that could cause receiver off-path attacker to spoof a TCP-AO segment that could cause receiver
validation effort. However, we note that between Internet routers validation effort. However, we note that between Internet routers,
both ports could be arbitrary (i.e., determined a-priori out of both ports could be arbitrary (i.e., determined a priori out of
band), which would constitute roughly the same off-path antispoofing band), which would constitute roughly the same off-path antispoofing
protection of an arbitrary SPI. protection of an arbitrary SPI.
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
outs, rather than more responsive recovery after such a crash. timeouts, rather than a 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. 7.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 and the connection is ACK is received without an expected TCP-AO and the connection 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 TCP-AO. 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 mechanisms 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 7.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
calculation. This prevents different concurrent connections using the calculation. This prevents different concurrent connections using
same MKT (for whatever reason) from potentially enabling a traffic- the same MKT (for whatever reason) from potentially enabling a
crossing attack, in which segments to one socket pair are diverted to traffic-crossing attack, in which segments to one socket pair are
attack a different socket pair. When multiple connections use the diverted to attack a different socket pair. When multiple
same MKT, it would be useful to know that segments intended for one connections use the same MKT, it would be useful to know that
ID could not be (maliciously or otherwise) modified in transit and segments intended for one ID could not be (maliciously or otherwise)
end up being authenticated for the other ID. That requirement would modified in transit and end up being authenticated for the other ID.
place an additional burden of uniqueness on MKTs within endsystems, That requirement would place an additional burden of uniqueness on
and potentially across endsystems. Although the resulting attack is MKTs within endsystems, and potentially across endsystems. Although
low probability, the protection afforded by including the received ID the resulting attack is low probability, the protection afforded by
warrants its inclusion in the MAC, and does not unduly increase the including the received ID warrants its inclusion in the MAC, and does
MAC calculation or MKT management. not unduly increase the MAC calculation or MKT management.
The use of any security algorithm can present an opportunity for a The use of any security algorithm can present an opportunity for a
CPU DOS attack, where the attacker sends false, random segments that CPU Denial-of-Service (DoS) attack, where the attacker sends false,
the receiver under attack expends substantial CPU effort to reject. random segments that the receiver under attack expends substantial
In IPsec, such attacks are reduced by the use of a large Security CPU effort to reject. In IPsec, such attacks are reduced by the use
Parameter Index (SPI) and Sequence Number fields to partly validate of a large Security Parameter Index (SPI) and Sequence Number fields
segments before CPU cycles are invested validated the Integrity Check to partly validate segments before CPU cycles are invested validated
Value (ICV). In TCP-AO, the socket pair performs most of the function the Integrity Check Value (ICV). In TCP-AO, the socket pair performs
of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay most of the function of IPsec's SPI, and IPsec's Sequence Number,
attacks, isn't needed due to TCP's Sequence Number, which is used to used to avoid replay attacks, isn't needed due to TCP's Sequence
reorder received segments (provided the sequence number doesn't wrap Number, which is used to reorder received segments (provided the
around, which is why TCP-AO adds the SNE in Section 8.2). TCP already sequence number doesn't wrap around, which is why TCP-AO adds the SNE
protects itself from replays of authentic segment data as well as in Section 6.2). TCP already protects itself from replays of
authentic explicit TCP control (e.g., SYN, FIN, ACK bits, but even authentic segment data as well as authentic explicit TCP control
authentic replays could affect TCP congestion control [Sa99]. TCP-AO (e.g., SYN, FIN, ACK bits) but even authentic replays could affect
does not protect TCP congestion control from this last form of attack TCP congestion control [Sa99]. TCP-AO does not protect TCP
due to the cumbersome nature of layering a windowed security sequence congestion control from this last form of attack due to the
number within TCP in addition to TCP's own sequence number; when such cumbersome nature of layering a windowed security sequence 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 TCP-AO, because doing so could separate Sequence Number field to TCP-AO, because doing so 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 12. IANA Considerations
[Paragraphs below in braces should be removed by the RFC Editor upon
publication]
[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 entry for the TCP MD5 option should be listed as "Obsoleted by
TCP-AO in IANA tables.]
The TCP Authentication Option (TCP-AO) was assigned TCP option TCP- The TCP Authentication Option (TCP-AO) was assigned TCP option 29 by
IANA-KIND by IANA action. IANA action.
This document defines no new namespaces. 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 [RFC5926].
15. References
15.1. Normative References 13. References
[Le09] Lebovitz, G., E. Rescorla, "Cryptographic Algorithms for 13.1. Normative References
TCP's Authentication Option, TCP-AO", draft-ietf-tcpm-tcp-
ao-crypto-02, Oct. 2009.
[RFC793] Postel, J., "Transmission Control Protocol," STD-7, [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
RFC-793, Standard, Sept. 1981. 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts -- [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers," RFC-1122, Oct. 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2018] Mathis, M., J. Mahdavi, S. Floyd, A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgement Options", RFC-2018, Proposed Selective Acknowledgment Options", RFC 2018, October 1996.
Standard, April 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP-14, RFC-2119, Best Current Requirement Levels", BCP 14, RFC 2119, March 1997.
Practice, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option," RFC-2385, Proposed Standard, Aug. 1998. Signature Option", RFC 2385, August 1998.
[RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP
and AH," RFC-2403, Proposed Standard, Nov. 1998. and AH", RFC 2403, November 1998.
[RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification," RFC-2460, Proposed Standard, Dec. (IPv6) Specification", RFC 2460, December 1998.
1998.
[RFC2883] Floyd, S., J. Mahdavi, M. Mathis, M. Podolsky, "An [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option Extension to the Selective Acknowledgement (SACK) Option
for TCP", RFC-2883, Proposed Standard, July 2000. for TCP", RFC 2883, July 2000.
[RFC3517] Blanton, E., M. Allman, K. Fall, L. Wang, "A Conservative [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
Selective Acknowledgment (SACK)-based Loss Recovery Conservative Selective Acknowledgment (SACK)-based Loss
Algorithm for TCP", RFC-3517, Proposed Standard, April Recovery Algorithm for TCP", RFC 3517, April 2003.
2003.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol",
RFC-4306, Proposed Standard, Dec. 2005. RFC 4306, December 2005.
[RFC4724] Sangli, S., E. Chen, R. Fernando, J. Scudder, Y. Rekhter, [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
"Graceful Restart Mechanism for BGP," RFC-4724, Jan. 2007. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
January 2007.
[RFC4271] Rekhter, Y, T. Li, S. Hares, "A Border Gateway Protocol 4 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border
(BGP-4)," RFC-4271, Jan. 2006. Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4781] Rekhter, Y., R. Aggarwal, "Graceful Restart Mechanism for [RFC4781] Rekhter, Y. and R. Aggarwal, "Graceful Restart Mechanism
BGP with MPLS," RFC-4781, Jan. 2007. for BGP with MPLS", RFC 4781, January 2007.
15.2. Informative References [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for
the TCP Authentication Option (TCP-AO)", RFC 5926, June
2010.
[Ba09] Bashyam, M., M. Jethanandani,, A. Ramaiah "Clarification of 13.2. Informative References
sender behaviour in persist condition," draft-ananth-tcpm-
persist-02, (work in progress), Jan. 2010.
[Be07] Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem [Ba10] Bashyam, M., Jethanandani, M., and A. Ramaiah
Statement and Requirements for a TCP Authentication "Clarification of sender behaviour in persist condition",
Option," draft-bellovin-tcpsec-01, (work in progress), Jul. Work in Progress, January 2010.
2007.
[Bo07] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler, [Bo07] Bonica, R., Weis, B., Viswanathan, S., Lange, A., and O.
"Authentication for TCP-based Routing and Management Wheeler, "Authentication for TCP-based Routing and
Protocols," draft-bonica-tcp-auth-06, (work in progress), Management Protocols", Work in Progress, February 2007.
Feb. 2007.
[Bo09] Borman, D., "TCP Options and MSS," draft-ietf-tcpm-tcpmss- [Bo09] Borman, D., "TCP Options and MSS", Work in Progress, July
02, Jul. 2009. 2009.
[La09] Larsen, M., F. Gont, "Port Randomization," draft-ietf- [Ed07] Eddy, W., Ed., Bellovin, S., Touch, J., and R. Bonica,
tsvwg-port-randomization-06, Feb. 2010. "Problem Statement and Requirements for a TCP
Authentication Option", Work in Progress, July 2007.
[Go09] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- [Go10] Gont, F., "ICMP Attacks against TCP", Work in Progress,
attacks-11, (work in progress), Feb. 2010. March 2010.
[Le09] Lepinski, M., S. Kent, "An Infrastructure to Support Secure [La10] Larsen, M. and F. Gont, "Transport Protocol Port
Internet Routing," draft-ietf-sidr-arch-09, (work in Randomization Recommendations", Work in Progress, April
progress), Oct. 2009. 2010.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, [Le09] Lepinski, M. and S. Kent, "An Infrastructure to Support
Informational, April 1992. Secure Internet Routing", Work in Progress, October 2009.
[RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
High Performance," RFC-1323, May 1992. April 1992.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks," [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
RFC-1948, Informational, May 1996. for High Performance", RFC 1323, May 1992.
[RFC2104] Krawczyk, H., M. Bellare, R. Canetti, "HMAC: Keyed-Hashing [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
for Message Authentication," RFC-2104, Informational, Feb. RFC 1948, May 1996.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997. 1997.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC 2663, Translator (NAT) Terminology and Considerations", RFC 2663,
August 1999. August 1999.
[RFC3234] Carpenter, B., S. Brim, "Middleboxes: Taxonomy and Issues," [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
RFC-3234, Informational, Feb. 2002. Issues", RFC 3234, February 2002.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option," RFC-3562, Informational, July 2003. Signature Option", RFC 3562, July 2003.
[RFC3947] Kivinen, T., B. Swander, A. Huttunen, V. Volpe, [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE," RFC-3947, "Negotiation of NAT-Traversal in the IKE", RFC 3947,
Proposed Standard, Jan. 2005. January 2005.
[RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Protocol," RFC-4301, Proposed Standard, Dec. 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5," [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC
RFC-4808, Informational, Mar. 2007. 4808, March 2007.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks," [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC
RFC-4953, Informational, Jul. 2007. 4953, July 2007.
[RFC5246] Dierks, T., E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2," RFC-5246, Aug. 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[Sa99] Savage, S., N. Cardwell, D. Wetherall, T. Anderson, "TCP [Sa99] Savage, S., N. Cardwell, D. Wetherall, T. Anderson, "TCP
Congestion Control with a Misbehaving Receiver," ACM Congestion Control with a Misbehaving Receiver", ACM
Computer Communications Review, V29, N5, pp71-78, October Computer Communications Review, V29, N5, pp71-78, October
1999. 1999.
[SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4)," [SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4)",
Specification SDN.401, Revision 1.2, July 12, 1988. Specification SDN.401, Revision 1.2, July 12, 1988.
[To06] Touch, J., A. Mankin, "The TCP Simple Authentication [To07] Touch, J. and A. Mankin, "The TCP Simple Authentication
Option," draft-touch-tcpm-tcp-simple-auth-03, (expired work Option", Work in Progress, July 2007.
in progress), Oct. 2006.
[To10] Touch, J., "A TCP Authentication Option NAT Extension," [To10] Touch, J., "A TCP Authentication Option NAT Extension",
draft-touch-tcp-ao-nat-01, Jan. 2010. Work in Progress, January 2010.
[Wa05] Wang, X., H. Yu, "How to break MD5 and other hash [Wa05] Wang, X., H. Yu, "How to break MD5 and other hash
functions," Proc. IACR Eurocrypt 2005, Denmark, pp.19-35. functions", Proc. IACR Eurocrypt 2005, Denmark, pp.19-35.
[We05] Weis, B., "TCP Message Authentication Code Option," draft- [We05] Weis, B., Appanna, C., McGrew, D., and A. Ramaiah, "TCP
weis-tcp-mac-option-00, (expired work in progress), Dec. Message Authentication Code Option", Work in Progress,
2005. December 2005.
16. Acknowledgments 14. Acknowledgments
This document evolved as the result of collaboration of the TCP
Authentication Design team (tcp-auth-dt), whose members were
(alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy,
Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy
Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus
Westerlund. The text of this document is derived from a proposal by
Joe Touch and Allison Mankin [To07] (originally from June 2006),
which was both inspired by and intended as a counterproposal to the
revisions to TCP MD5 suggested in a document by Ron Bonica, Brian
Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07]
(originally from September 2005) and in a document by Brian Weis
[We05].
Russ Housley suggested L4/application layer management of the master
key tuples. Steve Bellovin motivated the KeyID field. Eric Rescorla
suggested the use of TCP's Initial Sequence Numbers (ISNs) in the
traffic key computation and SNEs to avoid replay attacks, and Brian
Weis extended the computation to incorporate the entire connection ID
and provided the details of the traffic key computation. Mark
Allman, Wes Eddy, Lars Eggert, Ted Faber, Russ Housley, Gregory
Lebovitz, Tim Polk, Eric Rescorla, Joe Touch, and Brian Weis
developed the master key coordination mechanism.
Alfred Hoenes, Charlie Kaufman, Adam Langley, and numerous other Alfred Hoenes, Charlie Kaufman, Adam Langley, and numerous other
members of the TCPM WG provided substantial feedback on this members of the TCPM WG also provided substantial feedback on this
document. document.
This document was prepared using 2-Word-v2.0.template.dot. This document was originally prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Joe Touch Joe Touch
USC/ISI USC/ISI
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292-6695 Marina del Rey, CA 90292-6695
U.S.A. U.S.A.
Phone: +1 (310) 448-9151 Phone: +1 (310) 448-9151
Email: touch@isi.edu EMail: touch@isi.edu
URL: http://www.isi.edu/touch URL: http://www.isi.edu/touch
Allison Mankin Allison Mankin
Johns Hopkins Univ. Johns Hopkins Univ.
Washington, DC Baltimore, MD
U.S.A. U.S.A.
Phone: 1 301 728 7199 Phone: 1 301 728 7199
Email: mankin@psg.com EMail: mankin@psg.com
URL: http://www.psg.com/~mankin/ URL: http://www.psg.com/~mankin/
Ronald P. Bonica Ronald P. Bonica
Juniper Networks Juniper Networks
2251 Corporate Park Drive 2251 Corporate Park Drive
Herndon, VA 20171 Herndon, VA 20171
U.S.A. U.S.A.
Email: rbonica@juniper.net EMail: rbonica@juniper.net
 End of changes. 428 change blocks. 
1065 lines changed or deleted 1028 lines changed or added

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