draft-ietf-tcpm-tcp-auth-opt-08.txt   draft-ietf-tcpm-tcp-auth-opt-09.txt 
TCPM WG J. Touch TCPM WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Obsoletes: 2385 A. Mankin Obsoletes: 2385 A. Mankin
Intended status: Proposed Standard Johns Hopkins Univ. Intended status: Proposed Standard Johns Hopkins Univ.
Expires: April 2010 R. Bonica Expires: July 2010 R. Bonica
Juniper Networks Juniper Networks
October 27, 2009 January 31, 2010
The TCP Authentication Option The TCP Authentication Option
draft-ietf-tcpm-tcp-auth-opt-08.txt draft-ietf-tcpm-tcp-auth-opt-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 27, 2010. This Internet-Draft will expire on July 31, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. 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 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-AO
uses its own option identifier, even though used mutually exclusive uses a different option identifier than TCP MD5, even though TCP-AO
of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is and TCP MD5 are never permitted to be used simultaneously. TCP-AO
fully compatible with the proposed requirements for the replacement supports IPv6, and is fully compatible with the proposed requirements
of TCP MD5. for the replacement of TCP MD5.
Table of Contents Table of Contents
1. Contributors...................................................3 1. Contributors...................................................3
2. Introduction...................................................4 2. Introduction...................................................4
2.1. Executive Summary.........................................4 2.1. Applicability Statement...................................4
3. Conventions used in this document..............................6 2.2. Executive Summary.........................................5
4. The TCP Authentication Option..................................6 3. Conventions used in this document..............................7
4.1. Review of TCP MD5 Option..................................6 4. The TCP Authentication Option..................................7
4.2. The TCP-AO Option.........................................7 4.1. Review of TCP MD5 Option..................................7
5. TCP-AO Keys and Their Properties...............................9 4.2. The TCP-AO Option.........................................8
5.1. Master Key Tuple..........................................9
5.2. Traffic Keys.............................................11 5. TCP-AO Keys and Their Properties..............................10
5.3. MKT Properties...........................................12 5.1. Master Key Tuple.........................................10
6. Per-Connection TCP-AO Parameters..............................13 5.2. Traffic Keys.............................................12
7. Cryptographic Algorithms......................................14 5.3. MKT Properties...........................................13
7.1. MAC Algorithms...........................................14 6. Per-Connection TCP-AO Parameters..............................14
7.2. Key Derivation Functions.................................17 7. Cryptographic Algorithms......................................15
7.3. Traffic Key Establishment and Duration Issues............21 7.1. MAC Algorithms...........................................15
7.3.1. MKT Reuse Across Socket Pairs.......................21 7.2. Traffic Key Derivation Functions.........................18
7.3.2. MKTs Use Within a Long-lived Connection.............22 7.3. Traffic Key Establishment and Duration Issues............22
8. Additional Security Mechanisms................................22 7.3.1. MKT Reuse Across Socket Pairs.......................22
8.1. Coordinating Use of New MKTs.............................22 7.3.2. MKTs Use Within a Long-lived Connection.............23
8.2. Preventing replay attacks within long-lived connections..23 8. Additional Security Mechanisms................................23
9. TCP-AO Interaction with TCP...................................25 8.1. Coordinating Use of New MKTs.............................23
9.1. TCP User Interface.......................................26 8.2. Preventing replay attacks within long-lived connections..24
9.2. TCP States and Transitions...............................27 9. TCP-AO Interaction with TCP...................................26
9.3. TCP Segments.............................................27 9.1. TCP User Interface.......................................27
9.4. Sending TCP Segments.....................................28 9.2. TCP States and Transitions...............................28
9.5. Receiving TCP Segments...................................29 9.3. TCP Segments.............................................28
9.6. Impact on TCP Header Size................................31 9.4. Sending TCP Segments.....................................29
10. Obsoleting TCP MD5 and Legacy Interactions...................32 9.5. Receiving TCP Segments...................................30
11. Interactions with Middleboxes................................32 9.6. Impact on TCP Header Size................................32
11.1. Interactions with non-NAT/NAPT Middleboxes..............33 9.7. Connectionless Resets....................................33
11.2. Interactions with NAT/NAPT Devices......................33 10. Obsoleting TCP MD5 and Legacy Interactions...................34
12. Evaluation of Requirements Satisfaction......................33 11. Interactions with Middleboxes................................34
13. Security Considerations......................................39 11.1. Interactions with non-NAT/NAPT Middleboxes..............34
14. IANA Considerations..........................................41 11.2. Interactions with NAT/NAPT Devices......................35
15. References...................................................42 12. Evaluation of Requirements Satisfaction......................35
15.1. Normative References....................................42 13. Security Considerations......................................41
15.2. Informative References..................................43 14. IANA Considerations..........................................43
16. Acknowledgments..............................................44 15. References...................................................44
15.1. Normative References....................................44
15.2. Informative References..................................45
16. Acknowledgments..............................................47
1. Contributors 1. Contributors
This document evolved as the result of collaboration of the TCP This document evolved as the result of collaboration of the TCP
Authentication Design team (tcp-auth-dt), whose members were Authentication Design team (tcp-auth-dt), whose members were
(alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy, (alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy,
Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy
Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus
Westerlund. The text of this document is derived from a proposal by Westerlund. The text of this document is derived from a proposal by
Joe Touch and Allison Mankin [To06] (originally from June 2006), Joe Touch and Allison Mankin [To06] (originally from June 2006),
skipping to change at page 4, line 31 skipping to change at page 4, line 41
lack sufficient remaining space to handle such a negotiation (see lack sufficient remaining space to handle such a negotiation (see
Section 9.6). This document obsoletes the TCP MD5 option with a more Section 9.6). This document obsoletes the TCP MD5 option with a more
general TCP Authentication Option (TCP-AO), to support the use of general TCP Authentication Option (TCP-AO), to support the use of
other, stronger hash functions, provide replay protection for long- other, stronger hash functions, provide replay protection for long-
lived connections and across repeated instances of a single lived connections and across repeated instances of a single
connection, coordinate key changes between endpoints, and to provide connection, coordinate key changes between endpoints, and to provide
a more structured recommendation on external key management. The a more structured recommendation on external key management. The
result is compatible with IPv6, and is fully compatible with proposed result is compatible with IPv6, and is fully compatible with proposed
requirements for a replacement for TCP MD5 [Be07]. requirements for a replacement for TCP MD5 [Be07].
This document is not intended to replace the use of the IPsec suite TCP-AO obsoletes TCP MD5, although a particular implementation may
(IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In support both mechanisms for backward compatibility. For a given
fact, we recommend the use of IPsec and IKE, especially where IKE's connection, only one can be in use. TCP MD5-protected connections
level of existing support for parameter negotiation, session key cannot be migrated to TCP-AO because TCP MD5 does not support any
negotiation, or rekeying are desired. TCP-AO is intended for use only changes to a connection's security algorithm once established.
where the IPsec suite would not be feasible, e.g., as has been
suggested is the case to support some routing protocols, or in cases
where keys need to be tightly coordinated with individual transport
sessions [Be07].
Note that TCP-AO obsoletes TCP MD5, although a particular 2.1. Applicability Statement
implementation may support both mechanisms for backward
compatibility. For a given connection, only one can be in use. TCP
MD5-protected connections cannot be migrated to TCP-AO because TCP
MD5 does not support any changes to a connection's security algorithm
once established.
2.1. Executive Summary 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
LDP. It is also intended to provide similar protection to any long-
lived TCP connection, as might be used between proxy caches, e.g.,
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 enhances the capabilities of TCP MD5 as summarized in Section
2.2.
TCP-AO not intended to replace the use of the IPsec suite (IPsec and
IKE) to protect TCP connections [RFC4301][RFC4306]. Specific
differences are noted in Section 2.2. In fact, we recommend the use
of IPsec and IKE, especially where IKE's level of existing support
for parameter negotiation, session key negotiation, or rekeying are
desired. TCP-AO is intended for use only where the IPsec suite would
not be feasible, e.g., as has been suggested is the case to support
some routing protocols [RFC4953], or in cases where keys need to be
tightly coordinated with individual transport sessions [Be07].
TCP-AO is not intended to replace the use of Transport Layer Security
(TLS) [RFC5246], sBGP or soBGP [Le09], or any other mechanisms that
protect only the TCP data stream. TCP-AO protects the transport
layer, preventing attacks from disabling the TCP connection itself
[RFC4953]. Data stream mechanisms protect only the contents of the
TCP segments, and can be disrupted when the connection is affected.
Some of these data protection protocols - notably TLS - offer a
richer set of key management and authentication mechanisms than TCP-
AO, and thus protect the data stream in a different way. TCP-AO may
be used together with these data stream protections to complement
each others' strengths.
2.2. Executive Summary
This document replaces TCP MD5 as follows [RFC2385]: This document replaces TCP MD5 as follows [RFC2385]:
o TCP-AO uses a separate option Kind for TCP-AO (TBD-IANA-KIND). o TCP-AO uses a separate option Kind for TCP-AO (TBD-IANA-KIND).
o TCP-AO allows TCP MD5 to continue to be used concurrently for o TCP-AO allows TCP MD5 to continue to be used concurrently for
legacy connections. legacy connections.
o TCP-AO replaces MD5's single MAC algorithm with MACs specified in o TCP-AO replaces MD5's single MAC algorithm with MACs specified in
a separate document and can be extended to include other MACs. a separate document and can be extended to include other MACs.
skipping to change at page 6, line 42 skipping to change at page 7, line 36
The TCP Authentication Option (TCP-AO) uses a TCP option Kind value The TCP Authentication Option (TCP-AO) uses a TCP option Kind value
of TBD-IANA-KIND. of TBD-IANA-KIND.
4.1. Review of TCP MD5 Option 4.1. Review of TCP MD5 Option
For review, the TCP MD5 option is shown in Figure 1. For review, the TCP MD5 option is shown in Figure 1.
+---------+---------+-------------------+ +---------+---------+-------------------+
| Kind=19 |Length=18| MD5 digest... | | Kind=19 |Length=18| MD5 digest... |
+---------+---------+-------------------+ +---------+---------+-------------------+
| | | ...digest (con't)... |
+---------------------------------------+ +---------------------------------------+
| | | ... |
+---------------------------------------+ +---------------------------------------+
| | | ... |
+-------------------+-------------------+ +-------------------+-------------------+
| | | ...digest (con't) |
+-------------------+ +-------------------+
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:
skipping to change at page 8, line 49 skipping to change at page 9, line 49
further in Section 8.1. Note that the RNextKeyID has no further in Section 8.1. Note that the RNextKeyID has no
cryptographic properties - it need not be random, nor are there cryptographic properties - it need not be random, nor are there
any reserved values. any reserved values.
o MAC: Message Authentication Code. Its contents are determined by o MAC: Message Authentication Code. Its contents are determined by
the particulars of the security association. Typical MACs are 96- the particulars of the security association. Typical MACs are 96-
128 bits (12-16 bytes), but any length that fits in the header of 128 bits (12-16 bytes), but any length that fits in the header of
the segment being authenticated is allowed. The MAC computation is the segment being authenticated is allowed. The MAC computation is
described further in Section 7.1. described further in Section 7.1.
>> Required support for TCP-AO MACs are defined in [ao-crypto]; >> Required support for TCP-AO MACs are defined in [Le09]; other
other MACs MAY be supported. MACs MAY be supported.
The TCP-AO option fields do not indicate the MAC algorithm either The TCP-AO option fields do not indicate the MAC algorithm either
implicitly (as with TCP MD5) or explicitly. The particular algorithm implicitly (as with TCP MD5) or explicitly. The particular algorithm
used is considered part of the configuration state of the used is considered part of the configuration state of the
connection's security and is managed separately (see Section 5). connection's security and is managed separately (see Section 5).
Please note that the use of TCP-AO does not affect TCP's advertised Please note that the use of TCP-AO does not affect TCP's advertised
maximum segment size (MSS), as is the case for all TCP options maximum segment size (MSS), as is the case for all TCP options
[Bo09]. [Bo09].
skipping to change at page 10, line 36 skipping to change at page 11, line 36
may be derived from a separate shared key by an external protocol may be derived from a separate shared key by an external protocol
over a separate channel. This sequence is used in the traffic key over a separate channel. This sequence is used in the traffic key
generation algorithm described in Section 7.2. generation algorithm described in Section 7.2.
Implementations are advised to keep master key values in a Implementations are advised to keep master key values in a
private, protected area of memory or other storage. private, protected area of memory or other storage.
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. Explained further in Section 7.1 of this document and
specified in detail in [ao-crypto]. specified in detail in [Le09].
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,
explained further in Section 7.1 of this document and specified in explained further in Section 7.1 of this document and specified in
detail in [ao-crypto]. detail in [Le09].
>> Components of a MKT MUST NOT change during a connection. >> Components of a 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.
skipping to change at page 11, line 21 skipping to change at page 12, line 21
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 a 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 5.2. Traffic Keys
A traffic key is a key derived from the MKT and the properties of a A traffic key is a key derived from the MKT and the local and remote
connection. For established connections, these properties include the IP address pairs and TCP port numbers, and, for established
socket pair (local IP address, local TCP port, remote IP address, connections, the TCP Initial Sequence Numbers (ISNs) in each
remote port), and 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 MKTs: A single MKT can be used to derive any of four different traffic
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
skipping to change at page 14, line 14 skipping to change at page 15, line 14
Section 7.2. These traffic keys can be cached after computation, and Section 7.2. These traffic keys can be cached after computation, and
can be stored in the TCB with the corresponding MKT information. They can be stored in the TCB with the corresponding MKT information. They
can be considered part of the per-connection parameters. can be considered part of the per-connection parameters.
7. Cryptographic Algorithms 7. Cryptographic Algorithms
TCP-AO also uses cryptographic algorithms to compute the MAC (Message TCP-AO also uses cryptographic algorithms to compute the MAC (Message
Authentication Code) used to authenticate a segment and its headers; Authentication Code) used to authenticate a segment and its headers;
these are called MAC algorithms and are specified in a separate these are called MAC algorithms and are specified in a separate
document to facilitate updating the algorithm requirements document to facilitate updating the algorithm requirements
independently from the protocol [ao-crypto]. TCP-AO also uses independently from the protocol [Le09]. TCP-AO also uses
cryptographic algorithms to convert MKTs, which can be shared across cryptographic algorithms to convert MKTs, which can be shared across
connections, into unique traffic keys for each connection. These are connections, into unique traffic keys for each connection. These are
called Key Derivation Functions (KDFs), and are specified [ao- called Key Derivation Functions (KDFs), and are specified [Le09].
crypto]. This section describes how these algorithms are used by TCP- This section describes how these algorithms are used by TCP-AO.
AO.
7.1. MAC Algorithms 7.1. MAC Algorithms
MAC algorithms take a variable-length input and a key and output a MAC algorithms take a variable-length input and a key and output a
fixed-length number. This number is used to determine whether the fixed-length number. This number is used to determine whether the
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 in transit. MACs for TCP-AO have the following
interface: 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 [ao-crypto]. described in [Le09].
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. 7.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 7.1.
o MAC - the fixed-length output of the MAC algorithm, given the o MAC - the fixed-length output of the MAC algorithm, given the
parameters provided. parameters provided.
At the time of this writing, the algorithms' definitions for use in At the time of this writing, the algorithms' definitions for use in
TCP-AO, as described in [ao-crypto] are each truncated to 96 bits. TCP-AO, as described in [Le09] are each truncated to 96 bits. Though
Though the algorithms each output a larger MAC, 96 bits provides a the algorithms each output a larger MAC, 96 bits provides a
reasonable tradeoff between security and message size, for fitting reasonable tradeoff between security and message size, for fitting
into the TCP-AO header. Though could change in the future, so TCP-AO into the TCP-AO header. Though could change in the future, so TCP-AO
header sizes should not be assumed as fixed length. header sizes should not be assumed 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 [ao-crypto]'s definitions. done so by definition in the MKT, per [Le09]'s definitions.
The mandatory-to-implement MAC algorithms for use with TCP-AO are The mandatory-to-implement MAC algorithms for use with TCP-AO are
described in a separate RFC [ao-crypto]. This allows the TCP-AO described in a separate RFC [Le09]. This allows the TCP-AO
specification to proceed along the standards track even if changes specification to proceed along the standards track even if changes
are needed to its associated algorithms and their labels (as might be are needed to its associated algorithms and their labels (as might be
used in a user interface or automated MKT management protocol) as a used in a user interface or automated MKT management protocol) as a
result of the ever evolving world of cryptography. result of the ever evolving world of cryptography.
>> Additional algorithms, beyond those mandated for TCP-AO, MAY be >> Additional algorithms, beyond those mandated for TCP-AO, MAY be
supported. supported.
The data input to the MAC is the following fields in the following The data input to the MAC is the following fields in the following
sequence, interpreted in network-standard byte order: sequence, interpreted in network-standard byte order:
skipping to change at page 17, line 24 skipping to change at page 18, line 24
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 is
zeroed for the MAC processing. 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, e.g., as HMACs do
[RFC2104][RFC2403]. The traffic key is derived from the current MKT [RFC2104][RFC2403]. The traffic key is derived from the current MKT
as described in Sections 7.2. as described in Sections 7.2.
7.2. Key Derivation Functions 7.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 [ao- indicated in the MKT. This is specified as described in [Le09].
crypto].
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 [ao-crypto]. The specific way this traffic_key, as specified in [Le09]. The specific way this context
context is used, in conjunction with other information, to create is used, in conjunction with other information, to create the raw
the raw input to the KDF is also explained further in [ao-crypto]. input to the KDF is also explained further in [Le09].
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 [ao-crypto]. specified as described in [Le09].
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 7.1.
The context used as input to the KDF combines TCP socket pair with The context used as input to the KDF combines TCP socket pair with
the endpoint initial sequence numbers (ISNs) of a connection. This the endpoint initial sequence numbers (ISNs) of a connection. This
data is unique to each TCP connection instance, which enables TCP-AO data is unique to each TCP connection instance, which enables TCP-AO
to generate unique traffic keys for that connection, even from a MKT to generate unique traffic keys for that connection, even from a MKT
used across many different connections or across repeated connections used across many different connections or across repeated connections
skipping to change at page 20, line 50 skipping to change at page 21, line 50
unlikely because both endpoints should select ISNs pseudorandomly unlikely because both endpoints should select ISNs pseudorandomly
[RFC1948], their 32-bit space avoids repeated use except under [RFC1948], 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). connection).
A SYN is authenticated using a destination ISN of zero (whether sent A SYN is authenticated using a destination ISN of zero (whether sent
or received), and all other segments would be authenticated using the or received), and all other segments would be authenticated using the
ISN pair for the connection. There are other cases in which the ISN pair for the connection. There are other cases in which the
destination ISN is not known, but segments are emitted, such as after destination ISN is not known, but segments are emitted, such as after
an endpoint reboots, when is possible that the two endpoints would an endpoint reboots, when is possible that the two endpoints would
not have enough information to authenticate segments. In such cases, not have enough information to authenticate segments. This is
TCP's timeout mechanism will allow old state to be cleared to enable addressed further in Section 9.7.
new connections, except where the user timeout is disabled; it is
important that implementations are capable of detecting excesses of
TCP connections in such a configuration and can clear them out if
needed to protect its memory usage [Ba09].
7.3. Traffic Key Establishment and Duration Issues 7.3. Traffic Key Establishment and Duration Issues
The TCP-AO option does not provide a mechanism for traffic key The TCP-AO option does not provide a mechanism for traffic key
negotiation or parameter negotiation (MAC algorithm, length, or use negotiation or parameter negotiation (MAC algorithm, length, or use
of the TCP-AO option), or for coordinating rekeying during a of the TCP-AO option), or for coordinating rekeying during a
connection. We assume out-of-band mechanisms for MKT establishment, connection. We assume out-of-band mechanisms for MKT establishment,
parameter negotiation, and rekeying. This separation of MKT use from parameter negotiation, and rekeying. This separation of MKT use from
MKT management is similar to that in the IPsec security suite MKT management is similar to that in the IPsec security suite
[RFC4301][RFC4306]. [RFC4301][RFC4306].
skipping to change at page 31, line 14 skipping to change at page 32, line 14
prepends a fixed value to the computed portion and a corresponding prepends a fixed value to the computed portion and a corresponding
validation algorithm that verifies the fixed value before investing validation algorithm that verifies the fixed value before investing
in the computed portion. Such optimizations would be contained in the in the computed portion. Such optimizations would be contained in the
MAC algorithm specification, and thus are not specified in TCP-AO MAC algorithm specification, and thus are not specified in TCP-AO
explicitly. Note that the KeyID cannot be used for connection explicitly. Note that the KeyID cannot be used for connection
validation per se, because it is not assumed random. validation per se, because it is not assumed random.
9.6. Impact on TCP Header Size 9.6. Impact on TCP Header Size
The TCP-AO option, using the initially required 96-bit MACs, uses a The TCP-AO option, using the initially required 96-bit MACs, uses a
total of 16 bytes of TCP header space [ao-crypto]. TCP-AO is thus 2 total of 16 bytes of TCP header space [Le09]. TCP-AO is thus 2 bytes
bytes smaller than the TCP MD5 option (18 bytes). smaller than the TCP MD5 option (18 bytes).
Note that TCP option space is most critical in SYN segments, because Note that TCP option space is most critical in SYN segments, because
flags in those segments could potentially increase the option space flags in those segments could potentially increase the option space
area in other segments. Because TCP ignores unknown segments, area in other segments. Because TCP ignores unknown segments,
however, it is not possible to extend the option space of SYNs however, it is not possible to extend the option space of SYNs
without breaking backward-compatibility. without breaking backward-compatibility.
TCP's 4-bit data offset requires that the options end 60 bytes (15 TCP's 4-bit data offset requires that the options end 60 bytes (15
32-bit words) after the header begins, including the 20-byte header. 32-bit words) after the header begins, including the 20-byte header.
This leaves 40 bytes for options, of which 15 are expected in current This leaves 40 bytes for options, of which 15 are expected in current
skipping to change at page 32, line 11 skipping to change at page 33, line 11
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
TCP-AO allows TCP resets (RSTs) to be exchanged provided both sides
have established valid connection state. After such state is
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
happens because the rebooting side has lost its connection state, and
thus its traffic keys.
It is important that implementations are capable of detecting
excesses of TCP connections in such a configuration and can clear
them out if needed to protect its memory usage [Ba09]. To protect
against such state from accumulating and not being cleared out, a
number of recommendations are made:
>> Connections using TCP-AO SHOULD also use TCP keepalives [RFC1122].
The use of keepalives ensures that connections whose keys are lost
are terminated after a finite time. Keepalives help ensure the TCP
state is cleared out in such a case; the alternative, of allowing
unauthenticated RSTs to be received, would allow one of the primary
vulnerabilities that TCP-AO is intended to protect against.
Keepalives ensure that connections are dropped across reboots, but
this can have a detrimental effect on some protocols. In specific,
BGP reacts poorly to such connection drops; "graceful restart" was
introduced to address this effect [RFC4724], and extended to support
BGP with MPLS [RFC4781]. As a result:
>> BGP connections SHOULD require support for graceful restart when
using TCP-AO.
We recognize that support for graceful restart is not always
feasible. As a result:
>> When BGP without graceful restart is used with TCP-AO, both sides
of the connection SHOULD save traffic keys in storage that persists
across reboots and restore them after a reboot, and SHOULD limit any
performance impacts that result from this storage/restoration.
10. Obsoleting TCP MD5 and Legacy Interactions 10. Obsoleting TCP MD5 and Legacy Interactions
TCP-AO obsoletes TCP MD5. As we have noted earlier: TCP-AO obsoletes TCP MD5. As we have noted earlier:
>> TCP implementations MUST support TCP-AO. >> TCP implementations 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:
skipping to change at page 33, line 33 skipping to change at page 35, line 26
TCP-AO cannot interoperate natively across NAT/NAPT devices, which TCP-AO cannot interoperate natively across NAT/NAPT devices, which
modify the IP addresses and/or port numbers. We anticipate that modify the IP addresses and/or port numbers. We anticipate that
traversing such devices may require variants of existing NAT/NAPT traversing such devices may require variants of existing NAT/NAPT
traversal mechanisms, e.g., encapsulation of the TCP-AO-protected traversal mechanisms, e.g., encapsulation of the TCP-AO-protected
segment in another transport segment (e.g., UDP), as is done in IPsec segment in another transport segment (e.g., UDP), as is done in IPsec
[RFC2663][RFC3947]. Such variants can be adapted for use with TCP-AO, [RFC2663][RFC3947]. Such variants can be adapted for use with TCP-AO,
or IPsec NAT traversal can be used instead in such cases [RFC3947]. or IPsec NAT traversal can be used instead 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 [ao-nat]. independently of this specification [To10].
12. Evaluation of Requirements Satisfaction 12. Evaluation of Requirements Satisfaction
TCP-AO satisfies all the current requirements for a revision to TCP TCP-AO satisfies all the current requirements for a revision to TCP
MD5, as summarized below [Be07]. MD5, as summarized below [Be07].
1. Protected Elements 1. Protected Elements
A solution to revising TCP MD5 should protect (authenticate) the A solution to revising TCP MD5 should protect (authenticate) the
following elements. following elements.
skipping to change at page 35, line 41 skipping to change at page 37, line 29
This is supported - see Section 4.2. This is supported - see Section 4.2.
e. Compatible with Large Windows and SACK. e. Compatible with Large Windows and SACK.
The option should be compatible with the use of the Large The option should be compatible with the use of the Large
Windows and SACK options. Windows and SACK options.
This is supported - see Section 9.6. The size of the option is This is supported - see Section 9.6. The size of the option is
intended to allow use with Large Windows and SACK. See also intended to allow use with Large Windows and SACK. See also
Section 2.1, which indicates that TCP-AO is 2 bytes shorter Section 2.2, which indicates that TCP-AO is 2 bytes shorter
than TCP MD5 in the default case, assuming a 96-bit MAC. than TCP MD5 in the default case, assuming a 96-bit MAC.
3. Cryptography requirements 3. Cryptography requirements
A solution to revising TCP MD5 should support modern cryptography A solution to revising TCP MD5 should support modern cryptography
capabilities. capabilities.
a. Baseline defaults. a. Baseline defaults.
The option should have a default that is required in all The option should have a default that is required in all
implementations. implementations.
TCP-AO uses a default required algorithm as specified in [ao- TCP-AO uses a default required algorithm as specified in
crypto], as noted in Section 7.1. [Le09], as noted in Section 7.1.
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 [ao-crypto]. The KDF is also TCP-AO uses MACs as indicated in [Le09]. The KDF is also
specified in [ao-crypto]. The KDF input string follows the specified in [Le09]. The KDF input string follows the typical
typical design (see [ao-crypto]). design (see [Le09]).
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 allow agility over time. to 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 4.2. The use of set of
MKTs allows separate connections to use different algorithms, MKTs allows separate connections to use different algorithms,
both for the MAC and the KDF. both for the MAC and the KDF.
skipping to change at page 39, line 11 skipping to change at page 41, line 11
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 9.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 10. This is supported - see Section 9.7.
f. Optional ICMP discard. f. Optional 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 unreachable, port unreachable, or fragmentation protocol unreachable, port unreachable, or fragmentation
needed and IP DF field set), i.e., the ones indicating the needed and IP DF field set), i.e., the ones indicating the
failure of the endpoint to communicate. failure of the endpoint to communicate.
This is supported - see Section 13. This is supported - see Section 13.
skipping to change at page 39, line 39 skipping to change at page 41, line 39
13. Security Considerations 13. Security Considerations
Use of TCP-AO, like use of TCP MD5 or IPsec, will impact host Use of TCP-AO, like 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 attacked
by transmitting segments with invalid MACs. Attackers would need to by transmitting segments with invalid MACs. Attackers would need to
know only the TCP connection ID and TCP-AO Length value 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. As a result, it would be the source port (16 bits) is arbitrary (typically with less than 16
easier for an off-path attacker to spoof a TCP-AO segment that could bits of randomness [La09]). As a result, it would be easier for an
cause receiver validation effort. However, we note that between off-path attacker to spoof a TCP-AO segment that could cause receiver
Internet routers both ports could be arbitrary (i.e., determined a- validation effort. However, we note that between Internet routers
priori out of band), which would constitute roughly the same off-path both ports could be arbitrary (i.e., determined a-priori out of
antispoofing protection of an arbitrary SPI. band), which would constitute roughly the same off-path antispoofing
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 time-
outs, rather than more responsive recovery after such a crash. As outs, rather than more responsive recovery after such a crash.
noted in Section 7.2, such cases may also result in persistent TCP Recommendations for mitigating this effect are discussed in Section
state for old connections that cannot be cleared, and so 9.7.
implementations should be capable of detecting an excess of such
connections and clearing their state if needed to protect memory
utilization [Ba09].
TCP-AO does not include a fast decline capability, e.g., where a SYN- TCP-AO does not include a fast decline capability, e.g., where a SYN-
ACK is received without an expected TCP-AO option and the connection ACK is received without an expected TCP-AO option and the connection
is quickly reset or aborted. Normal TCP operation will retry and is quickly reset or aborted. Normal TCP operation will retry and
timeout, which is what should be expected when the intended receiver timeout, which is what should be expected when the intended receiver
is not capable of the TCP variant required anyway. Backoff is not is not capable of the TCP variant required anyway. Backoff is not
optimized because it would present an opportunity for attackers on optimized because it would present an opportunity for attackers on
the wire to abort authenticated connection attempts by sending the wire to abort authenticated connection attempts by sending
spoofed SYN-ACKs without the TCP-AO option. spoofed SYN-ACKs without the TCP-AO option.
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. robust security or more sophisticated security management. TCP-AO is
intended to protect the TCP protocol itself from attacks that TLS,
sBGP/soBGP, and other data stream protection mechanism cannot.
TCP-AO does not address the issue of ICMP attacks on TCP. IPsec makes TCP-AO does not address the issue of ICMP attacks on TCP. IPsec makes
recommendations regarding dropping ICMPs in certain contexts, or recommendations regarding dropping ICMPs in certain contexts, or
requiring that they are endpoint authenticated in others [RFC4301]. requiring that they are endpoint authenticated in others [RFC4301].
There are other mechanisms proposed to reduce the impact of ICMP There are other mechanisms proposed to reduce the impact of ICMP
attacks by further validating ICMP contents and changing the effect attacks by further validating ICMP contents and changing the effect
of some messages based on TCP state, but these do not provide the of some messages based on TCP state, but these do not provide the
level of authentication for ICMP that TCP-AO provides for TCP [Go09]. level of authentication for ICMP that TCP-AO provides for TCP [Go09].
>> A TCP-AO implementation MUST allow the system administrator to >> A TCP-AO implementation MUST allow the system administrator to
skipping to change at page 41, line 47 skipping to change at page 43, line 47
[NOTE: This section be removed prior to publication as an RFC] [NOTE: This section be removed prior to publication as an RFC]
The TCP-AO option defines no new namespaces. The TCP-AO option defines no new namespaces.
The TCP-AO option requires that IANA allocate a value from the TCP The TCP-AO option requires that IANA allocate a value from the TCP
option Kind namespace, to be replaced for TCP-IANA-KIND throughout option Kind namespace, to be replaced for TCP-IANA-KIND throughout
this document. this document.
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 [ao-crypto]. document that may involve IANA actions [Le09].
15. References 15. References
15.1. Normative References 15.1. Normative References
[Le09] Lebovitz, G., E. Rescorla, "Cryptographic Algorithms for
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-793, Standard, Sept. 1981. RFC-793, Standard, Sept. 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts -- [RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers," RFC-1122, Oct. 1989. Communication Layers," RFC-1122, Oct. 1989.
[RFC2018] Mathis, M., J. Mahdavi, S. Floyd, A. Romanow, "TCP [RFC2018] Mathis, M., J. Mahdavi, S. Floyd, A. Romanow, "TCP
Selective Acknowledgement Options", RFC-2018, Proposed Selective Acknowledgement Options", RFC-2018, Proposed
Standard, April 1996. Standard, April 1996.
skipping to change at page 42, line 45 skipping to change at page 44, line 49
for TCP", RFC-2883, Proposed Standard, July 2000. for TCP", RFC-2883, Proposed Standard, July 2000.
[RFC3517] Blanton, E., M. Allman, K. Fall, L. Wang, "A Conservative [RFC3517] Blanton, E., M. Allman, K. Fall, L. Wang, "A Conservative
Selective Acknowledgment (SACK)-based Loss Recovery Selective Acknowledgment (SACK)-based Loss Recovery
Algorithm for TCP", RFC-3517, Proposed Standard, April Algorithm for TCP", RFC-3517, Proposed Standard, April
2003. 2003.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol,"
RFC-4306, Proposed Standard, Dec. 2005. RFC-4306, Proposed Standard, Dec. 2005.
[ao-crypto] Lebovitz, G., E. Rescorla, "Cryptographic Algorithms for [RFC4724] Sangli, S., E. Chen, R. Fernando, J. Scudder, Y. Rekhter,
TCP's Authentication Option, TCP-AO", draft-ietf-tcpm-tcp- "Graceful Restart Mechanism for BGP," RFC-4724, Jan. 2007.
ao-crypto-02, Oct. 2009.
[RFC4781] Rekhter, Y., R. Aggarwal, "Graceful Restart Mechanism for
BGP with MPLS," RFC-4781, Jan. 2007.
15.2. Informative References 15.2. Informative References
[ao-nat] Touch, J., "A TCP Authentication Option NAT Extension," [Ba09] Bashyam, M., M. Jethanandani,, A. Ramaiah "Clarification of
draft-touch-tcp-ao-nat-00, Oct. 2009. 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 [Be07] Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem
Statement and Requirements for a TCP Authentication Statement and Requirements for a TCP Authentication
Option," draft-bellovin-tcpsec-01, (work in progress), Jul. Option," draft-bellovin-tcpsec-01, (work in progress), Jul.
2007. 2007.
[Bo07] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler, [Bo07] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler,
"Authentication for TCP-based Routing and Management "Authentication for TCP-based Routing and Management
Protocols," draft-bonica-tcp-auth-06, (work in progress), Protocols," draft-bonica-tcp-auth-06, (work in progress),
Feb. 2007. Feb. 2007.
[Bo09] Borman, D., "TCP Options and MSS," draft-ietf-tcpm-tcpmss- [Bo09] Borman, D., "TCP Options and MSS," draft-ietf-tcpm-tcpmss-
02, Jul. 2009. 02, Jul. 2009.
[La09] Larsen, M., F. Gont, "Port Randomization," draft-ietf-
tsvwg-port-randomization-05, Nov. 09.
[Go09] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- [Go09] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp-
attacks-06, (work in progress), Aug. 2009. attacks-10, (work in progress), Jan. 2010.
[Ba09] Bashyam, M., M. Jethanandani,, A. Ramaiah "Clarification of [Le09] Lepinski, M., S. Kent, "An Infrastructure to Support Secure
sender behaviour in persist condition," draft-ananth-tcpm- Internet Routing," draft-ietf-sidr-arch-09, (work in
persist-01, (work in progress), Jul. 2009. progress), Oct. 2009.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321,
Informational, April 1992. Informational, April 1992.
[RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for [RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for
High Performance," RFC-1323, May 1992. High Performance," RFC-1323, May 1992.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks," [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks,"
RFC-1948, Informational, May 1996. RFC-1948, Informational, May 1996.
skipping to change at page 44, line 18 skipping to change at page 46, line 28
[RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet
Protocol," RFC-4301, Proposed Standard, Dec. 2005. Protocol," RFC-4301, Proposed Standard, Dec. 2005.
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5," [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5,"
RFC-4808, Informational, Mar. 2007. RFC-4808, Informational, Mar. 2007.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks," [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks,"
RFC-4953, Informational, Jul. 2007. RFC-4953, Informational, Jul. 2007.
[RFC5246] Dierks, T., E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2," RFC-5246, Aug. 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 [To06] Touch, J., A. Mankin, "The TCP Simple Authentication
Option," draft-touch-tcpm-tcp-simple-auth-03, (expired work Option," draft-touch-tcpm-tcp-simple-auth-03, (expired work
in progress), Oct. 2006. in progress), Oct. 2006.
[To10] Touch, J., "A TCP Authentication Option NAT Extension,"
draft-touch-tcp-ao-nat-01, Jan. 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., "TCP Message Authentication Code Option," draft-
weis-tcp-mac-option-00, (expired work in progress), Dec. weis-tcp-mac-option-00, (expired work in progress), Dec.
2005. 2005.
16. Acknowledgments 16. Acknowledgments
Alfred Hoenes, Charlie Kaufman, and Adam Langley provided substantial Alfred Hoenes, Charlie Kaufman, Adam Langley, and numerous other
feedback on this document. members of the TCPM WG provided substantial feedback on this
document.
This document was prepared using 2-Word-v2.0.template.dot. This document was 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.
 End of changes. 53 change blocks. 
134 lines changed or deleted 223 lines changed or added

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