draft-ietf-tcpm-tcp-auth-opt-03.txt   draft-ietf-tcpm-tcp-auth-opt-04.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: August 2009 R. Bonica Expires: September 2009 R. Bonica
Juniper Networks Juniper Networks
February 16, 2009 March 9, 2009
The TCP Authentication Option The TCP Authentication Option
draft-ietf-tcpm-tcp-auth-opt-03.txt draft-ietf-tcpm-tcp-auth-opt-04.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 to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 August 16, 2009. This Internet-Draft will expire on September 9, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 configuration or an external, out-of-band master key master key configuration or an external, out-of-band master key
management mechanism; in either case, TCP-AO also protects management mechanism; in either case, TCP-AO also protects
connections when using the same master key across repeated instances connections when using the same master key across repeated instances
of a connection, using connection keys derived from the master key. of a connection, using traffic keys derived from the master key, and
The result is intended to support current infrastructure uses of TCP coordinates key changes between endpoints. The result is intended to
MD5, such as to protect long-lived connections (as used, e.g., in BGP support current infrastructure uses of TCP MD5, such as to protect
and LDP), and to support a larger set of MACs with minimal other long-lived connections (as used, e.g., in BGP and LDP), and to
system and operational changes. TCP-AO uses its own option support a larger set of MACs with minimal other system and
identifier, even though used mutually exclusive of TCP MD5 on a given operational changes. TCP-AO uses its own option identifier, even
TCP connection. TCP-AO supports IPv6, and is fully compatible with though used mutually exclusive of TCP MD5 on a given TCP connection.
the requirements for the replacement of TCP MD5. TCP-AO supports IPv6, and is fully compatible with the requirements
for the replacement of TCP MD5.
Table of Contents Table of Contents
1. Contributors...................................................3 1. Contributors...................................................3
2. Introduction...................................................3 2. Introduction...................................................4
2.1. Executive Summary.........................................4 2.1. Executive Summary.........................................4
2.2. Changes from Previous Versions............................5 2.2. Changes from Previous Versions............................6
2.2.1. New in draft-ietf-tcp-auth-opt-03....................6 2.2.1. New in draft-ietf-tcp-auth-opt-04....................6
2.2.2. New in draft-ietf-tcp-auth-opt-02....................6 2.2.2. New in draft-ietf-tcp-auth-opt-03....................6
2.2.3. New in draft-ietf-tcp-auth-opt-01....................7 2.2.3. New in draft-ietf-tcp-auth-opt-02....................7
2.2.4. New in draft-ietf-tcp-auth-opt-00....................8 2.2.4. New in draft-ietf-tcp-auth-opt-01....................8
2.2.5. New in draft-touch-tcp-simple-auth-03................9 2.2.5. New in draft-ietf-tcp-auth-opt-00....................9
2.2.6. New in draft-touch-tcp-simple-auth-02................9 2.2.6. New in draft-touch-tcp-simple-auth-03................9
2.2.7. New in draft-touch-tcp-simple-auth-01................9 2.2.7. New in draft-touch-tcp-simple-auth-02...............10
2.2.8. New in draft-touch-tcp-simple-auth-01...............10
3. Conventions used in this document.............................10 3. Conventions used in this document.............................10
4. The TCP Authentication Option.................................10 4. The TCP Authentication Option.................................11
4.1. Review of TCP MD5 Option.................................10 4.1. Review of TCP MD5 Option.................................11
4.2. TCP-AO Option............................................11 4.2. The TCP-AO Option........................................11
5. Preventing replay attacks within long-lived connections.......14 5. The TCP-AO Activation and Parameter Database..................13
6. Computing connection keys from TSAD entries...................16 6. Per-Connection Parameters.....................................16
7. Security Association Management...............................17 7. Cryptographic Algorithms......................................17
8. TCP-AO Interaction with TCP...................................21 7.1. MAC Algorithms...........................................17
8.1. TCP User Interface.......................................21 7.2. Key Derivation Functions.................................21
8.2. TCP States and Transitions...............................22 7.3. Traffic Key Establishment and Duration Issues............24
8.3. TCP Segments.............................................22 7.3.1. Master Key Reuse Across Socket Pairs................25
8.4. Sending TCP Segments.....................................23 7.3.2. Master Key Use Within a Long-lived Connection.......25
8.5. Receiving TCP Segments...................................24 8. Additional Security Mechanisms................................25
8.6. Impact on TCP Header Size................................25 8.1. Coordinating KeyID Changes...............................25
9. Connection Key Establishment and Duration Issues..............26 8.2. Preventing replay attacks within long-lived connections..26
9.1. Master Key Reuse Across Socket Pairs.....................27 9. TCP-AO Interaction with TCP...................................28
9.2. Master Key Use Within a Long-lived Connection............27 9.1. TCP User Interface.......................................29
10. Obsoleting TCP MD5 and Legacy Interactions...................27 9.2. TCP States and Transitions...............................30
11. Interactions with Middleboxes................................28 9.3. TCP Segments.............................................30
11.1. Interactions with non-NAT/NAPT Middleboxes..............28 9.4. Sending TCP Segments.....................................31
11.2. Interactions with NAT/NAPT Devices......................29 9.5. Receiving TCP Segments...................................32
12. Evaluation of Requirements Satisfaction......................29 9.6. Impact on TCP Header Size................................34
13. Security Considerations......................................35 10. Obsoleting TCP MD5 and Legacy Interactions...................35
14. IANA Considerations..........................................37 11. Interactions with Middleboxes................................36
15. References...................................................37 11.1. Interactions with non-NAT/NAPT Middleboxes..............36
15.1. Normative References....................................37 11.2. Interactions with NAT/NAPT Devices......................36
15.2. Informative References..................................38 12. Evaluation of Requirements Satisfaction......................36
16. Acknowledgments..............................................40 13. Security Considerations......................................42
14. IANA Considerations..........................................44
15. References...................................................45
15.1. Normative References....................................45
15.2. Informative References..................................46
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),
which was both inspired by and intended as a counterproposal to the which was both inspired by and intended as a counterproposal to the
revisions to TCP MD5 suggested in a document by Ron Bonica, Brian revisions to TCP MD5 suggested in a document by Ron Bonica, Brian
Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07] Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07]
(originally from Sept. 2005) and in a document by Brian Weis [We05]. (originally from Sept. 2005) and in a document by Brian Weis [We05].
Russ Housley suggested L4/application layer management of the TSAD. Russ Housley suggested L4/application layer management of the TAPD.
Steve Bellovin motivated the KeyID field. Eric Rescorla suggested the Steve Bellovin motivated the KeyID field. Eric Rescorla suggested the
use of ISNs in the connection key computation and ESNs to avoid use of ISNs in the traffic key computation and ESNs to avoid replay
replay attacks, and Brian Weis extended the computation to attacks, and Brian Weis extended the computation to incorporate the
incorporate the entire connection ID and provided the details of the entire connection ID and provided the details of the traffic key
connection key computation. computation. Mark Allman, Wes Eddy, Lars Eggert, Ted Faber, Russ
Housley, Gregory Lebovitz, Tim Polk, Eric Rescorla, Joe Touch, and
Brian Weis developed the key coordination mechanism.
2. Introduction 2. 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, but notes that TCP does not provide a sufficient adds the latter, and provides a simple key coordination mechanism
framework for cryptographic key management, because SYN segments lack giving the ability to move from one key to another within the same
sufficient remaining space to support key coordination in-band (see connection. It does not however provide for complete cryptographic
Section 8.6). This document obsoletes the TCP MD5 option with a more key management to be handled in-band of TCP, because TCP SYN segments
lack sufficient remaining space to handle such a negotiation (see
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, and to provide a more structured recommendation on connection, coordinate key changes between endpoints, and to provide
external key management. The result is compatible with IPv6, and is a more structured recommendation on external key management. The
fully compatible with requirements under development for a result is compatible with IPv6, and is fully compatible with
replacement for TCP MD5 [Be07]. requirements under development for a replacement for TCP MD5 [Be07].
This document is not intended to replace the use of the IPsec suite This document is not intended to replace the use of the IPsec suite
(IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In
fact, we recommend the use of IPsec and IKE, especially where IKE's fact, we recommend the use of IPsec and IKE, especially where IKE's
level of existing support for parameter negotiation, session key level of existing support for parameter negotiation, session key
negotiation, or rekeying are desired. TCP-AO is intended for use only 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 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 suggested is the case to support some routing protocols, or in cases
where keys need to be tightly coordinated with individual transport where keys need to be tightly coordinated with individual transport
sessions [Be07]. sessions [Be07].
Note that TCP-AO obsoletes TCP MD5, although a particular Note that TCP-AO obsoletes TCP MD5, although a particular
implementation may support both for backward compatibility. For a implementation may support both mechanisms for backward
given connection, only one can be in use. TCP MD5-protected compatibility. For a given connection, only one can be in use. TCP
connections cannot be migrated to TCP-AO because TCP MD5 does not MD5-protected connections cannot be migrated to TCP-AO because TCP
support any changes to a connection's security algorithm once MD5 does not support any changes to a connection's security algorithm
established. once established.
2.1. Executive Summary 2.1. 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 allows extension to include other MACs. a separate document and allows extension 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 coordinates the key out-of-band protocol or manual mechanism provides the new keys. In
change. In such cases, a key ID allows the efficient concurrent such cases, a key ID allows the efficient concurrent use of
use of multiple keys. Note that TCP MD5 does not preclude rekeying multiple keys, and a key coordination mechanism manages the key
during a connection, but does not require its support either. change within a connection. Note that TCP MD5 does not preclude
Further, TCP-AO supports rekeying with zero packet loss, whereas rekeying during a connection, but does not require its support
rekeying in TCP MD5 can lose packets in transit during the either. Further, TCP-AO supports key changes with zero packet
changeover or require trying multiple keys on each received loss, whereas key changes in TCP MD5 can lose packets in transit
segment during key use overlap because it lacks an explicit key during the changeover or require trying multiple keys on each
ID. received segment during key use overlap because it lacks an
explicit key ID.
o TCP-AO provides automatic replay protection for long-lived o TCP-AO provides automatic replay protection for long-lived
connections using an extended sequence number. connections using an extended sequence number.
o TCP-AO ensures per-connection keys as unique as the TCP connection o TCP-AO ensures per-connection traffic keys as unique as the TCP
itself, using TCP's ISNs for differentiation, even when static connection itself, using TCP's ISNs for differentiation, even when
master keys are used across repeated instances of a socket pair. static master keys are used across repeated instances of a socket
pair.
o This document provides detail in how this option interacts with o TCP-AO specifies the details of how this option interacts with
TCP's states, event processing, and user interface. TCP's states, event processing, and user interface.
o The TCP-AO option is 3 bytes shorter than TCP MD5 (15 bytes o The TCP-AO option is 2 bytes shorter than TCP MD5 (16 bytes
overall, rather than 18) in the default case (using a 96-bit MAC). overall, rather than 18) in the default case (using a 96-bit MAC).
This document differs from an IPsec/IKE solution in that TCP-AO as This document differs from an IPsec/IKE solution in that TCP-AO as
follows [RFC4301][RFC4306]: follows [RFC4301][RFC4306]:
o TCP-AO does not support dynamic parameter negotiation. o TCP-AO does not support dynamic parameter negotiation.
o TCP-AO uses TCP's socket pair (source address, destination o TCP-AO uses TCP's socket pair (source address, destination
address, source port, destination port) as a security parameter address, source port, destination port) as a security parameter
index, rather than using a separate field as a primary index index, rather than using a separate field as a primary index
skipping to change at page 6, line 5 skipping to change at page 6, line 14
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 via IPsec, depending on the configuration). be authenticated via IPsec, depending on the configuration).
2.2. Changes from Previous Versions 2.2. Changes from Previous Versions
[NOTE: to be omitted upon final publication as RFC] [NOTE: to be omitted upon final publication as RFC]
2.2.1. New in draft-ietf-tcp-auth-opt-03 2.2.1. New in draft-ietf-tcp-auth-opt-04
o Major revision to the document structure, including renaming the
TSAD to TAPD.
o Added a key change coordination mechanism in Section 8.1.
o Added a requirement for symmetric use of TCP-AO, required for the
key change coordination mechanism. This includes an update of the
TAPD to indicate that all master keys are bidirectional.
o Augmented the discussion of the available space for options.
o Fixed a bug in the ESN algorithm.
o Adds a text referring to the TCP-AO cryptography companion
document.
o Changed RFC-TBD to ao-crypto (until the RFC number is assigned).
2.2.2. New in draft-ietf-tcp-auth-opt-03
o Added a placeholder to discuss key change coordination in Section o Added a placeholder to discuss key change coordination in Section
9. 8.1.
o Moved discussion of required MAC algorithms and PRF to a separate o Moved discussion of required MAC algorithms and PRF to a separate
document, indicated as RFC-TBD until assigned. Included the PRF in document, indicated as RFC-TBD until assigned. Included the PRF in
the TSAD master key tuple so that TCP-AO is PRF algorithm agile, the TSAD master key tuple so that TCP-AO is PRF algorithm agile,
and updated general PRF input format. and updated general PRF input format.
o Revised the description the TSAD and impact to the TCP user o Revised the description the TSAD and impact to the TCP user
interface. Removed the description of the TSAD API. Access to the interface. Removed the description of the TSAD API. Access to the
API is assumed specific to the implementation, and not part of the API is assumed specific to the implementation, and not part of the
protocol specification. protocol specification.
skipping to change at page 6, line 41 skipping to change at page 7, line 22
o Provided detail on size of typical options (motivating a small o Provided detail on size of typical options (motivating a small
option). option).
o Confirmed WG consensus on IETF-72 topic - no algorithm ID and T- o Confirmed WG consensus on IETF-72 topic - no algorithm ID and T-
bit (options excluded) locations in the header. bit (options excluded) locations in the header.
o Confirmed WG consensus on IETF-72 topic - no additional header o Confirmed WG consensus on IETF-72 topic - no additional header
bits for in-band key change signaling (the "K" bit from [Bo07]). bits for in-band key change signaling (the "K" bit from [Bo07]).
2.2.2. New in draft-ietf-tcp-auth-opt-02 2.2.3. New in draft-ietf-tcp-auth-opt-02
o List issue - Replay Protection: incorporated extended sequence o List issue - Replay Protection: incorporated extended sequence
number space, not using KeyID space. number space, not using KeyID space.
o List issue - Unique Connection Keys: ISNs are used to generate o List issue - Unique Connection Keys: ISNs are used to generate
unique connection keys even when static keys used for repeated unique connection keys even when static keys used for repeated
instances of a socket pair. instances of a socket pair.
o List issue - Header Format and Alignment: Moved KeyID to front. o List issue - Header Format and Alignment: Moved KeyID to front.
skipping to change at page 7, line 47 skipping to change at page 8, line 26
o Explained why option exclusion can't be changed during a o Explained why option exclusion can't be changed during a
connection. connection.
o Clarified that AO explicitly allows rekeying during a TCP o Clarified that AO explicitly allows rekeying during a TCP
connection, without impacting packet loss. connection, without impacting packet loss.
o Described TCP-AO's interaction with reboots more clearly, and o Described TCP-AO's interaction with reboots more clearly, and
explained the need to clear out old state that persists explained the need to clear out old state that persists
indefinitely. indefinitely.
2.2.3. New in draft-ietf-tcp-auth-opt-01 2.2.4. New in draft-ietf-tcp-auth-opt-01
o Require KeyID in all versions. Remove odd/even indicator of KeyID o Require KeyID in all versions. Remove odd/even indicator of KeyID
usage. usage.
o Relax restrictions on key reuse: requiring an algorithm for nonce o Relax restrictions on key reuse: requiring an algorithm for nonce
introduction based on ISNs, and suggest key rollover every 2^31 introduction based on ISNs, and suggest key rollover every 2^31
bytes (rather than using an extended sequence number, which bytes (rather than using an extended sequence number, which
introduces new state to the TCP connection). introduces new state to the TCP connection).
o Clarify NAT interaction; currently does not support omitting the o Clarify NAT interaction; currently does not support omitting the
skipping to change at page 8, line 29 skipping to change at page 9, line 9
length changes of such options. length changes of such options.
o Augment replay discussion in security considerations. o Augment replay discussion in security considerations.
o Revise discussion of IKEv2 MAC algorithm names. o Revise discussion of IKEv2 MAC algorithm names.
o Remove executive summary comparison to expired documents. o Remove executive summary comparison to expired documents.
o Clarified key words to exclude lower case usage. o Clarified key words to exclude lower case usage.
2.2.4. New in draft-ietf-tcp-auth-opt-00 2.2.5. New in draft-ietf-tcp-auth-opt-00
o List of TBD values, and indication of how each is determined. o List of TBD values, and indication of how each is determined.
o Changed TCP-SA to TCP-AO (removed 'simple' throughout). o Changed TCP-SA to TCP-AO (removed 'simple' throughout).
o Removed proposed NAT mechanism; cited RFC-3947 NAT-T as o Removed proposed NAT mechanism; cited RFC-3947 NAT-T as
appropriate approach instead. appropriate approach instead.
o Made several changes coordinated in the TCP-AUTH-DT as follow: o Made several changes coordinated in the TCP-AUTH-DT as follow:
skipping to change at page 9, line 10 skipping to change at page 9, line 38
o Allow 0 as a legitimate KeyID. o Allow 0 as a legitimate KeyID.
o Allow the WG to determine the two appropriate required MAC o Allow the WG to determine the two appropriate required MAC
algorithms. algorithms.
o Add TO-DO items. o Add TO-DO items.
o Added discussion at end of Introduction as to why TCP MD5 o Added discussion at end of Introduction as to why TCP MD5
connections cannot be upgraded to TCP-AO. connections cannot be upgraded to TCP-AO.
2.2.5. New in draft-touch-tcp-simple-auth-03 2.2.6. New in draft-touch-tcp-simple-auth-03
o Added support for NAT/NAPT. o Added support for NAT/NAPT.
o Added support for IPv6. o Added support for IPv6.
o Added discussion of how this proposal satisfies requirements under o Added discussion of how this proposal satisfies requirements under
development, including those indicated in [Be07]. development, including those indicated in [Be07].
o Clarified the byte order of all data used in the MAC. o Clarified the byte order of all data used in the MAC.
o Changed the TCP option exclusion bit from a bit to a list. o Changed the TCP option exclusion bit from a bit to a list.
2.2.6. New in draft-touch-tcp-simple-auth-02 2.2.7. New in draft-touch-tcp-simple-auth-02
o Add reference to Bellovin's need-for-TCP-auth doc [Be07]. o Add reference to Bellovin's need-for-TCP-auth doc [Be07].
o Add reference to SP4 [SDNS88]. o Add reference to SP4 [SDNS88].
o Added notes that TSAD to be externally implemented; this was o Added notes that TSAD to be externally implemented; this was
compatible with the TSAD described in the previous version. compatible with the TSAD described in the previous version.
o Augmented the protocol to allow a KeyID, required to support o Augmented the protocol to allow a KeyID, required to support
efficient overlapping keys during rekeying, and potentially useful efficient overlapping keys during rekeying, and potentially useful
during connection establishment. Accommodated by redesigning the during connection establishment. Accommodated by redesigning the
TSAD. TSAD.
o Added the odd/even indicator for the KeyID. o Added the odd/even indicator for the KeyID.
o Allow for the exclusion of all TCP options in the MAC calculation. o Allow for the exclusion of all TCP options in the MAC calculation.
2.2.7. New in draft-touch-tcp-simple-auth-01 2.2.8. New in draft-touch-tcp-simple-auth-01
o Allows intra-session rekeying, assuming out-of-band coordination. o Allows intra-session rekeying, assuming out-of-band coordination.
o MUST allow TSAD entries to change, enabling rekeying within a TCP o MUST allow TSAD entries to change, enabling rekeying within a TCP
connection. connection.
o Omits discussion of the impact of connection reestablishment on o Omits discussion of the impact of connection reestablishment on
BGP, because added support for rekeying renders this point moot. BGP, because added support for rekeying renders this point moot.
o Adds further discussion on the need for rekeying. o Adds further discussion on the need for rekeying.
skipping to change at page 10, line 15 skipping to change at page 10, line 45
3. Conventions used in this document 3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance. interpreted as carrying RFC-2119 significance.
In this document, the characters ">>" proceeding an indented line(s)
indicates a compliance requirement statement using the key words
listed above. This convention aids reviewers in quickly identifying
or finding this RFC's explicit compliance requirements.
4. The TCP Authentication Option 4. The TCP Authentication Option
The TCP Authentication Option (TCP-AO) uses a TCP option Kind value The TCP Authentication Option (TCP-AO) uses a TCP option Kind value
of TBD-IANA-KIND. of TBD-IANA-KIND.
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.
+---------+---------+-------------------+ +---------+---------+-------------------+
skipping to change at page 11, line 5 skipping to change at page 11, line 42
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 TCP pseudoheader (IP source and destination addresses, 1. The TCP pseudoheader (IP source and destination addresses,
protocol number, and segment length). protocol 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. The connection key. 4. A key.
4.2. TCP-AO Option 4.2. The TCP-AO Option
The new TCP-AO option provides a superset of the capabilities of TCP The new TCP-AO option provides a superset of the capabilities of TCP
MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new
Kind field, and similar Length field to TCP MD5, as well as a KeyID Kind field, and similar Length field to TCP MD5, a KeyID field, and a
field as shown in Figure 2. NextKeyID field as shown in Figure 2.
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Kind | Length | KeyID | MAC | | Kind | Length | KeyID | NextKeyID|
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| MAC (con't) ... | MAC ...
+----------------------------------... +----------------------------------...
...-----------------+ ...-----------------+
... MAC (con't) | ... MAC (con't) |
...-----------------+ ...-----------------+
Figure 2 The TCP-AO Option Figure 2 The TCP-AO Option
The TCP-AO defines the following fields: The TCP-AO defines the following fields:
o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP- o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP-
AO uses a new Kind value of TBD-IANA-KIND. Because of how keys are AO uses a new Kind value of TBD-IANA-KIND.
managed (see Section 7), an endpoint will not use TCP-AO for the
same connection in which TCP MD5 is used. >> An endpoint MUST NOT use TCP-AO for the same connection in
which TCP MD5 is used.
>> A single TCP segment MUST NOT have more than one TCP-AO option. >> A single TCP segment MUST NOT have more than one TCP-AO option.
o Length: An unsigned 1-byte field indicating the length of the TCP- o Length: An unsigned 1-byte field indicating the length of the TCP-
AO option in bytes, including the Kind, Length, KeyID, and MAC AO option in bytes, including the Kind, Length, KeyID, NextKeyID,
fields. and MAC fields.
>> The Length value MUST be greater than or equal to 3. >> The Length value MUST be greater than or equal to 4.
>> The Length value MUST be consistent with the TCP header length; >> The Length value MUST be consistent with the TCP header length;
this is a consistency check and avoids overrun/underrun abuse. this is a consistency check and avoids overrun/underrun abuse.
Values of 3 and other small values are of dubious utility (e.g., Values of 4 and other small values are of dubious utility but are
for MAC=NONE, or small values for very short MACs) but not not specifically prohibited.
specifically prohibited.
o KeyID: An unsigned 1-byte field is used to support efficient key o KeyID: An unsigned 1-byte field used to support efficient key
changes during a connection and/or to help with key coordination changes during a connection and/or to help with key coordination
during connection establishment, and will be discussed further in during connection establishment, to be discussed further in
Section 4. Note that the KeyID has no cryptographic properties - Section 8.1. Note that the KeyID has no cryptographic properties -
it need not be random, nor are there any reserved values. it need not be random, nor are there any reserved values.
o MAC: Message Authentication Field. Its contents are determined by o NextKeyID: An unsigned 1-byte field used to support efficient key
change coordination, to be discussed further in Section 8.1. Note
that the NextKeyID has no cryptographic properties - it need not
be random, nor are there any reserved values.
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 segment being authenticated is allowed. The MAC computation is
described further in Section 7.1.
>> Required support for TCP-AO MACs as defined in RFC-TBD; other >> Required support for TCP-AO MACs as defined in [ao-crypto];
MACs MAY be supported [RFC2403]. other MACs MAY be supported.
The MAC is computed over the following fields in the following order: The TCP-AO option fields do not indicate the MAC algorithm either
implicitly (as with TCP MD5) or explicitly. The particular algorithm
used is considered part of the configuration state of the
connection's security and is managed separately (see Section 5).
The remainder of this document explains how the TCP-AO option is
handled and its relationship to TCP.
5. The TCP-AO Activation and Parameter Database
TCP-AO relies on a TCP-AO Activation and Parameter Database (TAPD),
which indicates whether a TCP connection requires TCP-AO, and its
parameters when so. TAPD entries are assumed to exist at the
endpoints where TCP-AO is used, in advance of the connection, and
consist of the following:
1. TCP connection identifier (ID), i.e., socket pair - IP source
address, IP destination address, TCP source port, and TCP
destination port [RFC793]. TAPD entries are uniquely determined by
their TCP connection ID, which is used to index those entries. A
TAPD entry may allow wildcards, notably in the source port value.
>> There MUST be no more than one matching TAPD entry per
direction for a fully-instantiated (no wildcards) TCP connection
ID.
2. A TCP option flag. When 0, this flag allows default operation,
i.e., TCP options are included in the MAC calculation, with TCP-
AO's MAC field zeroed out. When 1, all options (excluding TCP-AO)
are excluded from all MAC calculations (skipped over, not simply
zeroed). The option flag applies to TCP options in both directions
(incoming and outgoing segments).
>> The TCP option flag MUST NOT change during a TCP connection.
The TCP option flag cannot change during a connection because TCP
state is coordinated during connection establishment. TCP lacks a
handshake for modifying that state after a connection has been
established.
3. A list of zero or more master key tuples.
>> Components of a TAPD master key tuple MUST NOT change during a
connection.
Keeping the tuple components static ensures that the KeyID
uniquely determines the properties of a packet; this supports use
of the KeyID to determine the packet properties.
>> The set of TAPD master key tuples MAY change during a
connection, but KeyIDs of those tuples MUST NOT overlap. I.e.,
tuple parameter changes MUST be accompanied by master key changes.
>> If there are multiple tuples in a TAPD entry, then one tuple
MUST be flagged as the preferred key; that key, when instantiated
as a traffic_key, becomes the current_key for the connection (see
Section 6).
Each tuple is defined as the following components:
a. KeyID. The value as used in the TCP-AO option; used to
differentiate master keys in concurrent use, as well as to
indicate when master keys are ready for use.
>> A TAPD implementation MUST support at least two KeyIDs per
connection per direction, and MAY support up to 256.
>> A KeyID MUST support any value, 0-255 inclusive. There are
no reserved KeyID values.
KeyID values are assigned arbitrarily. They can be assigned in
sequence, or based on any method mutually agreed by the
connection endpoints (e.g., using an external master key
management mechanism).
>> KeyIDs MUST NOT be assumed to be randomly assigned.
Note that KeyIDs are unique only within a TAPD entry.
b. Master key. A byte sequence used for generating traffic keys,
this may be derived from a separate shared key by an external
protocol over a separate channel. This sequence is used in the
traffic key generation algorithm described in Section 7.2.
Implementations are advised to keep master key values in a
private, protected area of memory or other storage.
Implementations are also advised to indicate the length of
this key explicitly, because there are no reserved byte
values.
c. MAC algorithm. Indicates the MAC algorithm used for this
connection, explained further in Section 7.1 [ao-crypto]. The
MAC_algorithm indicates other properties, such as MAC
truncation, PRF algorithm, and KDF truncation, as explained
further in [ao-crypto]
The TAPD is consulted when new connections are established to
determine whether TCP-AO is required.
>> When a TAPD entry matches a new connection, TCP-AO is required.
This is true regardless of whether there are any master key tuples
present.
>> When TCP-AO is required, the TCP-AO option MUST occur in every
incoming and outgoing TCP segment. In this case, segments lacking the
TCP-AO option MUST be silently ignored.
For a particular endpoint (i.e., IP address) there would be exactly
one TAPD that is consulted by all pending connections, the same way
that there is only one table of TCBs (a database can support multiple
endpoints, but an endpoint is represented in only one database).
Multiple databases could be used to support virtual hosts, i.e.,
groups of interfaces.
This document does not address how TAPD entries are created by
users/processes; it specifies how they must be destroyed
corresponding to connection states, but users/processes may destroy
entries as well. It is presumed that a TAPD entry affecting a
particular connection cannot be destroyed during an active connection
- or, equivalently, that its parameters are copied to an area local
to the connection (i.e., instantiated) and so changes would affect
only new connections. The TAPD can be managed by a separate
application protocol.
NOTE: an open issue is whether to require actions when master keys
are added to the TAPD. In particular, there is a suggestion to force
new added keys to update current_key to the newly added value, and to
set a timer or flag on previous current_key values. If a timer, the
value is unclear (2*MSL isn't appropriate, because we don't know how
long a key changeover may take, and we're not reacting to messages
from the other side). If a flag, this would require that flagged
entries could never be advertised as NextKeyID.
6. Per-Connection Parameters
TCP-AO uses a small number of parameters associated with each
connection that uses the TCP-AO option, once instantiated. These
values would typically be stored in the Transport Control Block (TCP)
[RFC793]. These values are explained in subsequent sections of this
document as noted; they include:
1. Current_key - the KeyID of the master key tuple currently used to
authenticate outgoing segments, inserted in outgoing segments as
KeyID (see Section 9.4, step 5). Incoming segments are
authenticated using the KeyID in the segment's TCP-AO header (see
Section 9.5, step 5). There is only one current_key at any given
time on a particular connection.
>> Every connection in a non-IDLE state MUST have exactly one
current_key value specified.
2. Next_key - the KeyID of the master key tuple currently preferred
for future use, as inserted in outgoing segments as NextKeyID (see
Section 9.5, step 5).
>> Each connection in a non-IDLE state MUST have exactly one
next_key value specified.
3. A pair of Extended Sequence Numbers (ESNs). ESNs are used to
prevent replay attacks, as described in Section 8.2. Each ESN is
initialized to zero upon connection establishment. Its use in the
MAC calculation is described in Section 7.1.
4. One or more master key tuples. These are all the master key tuples
that match this connection's socket pair in the TAPD. When a new
tuple is added to the TAPD, it is added to the TCB of all matching
connections.
Master key tuples are used, together with other parameters of a
connection, to create traffic keys unique to each connection, as
described in Section 7.2. These traffic keys can be cached after
computation, and are typically stored in the TCB with the
corresponding master key tuple information. They can be considered
part of the per-connection parameters.
7. Cryptographic Algorithms
TCP-AO also uses cryptographic algorithms to compute the MAC (Message
Authentication Code) used to authenticate a segment and its headers;
these are called MAC algorithms and are specified in a separate
document to facilitate updating the algorithm requirements
independently from the protocol [ao-crypto]. TCP-AO also uses
cryptographic algorithms to convert master keys, which can be shared
across connections, into unique traffic keys for each connection.
These are called Key Derivation Functions (KDFs), and are specified
[ao-crypto]. This section describes how these algorithms are used by
TCP-AO.
7.1. MAC Algorithms
MAC algorithms take a variable-length input and a key and output a
fixed-length number. This number is used to determine whether the
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
interface:
INPUT: MAC_alg, MAC_truncation, traffic_key, data_block
OUTPUT: MAC
where:
o MAC_alg - MAC algorithm used for this computation
o MAC_truncation - the number of bytes to truncate the output of the
MAC to. This is indicated by the MAC algorithm, as specified in
[ao-crypto].
o Traffic_key - traffic key used for this computation. This is
computed from the connection's current master key as described in
Section 7.2.
o Data_block - input data over which the MAC is computed. In TCP-AO,
this is the TCP segment prepended by the TCP pseudoheader and TCP
header options, as described in Section 7.1.
o MAC - the fixed-length output of the MAC algorithm, given the
parameters provided. If the MAC_alg output is smaller than the
desired MAC_truncation, it is padded with trailing zeroes as
needed.
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.
Though the algorithms each output a larger MAC, we truncate the
output to 96 bits to provide a reasonable tradeoff between security
and message size, for fitting into the TCP-AO header. Though could
change in the future, so TCP-AO header sizes should not be assumed as
fixed length.
>> To allow a TCP-AO implementation to compute any implicit MAC
algorithm padding required, the specification for each algorithm used
with TCP-AO MUST specify the padding modulus for the algorithm, if
one is required.
The MAC algorithm employed for the MAC computation on any connection
is done so by policy definition in the TAPD entry, and is chosen from
a list of available MACs, where each MAC also infers an underlying
KDF, per [ao-crypto]'s definitions.
The mandatory-to-implement MAC algorithms for use with TCP-AO are
described in a separate RFC [ao-crypto]. This allows the TCP-AO
specification to proceed along the standards track even if changes
are needed to its associated algorithms and their labels (as might be
used in a user interface or automated master key management protocol)
as a result of the ever evolving world of cryptography.
>> Additional algorithms, beyond those mandated for TCP-AO, MAY be
supported.
The data input to the MAC is the following fields in the following
sequence, interpreted in network-standard byte order:
1. The extended sequence number (ESN), in network-standard byte 1. The extended sequence number (ESN), in network-standard byte
order, as follows (described further in Section 5): order, as follows (described further in Section 8.2):
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| ESN | | ESN |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 3 Extended sequence number Figure 3 Extended sequence number
The ESN for transmitted segments is locally maintained from a The ESN for transmitted segments is maintained locally in the
locally maintained SND.ESN value, for received segments, a local SND.ESN value; for received segments, a local RCV.ESN value is
RCV.ESN value is used. The details of how these values are used. The details of how these values are maintained and used is
maintained and used is described in Sections 5, 8.4, and 8.5. described in Sections 8.2, 9.4, and 9.5.
2. The TCP pseudoheader: IP source and destination addresses, 2. The TCP pseudoheader: IP source and destination addresses,
protocol number and segment length, all in network byte order, protocol number and segment length, all in network byte order,
prepended to the TCP header below. The pseudoheader is exactly as prepended to the TCP header below. The pseudoheader is exactly as
used for the TCP checksum in either IPv4 or IPv6 used for the TCP checksum in either IPv4 or IPv6
[RFC793][RFC2460]: [RFC793][RFC2460]:
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source Address | | Source Address |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
skipping to change at page 13, line 31 skipping to change at page 20, line 31
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Upper-Layer Packet Length | | Upper-Layer Packet Length |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| zero | Next Header | | zero | Next Header |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 5 TCP IPv6 pseudoheader [RFC2460] Figure 5 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.
4. TCP data, in network byte order
Note that the connection key is not included here; the MAC algorithm
indicates how to use the connection key, e.g., as HMACs do in general
[RFC2104][RFC2403]. The connection key is derived from the TSAD
entry's master key as described in Sections 7, 8.4, and 8.5.
By default, TCP-AO includes the TCP options in the MAC calculation
because these options are intended to be end-to-end and some are
required for proper TCP operation (e.g., SACK, timestamp, large
windows). Middleboxes that alter TCP options en-route are a kind of
attack and would be successfully detected by TCP-AO. In cases where
the configuration of the connection's security association state
indicates otherwise, the TCP options can be excluded from the MAC
calculation. When options are excluded, all options - including TCP-
AO - are skipped over during the MAC calculation (rather than being
zeroed).
The TCP-AO option does not indicate the MAC algorithm either
implicitly (as with TCP MD5) or explicitly. The particular algorithm
used is considered part of the configuration state of the
connection's security association and is managed separately (see
Section 7).
5. Preventing replay attacks within long-lived connections
TCP uses a 32-bit sequence number which may, for long-lived
connections, roll over and repeat. This could result in TCP segments
being intentionally and legitimately replayed within a connection.
TCP-AO prevents replay attacks, and thus requires a way to
differentiate these legitimate replays from each other, and so it
adds a 32-bit extended sequence number (ESN) for transmitted and
received segments.
The ESN extends TCP's sequence number so that segments within a When the TCP option flag is 0, the TCP options are included in MAC
single connection are always unique. When TCP's sequence number rolls processing, except that the MAC field of the TCP-AO option is
over, there is a chance that a segment could be repeated in total; zeroed-out.
using an ESN differentiates even identical segments sent with
identical sequence numbers at different times in a connection. TCP-AO
emulates a 64-bit sequence number space by inferring when to
increment the high-order 32-bit portion (the ESN) based on
transitions in the low-order portion (the TCP sequence number).
TCP-AO thus maintains SND.ESN for transmitted segments, and RCV.ESN When the TCP option flag is 1, all TCP options are omitted from
for received segments, both initialized as zero when a connection MAC processing, except for the non-MAC portions of the TCP-AO
begins. The intent of these ESNs is, together with TCP's 32-bit option. In this case, the following field is used instead of the
sequence numbers, to provide a 64-bit overall sequence number space. options part of the TCP header:
For transmitted segments SND.ESN can be implemented by extending +----------+----------+----------+----------+
TCP's sequence number to 64-bits; SND.ESN would be the top (high- | Kind | Length | KeyID | NextKeyID|
order) 32 bits of that number. For received segments, TCP-AO needs to +----------+----------+----------+----------+
emulate the use of a 64-bit number space, and correctly infer the
appropriate high-order 32-bits of that number as RCV.ESN from the
received 32-bit sequence number and the current connection context.
The implementation of ESNs is not specified in this document, but one 4. The TCP data, i.e., the payload of the TCP segment.
possible way is described here that can be used for either RCV.ESN,
SND.ESN, or both.
Consider an implementation with two ESNs as required (SND.ESN, Note that the traffic key is not included as part of the data; the
RCV.ESN), and additional variables as listed below, all initialized MAC algorithm indicates how to use the traffic key, e.g., as HMACs do
to zero, as well as a current TCP segment field (SEG.SEQ): in general [RFC2104][RFC2403]. The traffic key is derived from the
current master key as described in Sections 7.2.
o SND.PREV_SEQ, needed to detect rollover of SND.SEQ 7.2. Key Derivation Functions
o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ
o SND.ESN_FLAG, which indicates when to increment the SND.ESN TCP-AO's traffic keys are derived from the master key tuples using
Key Derivation Functions (KDFs). The KDFs used in TCP-AO have the
following interface:
o RCV.ESN_FLAG, which indicates when to increment the RCV.ESN INPUT: PRF_alg, master_key, output_length, data_block
When a segment is received, the following algorithm (written in C) OUTPUT: traffic_key
computes the ESN used in the MAC; an equivalent algorithm can be
applied to the "SND" side:
# where:
# ROLL is just shorthand
ROLL = (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff);
#
# set the flag when the SEG.SEQ first rolls over
if ((RCV.ESN_FLAG == 0) && (ROLL)) {
RCV.ESN = RCV.ESN + 1;
RCV.ESN_FLAG = 1;
}
#
# decide which ESN to use during rollover after incremented
if ((RCV.ESN_FLAG == 1) && (ROLL)) {
ESN = RCV.ESN - 1; # use the pre-increment value
} else {
ESN = RCV.ESN; # use the current value
}
#
# reset the flag in the *middle* of the window
if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) {
RCV.ESN_FLAG = 0;
}
#
# save the current SEQ for the next time through the code
RCV.PREV_SEQ = SEG.SEQ;
In the above code, ROLL is true in the first line when the sequence o PRF_alg - the specific pseudorandom function (PRF) that is the
number rolls over, i.e., when the new number is low (in the bottom basic building block used in constructing the given KDF. This is
half of the number space) and the old number is high (in the top half specified by the MAC algorithm as specified in [ao-crypto].
of the number space). The first time this happens, the ESN is
incremented and a flag is set. The flag prevents the ESN from being
incremented again until the flag 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 the receive window is never
larger than half of the number space, it is impossible to both set
and reset the flag at the same time - outstanding packets, regardless
of reordering, cannot straddle both regions simultaneously.
6. Computing connection keys from TSAD entries o Master_key - The master_key string, as will be stored into the
associated TCP-AO TAPD master key tuple.
TSAD entries, described in Section 7, include master keys which are o Output_length - The desired output length of the KDF, i.e., the
used in conjunction with a TCP's connection ISNs to generate unique length to which the KDF's output will be truncated or padded. In
connection keys. This allows a static master key to be reused across TCP-AO, the output_length is the PRF_truncation value of the
different connections, or across different instances of connections master key tuple. This is specified by the MAC algorithm as
within a socket pair, while maintaining unique connection keys. specified in [ao-crypto].
Unique connection keys are generated without relying on external key
management properties.
Given a master key tuple, the TCP socket pair, and the connection o Data_block - The data block used as input in constructing the KDF.
ISNs, the connection key used in the MAC algorithm is computed as The data block provided by TCP-AO is used as the "context" as
follows, truncated to the same length as the master key, using a specified in [ao-crypto]. The specific way this context is used,
pseudorandom function (PRF): in conjunction with other information, to create the raw input to
the PRF is also explained further in [ao-crypto].
Conn_key = PRF(TSAD_master_key, input) The data used as input to the KDF combines TCP socket pair with the
where endpoint initial sequence numbers (ISNs) of a connection. This
input = 0 + "TCP-AO" + connblock + TSAD_master_key_len provides context unique to each TCP connection instance, which
enables TCP-AO to generate unique traffic keys for that connection,
even from a master key 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. This data block is defined in Figure 6 and Figure 7.
The components of the input are concatenated as a single byte string +--------+--------+--------+--------+
(the string concatenation operator is shown here as "+"). The initial | Source Address |
zero of the input is a single byte, "TCP-AO" is a null-terminated +--------+--------+--------+--------+
string, connblock is defined below, and TSAD_master_key_len is the | Destination Address |
length of the TSAD master key in bytes, as stored in the TSAD entry. +--------+--------+--------+--------+
The PRF to be used for a given master key is indicated in the TDAD | Source Port | Dest. Port |
master key tuple, and details of the PRF are provided in [RFC-TBD]. +--------+--------+--------+--------+
| Source ISN |
+--------+--------+--------+--------+
| Dest. ISN |
+--------+--------+--------+--------+
The connection block (connblock) is defined as follows (IP addresses Figure 6 Data block for an IPv4 connection
are correspondingly longer for IPv6 addresses):
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source IP | | |
+ +
| |
+ Source Address +
| |
+ +
| |
+ +
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Destination IP | | |
+ +
| |
+ Destination Address +
| |
+ +
| |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source Port | Dest. Port | | Source Port | Dest. Port |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source ISN | | Source ISN |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Destination ISN | | Dest. ISN |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 6 Connection block used for connection key generation Figure 7 Data block for an IPv6 connection
"Source" and "destination" are defined by the direction of the "Source" and "destination" are defined by the direction of the
segment being MAC'd; for incoming packets, source is the remote side, segment being MAC'd; for incoming packets, source is the remote side,
whereas for outgoing packets source is the local side. This further whereas for outgoing packets source is the local side. This further
ensures that connection keys generated for each direction are unique. ensures that 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 connection block shown above, in which the key is computed using the connection block 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 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.
>> Segments sent in response to connections for which the ISNs are Overall, this means that each connection will use up to four distinct
not known SHOULD NOT use TCP-AO. traffic keys for each master key:
Once a connection is established, a connection key would typically be o Send_SYN_traffic_key - the traffic key used to authenticate
cached to avoid recomputing it on a per-segment basis (e.g., in the outgoing SYNs. The source ISN known (the TCP connection's local
TCP Transmission Control Block, i.e, the TCB [RFC793]). The use of ISN), and the destination (remote) ISN is unknown (and so the
both ISNs in the connection key computation ensures that segments value 0 is used).
cannot be replayed across repeated connections reusing the same
socket pair (provided the ISN pair does not repeat, which is unlikely o Receive_SYN_traffic_key - the traffic key used to authenticate
because both endpoints should select ISNs pseudorandomly [RFC1948], incoming SYNs. The source ISN known (the TCP connection's remote
their 32-bit space avoids repeated use except under reboot, and reuse ISN), and the destination (remote) ISN is unknown (and so the
assumes both sides repeat their use on the same connection). value 0 is used).
o Send_other_traffic_key - the traffic key used to authenticate all
other outgoing TCP segments. The source ISN is the TCP
connection's local ISN, and the destination ISN is the TCP
connection's remote ISN.
o Receive_other_traffic_key - the traffic key used to authenticate
all other incoming TCP segments. The source ISN is the TCP
connection's remote ISN, and the destination ISN is the TCP
connection's remote ISN.
The use of both ISNs in the KDF ensures that segments cannot be
replayed across repeated connections reusing the same socket pair
(provided the ISN pair does not repeat, which is unlikely because
both endpoints should select ISNs pseudorandomly [RFC1948], their 32-
bit space avoids repeated use except under reboot, and reuse assumes
both sides repeat their use on the same connection).
In general, a SYN would be MAC'd using a destination ISN of zero In general, a SYN would be MAC'd using a destination ISN of zero
(whether sent or received), and all other segments would be MAC'd (whether sent or received), and all other segments would be MAC'd
using the ISN pair for the connection. There are other cases in which using the ISN pair for the connection. There are other cases in which
the destination ISN is not known, but segments are emitted, such as the destination ISN is not known, but segments are emitted, such as
after an endpoint reboots, when is possible that the two endpoints after an endpoint reboots, when is possible that the two endpoints
would not have enough information to authenticate segments. In such would not have enough information to authenticate segments. In such
cases, TCP's timeout mechanism will allow old state to be cleared to cases, TCP's timeout mechanism will allow old state to be cleared to
enable new connections, except where the user timeout is disabled; it enable new connections, except where the user timeout is disabled; it
is important that implementations are capable of detecting excesses is important that implementations are capable of detecting excesses
of TCP connections in such a configuration and can clear them out if of TCP connections in such a configuration and can clear them out if
needed to protect its memory usage [Je07]. needed to protect its memory usage [Je07].
7. Security Association Management 7.3. Traffic Key Establishment and Duration Issues
TCP-AO relies on a TCP Security Association Database (TSAD), which The TCP-AO option does not provide a mechanism for traffic key
indicates whether a TCP connection requires TCP-AO, and its negotiation or parameter negotiation (MAC algorithm, length, or use
parameters when so. The TSAD is described as an explicit component of of the TCP-AO option), or for coordinating rekeying during a
TCP-AO to enable external (master) key management mechanisms - connection. We assume out-of-band mechanisms for master key
automatic or manual - to interact with TCP-AO as needed. establishment, parameter negotiation, and rekeying. This separation
of master key use from master key management is similar to that in
the IPsec security suite [RFC4301][RFC4306].
TSAD entries are assumed to exist at the endpoints where TCP-AO is We encourage users of TCP-AO to apply known techniques for generating
used, in advance of the connection: appropriate master keys, including the use of reasonable master key
lengths, limited traffic key sharing, and limiting the duration of
master key use [RFC3562]. This also includes the use of per-
connection nonces, as suggested in Section 7.2.
1. TCP connection identifier (ID), i.e., socket pair - IP source TCP-AO supports rekeying in which new master keys are negotiated and
address, IP destination address, TCP source port, and TCP coordinated out-of-band, either via a protocol or a manual procedure
destination port [RFC793]. TSAD entries are uniquely determined by [RFC4808]. New master key use is coordinated using the out-of-band
their TCP connection ID, which is used to index those entries. A mechanism to update the TAPD at both TCP endpoints. When only a
TSAD entry may allow wildcards, notably in the source port value. single master key is used at a time, the temporary use of invalid
master keys could result in packets being dropped; although TCP is
already robust to such drops, TCP-AO uses the KeyID field to avoid
such drops. The TAPD can contain multiple concurrent master keys,
where the KeyID field is used to identify the master key that
corresponds to the traffic key used for a segment, to avoid the need
for expensive trial-and-error testing of master keys in sequence.
>> There MUST be no more than one matching TSAD entry per TCP-AO provides an explicit key coordination mechanism, described in
direction for a fully-instantiated (no wildcards) TCP connection Section 8.1. Such a mechanism is useful when new keys are installed,
ID. or when keys are changed, to determine when to commence using
installed keys.
2. For each of inbound (for received TCP segments) and outbound (for The KeyID field is also useful in coordinating master keys used for
sent TCP segments) directions for this connection (except as new connections. A TAPD entry may be configured that matches the
noted): unbound source port, which would return a set of possible master
keys. The KeyID would then indicate the specific master key, allowing
more efficient connection establishment; otherwise, the master keys
could have been tried in sequence.
a. TCP option flag. When 0, this flag allows default operation, Users are advised to manage master keys following the spirit of the
i.e., TCP options are included in the MAC calculation, with advice for key management when using TCP MD5 [RFC3562], notably to
TCP-AO's MAC field zeroed out. When 1, all options (including use appropriate key lengths (12-24 bytes) and to avoid sharing master
TCP-AO) are excluded from all MAC calculations (skipped over, keys among multiple BGP peering arrangements. This requires that the
not simply zeroed). TAPD support monitoring and modification.
>> The TCP option flag MUST default to 0 (i.e., options not 7.3.1. Master Key Reuse Across Socket Pairs
excluded).
>> The TCP option flag MUST NOT change during a TCP Master keys can be reused across different socket pairs within a
connection. host, or across different instances of a socket pair within a host.
In either case, replay protection is maintained.
The TCP option flag cannot change during a connection because Master keys reused across different socket pairs cannot enable replay
TCP state is coordinated during connection establishment. TCP attacks because the TCP socket pair is included in the MAC, as well
lacks a handshake for modifying that state after a connection as in the generation of the traffic key. Master keys reused across
has been established. repeated instances of a given socket pair cannot enable replay
attacks because the connection ISNs are included in the traffic key
generation algorithm, and ISN pairs are unlikely to repeat over
useful periods.
b. An extended sequence number (ESN). The ESN enables each 7.3.2. Master Key Use Within a Long-lived Connection
segment's MAC calculation to have unique input data, even when
payload data is retransmitted and the TCP sequence number
repeats due to wraparound. The ESN is initialized to zero upon
connection establishment. Its use in the MAC calculation is
described in Section 4.2, and its management is described in
Section 5.
c. An ordered list of zero or more master key tuples. Each tuple TCP-AO uses extended sequence numbers (ESNs) to prevent replay
is defined as the set <KeyID, MAC type, master key length, attacks within long-lived connections. Explicit master key rollover,
master key, PRF> as follows: accomplished by external means and indexed using the KeyID field, can
be used to change keying material for various reasons (e.g.,
personnel turnover), but is not required to support long-lived
connections.
>> Components of a TSAD master key tuple MUST NOT change 8. Additional Security Mechanisms
during a connection.
Keeping the tuple components static ensures that the KeyID TCP-AO adds mechanisms to support efficient use, especially in
uniquely determines the properties of a packet; this supports environments where only manual keying is available. These include the
use of the KeyID to determine the packet properties. previously described mechanisms for supporting multiple concurrent
keys (via the KeyID field) and for generating unique per-connection
traffic keys (via the KDF). This section describes additional
mechanisms to coordinate KeyID changes and to prevent replay attacks
when a traffic key is not changed for long periods of time.
>> The set of TSAD master key tuples MAY change during a 8.1. Coordinating KeyID Changes
connection, but KeyIDs of those tuples MUST NOT overlap. I.e.,
tuple parameter changes MUST be accompanied by master key
changes.
i. KeyID. The value as used in the TCP-AO option; used to At any given time, a single TCP connection may have multiple KeyIDs
differentiate connection keys in concurrent use that are specified for each segment direction (incoming, outgoing). TCP-AO
derived from different master keys. provides a mechanism to indicate when a new KeyID is ready, to allow
the sender to commence use of that new KeyID. This supported by using
two key ID fields in the header:
>> A TSAD implementation MUST support at least two KeyIDs o KeyID
per connection per direction, and MAY support up to 256.
>> A KeyID MUST support any value, 0-255 inclusive. There o NextKeyID
are no reserved KeyID values.
KeyID values are assigned arbitrarily. They can be KeyID represents the outgoing keying information used by the segment
assigned in sequence, or based on any method mutually sender to create the segment's MAC (outgoing), and the corresponding
agreed by the connection endpoints (e.g., using an incoming keying information used by the segment receiver to validate
external master key management mechanism). that MAC. It indicates the KeyID in active use in that direction.
>> KeyIDs MUST NOT be assumed to be randomly assigned. NextKeyID represents the preferred keying information to be used for
subsequent segments. I.e., it is a way for the segment sender to
indicate ready incoming keying information for future segments it
receives, so that the segment receiver can know when to switch
traffic keys (and thus their KeyIDs).
ii. MAC type. Indicates the MAC used for this connection, as There are two pointers kept by each side of a connection, as noted in
defined in [RFC-TBD]. This includes the MAC algorithm the per-connection information (see Section 6):
(e.g., HMAC-SHA1, AES-CMAC, etc.) and the length of the
MAC as truncated to (e.g., 96, 128, etc.).
>> A MAC type of "NONE" MUST be supported, to indicate o Currently active outgoing KeyID (Current_key)
that authentication is not used in this direction; this
allows asymmetric use of TCP-AO.
>> At least one direction (inbound/outbound) SHOULD have o Current preference for KeyIDs (Next_key)
a non-"NONE" MAC in practice, but this MUST NOT be
strictly required by an implementation.
>> When the outbound MAC is set to values other than Current_key points to a KeyID (and associated master key tuple) that
"NONE", TCP-AO MUST occur in every outbound TCP segment is used to authenticate outgoing segments. Upon connection
for that connection; when set to NONE or when no tuple establishment, it points to the first key selected for use.
exists, TCP-AO MUST NOT occur in those segments.
>> When the inbound MAC is set to values other than Next_key points to an incoming KeyID (and associated master key
"NONE", TCP-AO MUST occur in every inbound TCP segment tuple) that is ready and preferred for use. Upon connection
for that connection; when set to "NONE" or when no tuple establishment, this points to the currently active incoming key. It
exists, TCP-AO SHOULD NOT be added to those segments, but can be changed when new keys are installed (e.g., either by automatic
MAY occur and MUST be ignored. key management protocol operation or by user manual selection).
iii. Master key length. Indicates the length of the master key Next_key is changed only by manual user intervention or key
in bytes. management protocol operation. It is not manipulated by TCP-AO.
Current_key is updated by TCP-AO when processing received TCP
segments as discussed in the segment processing description in
Section 9.5.
iv. Master key. A byte sequence used for generating 8.2. Preventing replay attacks within long-lived connections
connection keys, this may be derived from a separate
shared key by an external protocol over a separate
channel. This sequence is used in network-standard byte
order in the connection key generation algorithm
described in Section 6.
v. PRF. A pseudorandom function used for the geneation of a TCP uses a 32-bit sequence number which may, for long-lived
connection key from the master key tuple, as described in connections, roll over and repeat. This could result in TCP segments
Section 6. The specific functions used are described in being intentionally and legitimately replayed within a connection.
[RFC-TBD]. TCP-AO prevents replay attacks, and thus requires a way to
differentiate these legitimate replays from each other, and so it
adds a 32-bit extended sequence number (ESN) for transmitted and
received segments.
It is anticipated that TSAD entries for TCP connections in states The ESN extends TCP's sequence number so that segments within a
other than CLOSED can be indexed in the TCP TCB for convenience, but single connection are always unique. When TCP's sequence number rolls
that the index would reference a separate database with entries for over, there is a chance that a segment could be repeated in total;
all connections to an IP address (see Section 9.1 for notes on the using an ESN differentiates even identical segments sent with
latter. This means that for a particular endpoint (i.e., IP address) identical sequence numbers at different times in a connection. TCP-AO
there would be exactly one database that is consulted by all pending emulates a 64-bit sequence number space by inferring when to
connections, the same way that there is only one table of TCBs (a increment the high-order 32-bit portion (the ESN) based on
database can support multiple endpoints, but an endpoint is transitions in the low-order portion (the TCP sequence number).
represented in only one database). Multiple databases could be used
to support virtual hosts, i.e., groups of interfaces.
Note that the TCP-AO fields omit an explicit algorithm ID; that TCP-AO thus maintains SND.ESN for transmitted segments, and RCV.ESN
algorithm is already specified by the TCP connection ID and stored in for received segments, both initialized as zero when a connection
the TSAD. begins. The intent of these ESNs is, together with TCP's 32-bit
sequence numbers, to provide a 64-bit overall sequence number space.
Also note that this document does not address how TSAD entries are For transmitted segments SND.ESN can be implemented by extending
created by users/processes; it specifies how they must be destroyed TCP's sequence number to 64-bits; SND.ESN would be the top (high-
corresponding to connection states, but users/processes may destroy order) 32 bits of that number. For received segments, TCP-AO needs to
entries as well. It is presumed that a TSAD entry affecting a emulate the use of a 64-bit number space, and correctly infer the
particular connection cannot be destroyed during an active connection appropriate high-order 32-bits of that number as RCV.ESN from the
- or, equivalently, that its parameters are copied to TSAD entries received 32-bit sequence number and the current connection context.
local to the connection (i.e., instantiated) and so changes would
affect only new connections. The TSAD could be managed by a separate
application protocol.
8. TCP-AO Interaction with TCP The implementation of ESNs is not specified in this document, but one
possible way is described here that can be used for either RCV.ESN,
SND.ESN, or both.
Consider an implementation with two ESNs as required (SND.ESN,
RCV.ESN), and additional variables as listed below, all initialized
to zero, as well as a current TCP segment field (SEG.SEQ):
o SND.PREV_SEQ, needed to detect rollover of SND.SEQ
o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ
o SND.ESN_FLAG, which indicates when to increment the SND.ESN
o RCV.ESN_FLAG, which indicates when to increment the RCV.ESN
When a segment is received, the following algorithm (written in C)
computes the ESN used in the MAC; an equivalent algorithm can be
applied to the "SND" side:
/* */
/* set the flag when the SEG.SEQ first rolls over */
if ((RCV.ESN_FLAG == 0)
&& (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) {
RCV.ESN = RCV.ESN + 1;
RCV.ESN_FLAG = 1;
}
/* */
/* decide which ESN to use after incremented */
if ((RCV.ESN_FLAG == 1) && (SEG.SEQ > 0x7fff)) {
ESN = RCV.ESN - 1; # use the pre-increment value
} else {
ESN = RCV.ESN; # use the current value
}
/* */
/* reset the flag in the *middle* of the window */
if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) {
RCV.ESN_FLAG = 0;
}
/* */
/* save the current SEQ for the next time through the code */
RCV.PREV_SEQ = SEG.SEQ;
In the above code, the first line when the sequence number first
rolls over, i.e., when the new number is low (in the bottom half of
the number space) and the old number is high (in the top half of the
number space). The first time this happens, the ESN is incremented
and a flag is set.
If the flag is set and a high number is seen, it must be a reordered
packet, so use the pre-increment ESN, otherwise use the current ESN.
The flag will be cleared by the time the number rolls all the way
around.
The flag prevents the ESN from being incremented again until the flag
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
the receive window is never larger than half of the number space, it
is impossible to both set and reset the flag at the same time -
outstanding packets, regardless of reordering, cannot straddle both
regions simultaneously.
9. 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].
8.1. TCP User Interface 9.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 this
interface as it applies to TCP, but some commands or command 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 TSAD TCP-AO requires the TCP user interface be extended to allow the TAPD
to be configured, as well as to allow an ongoing connection to manage to be configured, as well as to allow an ongoing connection to manage
which KeyID tuples are active. The TSAD needs to be configured prior which KeyID tuples are active. The TAPD needs to be configured prior
to connection establishment, and possibly changed during a to connection establishment, and possibly changed 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 TSAD entry can be configured. a TAPD entry can be configured.
>> A TCP-AO implmentation MUST allow TSAD entries for ongoing TCP >> A TCP-AO implmentation MUST allow TAPD entries 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.
Parameters not used to index a connection MAY be modified; parameters Parameters not used to index a connection MAY be modified; parameters
used to index a connection MUST NOT be modified. used to index a connection MUST NOT be modified.
The TSAD information of a connection needs to be available for The TAPD information of a connection needs to be available for
confirmation; this includes the ability to read the connection key: confirmation; this includes the ability to read the connection key:
>> TCP STATUS SHOULD be augmented to allow the TSAD entry of a >> TCP STATUS SHOULD be augmented to allow the TAPD entry of a
current or pending connection to be read (for confirmation). current or pending connection to be read (for confirmation).
Senders need to be able to determine when the outgoing KeyID changes; Senders may need to be able to determine when the outgoing KeyID
this change immediately affects all subsequent outgoing segments changes or when a new preferred KeyID (NextKeyID) is indicated; these
(i.e., it need not be synchronized with the data of the SEND call, if changes immediately affect all subsequent outgoing segments:
indicated therein):
>> 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 KeyID of a TSAD entry can be indicated. augmented so that the preferred KeyID (Current_key) and/or the
Next_key of a connection can be indicated.
It may be useful to change the sender-side active KeyID even when no It may be useful to change the outgoing active KeyID (Current_key)
data is being sent, which can be achieved by sending a zero-length even when no data is being sent, which can be achieved by sending a
buffer or by using a non-send interface (e.g., socket options in zero-length buffer or by using a non-send interface (e.g., socket
Unix), depending on the implementation. options in Unix), depending on the implementation.
It is also useful for the receive side to indicate the recent KeyID It is also useful to indicate recent KeyID and NextKeyID values
received; although there could be a number of such KeyIDs, the KeyIDs received; although there could be a number of such values, they are
are not expected to change quickly so any recent sample of a received not expected to change quickly so any recent sample should be
KeyID is sufficient: 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 of a recently received segment is MUST be augmented so that the KeyID and NextKeyID of a recently
available to the user out-of-band (e.g., as an additional parameter received segment is available to the user out-of-band (e.g., as an
to RECEIVE, or via a STATUS call). additional parameter to RECEIVE, or via a STATUS call).
8.2. TCP States and Transitions 9.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 TSAD entry MAY be associated with any TCP state. >> A TAPD entry MAY be associated with any TCP state.
>> A TSAD entry MAY underspecify the TCP connection for the LISTEN >> A TAPD entry MAY underspecify the TCP connection for the LISTEN
state. Such an entry MUST NOT be used for more than one connection state. Such an entry MUST NOT be used for more than one connection
progressing out of the LISTEN state. progressing out of the LISTEN state.
8.3. TCP Segments 9.3. TCP Segments
TCP includes control (at least one of SYN, FIN, RST flags set) and TCP includes control (at least one of SYN, FIN, RST flags set) and
data (none of SYN, FIN, or RST flags set) segments. Note that some data (none of SYN, FIN, or RST flags set) segments. Note that some
control segments can include data (e.g., SYN). control segments can include data (e.g., SYN).
>> All TCP segments MUST be checked against the TSAD for matching TCP >> All TCP segments MUST be checked against the TAPD for matching TCP
connection IDs. connection IDs.
>> TCP segments matching TSAD entries with non-NULL MACs without TCP- >> TCP segments matching TAPD entries without TCP-AO, or with TCP-AO
AO, or with TCP-AO and whose MACs and KeyIDs do not validate MUST be and whose MACs and KeyIDs do not validate MUST be silently discarded.
silently discarded.
>> TCP segments with TCP-AO but not matching TSAD entries MUST be >> TCP segments with TCP-AO but not matching TAPD entries MUST be
silently accepted; this is required for equivalent function with TCPs silently accepted; this is required for equivalent function with TCPs
not implementing TCP-AO. not implementing TCP-AO.
>> Silent discard events SHOULD be signaled to the user as a warning, >> Silent discard events SHOULD be signaled to the user as a warning,
and silent accept events MAY be signaled to the user as a warning. and silent accept events MAY be signaled to the user as a warning.
Both warnings, if available, MUST be accessible via the STATUS Both warnings, if available, MUST be accessible via the STATUS
interface. Either signal MAY be asynchronous, but if so they MUST be interface. Either signal MAY be asynchronous, but if so they MUST be
rate-limited. Either signal MAY be logged; logging SHOULD allow rate- rate-limited. Either signal MAY be logged; logging SHOULD allow rate-
limiting as well. limiting as well.
All TCP-AO processing occurs between the interface of TCP and IP; for All TCP-AO processing occurs between the interface of TCP and IP; for
incoming segments, this occurs after validation of the TCP checksum. incoming segments, this occurs after validation of the TCP checksum.
For outgoing segments, this occurs before computation of the TCP For outgoing segments, this occurs before computation of the TCP
checksum. checksum.
Note that the TCP-AO option is not negotiated. It is the Note that the TCP-AO option is not negotiated. It is the
responsibility of the receiver to determine when TCP-AO is required responsibility of the receiver to determine when TCP-AO is required
and to enforce that requirement. and to enforce that requirement.
8.4. Sending TCP Segments 9.4. Sending TCP Segments
The following procedure describes the modifications to TCP to support The following procedure describes the modifications to TCP to support
TCP-AO when a segment departs. TCP-AO when a segment departs.
1. Check the segment's TCP connection ID against the TSAD >> Note that TCP-AO MUST be the last TCP option processed on outgoing
segments, because its MAC calculation may include the values of other
TCP options.
2. If there is NO TSAD entry, omit the TCP-AO option. Proceed with 1. Find the per-connection parameters for the segment:
computing the TCP checksum and transmit the segment.
3. If there is a TSAD entry with zero master key tuples, omit the a. If the segment is a SYN, then this is the first segment of a
TCP-AO option. Proceed with computing the TCP checksum and new connection. Consult the TAPD to find the appropriate
transmit the segment. master key tuple.
4. If there is a TSAD entry and a master key tuple and the outgoing i. If there is no matching TAPD entry, omit the TCP-AO
MAC is NONE, omit the TCP-AO option. Proceed with computing the option. Proceed with transmitting the segment.
TCP checksum and transmit the segment.
5. If there is a TSAD entry and a master key tuple and the outgoing ii. If there is a TAPD entry with zero master key tuples,
MAC is not NONE: silently discard the segment and cease further
processing.
iii. If there is a TAPD entry and at least one master key
tuple, then set the per-connection parameters as needed
(see Section 6). Proceed with the step 2.
b. If the segment is not a SYN, then determine whether TCP-AO is
being used and the current_key value from the per-connection
parameters (see Section 6) and proceed with the step 2.
2. Using the per-connection parameters:
a. Augment the TCP header with the TCP-AO, inserting the a. Augment the TCP header with the TCP-AO, inserting the
appropriate Length and KeyID based on the indexed TSAD entry. appropriate Length and KeyID based on the master key tuple
Update the TCP header length accordingly. indicated by current_key. Update the TCP header length
accordingly.
b. Determine SND.ESN as described in Section 5. b. Determine SND.ESN as described in Section 8.2.
c. Determine the connection key from the indexed TSAD entry as c. Determine the appropriate traffic key, i.e., as pointed to by
described in Section 6. current_key (as noted in Section 8.1, and as probably cached
in the TCB). I.e., use the Send_SYN_traffic_key for SYN
segments, and the send_other_traffic_key for other segments.
d. Compute the MAC using the indexed TSAD entry and data from the d. Determine the NextKeyID as indicated by the Next_key pointer
segment as specified in Section 4.2, including the TCP (as noted in Section 8.1).
pseudoheader and TCP header. Include or exclude the options as
indicated by the TSAD entry's TCP option exclusion flag.
e. Insert the MAC in the TCP-AO field. e. Compute the MAC using the master key tuple (and cached traffic
key) and data from the segment as specified in Section 7.1.
f. Proceed with computing the TCP checksum on the outgoing packet f. Insert the MAC in the TCP-AO field.
and transmit the segment.
8.5. Receiving TCP Segments g. Proceed with transmitting the segment.
9.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.
1. Check the segment's TCP connection ID against the TSAD. >> Note that TCP-AO MUST be the first TCP option processed on
incoming segments, because its MAC calculation may include the values
of other TCP options which could change during TCP option processing.
This also protects the behavior of all other TCP options from the
impact of spoofed segments or modified header information.
2. If there is NO TSAD entry, proceed with TCP processing. >> Note that TCP-AO checks MUST be performed for all incoming SYNs to
avoid accepting SYNs lacking the TCP-AO option where required. Other
segments can cache whether TCP-AO is needed in the TCB.
3. If there is a TSAD entry with zero master key tuples, proceed with 1. Find the per-connection parameters for the segment:
TCP processing.
4. If there is a TSAD entry with a master key tuple and the incoming a. If the segment is a SYN, then this is the first segment of a
MAC is NONE, proceed with TCP processing. new connection. Consult the TAPD to find the appropriate
master key tuple.
5. If there is a TSAD entry with a master key tuple and the incoming i. If there is no matching TAPD entry, omit the TCP-AO
MAC is not NONE: option. Proceed with further TCP handling of the segment.
a. Check that the segment's TCP-AO Length matches the length ii. If there is a TAPD entry with zero master key tuples,
indicated by the indexed TSAD. silently discard the segment and cease further TCP
processing.
i. If Lengths differ, silently discard the segment. Log iii. If there is a TAPD entry and at least one master key
and/or signal the event as indicated in Section 8.3. tuple, then set the per-connection parameters as needed
(see Section 6). Proceed with the step 2.
b. Use the KeyID value to index the appropriate connection key 2. Using the per-connection parameters:
for this connection.
i. If the TSAD has no entry corresponding to the segment's a. Check that the segment's TCP-AO Length matches the length
KeyID, silently discard the segment. indicated by the master key indicated by the segment's TCP-AO
KeyID field.
c. Determine the segment's RCV.ESN as described in Section 5. i. If lengths differ, silently discard the segment. Log
and/or signal the event as indicated in Section 9.3.
d. Determine the segment's connection key from the indexed TSAD b. Use the segment's KeyID value to index the appropriate
entry as described in Section 6. connection key for this connection.
e. Compute the segment's MAC using the indexed TSAD entry and c. Determine the segment's RCV.ESN as described in Section 8.2.
portions of the segment as indicated in Section 4.2.
Again, if options are excluded (as per the TCP option d. Determine the segment's traffic key from the master key tuple
exclusion flag), they are skipped over (rather than zeroed) as described in Section 7.1 (and as likely cached in the TCB).
when used as input to the MAC calculation. I.e., use the receive_SYN_traffic_key for SYN segments, and
the receive_other_traffic_key for other segments.
e. Compute the segment's MAC using the master key tuple (and its
derived traffic key) and portions of the segment as indicated
in Section 7.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 event as indicated in Section 8.3. the event as indicated in Section 9.3.
f. Proceed with TCP processing of the segment. f. Compare the received NextKeyID value to the currently active
outgoing KeyID value (Current_key).
i. If they match, no further action is required.
ii. If they differ, determine whether the NextKeyID keying
information is ready.
1. If the NextKeyID keying information is not
available, no action is required.
2. If the NextKeyID keying information is available:
NOTE: there is an open question as to whether to
refuse to change to the suggested NextKeyID if it
already has a 2*MSL timer set on it, i.e., to refuse
to 'backup' and use a key once it has been
previously used.
a. Set a timer on the previous value of current_key
to ensure that the corresponding master key
cannot be removed from the TAPD for 2*MSL.
b. Set Current_key to the NextKeyID value.
g. 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 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.
8.6. Impact on TCP Header Size 9.6. Impact on TCP Header Size
The TCP-AO option typically uses a total of 17-19 bytes of TCP header The TCP-AO option typically uses a total of 17-19 bytes of TCP header
space. TCP-AO is no larger than and typically 3 bytes smaller than space. TCP-AO is no larger than and typically 3 bytes smaller than
the TCP MD5 option (assuming a 96-bit MAC). the TCP MD5 option (assuming a 96-bit MAC).
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
implementations (listed below), leaving at most 20 for TCP-AO. implementations (listed below), leaving at most 25 for other uses.
Assuming a 96-bit MAC, TCP-AO consumes 15 bytes, leaving up to 10 Assuming a 96-bit MAC, TCP-AO consumes 16 bytes, leaving up to 9
bytes for other options (depending on implementation dependant bytes for additional SYN options (depending on implementation
alignment padding, which could consume another 2 bytes at most). dependant alignment padding, which could consume another 2 bytes at
most).
o SACK permitted (2 bytes) [RFC2018][RFC3517] o SACK permitted (2 bytes) [RFC2018][RFC3517]
o Timestamps (10 bytes) [RFC1323] o Timestamps (10 bytes) [RFC1323]
o Window scale (3 bytes) [RFC1323] o Window scale (3 bytes) [RFC1323]
Although TCP option space is limited, we believe TCP-AO is consistent After a SYN, the following options are expected in current
with the desire to authenticate TCP at the connection level for implementations of TCP:
similar uses as were intended by TCP MD5.
9. Connection Key Establishment and Duration Issues
The TCP-AO option does not provide a mechanism for connection key
negotiation or parameter negotiation (MAC algorithm, length, or use
of the TCP-AO option), or for coordinating rekeying during a
connection. We assume out-of-band mechanisms for master key
establishment, parameter negotiation, and rekeying. This separation
of master key use from master key management is similar to that in
the IPsec security suite [RFC4301][RFC4306].
We encourage users of TCP-AO to apply known techniques for generating
appropriate master keys, including the use of reasonable master key
lengths, limited connection key sharing, and limiting the duration of
master key use [RFC3562]. This also includes the use of per-
connection nonces, as suggested in Section 4.2.
TCP-AO supports rekeying in which new master keys are negotiated and
coordinated out-of-band, either via a protocol or a manual procedure
[RFC4808]. New master key use is coordinated using the out-of-band
mechanism to update the TSAD at both TCP endpoints. When only a
single master key is used at a time, the temporary use of invalid
master keys could result in packets being dropped; although TCP is
already robust to such drops, TCP-AO uses the KeyID field to avoid
such drops. The TSAD can contain multiple concurrent master keys,
where the KeyID field is used to identify the master key that
corresponds to the connection key used for a segment, to avoid the
need for expensive trial-and-error testing of master keys in
sequence.
TCP-AO does not currently provide an explicit key coordination
mechanism. Such a mechanism is useful when new keys are installed, or
when keys are changed, to determine when to commence using installed
keys. Note that because TCP-AO uses directional keys, the receive-
side keys can be installed in advance of the send side, avoiding the
need for tight coordination between endpoints.
The KeyID field is also useful in coordinating master keys used for
new connections. A TSAD entry may be configured that matches the
unbound source port, which would return a set of possible master
keys. The KeyID would then indicate the specific master key, allowing
more efficient connection establishment; otherwise, the master keys
could have been tried in sequence. See also Section 9.1.
Users are advised to manage master keys following the spirit of the
advice for key management when using TCP MD5 [RFC3562], notably to
use appropriate key lengths (12-24 bytes), to avoid sharing master
keys among multiple BGP peering arrangements, and to change master
keys every 90 days. This requires that the TSAD support monitoring
and modification.
9.1. Master Key Reuse Across Socket Pairs
Master keys can be reused across different socket pairs within a
host, or across different instances of a socket pair within a host.
In either case, replay protection is maintained.
Master keys reused across different socket pairs cannot enable replay o SACK (10bytes) [RFC2018][RFC3517] (18 bytes if D-SACK [RFC2883]
attacks because the TCP socket pair is included in the MAC, as well
as in the generation of the connection key. Master keys reused across
repeated instances of a given socket pair cannot enable replay
attacks because the connection ISNs are included in the connection
key generation algorithm, and ISN pairs are unlikely to repeat over
useful periods.
9.2. Master Key Use Within a Long-lived Connection o Timestamps (10 bytes) [RFC1323]
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
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
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 option) [RFC2883]. Note that D-SACK is not supportable in TCP-
MD5 in the presence of timestamps, because TCP MD5's MAC length is
fixed and too large to leave sufficient option space.
TCP-AO uses extended sequence numbers (ESNs) to prevent replay Although TCP option space is limited, we believe TCP-AO is consistent
attacks within long-lived connections. Explicit master key rollover, with the desire to authenticate TCP at the connection level for
accomplished by external means and indexed using the KeyID field, can similar uses as were intended by TCP MD5.
be used to change keying material for various reasons (e.g.,
personnel turnover), but is not required to support long-lived
connections.
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 28, line 26 skipping to change at page 35, line 43
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 the TSAD could be augmented to support TCP MD5, It is possible that the TAPD could be augmented to support TCP MD5,
although use of a TSAD-like system is not described in RFC2385. although use of a TAPD-like system is not described in RFC2385.
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 11. Interactions with Middleboxes
skipping to change at page 29, line 33 skipping to change at page 36, line 50
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.
This is supported - see Section 4.2. This is supported - see Section 7.1.
a. TCP pseudoheader, including IPv4 and IPv6 versions. a. TCP pseudoheader, including IPv4 and IPv6 versions.
Note that we do not allow optional coverage because IP Note that we do not allow optional coverage because IP
addresses define a connection. If they can be coordinated addresses define a connection. If they can be coordinated
across a NAT/NAPT, the sender can compute the MAC based on the across a NAT/NAPT, the sender can compute the MAC based on the
received values; if not, a tunnel is required, as noted in received values; if not, a tunnel is required, as noted in
Section 11.2. Section 11.2.
b. TCP header. b. TCP header.
skipping to change at page 30, line 18 skipping to change at page 37, line 34
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 11.
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 4.2. This is supported - see Section 7.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 master key index, MAC, and overall TCP-AO exposes only the master key index, MAC, and overall
option length on the wire. Note that short MACs could be option length on the wire. Note that short MACs could be
obscured by using longer option lengths but specifying a short obscured by using longer option lengths but specifying a short
MAC length (this is equivalent to a different MAC algorithm, MAC length (this is equivalent to a different MAC algorithm,
and is specified in the TSAD entry). See Section 4.2. and is specified in the TAPD entry). See Section 4.2.
b. Allow optional per connection. b. Allow optional per connection.
The option should not be required on every connection; it The option should not be required on every connection; it
should be optional on a per connection basis. should be optional on a per connection basis.
This is supported - see Sections 8.3, 8.4, and 8.5. This is supported - see Sections 9.3, 9.4, and 9.5.
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 - see Sections 8.3, 8.4, and 8.5. This is supported - see Sections 9.3, 9.4, and 9.5.
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 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 8.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 3 bytes shorter Section 2.1, which indicates that TCP-AO is 3 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 [RFC- TCP-AO uses a default required algorithm as specified in [ao-
TBD], as noted in Section 4.2. crypto], 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 [RFC-TBD]. The PRF is also TCP-AO uses MACs as indicated in [ao-crypto]. The PRF is also
specified in [RFC-TBD]. The PRF input string follows the specified in [ao-crypto]. The PRF input string follows the
typical design (in Section 6). typical design (see [ao-crypto]).
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 TSAD allows space limitations, as noted in Section 4.2. The TAPD allows
separate connections to use different algorithms, both for the separate connections to use different algorithms, both for the
MAC and the PRF. MAC and the PRF.
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 8.3, 8.4, and 8.5. Note that This is supported - see Sections 9.3, 9.4, and 9.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 state and out-of-window checks; many such segments, connection state and out-of-window checks; many such segments,
although discarded, cause a host to respond with a replay of although discarded, cause a host to respond with a replay of
the last valid ACK, e.g. [RFC793]. See also the derivation of the last valid ACK, e.g. [RFC793]. See also the derivation of
the ESN, which is reconstituted at the receiver using a the ESN, which is reconstituted at the receiver using a
demonstration algorithm that avoids the need for reordering demonstration algorithm that avoids the need for reordering
(in Section 5). (in Section 8.2).
e. Security parameter changes require key changes. e. Security parameter changes require key changes.
The option should require that the key change whenever the The option should require that the key 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 for TCP options. This also helps allow "bump in the typical for TCP options. This also helps allow "bump in the
stack" implementations that are not integrated with endpoint stack" implementations that are not integrated with endpoint
TCP implementations. TCP implementations.
TSAD parameters that should not change during a connection (by TAPD parameters that should not change during a connection (by
defininition, e.g., TCP connection ID, receiver TCP connection defininition, e.g., TCP connection ID, receiver TCP connection
ID, TCP option exclusion list) cannot change. Other parameters ID, TCP option exclusion list) cannot change. Other parameters
change only when a master key is changed, using the master key change only when a master key is changed, using the master key
tuple mechanism in the TSAD. See Section 7. tuple mechanism in the TAPD. See Section 5.
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 master key management system, Note that TCP-AO does not specify a master key management system,
but does indicate a proposed interface to the TSAD, allowing a but does indicate a proposed interface to the TAPD, allowing a
completely separate master key system, as noted in Section 7. completely separate master key system, as noted in Section 5.
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 KeyID and multiple master key tuples This is supported by the KeyID and multiple master key tuples
in a TSAD entry; see Section 7. in a TAPD entry; see Section 5.
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 9. This is supported by the use of the KeyID. See Section 8.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 a separate TSAD allows external automated and The use of a separate TAPD allows external automated and
manual keying. See Section 9. This capability is enhanced by manual keying. See Section 5. This capability is enhanced by
the generation of unique per-connection keys, which enables the generation of unique per-connection keys, which enables
use of manual master keys with automatically generated use of manual master keys with automatically generated
connection keys as noted in Section 6. connection keys as noted in Section 7.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 separate TSAD. See Section 9.1. This is supported by use of a separate TAPD. See Section 5.
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 those events should be logged. and those events should be logged.
This is supported - see Sections 8.3, 8.4, and 8.5. This is supported - see Sections 9.3, 9.4, and 9.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. 4.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 8.4. This is supported - see Section 9.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 8.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 10.
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, Codes 2-4. Type 3 (destination unreachable), Codes 2-4 (transport
protocol unreachable, port unreachable, or fragmentation
needed and IP DF field set), i.e., the ones indicating the
failure of the endpoint to communicate.
This is supported - see Section 13. This is supported - see Section 13.
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 7 and 11. This is supported - see Sections 5 and 11.
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
skipping to change at page 35, line 41 skipping to change at page 43, line 11
Internet routers both ports could be arbitrary (i.e., determined a- Internet routers both ports could be arbitrary (i.e., determined a-
priori out of band), which would constitute roughly the same off-path priori out of band), which would constitute roughly the same off-path
antispoofing protection of an arbitrary SPI. 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. As
noted in Section 6, such cases may also result in persistent TCP noted in Section 7.2, such cases may also result in persistent TCP
state for old connections that cannot be cleared, and so state for old connections that cannot be cleared, and so
implementations should be capable of detecting an excess of such implementations should be capable of detecting an excess of such
connections and clearing their state if needed to protect memory connections and clearing their state if needed to protect memory
utilization [Je07]. utilization [Je07].
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
skipping to change at page 36, line 24 skipping to change at page 43, line 42
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 [Go07]. level of authentication for ICMP that TCP-AO provides for TCP [Go07].
>> A TCP-AO implementation MUST allow the system administrator to >> A TCP-AO implementation MUST allow the system administrator to
configure whether TCP will ignore incoming ICMP messages of Type 3 configure whether TCP will ignore incoming ICMP messages of Type 3
(destination unreachable) Codes 2-4 (protocol unreachable, port (destination unreachable) Codes 2-4 (protocol unreachable, port
unreachable, and fragmentation needed - 'hard errors') intended for unreachable, and fragmentation needed - 'hard errors') intended for
connections that match TSAD entries with non-NONE inbound MACs. An connections that match TAPD entries with non-NONE inbound MACs. An
implementation SHOULD allow ignored ICMPs to be logged. 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
[RFC4301]. [RFC4301].
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 the
same connection key (for whatever reason) from potentially enabling a same connection key (for whatever reason) from potentially enabling a
traffic-crossing attack, in which segments to one socket pair are traffic-crossing attack, in which segments to one socket pair are
diverted to attack a different socket pair. When multiple connections diverted to attack a different socket pair. When multiple connections
use the same master key, it would be useful to know that packets use the same master key, it would be useful to know that packets
intended for one ID could not be (maliciously or otherwise) modified intended for one ID could not be (maliciously or otherwise) modified
in transit and end up being authenticated for the other ID. The ID in transit and end up being authenticated for the other ID. The ID
cannot be zeroed, because to do so would require that the TSAD index cannot be zeroed, because to do so would require that the TAPD index
was unique in both directions (ID->key and key->ID). That requirement was unique in both directions (ID->key and key->ID). That requirement
would place an additional burden of uniqueness on master keys within would place an additional burden of uniqueness on master keys within
endsystems, and potentially across endsystems. Although the resulting endsystems, and potentially across endsystems. Although the resulting
attack is low probability, the protection afforded by including the attack is low probability, the protection afforded by including the
received ID warrants its inclusion in the MAC, and does not unduly received ID warrants its inclusion in the MAC, and does not unduly
increase the MAC calculation or master key management system. increase the MAC calculation or master key management system.
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 DOS attack, where the attacker sends false, random segments that
the receiver under attack expends substantial CPU effort to reject. the receiver under attack expends substantial CPU effort to reject.
skipping to change at page 37, line 4 skipping to change at page 44, line 21
was unique in both directions (ID->key and key->ID). That requirement was unique in both directions (ID->key and key->ID). That requirement
would place an additional burden of uniqueness on master keys within would place an additional burden of uniqueness on master keys within
endsystems, and potentially across endsystems. Although the resulting endsystems, and potentially across endsystems. Although the resulting
attack is low probability, the protection afforded by including the attack is low probability, the protection afforded by including the
received ID warrants its inclusion in the MAC, and does not unduly received ID warrants its inclusion in the MAC, and does not unduly
increase the MAC calculation or master key management system. increase the MAC calculation or master key management system.
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 DOS attack, where the attacker sends false, random segments that
the receiver under attack expends substantial CPU effort to reject. the receiver under attack expends substantial CPU effort to reject.
In IPsec, such attacks are reduced by the use of a large Security In IPsec, such attacks are reduced by the use of a large Security
Parameter Index (SPI) and Sequence Number fields to partly validate Parameter Index (SPI) and Sequence Number fields to partly validate
segments before CPU cycles are invested validated the Integrity Check segments before CPU cycles are invested validated the Integrity Check
Value (ICV). In TCP-AO, the socket pair performs most of the function Value (ICV). In TCP-AO, the socket pair performs most of the function
of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay
attacks, isn't needed in all cases due to TCP's Sequence Number, attacks, isn't needed due to TCP's Sequence Number, which is used to
which is used to reorder received segments. TCP already protects reorder received segments (provided the sequence number doesn't wrap
itself from replays of authentic segment data as well as authentic around, which is why TCP-AO adds the ESN in Section 8.2). TCP already
explicit TCP control (e.g., SYN, FIN, ACK bits, but even authentic protects itself from replays of authentic segment data as well as
replays could affect TCP congestion control [Sa99]. TCP-AO does not authentic explicit TCP control (e.g., SYN, FIN, ACK bits, but even
protect TCP congestion control from such attacks due to the authentic replays could affect TCP congestion control [Sa99]. TCP-AO
cumbersome nature of layering a windowed security sequence number does not protect TCP congestion control from this last form of attack
within TCP in addition to TCP's own sequence number; when such due to the 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 the TCP-AO option, because doing so separate Sequence Number field to the TCP-AO option, because doing so
could cause a change in TCP's behavior even when segments are valid. could cause a change in TCP's behavior even when segments are valid.
14. IANA Considerations 14. IANA Considerations
[NOTE: This section be removed prior to publication as an RFC] [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 PRF algorithms, TCP-AO refers to a separate To specify MAC and PRF algorithms, TCP-AO refers to a separate
document that may involve IANA actions [RFC-TBD]. document that may involve IANA actions [ao-crypto].
15. References 15. References
15.1. Normative References 15.1. Normative References
[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., Mahdavi, J., Floyd, S. and 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.
[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, Best Current
Practice, 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, Proposed Standard, Aug. 1998.
[RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP [RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP
and AH," RFC-2403, Proposed Standard, Nov. 1998. and AH," RFC-2403, Proposed Standard, Nov. 1998.
[RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification," RFC-2460, Proposed Standard, Dec. (IPv6) Specification," RFC-2460, Proposed Standard, Dec.
1998. 1998.
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A [RFC2883] Floyd, S., J. Mahdavi, M. Mathis, M. Podolsky, "An
Conservative Selective Acknowledgment (SACK)-based Loss Extension to the Selective Acknowledgement (SACK) Option
Recovery Algorithm for TCP", RFC-3517, Proposed Standard, for TCP", RFC-2883, Proposed Standard, July 2000.
April 2003.
[RFC3517] Blanton, E., M. Allman, K. Fall, L. Wang, "A Conservative
Selective Acknowledgment (SACK)-based Loss Recovery
Algorithm for TCP", RFC-3517, Proposed Standard, April
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.
[RFC-TBD] Lebovitz, G., "MAC Algorithms for TCP-AO," RFC-TBD, date [ao-crypto] Lebovitz, G., "Cryptographic Algorithms, Use, &
TBD. Implementation Requirments for TCP Authentication Option",
draft-lebovitz-ietf-tcpm-tcp-ao-crypto, Mar. 2009.
15.2. Informative References 15.2. Informative References
[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.
[Go07] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- [Go07] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp-
attacks-04, (work in progress), Oct. 2008. attacks-04, (work in progress), Oct. 2008.
[Je07] Jethanandani, M., and M. Bashyam, "TCP Robustness in [Je07] Jethanandani, M., M. Bashyam, "TCP Robustness in Persist
Persist Condition," draft-mahesh-persist-timeout-02, (work Condition," draft-mahesh-persist-timeout-02, (work in
in progress), Oct. 2007. progress), Oct. 2007.
[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.
[RFC2104] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed- [RFC2104] Krawczyk, H., M. Bellare, R. Canetti, "HMAC: Keyed-Hashing
Hashing for Message Authentication," RFC-2104, for Message Authentication," RFC-2104, Informational, Feb.
Informational, Feb. 1997. 1997.
[RFC2766] Tsirtsis, G., Srisuresh, P., "Network Address Translation - [RFC2766] Tsirtsis, G., P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)," RFC-2766, Proposed Protocol Translation (NAT-PT)," RFC-2766, Proposed
Standard, Feb. 2000. Standard, Feb. 2000.
[RFC3234] Carpenter, B., S. Brim, "Middleboxes: Taxonomy and Issues," [RFC3234] Carpenter, B., S. Brim, "Middleboxes: Taxonomy and Issues,"
RFC-3234, Informational, Feb. 2002. RFC-3234, Informational, Feb. 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, Informational, July 2003.
[RFC3947] Kivinen, T., B. Swander, A. Huttunen, V. Volpe, [RFC3947] Kivinen, T., B. Swander, A. Huttunen, V. Volpe,
 End of changes. 191 change blocks. 
594 lines changed or deleted 925 lines changed or added

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