TCPM WG                                                        J. Touch
Internet Draft                                                  USC/ISI
Obsoletes: 2385                                               A. Mankin
Intended status: Proposed Standard                  Johns Hopkins Univ.
Expires: August September 2009                                       R. Bonica
                                                       Juniper Networks
                                                      February 16,
                                                          March 9, 2009

                       The TCP Authentication Option
                    draft-ietf-tcpm-tcp-auth-opt-03.txt
                    draft-ietf-tcpm-tcp-auth-opt-04.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on August 16, September 9, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document specifies the TCP Authentication Option (TCP-AO), which
   obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO
   specifies the use of stronger Message Authentication Codes (MACs),
   protects against replays even for long-lived TCP connections, and
   provides more details on the association of security with TCP
   connections than TCP MD5. TCP-AO is compatible with either static
   master key configuration or an external, out-of-band master key
   management mechanism; in either case, TCP-AO also protects
   connections when using the same master key across repeated instances
   of a connection, using connection traffic keys derived from the master key. key, and
   coordinates key changes between endpoints. The result is intended to
   support current infrastructure uses of TCP MD5, such as to protect
   long-lived connections (as used, e.g., in BGP and LDP), and to
   support a larger set of MACs with minimal other system and
   operational changes. TCP-AO uses its own option identifier, even
   though used mutually exclusive of TCP MD5 on a given TCP connection.
   TCP-AO supports IPv6, and is fully compatible with the requirements
   for the replacement of TCP MD5.

Table of Contents

   1. Contributors...................................................3
   2. Introduction...................................................3 Introduction...................................................4
      2.1. Executive Summary.........................................4
      2.2. Changes from Previous Versions............................5 Versions............................6
         2.2.1. New in draft-ietf-tcp-auth-opt-03....................6 draft-ietf-tcp-auth-opt-04....................6
         2.2.2. New in draft-ietf-tcp-auth-opt-02....................6 draft-ietf-tcp-auth-opt-03....................6
         2.2.3. New in draft-ietf-tcp-auth-opt-01....................7 draft-ietf-tcp-auth-opt-02....................7
         2.2.4. New in draft-ietf-tcp-auth-opt-00....................8 draft-ietf-tcp-auth-opt-01....................8
         2.2.5. New in draft-touch-tcp-simple-auth-03................9 draft-ietf-tcp-auth-opt-00....................9
         2.2.6. New in draft-touch-tcp-simple-auth-02................9 draft-touch-tcp-simple-auth-03................9
         2.2.7. New in draft-touch-tcp-simple-auth-01................9 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
   4. The TCP Authentication Option.................................10 Option.................................11
      4.1. Review of TCP MD5 Option.................................10 Option.................................11
      4.2. The TCP-AO Option............................................11 Option........................................11
   5. The TCP-AO Activation and Parameter Database..................13
   6. Per-Connection Parameters.....................................16
   7. Cryptographic Algorithms......................................17
      7.1. MAC Algorithms...........................................17
      7.2. Key Derivation Functions.................................21
      7.3. Traffic Key Establishment and Duration Issues............24
         7.3.1. Master Key Reuse Across Socket Pairs................25
         7.3.2. Master Key Use Within a Long-lived Connection.......25
   8. Additional Security Mechanisms................................25
      8.1. Coordinating KeyID Changes...............................25
      8.2. Preventing replay attacks within long-lived connections.......14
   6. Computing connection keys from TSAD entries...................16
   7. Security Association Management...............................17
   8. connections..26
   9. TCP-AO Interaction with TCP...................................21
      8.1. TCP...................................28
      9.1. TCP User Interface.......................................21
      8.2. Interface.......................................29
      9.2. TCP States and Transitions...............................22
      8.3. Transitions...............................30
      9.3. TCP Segments.............................................22
      8.4. Segments.............................................30
      9.4. Sending TCP Segments.....................................23
      8.5. Segments.....................................31
      9.5. Receiving TCP Segments...................................24
      8.6. Segments...................................32
      9.6. Impact on TCP Header Size................................25
   9. Connection Key Establishment and Duration Issues..............26
      9.1. Master Key Reuse Across Socket Pairs.....................27
      9.2. Master Key Use Within a Long-lived Connection............27 Size................................34
   10. Obsoleting TCP MD5 and Legacy Interactions...................27 Interactions...................35
   11. Interactions with Middleboxes................................28 Middleboxes................................36
      11.1. Interactions with non-NAT/NAPT Middleboxes..............28 Middleboxes..............36
      11.2. Interactions with NAT/NAPT Devices......................29 Devices......................36
   12. Evaluation of Requirements Satisfaction......................29 Satisfaction......................36
   13. Security Considerations......................................35 Considerations......................................42
   14. IANA Considerations..........................................37 Considerations..........................................44
   15. References...................................................37 References...................................................45
      15.1. Normative References....................................37 References....................................45
      15.2. Informative References..................................38 References..................................46
   16. Acknowledgments..............................................40 Acknowledgments..............................................47

1. Contributors

   This document evolved as the result of collaboration of the TCP
   Authentication Design team (tcp-auth-dt), whose members were
   (alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy,
   Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy
   Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus
   Westerlund. The text of this document is derived from a proposal by
   Joe Touch and Allison Mankin [To06] (originally from June 2006),
   which was both inspired by and intended as a counterproposal to the
   revisions to TCP MD5 suggested in a document by Ron Bonica, Brian
   Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07]
   (originally from Sept. 2005) and in a document by Brian Weis [We05].

   Russ Housley suggested L4/application layer management of the TSAD. TAPD.
   Steve Bellovin motivated the KeyID field. Eric Rescorla suggested the
   use of ISNs in the connection traffic key computation and ESNs to avoid replay
   attacks, and Brian Weis extended the computation to incorporate the
   entire connection ID and provided the details of the
   connection traffic key
   computation. Mark Allman, Wes Eddy, Lars Eggert, Ted Faber, Russ
   Housley, Gregory Lebovitz, Tim Polk, Eric Rescorla, Joe Touch, and
   Brian Weis developed the key coordination mechanism.

2. Introduction

   The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates
   TCP segments, including the TCP IPv4 pseudoheader, TCP header, and
   TCP data. It was developed to protect BGP sessions from spoofed TCP
   segments which could affect BGP data or the robustness of the TCP
   connection itself [RFC2385][RFC4953].

   There have been many recent concerns about TCP MD5. Its use of a
   simple keyed hash for authentication is problematic because there
   have been escalating attacks on the algorithm itself [Wa05]. TCP MD5
   also lacks both key management and algorithm agility. This document
   adds the latter, but notes that TCP and provides a simple key coordination mechanism
   giving the ability to move from one key to another within the same
   connection. It does not however provide a sufficient
   framework for complete cryptographic
   key management, management to be handled in-band of TCP, because TCP SYN segments
   lack sufficient remaining space to support key coordination in-band handle such a negotiation (see
   Section 8.6). 9.6). This document obsoletes the TCP MD5 option with a more
   general TCP Authentication Option (TCP-AO), to support the use of
   other, stronger hash functions, provide replay protection for long-
   lived connections and across repeated instances of a single
   connection, coordinate key changes between endpoints, and to provide
   a more structured recommendation on external key management. The
   result is compatible with IPv6, and is fully compatible with
   requirements under development for a replacement for TCP MD5 [Be07].

   This document is not intended to replace the use of the IPsec suite
   (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In
   fact, we recommend the use of IPsec and IKE, especially where IKE's
   level of existing support for parameter negotiation, session key
   negotiation, or rekeying are desired. TCP-AO is intended for use only
   where the IPsec suite would not be feasible, e.g., as has been
   suggested is the case to support some routing protocols, or in cases
   where keys need to be tightly coordinated with individual transport
   sessions [Be07].

   Note that TCP-AO obsoletes TCP MD5, although a particular
   implementation may support both mechanisms for backward
   compatibility. For a given connection, only one can be in use. TCP
   MD5-protected connections cannot be migrated to TCP-AO because TCP
   MD5 does not support any changes to a connection's security algorithm
   once established.

2.1. Executive Summary

   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 allows TCP MD5 to continue to be used concurrently for
      legacy connections.

   o  TCP-AO replaces MD5's single MAC algorithm with MACs specified in
      a separate document and allows extension to include other MACs.

   o  TCP-AO allows rekeying during a TCP connection, assuming that an
      out-of-band protocol or manual mechanism coordinates provides the key
      change. new keys. In
      such cases, a key ID allows the efficient concurrent use of
      multiple keys. keys, and a key coordination mechanism manages the key
      change within a connection. Note that TCP MD5 does not preclude
      rekeying during a connection, but does not require its support
      either. Further, TCP-AO supports rekeying key changes with zero packet
      loss, whereas
      rekeying key changes in TCP MD5 can lose packets in transit
      during the changeover or require trying multiple keys on each
      received segment during key use overlap because it lacks an
      explicit key ID.

   o  TCP-AO provides automatic replay protection for long-lived
      connections using an extended sequence number.

   o  TCP-AO ensures per-connection traffic keys as unique as the TCP
      connection itself, using TCP's ISNs for differentiation, even when
      static master keys are used across repeated instances of a socket
      pair.

   o  This document provides detail in  TCP-AO specifies the details of how this option interacts with
      TCP's states, event processing, and user interface.

   o  The TCP-AO option is 3 2 bytes shorter than TCP MD5 (15 (16 bytes
      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
   follows [RFC4301][RFC4306]:

   o  TCP-AO does not support dynamic parameter negotiation.

   o  TCP-AO uses TCP's socket pair (source address, destination
      address, source port, destination port) as a security parameter
      index, rather than using a separate field as a primary index
      (IPsec's SPI).

   o  TCP-AO forces a change of computed MACs when a connection
      restarts, even when reusing a TCP socket pair (IP addresses and
      port numbers) [Be07].

   o  TCP-AO does not support encryption.

   o  TCP-AO does not authenticate ICMP messages (some ICMP messages may
      be authenticated via IPsec, depending on the configuration).

2.2. Changes from Previous Versions

   [NOTE: to be omitted upon final publication as RFC]

2.2.1. New in draft-ietf-tcp-auth-opt-03 draft-ietf-tcp-auth-opt-04

   o  Major revision to the document structure, including renaming the
      TSAD to TAPD.

   o  Added a placeholder to discuss key change coordination mechanism in Section
      9. 8.1.

   o  Moved discussion  Added a requirement for symmetric use of TCP-AO, required MAC algorithms and PRF for the
      key change coordination mechanism. This includes an update of the
      TAPD to a separate
      document, indicated as RFC-TBD until assigned. Included indicate that all master keys are bidirectional.

   o  Augmented the PRF discussion of the available space for options.

   o  Fixed a bug in the TSAD master key 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
      8.1.

   o  Moved discussion of required MAC algorithms and PRF to a separate
      document, indicated as RFC-TBD until assigned. Included the PRF in
      the TSAD master key tuple so that TCP-AO is PRF algorithm agile,
      and updated general PRF input format.

   o  Revised the description the TSAD and impact to the TCP user
      interface. Removed the description of the TSAD API. Access to the
      API is assumed specific to the implementation, and not part of the
      protocol specification.

   o  Clarified the different uses of the term key; includes master key
      (from the TSAD) and connection key (per-connection key, derived
      from the master via the PRF).

   o  Explained the ESN pseudocode operation in detail.

   o  Added a contributors section up front.

   o  Update discussion of requirements to be sufficiently stand-alone;
      update list to correlate more directly to Be07 (so that Be07 can
      be dropped from consideration for publication).

   o  Provided detail on size of typical options (motivating a small
      option).

   o  Confirmed WG consensus on IETF-72 topic - no algorithm ID and T-
      bit (options excluded) locations in the header.

   o  Confirmed WG consensus on IETF-72 topic - no additional header
      bits for in-band key change signaling (the "K" bit from [Bo07]).

2.2.2.

2.2.3. New in draft-ietf-tcp-auth-opt-02

   o  List issue - Replay Protection: incorporated extended sequence
      number space, not using KeyID space.

   o  List issue - Unique Connection Keys: ISNs are used to generate
      unique connection keys even when static keys used for repeated
      instances of a socket pair.

   o  List issue - Header Format and Alignment: Moved KeyID to front.

   o  List issue - Reserved KeyID Value: Suggestion to reserve a single
      KeyID value for implementation optimization received no support on
      the WG list, so this was not changed.

   o  List issue - KeyID Randomness: KeyIDs are not assumed random; a
      note was added that nonce-based filtering should be done on a
      portion of the MAC (incorporated into the algorithm), and that
      header fields should not be assumed to have cryptographic
      properties (e.g., randomness).

   o  List issue - Support for NATs: preliminary rough consensus
      suggests that TCP-AO should not be augmented to support NAT
      traversal. Existing mechanisms for such traversal (UDP support)
      can be applied, or IPsec NAT traversal is recommended in such
      cases instead.

   o  IETF-72 topic - providing algorithm ID and T-bit (options
      excluded) locations in the header: (No current consensus was
      reached on this topic, so no change was made.)
   o  IETF-72 topic - providing additional header bits for in-band key
      change signaling (draft-bonica's "K" bit): (No current consensus
      was reached on this topic, so no change was made.)

   o  Clarified TCP-AO as obsoleting TCP MD5.

   o  Clarified the MAC Type as referring to the IANA registry of IKEv2
      transforms, not the RFC establishing that registry.

   o  Added citation to the Wang/Yu paper regarding attacks on MD5 Wa05
      to replace reports in Be05 and Bu06.

   o  Explained why option exclusion can't be changed during a
      connection.

   o  Clarified that AO explicitly allows rekeying during a TCP
      connection, without impacting packet loss.

   o  Described TCP-AO's interaction with reboots more clearly, and
      explained the need to clear out old state that persists
      indefinitely.

2.2.3.

2.2.4. New in draft-ietf-tcp-auth-opt-01

   o  Require KeyID in all versions. Remove odd/even indicator of KeyID
      usage.

   o  Relax restrictions on key reuse: requiring an algorithm for nonce
      introduction based on ISNs, and suggest key rollover every 2^31
      bytes (rather than using an extended sequence number, which
      introduces new state to the TCP connection).

   o  Clarify NAT interaction; currently does not support omitting the
      IP addresses or TCP ports, both of which would be required to
      support NATs without any coordination. This appears to present a
      problem for key management - if the key manager knows the received
      addrs and ports, it should coordinate them (as indicated in Sec
      8).

   o  Options are included or excluded all-or-none. Excluded options are
      deleted, not just zeroed, to avoid the impact of reordering or
      length changes of such options.

   o  Augment replay discussion in security considerations.

   o  Revise discussion of IKEv2 MAC algorithm names.

   o  Remove executive summary comparison to expired documents.

   o  Clarified key words to exclude lower case usage.

2.2.4.

2.2.5. New in draft-ietf-tcp-auth-opt-00

   o  List of TBD values, and indication of how each is determined.

   o  Changed TCP-SA to TCP-AO (removed 'simple' throughout).

   o  Removed proposed NAT mechanism; cited RFC-3947 NAT-T as
      appropriate approach instead.

   o  Made several changes coordinated in the TCP-AUTH-DT as follow:

   o  Added R. Bonica as co-author.

   o  Use new TCP option Kind in the core doc.

   o  Addresses the impact of explicit declines on security.

   o  Add limits to TSAD size (2 <= TSAD <= 256).

   o  Allow 0 as a legitimate KeyID.

   o  Allow the WG to determine the two appropriate required MAC
      algorithms.

   o  Add TO-DO items.

   o  Added discussion at end of Introduction as to why TCP MD5
      connections cannot be upgraded to TCP-AO.

2.2.5.

2.2.6. New in draft-touch-tcp-simple-auth-03

   o  Added support for NAT/NAPT.

   o  Added support for IPv6.

   o  Added discussion of how this proposal satisfies requirements under
      development, including those indicated in [Be07].

   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.

2.2.6.

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 SP4 [SDNS88].

   o  Added notes that TSAD to be externally implemented; this was
      compatible with the TSAD described in the previous version.

   o  Augmented the protocol to allow a KeyID, required to support
      efficient overlapping keys during rekeying, and potentially useful
      during connection establishment. Accommodated by redesigning the
      TSAD.

   o  Added the odd/even indicator for the KeyID.

   o  Allow for the exclusion of all TCP options in the MAC calculation.

2.2.7.

2.2.8. New in draft-touch-tcp-simple-auth-01

   o  Allows intra-session rekeying, assuming out-of-band coordination.

   o  MUST allow TSAD entries to change, enabling rekeying within a TCP
      connection.

   o  Omits discussion of the impact of connection reestablishment on
      BGP, because added support for rekeying renders this point moot.

   o  Adds further discussion on the need for rekeying.

3. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

   In this document, the characters ">>" proceeding an indented line(s)
   indicates a compliance requirement statement using the key words
   listed above. This convention aids reviewers in quickly identifying
   or finding this RFC's explicit compliance requirements.

4. The TCP Authentication Option

   The TCP Authentication Option (TCP-AO) uses a TCP option Kind value
   of TBD-IANA-KIND.

4.1. Review of TCP MD5 Option

   For review, the TCP MD5 option is shown in Figure 1.

                +---------+---------+-------------------+
                | Kind=19 |Length=18|   MD5 digest...   |
                +---------+---------+-------------------+
                |                                       |
                +---------------------------------------+
                |                                       |
                +---------------------------------------+
                |                                       |
                +-------------------+-------------------+
                |                   |
                +-------------------+

                   Figure 1 The TCP MD5 Option [RFC2385]

   In the TCP MD5 option, the length is fixed, and the MD5 digest
   occupies 16 bytes following the Kind and Length fields, using the
   full MD5 digest of 128 bits [RFC1321].

   The TCP MD5 option specifies the use of the MD5 digest calculation
   over the following values in the following order:

   1. The TCP pseudoheader (IP source and destination addresses,
      protocol number, and segment length).

   2. The TCP header excluding options and checksum.

   3. The TCP data payload.

   4. The connection A key.

4.2. The TCP-AO Option

   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
   Kind field, and similar Length field to TCP MD5, as well as a KeyID field, and a
   NextKeyID field as shown in Figure 2.

            +----------+----------+----------+----------+
            |   Kind   |  Length  |  KeyID   |   MAC    | NextKeyID|
            +----------+----------+----------+----------+
            |                    MAC (con't)           ...
            +----------------------------------...

              ...-----------------+
              ...  MAC (con't)    |
              ...-----------------+

                        Figure 2 The TCP-AO Option

   The TCP-AO defines the following fields:

   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
      managed (see Section 7), an

      >> An endpoint will not 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.

   o  Length: An unsigned 1-byte field indicating the length of the TCP-
      AO option in bytes, including the Kind, Length, KeyID, NextKeyID,
      and MAC fields.

      >> The Length value MUST be greater than or equal to 3. 4.

      >> The Length value MUST be consistent with the TCP header length;
      this is a consistency check and avoids overrun/underrun abuse.

      Values of 3 4 and other small values are of dubious utility (e.g.,
      for MAC=NONE, or small values for very short MACs) but are
      not specifically prohibited.

   o  KeyID: An unsigned 1-byte field is used to support efficient key
      changes during a connection and/or to help with key coordination
      during connection establishment, and will to be discussed further in
      Section 4. 8.1. Note that the KeyID has no cryptographic properties -
      it need not be random, nor are there any reserved values.

   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 Field. Code. Its contents are determined by
      the particulars of the security association. Typical MACs are 96-
      128 bits (12-16 bytes), but any length that fits in the header of
      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; [ao-crypto];
      other MACs MAY be supported [RFC2403]. supported.

   The TCP-AO option fields do not indicate the MAC algorithm either
   implicitly (as with TCP MD5) or explicitly. The particular algorithm
   used is computed over considered part of the following fields in configuration state of the following order:

   1. The extended sequence number (ESN), in network-standard byte
      order, as follows (described further in
   connection's security and is managed separately (see Section 5):

                   +--------+--------+--------+--------+
                   |                ESN                |
                   +--------+--------+--------+--------+

                     Figure 3 Extended sequence number 5).

   The ESN for transmitted segments is locally maintained from a
      locally maintained SND.ESN value, for received segments, a local
      RCV.ESN value is used. The details remainder of this document explains how these values are
      maintained and used the TCP-AO option is described in Sections 5, 8.4,
   handled and 8.5.

   2. its relationship to TCP.

5. The TCP pseudoheader: IP source TCP-AO Activation and destination addresses,
      protocol number Parameter Database

   TCP-AO relies on a TCP-AO Activation and segment length, all in network byte order,
      prepended 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 TCP header below. The pseudoheader
   endpoints where TCP-AO is exactly as
      used for the TCP checksum used, in either IPv4 or IPv6
      [RFC793][RFC2460]:

                   +--------+--------+--------+--------+
                   |           Source Address          |
                   +--------+--------+--------+--------+
                   |         Destination Address       |
                   +--------+--------+--------+--------+
                   |  zero  | Proto  |    TCP Length   |
                   +--------+--------+--------+--------+

                  Figure 4 TCP IPv4 pseudoheader [RFC793]
                   +--------+--------+--------+--------+
                   |                                   |
                   +                                   +
                   |                                   |
                   +           Source Address          +
                   |                                   |
                   +                                   +
                   |                                   |
                   +                                   +
                   +--------+--------+--------+--------+
                   |                                   |
                   +                                   +
                   |                                   |
                   +         Destination Address       +
                   |                                   |
                   +                                   +
                   |                                   |
                   +--------+--------+--------+--------+
                   |      Upper-Layer Packet Length    |
                   +--------+--------+--------+--------+
                   |      zero       |   Next Header   |
                   +--------+--------+--------+--------+

                 Figure 5 TCP IPv6 pseudoheader [RFC2460]

   3. The TCP header, by default including options, advance of the connection, and where
   consist of the following:

   1. TCP
      checksum connection identifier (ID), i.e., socket pair - IP source
      address, IP destination address, TCP source port, and TCP-AO MAC fields TCP
      destination port [RFC793]. TAPD entries are set to zero, all in network
      byte order

   4. uniquely determined by
      their TCP data, in network byte order

   Note that the connection key ID, which is not included here; the MAC algorithm
   indicates how used 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 index those entries. A
      TAPD entry may allow wildcards, notably in the MAC calculation
   because these options are intended to source port value.

      >> There MUST be end-to-end and some are
   required no more than one matching TAPD entry per
      direction for proper a fully-instantiated (no wildcards) TCP operation (e.g., SACK, timestamp, large
   windows). Middleboxes that alter connection
      ID.

   2. A 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 option flag. When 0, this flag allows default operation,
      i.e., TCP options can be excluded from are included in the MAC
   calculation. calculation, with TCP-
      AO's MAC field zeroed out.  When options are excluded, 1, all options - including TCP-
   AO - (excluding TCP-AO)
      are skipped over during the excluded from all MAC calculation (rather than being calculations (skipped over, not simply
      zeroed). The TCP-AO option does not indicate the MAC algorithm either
   implicitly (as with flag applies to TCP MD5) or explicitly. The particular algorithm
   used is considered part of the configuration state of the
   connection's security association options in both directions
      (incoming and is managed separately (see
   Section 7).

5. Preventing replay attacks within long-lived connections outgoing segments).

      >> The TCP uses option flag MUST NOT change during 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

      The TCP option flag cannot change during a way to
   differentiate these legitimate replays from each other, and so it
   adds connection because TCP
      state is coordinated during connection establishment. TCP lacks a 32-bit extended sequence number (ESN)
      handshake for transmitted and
   received segments.

   The ESN extends TCP's sequence number so modifying that segments within state after a
   single connection are always unique. When TCP's sequence number rolls
   over, there is a chance that has been
      established.

   3. A list of zero or more master key tuples.

      >> Components of a segment could be repeated in total;
   using an ESN differentiates even identical segments sent with
   identical sequence numbers at different times in TAPD master key tuple MUST NOT change during a
      connection. TCP-AO
   emulates a 64-bit sequence number space by inferring when to
   increment

      Keeping the high-order 32-bit portion (the ESN) based on
   transitions in tuple components static ensures that the low-order portion (the TCP sequence number).

   TCP-AO thus maintains SND.ESN for transmitted segments, and RCV.ESN
   for received segments, both initialized as zero when KeyID
      uniquely determines the properties of a connection
   begins. The intent packet; this supports use
      of these ESNs is, together with TCP's 32-bit
   sequence numbers, the KeyID to provide determine the packet properties.

      >> The set of TAPD master key tuples MAY change during a 64-bit overall sequence number space.

   For transmitted segments SND.ESN can
      connection, but KeyIDs of those tuples MUST NOT overlap. I.e.,
      tuple parameter changes MUST be implemented accompanied by extending
   TCP's sequence number to 64-bits; SND.ESN would master key changes.

      >> If there are multiple tuples in a TAPD entry, then one tuple
      MUST be flagged as the top (high-
   order) 32 bits of preferred key; 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 key, when instantiated
      as RCV.ESN from a traffic_key, becomes the
   received 32-bit sequence number and current_key for the current connection context.

   The implementation of ESNs is not specified in this document, but one
   possible way (see
      Section 6).

      Each tuple is described here that can be used for either RCV.ESN,
   SND.ESN, or both.

   Consider an implementation with two ESNs defined as required (SND.ESN,
   RCV.ESN), and additional variables the following components:

       a. KeyID. The value as listed below, all initialized used in the TCP-AO option; used to zero,
          differentiate master keys in concurrent use, 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
          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 increment 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 SND.ESN

   o  RCV.ESN_FLAG, which indicates when
          connection endpoints (e.g., using an external master key
          management mechanism).

          >> KeyIDs MUST NOT be assumed to increment the RCV.ESN

   When be randomly assigned.

          Note that KeyIDs are unique only within a segment 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 received, used in the following
          traffic key generation algorithm (written described in C)
   computes 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 ESN 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 MAC; an equivalent algorithm
   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
   applied used to the "SND" side:

         #
         # ROLL 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 just shorthand
         ROLL = (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff);
         #
         # set 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 flag 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
      order, as follows (described further in Section 8.2):

                   +--------+--------+--------+--------+
                   |                ESN                |
                   +--------+--------+--------+--------+

                     Figure 3 Extended sequence number

      The ESN for transmitted segments is maintained locally in the
      SND.ESN value; for received segments, a local RCV.ESN value is
      used. The details of how these values are maintained and used is
      described in Sections 8.2, 9.4, and 9.5.

   2. The TCP pseudoheader: IP source and destination addresses,
      protocol number and segment length, all in network byte order,
      prepended to the TCP header below. The pseudoheader is exactly as
      used for the TCP checksum in either IPv4 or IPv6
      [RFC793][RFC2460]:

                   +--------+--------+--------+--------+
                   |           Source Address          |
                   +--------+--------+--------+--------+
                   |         Destination Address       |
                   +--------+--------+--------+--------+
                   |  zero  | Proto  |    TCP Length   |
                   +--------+--------+--------+--------+

                  Figure 4 TCP IPv4 pseudoheader [RFC793]
                   +--------+--------+--------+--------+
                   |                                   |
                   +                                   +
                   |                                   |
                   +           Source Address          +
                   |                                   |
                   +                                   +
                   |                                   |
                   +                                   +
                   +--------+--------+--------+--------+
                   |                                   |
                   +                                   +
                   |                                   |
                   +         Destination Address       +
                   |                                   |
                   +                                   +
                   |                                   |
                   +--------+--------+--------+--------+
                   |      Upper-Layer Packet Length    |
                   +--------+--------+--------+--------+
                   |      zero       |   Next Header   |
                   +--------+--------+--------+--------+

                 Figure 5 TCP IPv6 pseudoheader [RFC2460]

   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
      byte order.

      When the TCP option flag is 0, the TCP options are included in MAC
      processing, except that the MAC field of the TCP-AO option is
      zeroed-out.

      When the TCP option flag is 1, all TCP options are omitted from
      MAC processing, except for the non-MAC portions of the TCP-AO
      option. In this case, the following field is used instead of the
      options part of the TCP header:

            +----------+----------+----------+----------+
            |   Kind   |  Length  |  KeyID   | NextKeyID|
            +----------+----------+----------+----------+

   4. The TCP data, i.e., the payload of the TCP segment.

   Note that the traffic key is not included as part of the data; the
   MAC algorithm indicates how to use the traffic key, e.g., as HMACs do
   in general [RFC2104][RFC2403]. The traffic key is derived from the
   current master key as described in Sections 7.2.

7.2. Key Derivation Functions

   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:

      INPUT: PRF_alg, master_key, output_length, data_block

      OUTPUT: traffic_key

   where:

   o  PRF_alg - the specific pseudorandom function (PRF) that is the
      basic building block used in constructing the given KDF. This is
      specified by the MAC algorithm as specified in [ao-crypto].

   o  Master_key - The master_key string, as will be stored into the
      associated TCP-AO TAPD master key tuple.

   o  Output_length - The desired output length of the KDF, i.e., the
      length to which the KDF's output will be truncated or padded. In
      TCP-AO, the output_length is the PRF_truncation value of the
      master key tuple. This is specified by the MAC algorithm as
      specified in [ao-crypto].

   o  Data_block - The data block used as input in constructing the KDF.
      The data block provided by TCP-AO is used as the "context" as
      specified in [ao-crypto]. The specific way this context is used,
      in conjunction with other information, to create the raw input to
      the PRF is also explained further in [ao-crypto].

   The data used as input to the KDF combines TCP socket pair with the
   endpoint initial sequence numbers (ISNs) of a connection. This
   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.

                   +--------+--------+--------+--------+
                   |           Source Address          |
                   +--------+--------+--------+--------+
                   |         Destination Address       |
                   +--------+--------+--------+--------+
                   |   Source Port   |    Dest. Port   |
                   +--------+--------+--------+--------+
                   |            Source ISN             |
                   +--------+--------+--------+--------+
                   |             Dest. ISN             |
                   +--------+--------+--------+--------+

                Figure 6 Data block for an IPv4 connection

                   +--------+--------+--------+--------+
                   |                                   |
                   +                                   +
                   |                                   |
                   +           Source Address          +
                   |                                   |
                   +                                   +
                   |                                   |
                   +                                   +
                   +--------+--------+--------+--------+
                   |                                   |
                   +                                   +
                   |                                   |
                   +         Destination Address       +
                   |                                   |
                   +                                   +
                   |                                   |
                   +--------+--------+--------+--------+
                   |   Source Port   |    Dest. Port   |
                   +--------+--------+--------+--------+
                   |            Source ISN             |
                   +--------+--------+--------+--------+
                   |             Dest. ISN             |
                   +--------+--------+--------+--------+

                Figure 7 Data block for an IPv6 connection

   "Source" and "destination" are defined by 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 direction of the pre-increment value
         } else {
            ESN = RCV.ESN; # use
   segment being MAC'd; for incoming packets, source is the current value
         }
         #
         # reset remote side,
   whereas for outgoing packets source is the flag in local side. This further
   ensures that connection keys generated for each direction are unique.

   For SYN segments (segments with the *middle* of SYN set, but the window
         if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) {
            RCV.ESN_FLAG = 0;
         }
         #
         # save ACK not set),
   the current SEQ for destination ISN is not known. For these segments, the next time through connection
   key is computed using the code
         RCV.PREV_SEQ = SEG.SEQ;

   In connection block shown above, in which the above code, ROLL
   Destination ISN value is true in zero. For all other segments, the first line ISN pair
   is used when known. If the sequence
   number rolls over, i.e., ISN pair is not known, e.g., when sending
   a RST after a reboot, the new number is low (in segment should be sent without
   authentication; if authentication was required, the segment cannot
   have been MAC'd properly anyway and would have been dropped on
   receipt.

   >> 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 bottom
   half of
   known ISN pair.

   Overall, this means that each connection will use up to four distinct
   traffic keys for each master key:

   o  Send_SYN_traffic_key - the number space) traffic key used to authenticate
      outgoing SYNs. The source ISN known (the TCP connection's local
      ISN), and the old number destination (remote) ISN is high (in unknown (and so the top half
   of
      value 0 is used).

   o  Receive_SYN_traffic_key - the number space). traffic key used to authenticate
      incoming SYNs. The first time this happens, the ESN is
   incremented source ISN known (the TCP connection's remote
      ISN), and a flag is set. The flag prevents the ESN from being
   incremented again until the flag destination (remote) ISN is reset, which happens in the
   middle of unknown (and so the window (when
      value 0 is used).

   o  Send_other_traffic_key - the old number traffic key used to authenticate all
      other outgoing TCP segments. The source ISN is in the bottom half TCP
      connection's local ISN, and the new destination ISN is in the top half). Because TCP
      connection's remote ISN.

   o  Receive_other_traffic_key - the receive window traffic key used to authenticate
      all other incoming TCP segments. The source ISN is never
   larger than half of the number space, it is impossible to both set TCP
      connection's remote ISN, and reset the flag at destination ISN is the same time - outstanding packets, regardless TCP
      connection's remote ISN.

   The use of reordering, cannot straddle both regions simultaneously.

6. Computing connection keys from TSAD entries

   TSAD entries, described ISNs in Section 7, include master keys the KDF ensures that segments cannot be
   replayed across repeated connections reusing the same socket pair
   (provided the ISN pair does not repeat, which are
   used in conjunction with a TCP's connection is unlikely because
   both endpoints should select ISNs to generate unique
   connection keys. This allows 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 static master key to SYN would be reused across
   different connections, or across different instances of connections
   within a socket pair, while maintaining unique connection keys.
   Unique connection keys are generated without relying on external key
   management properties.

   Given MAC'd using a master key tuple, the TCP socket pair, destination ISN of zero
   (whether sent or received), and all other segments would be MAC'd
   using the connection
   ISNs, ISN pair for the connection key used connection. There are other cases in which
   the MAC algorithm destination ISN is computed as
   follows, truncated to the same length not known, but segments are emitted, such as
   after an endpoint reboots, when is possible that the master key, using a
   pseudorandom function (PRF):

      Conn_key = PRF(TSAD_master_key, input) two endpoints
   would not have enough information to authenticate segments. In such
   cases, TCP's timeout mechanism will allow old state to be cleared to
   enable new connections, except where
         input = 0 + "TCP-AO" + connblock + TSAD_master_key_len

   The components of the input user timeout is disabled; it
   is important that implementations are concatenated as capable of detecting excesses
   of TCP connections in such a single byte string
   (the string concatenation operator is shown here as "+"). configuration and can clear them out if
   needed to protect its memory usage [Je07].

7.3. Traffic Key Establishment and Duration Issues

   The initial
   zero TCP-AO option does not provide a mechanism for traffic key
   negotiation or parameter negotiation (MAC algorithm, length, or use
   of the input is a single byte, "TCP-AO" is TCP-AO option), or for coordinating rekeying during a null-terminated
   string, connblock is defined below,
   connection. We assume out-of-band mechanisms for master key
   establishment, parameter negotiation, and TSAD_master_key_len is the
   length rekeying. This separation
   of the TSAD master key in bytes, as stored use from master key management is similar to that in
   the TSAD entry.
   The PRF IPsec security suite [RFC4301][RFC4306].

   We encourage users of TCP-AO to be used apply known techniques for a given generating
   appropriate master key is indicated in keys, including the TDAD use of reasonable master key tuple,
   lengths, limited traffic key sharing, and details limiting the duration of
   master key use [RFC3562]. This also includes the PRF are provided in [RFC-TBD].

   The use of per-
   connection block (connblock) is defined nonces, as follows (IP addresses suggested in Section 7.2.

   TCP-AO supports rekeying in which new master keys are correspondingly longer for IPv6 addresses):

                   +--------+--------+--------+--------+
                   |             Source IP             |
                   +--------+--------+--------+--------+
                   |           Destination IP          |
                   +--------+--------+--------+--------+
                   |   Source Port   |    Dest. Port   |
                   +--------+--------+--------+--------+
                   |            Source ISN             |
                   +--------+--------+--------+--------+
                   |          Destination ISN          |
                   +--------+--------+--------+--------+

       Figure 6 Connection block used for connection key generation

   "Source" negotiated and "destination" are defined by
   coordinated out-of-band, either via a protocol or a manual procedure
   [RFC4808]. New master key use is coordinated using the direction of out-of-band
   mechanism to update the
   segment being MAC'd; for incoming packets, source TAPD at both TCP endpoints. When only a
   single master key is used at a time, the remote side,
   whereas for outgoing temporary use of invalid
   master keys could result in packets source being dropped; although TCP is
   already robust to such drops, TCP-AO uses the local side. This further
   ensures that connection keys generated for each direction are unique.

   For SYN segments (segments with the SYN set, but the ACK not set), KeyID field to avoid
   such drops. The TAPD can contain multiple concurrent master keys,
   where the destination ISN KeyID field is not known. For these segments, used to identify the connection master key is computed using the connection block shown above, in which the
   Destination ISN value is zero. For all other segments, that
   corresponds to the ISN pair
   is traffic key used when known. If for a segment, to avoid the ISN pair need
   for expensive trial-and-error testing of master keys in sequence.

   TCP-AO provides an explicit key coordination mechanism, described in
   Section 8.1. Such a mechanism is not known, e.g., useful when sending
   a RST after a reboot, the segment should new keys are installed,
   or when keys are changed, to determine when to commence using
   installed keys.

   The KeyID field is also useful in coordinating master keys used for
   new connections. A TAPD entry may be sent without
   authentication; if authentication was required, configured that matches the segment cannot
   have been MAC'd properly anyway and
   unbound source port, which would have been dropped on
   receipt.

   >> TCP-AO SYN segments (SYN set, no ACK set) MUST use return a destination
   ISN set of zero (whether sent or received); all other segments use possible master
   keys. The KeyID would then indicate the
   known ISN pair.

   >> Segments sent in response to connections for which specific master key, allowing
   more efficient connection establishment; otherwise, the ISNs master keys
   could have been tried in sequence.

   Users are
   not known SHOULD NOT use TCP-AO.

   Once a connection is established, a connection key would typically be
   cached advised to avoid recomputing it on a per-segment basis (e.g., in the
   TCP Transmission Control Block, i.e, manage master keys following the TCB [RFC793]). The use spirit of
   both ISNs in the connection
   advice for key management when using TCP MD5 [RFC3562], notably to
   use appropriate key computation ensures lengths (12-24 bytes) and to avoid sharing master
   keys among multiple BGP peering arrangements. This requires that segments
   cannot the
   TAPD support monitoring and modification.

7.3.1. Master Key Reuse Across Socket Pairs

   Master keys can be replayed reused across repeated connections reusing the same different socket pairs within a
   host, or across different instances of a socket pair (provided within a host.
   In either case, replay protection is maintained.

   Master keys reused across different socket pairs cannot enable replay
   attacks because the ISN TCP socket 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 included in the same connection).

   In general, a SYN would be MAC'd using a destination ISN MAC, as well
   as in the generation of zero
   (whether sent or received), and all other segments would be MAC'd
   using the ISN traffic key. Master keys reused across
   repeated instances of a given socket pair for cannot enable replay
   attacks because the connection. There connection ISNs are other cases included in which the destination traffic key
   generation algorithm, and ISN is not known, but segments pairs are emitted, such as
   after an endpoint reboots, when is possible that the two endpoints
   would not have enough information unlikely to authenticate segments. In such
   cases, TCP's timeout mechanism will allow old state repeat over
   useful periods.

7.3.2. Master Key Use Within a Long-lived Connection

   TCP-AO uses extended sequence numbers (ESNs) to prevent replay
   attacks within long-lived connections. Explicit master key rollover,
   accomplished by external means and indexed using the KeyID field, can
   be cleared used to
   enable new connections, except where the user timeout is disabled; it change keying material for various reasons (e.g.,
   personnel turnover), but is important that implementations are capable of detecting excesses
   of TCP connections in such a configuration and can clear them out if
   needed not required to protect its memory usage [Je07].

7. support long-lived
   connections.

8. Additional Security Association Management Mechanisms

   TCP-AO relies on a TCP Security Association Database (TSAD), which
   indicates whether a TCP connection requires TCP-AO, adds mechanisms to support efficient use, especially in
   environments where only manual keying is available. These include the
   previously described mechanisms for supporting multiple concurrent
   keys (via the KeyID field) and its
   parameters 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 so. The TSAD a traffic key is described as an explicit component not changed for long periods of time.

8.1. Coordinating KeyID Changes

   At any given time, a single TCP connection may have multiple KeyIDs
   specified for each segment direction (incoming, outgoing). TCP-AO
   provides a mechanism to enable external (master) key management mechanisms -
   automatic or manual - to interact with TCP-AO as needed.

   TSAD entries are assumed indicate when a new KeyID is ready, to exist at allow
   the endpoints where TCP-AO is
   used, in advance sender to commence use of that new KeyID. This supported by using
   two key ID fields in the connection:

   1. TCP connection identifier (ID), i.e., socket pair - IP source
      address, IP destination address, TCP source port, and TCP
      destination port [RFC793]. TSAD entries are uniquely determined header:

   o  KeyID

   o  NextKeyID

   KeyID represents the outgoing keying information used by
      their TCP connection ID, which is the segment
   sender to create the segment's MAC (outgoing), and the corresponding
   incoming keying information used by the segment receiver to index those entries. A
      TSAD entry may allow wildcards, notably validate
   that MAC. It indicates the KeyID in active use in that direction.

   NextKeyID represents the source port value.

      >> There MUST preferred keying information to be no more than one matching TSAD entry per
      direction used for
   subsequent segments. I.e., it is a fully-instantiated (no wildcards) TCP connection
      ID.

   2. For 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).

   There are two pointers kept by each side of inbound (for received TCP segments) a connection, as noted in
   the per-connection information (see Section 6):

   o  Currently active outgoing KeyID (Current_key)

   o  Current preference for KeyIDs (Next_key)

   Current_key points to a KeyID (and associated master key tuple) that
   is used to authenticate outgoing segments. Upon connection
   establishment, it points to the first key selected for use.

   Next_key points to an incoming KeyID (and associated master key
   tuple) that is ready and outbound (for
      sent TCP segments) directions preferred for this use. Upon connection (except as
      noted):

       a. TCP option flag. When 0,
   establishment, this flag allows default operation,
          i.e., TCP options are included in points to the MAC calculation, with
          TCP-AO's MAC field zeroed out.  When 1, all options (including
          TCP-AO) currently active incoming key. It
   can be changed when new keys are excluded from all MAC calculations (skipped over,
          not simply zeroed).

          >> The TCP option flag MUST default to 0 (i.e., options installed (e.g., either by automatic
   key management protocol operation or by user manual selection).

   Next_key is changed only by manual user intervention or key
   management protocol operation. It is not
          excluded).

          >> The TCP option flag MUST NOT change during a manipulated by TCP-AO.
   Current_key is updated by TCP-AO when processing received TCP
          connection.

          The
   segments as discussed in the segment processing description in
   Section 9.5.

8.2. Preventing replay attacks within long-lived connections

   TCP option flag cannot change during uses a connection because
          TCP state is coordinated during connection establishment. 32-bit sequence number which may, for long-lived
   connections, roll over and repeat. This could result in TCP
          lacks segments
   being intentionally and legitimately replayed within a handshake for modifying that state after connection.
   TCP-AO prevents replay attacks, and thus requires a connection
          has been established.

       b. An way to
   differentiate these legitimate replays from each other, and so it
   adds a 32-bit extended sequence number (ESN). (ESN) for transmitted and
   received segments.

   The ESN enables each
          segment's MAC calculation to have unique input data, even when
          payload data is retransmitted and the TCP extends TCP's sequence number
          repeats due to wraparound. The ESN is initialized to zero upon so that segments within a
   single connection establishment. Its use in the MAC calculation are always unique. When TCP's sequence number rolls
   over, there is
          described a chance that a segment could be repeated in Section 4.2, and its management is described total;
   using an ESN differentiates even identical segments sent with
   identical sequence numbers at different times in
          Section 5.

       c. An ordered list of zero or more master key tuples. Each tuple
          is defined as the set <KeyID, MAC type, master key length,
          master key, PRF> as follows:

          >> Components of a TSAD master key tuple MUST NOT change
          during a connection.

          Keeping the tuple components static ensures that the KeyID
          uniquely determines the properties of TCP-AO
   emulates a packet; this supports
          use of the KeyID 64-bit sequence number space by inferring when to determine
   increment the packet properties.

          >> 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
   for received segments, both initialized as zero when a connection
   begins. The set intent of TSAD master key tuples MAY change during these ESNs is, together with TCP's 32-bit
   sequence numbers, to provide a
          connection, but KeyIDs of those tuples MUST NOT overlap. I.e.,
          tuple parameter changes MUST 64-bit overall sequence number space.

   For transmitted segments SND.ESN can be accompanied implemented by master key
          changes.

           i. KeyID. The value as used in extending
   TCP's sequence number to 64-bits; SND.ESN would be the top (high-
   order) 32 bits of that number. For received segments, TCP-AO option; used needs to
               differentiate connection keys in concurrent
   emulate the use of a 64-bit number space, and correctly infer the
   appropriate high-order 32-bits of that are
               derived number as RCV.ESN from different master keys.

               >> A TSAD implementation MUST support at least two KeyIDs
               per connection per direction, the
   received 32-bit sequence number 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 current connection endpoints (e.g., using an
               external master key management mechanism).

               >> KeyIDs MUST NOT be assumed to context.

   The implementation of ESNs is not specified in this document, but one
   possible way is described here that can be randomly assigned.

          ii. MAC type. Indicates the MAC used for this connection, for either RCV.ESN,
   SND.ESN, or both.

   Consider an implementation with two ESNs as
               defined in [RFC-TBD]. This includes the MAC algorithm
               (e.g., HMAC-SHA1, AES-CMAC, etc.) required (SND.ESN,
   RCV.ESN), and the length of the
               MAC additional variables as truncated listed below, all initialized
   to (e.g., 96, 128, etc.).

               >> A MAC type zero, as well as a current TCP segment field (SEG.SEQ):

   o  SND.PREV_SEQ, needed to detect rollover of "NONE" MUST be supported, SND.SEQ

   o  RCV.PREV_SEQ, needed to indicate
               that authentication is not used in this direction; this
               allows asymmetric use detect rollover of TCP-AO.

               >> At least one direction (inbound/outbound) SHOULD have 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 non-"NONE" MAC segment is received, the following algorithm (written in practice, but this MUST NOT be
               strictly required by C)
   computes the ESN used in the MAC; an implementation.

               >> When equivalent algorithm can be
   applied to the outbound MAC is "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 values other than
               "NONE", TCP-AO MUST occur 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 every outbound TCP segment the *middle* of the window */
         if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) {
            RCV.ESN_FLAG = 0;
         }
         /* */
         /* save the current SEQ for that connection; the next time through the code */
         RCV.PREV_SEQ = SEG.SEQ;

   In the above code, the first line when set to NONE or the sequence number first
   rolls over, i.e., when no tuple
               exists, TCP-AO MUST NOT occur in those segments.

               >> When the inbound MAC new number is set to values other than
               "NONE", TCP-AO MUST occur in every inbound TCP segment
               for that connection; when set to "NONE" or when no tuple
               exists, TCP-AO SHOULD NOT be added to those segments, but
               MAY occur low (in the bottom half of
   the number space) and MUST be ignored.

         iii. Master key length. Indicates the length old number is high (in the top half of the master key
               in bytes.

          iv. Master key. A byte sequence used for generating
               connection keys,
   number space). The first time this may be derived from a separate
               shared key by an external protocol over happens, the ESN is incremented
   and a separate
               channel. This sequence flag is used in network-standard byte
               order in the connection key generation algorithm
               described in Section 6.

           v. PRF. A pseudorandom function used for set.

   If the geneation of flag is set and a
               connection key from the master key tuple, as described in
               Section 6. The specific functions used are described in
               [RFC-TBD].

   It high number is anticipated that TSAD entries for TCP connections in states
   other than CLOSED can seen, it must be indexed in the TCP TCB for convenience, but
   that the index would reference a separate database with entries for
   all connections to an IP address (see Section 9.1 for notes on reordered
   packet, so use the
   latter. This means that for a particular endpoint (i.e., IP address)
   there would pre-increment ESN, otherwise use the current ESN.
   The flag will be exactly one database that is consulted cleared by the time the number rolls all pending
   connections, the same way that there is only one table of TCBs (a
   database can support multiple endpoints, but an endpoint
   around.

   The flag prevents the ESN from being incremented again until the flag
   is
   represented reset, which happens in only one database). Multiple databases could be used
   to support virtual hosts, i.e., groups the middle of interfaces.

   Note that the TCP-AO fields omit an explicit algorithm ID; that
   algorithm window (when the old
   number is already specified by in the TCP connection ID bottom half and stored the new is in the TSAD.

   Also note that this document does not address how TSAD entries are
   created by users/processes; top half). Because
   the receive window is never larger than half of the number space, it specifies how they must be destroyed
   corresponding to connection states, but users/processes may destroy
   entries as well. It
   is presumed that a TSAD entry affecting a
   particular connection cannot be destroyed during an active connection
   - or, equivalently, that its parameters are copied to TSAD entries
   local impossible to the connection (i.e., instantiated) both set and so changes would
   affect only new connections. The TSAD could be managed by a separate
   application protocol.

8. 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
   states, segments, events, and interfaces. This description is
   intended to augment the description of TCP as provided in RFC-793,
   and its presentation mirrors that of RFC-793 as a result [RFC793].

8.1.

9.1. TCP User Interface

   The TCP user interface supports active and passive OPEN, SEND,
   RECEIVE, CLOSE, STATUS and ABORT commands. TCP-AO does not alter this
   interface as it applies to TCP, but some commands or command
   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 requires the TCP user interface be extended to allow the TSAD TAPD
   to be configured, as well as to allow an ongoing connection to manage
   which KeyID tuples are active. The TSAD TAPD needs to be configured prior
   to connection establishment, and possibly changed during 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
   a TSAD TAPD entry can be configured.

   >> A TCP-AO implmentation MUST allow TSAD TAPD entries for ongoing TCP
   connections (i.e., not in the CLOSED state) to be modified.
   Parameters not used to index a connection MAY be modified; parameters
   used to index a connection MUST NOT be modified.

   The TSAD TAPD information of a connection needs to be available for
   confirmation; this includes the ability to read the connection key:

   >> TCP STATUS SHOULD be augmented to allow the TSAD TAPD entry of a
   current or pending connection to be read (for confirmation).

   Senders may need to be able to determine when the outgoing KeyID changes;
   this change
   changes or when a new preferred KeyID (NextKeyID) is indicated; these
   changes immediately affects affect all subsequent outgoing segments
   (i.e., it need not be synchronized with the data of the SEND call, if
   indicated therein): segments:

   >> TCP SEND, or a sequence of commands resulting in a SEND, MUST be
   augmented so that the preferred KeyID (Current_key) and/or the
   Next_key of a TSAD entry connection can be indicated.

   It may be useful to change the sender-side outgoing active KeyID (Current_key)
   even when no data is being sent, which can be achieved by sending a
   zero-length buffer or by using a non-send interface (e.g., socket
   options in Unix), depending on the implementation.

   It is also useful for the receive side to indicate the recent KeyID and NextKeyID values
   received; although there could be a number of such KeyIDs, the KeyIDs values, they are
   not expected to change quickly so any recent sample of a received
   KeyID is should be
   sufficient:

   >> TCP RECEIVE, or the sequence of commands resulting in a RECEIVE,
   MUST be augmented so that the KeyID and NextKeyID of a recently
   received segment is available to the user out-of-band (e.g., as an
   additional parameter to RECEIVE, or via a STATUS call).

8.2.

9.2. TCP States and Transitions

   TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED,
   FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and
   CLOSED.

   >> A TSAD TAPD entry MAY be associated with any TCP state.

   >> A TSAD TAPD entry MAY underspecify the TCP connection for the LISTEN
   state. Such an entry MUST NOT be used for more than one connection
   progressing out of the LISTEN state.

8.3.

9.3. TCP Segments

   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
   control segments can include data (e.g., SYN).

   >> All TCP segments MUST be checked against the TSAD TAPD for matching TCP
   connection IDs.

   >> TCP segments matching TSAD TAPD entries with non-NULL MACs without TCP-
   AO, TCP-AO, or with TCP-AO
   and whose MACs and KeyIDs do not validate MUST be silently discarded.

   >> TCP segments with TCP-AO but not matching TSAD TAPD entries MUST be
   silently accepted; this is required for equivalent function with TCPs
   not implementing TCP-AO.

   >> 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.
   Both warnings, if available, MUST be accessible via the STATUS
   interface. Either signal MAY be asynchronous, but if so they MUST be
   rate-limited. Either signal MAY be logged; logging SHOULD allow rate-
   limiting as well.

   All TCP-AO processing occurs between the interface of TCP and IP; for
   incoming segments, this occurs after validation of the TCP checksum.
   For outgoing segments, this occurs before computation of the TCP
   checksum.

   Note that the TCP-AO option is not negotiated. It is the
   responsibility of the receiver to determine when TCP-AO is required
   and to enforce that requirement.

8.4. Sending TCP Segments

   The following procedure describes the modifications to TCP to support
   TCP-AO when a segment departs.

   1. Check the segment's TCP connection ID against the TSAD

   2. If there is NO TSAD entry, omit the TCP-AO option. Proceed with
      computing the TCP checksum and transmit the segment.

   3. If there is a TSAD entry with zero master key tuples, omit the
      TCP-AO option. Proceed with computing the TCP checksum and
      transmit the segment.

   4. If there is a TSAD entry and a master key tuple and the outgoing
      MAC is NONE, omit the TCP-AO option. Proceed with computing the
      TCP checksum and transmit the segment.

   5. If there is a TSAD entry and a master key tuple and the outgoing
      MAC is not NONE:

       a. Augment the TCP header with the TCP-AO, inserting the
          appropriate Length and KeyID based on the indexed TSAD entry.
          Update the TCP header length accordingly.

       b. Determine SND.ESN as described in Section 5.

       c. Determine the connection key from the indexed TSAD entry as
          described in Section 6.

       d. Compute the MAC using the indexed TSAD entry and data from the
          segment as specified in Section 4.2, including between the interface of TCP
          pseudoheader and TCP header. Include or exclude the options as
          indicated by IP; for
   incoming segments, this occurs after validation of the TSAD entry's TCP option exclusion flag.

       e. Insert checksum.
   For outgoing segments, this occurs before computation of the MAC in TCP
   checksum.

   Note that the TCP-AO field.

       f. Proceed with computing option is not negotiated. It is the TCP checksum on
   responsibility of the outgoing packet receiver to determine when TCP-AO is required
   and transmit the segment.

8.5. Receiving to enforce that requirement.

9.4. Sending TCP Segments

   The following procedure describes the modifications to TCP to support
   TCP-AO when a segment arrives.

   1. Check departs.

   >> Note that TCP-AO MUST be the segment's last TCP connection ID against option processed on outgoing
   segments, because its MAC calculation may include the TSAD.

   2. values of other
   TCP options.

   1. Find the per-connection parameters for the segment:

       a. If the segment is a SYN, then this is the first segment of a
          new connection. Consult the TAPD to find the appropriate
          master key tuple.

           i. If there is NO TSAD no matching TAPD entry, proceed omit the TCP-AO
               option. Proceed with TCP processing.

   3. transmitting the segment.

          ii. If there is a TSAD TAPD entry with zero master key tuples, proceed with
      TCP
               silently discard the segment and cease further
               processing.

   4.

         iii. If there is a TSAD TAPD entry with a and at least one master key tuple and
               tuple, then set the incoming
      MAC is NONE, proceed per-connection parameters as needed
               (see Section 6). Proceed with TCP processing.

   5. the step 2.

       b. If there the segment is not a TSAD entry with a master key tuple SYN, then determine whether TCP-AO is
          being used and the incoming
      MAC is not NONE:

       a. Check that current_key value from the segment's TCP-AO Length matches per-connection
          parameters (see Section 6) and proceed with the length
          indicated by step 2.

   2. Using the indexed TSAD.

           i. If Lengths differ, silently discard per-connection parameters:

       a. Augment the segment. Log
               and/or signal TCP header with the event as indicated in Section 8.3.

       b. Use TCP-AO, inserting the
          appropriate Length and KeyID value to index based on the appropriate connection master key
          for this connection.

           i. If the TSAD has no entry corresponding to the segment's
               KeyID, silently discard tuple
          indicated by current_key. Update the segment.

       c. TCP header length
          accordingly.

       b. Determine the segment's RCV.ESN SND.ESN as described in Section 5.

       d. 8.2.

       c. Determine the segment's connection key from the indexed TSAD
          entry appropriate traffic key, i.e., as described pointed to by
          current_key (as noted in Section 6.

       e. Compute the segment's MAC using the indexed TSAD entry 8.1, and
          portions of the segment as indicated probably cached
          in Section 4.2.

          Again, if options are excluded (as per the TCP option
          exclusion flag), they are skipped over (rather than zeroed)
          when used as input to the MAC calculation.

           i. If the computed MAC differs from TCB). I.e., use the TCP-AO MAC field
               value, silently discard Send_SYN_traffic_key for SYN
          segments, and the segment. Log and/or signal send_other_traffic_key for other segments.

       d. Determine the event NextKeyID as indicated in Section 8.3.

       f. Proceed with TCP processing of the segment.

   It is suggested that TCP-AO implementations validate a segment's
   Length field before computing a MAC, to reduce the overhead incurred by spoofed segments with invalid TCP-AO fields.

   Additional reductions in MAC validation overhead can be supported the Next_key pointer
          (as noted in Section 8.1).

       e. Compute the MAC algorithms, e.g, by using a computation algorithm that
   prepends a fixed value to the computed portion master key tuple (and cached traffic
          key) and a corresponding
   validation algorithm that verifies the fixed value before investing
   in data from the computed portion. Such optimizations would be contained segment as specified in Section 7.1.

       f. Insert the MAC algorithm specification, and thus are not specified in the TCP-AO
   explicitly. Note that field.

       g. Proceed with transmitting the KeyID cannot be used for connection
   validation per se, because it is not assumed random.

8.6. Impact on segment.

9.5. Receiving TCP Header Size Segments

   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 following procedure describes the modifications to TCP MD5 option (assuming to support
   TCP-AO when a 96-bit MAC). segment arrives.

   >> Note that TCP-AO MUST be the first TCP option space is most critical in SYN processed on
   incoming segments, because
   flags in those segments could potentially increase its MAC calculation may include the option space
   area in values
   of other segments. Because TCP ignores unknown segments,
   however, it is not possible to extend the options which could change during TCP option space of SYNs
   without breaking backward-compatibility.

   TCP's 4-bit data offset requires that processing.
   This also protects the behavior of all other TCP options end 60 bytes (15
   32-bit words) after the header begins, including from the 20-byte header.
   This leaves 40 bytes for options,
   impact of which 15 are expected in current
   implementations (listed below), leaving at most 20 for TCP-AO.
   Assuming a 96-bit MAC, spoofed segments or modified header information.

   >> Note that TCP-AO consumes 15 bytes, leaving up to 10
   bytes checks MUST be performed for other options (depending on implementation dependant
   alignment padding, which could consume another 2 bytes at most).

   o  SACK permitted (2 bytes) [RFC2018][RFC3517]

   o  Timestamps (10 bytes) [RFC1323]

   o  Window scale (3 bytes) [RFC1323]

   Although TCP all incoming SYNs to
   avoid accepting SYNs lacking the TCP-AO option space where required. Other
   segments can cache whether TCP-AO is needed in the TCB.

   1. Find the per-connection parameters for the segment:

       a. If the segment is limited, we believe TCP-AO a SYN, then this is consistent
   with the desire first segment of a
          new connection. Consult the TAPD to authenticate TCP at find the connection level for
   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 appropriate
          master key
   negotiation or parameter negotiation (MAC algorithm, length, or use
   of tuple.

           i. If there is no matching TAPD entry, omit the TCP-AO option), or for coordinating rekeying during
               option. Proceed with further TCP handling of the segment.

          ii. If there is a
   connection. We assume out-of-band mechanisms for TAPD entry with zero master key
   establishment, parameter negotiation, tuples,
               silently discard the segment and rekeying. This separation
   of cease further TCP
               processing.

         iii. If there is a TAPD entry and at least one master key use from
               tuple, then set the per-connection parameters as needed
               (see Section 6). Proceed with the step 2.

   2. Using the per-connection parameters:

       a. Check that the segment's TCP-AO Length matches the length
          indicated by the master key management is similar to that in indicated by the IPsec security suite [RFC4301][RFC4306].

   We encourage users of segment's TCP-AO
          KeyID field.

           i. If lengths differ, silently discard the segment. Log
               and/or signal the event as indicated in Section 9.3.

       b. Use the segment's KeyID value to apply known techniques for generating index the appropriate
          connection key for this connection.

       c. Determine the segment's RCV.ESN as described in Section 8.2.

       d. Determine the segment's traffic key from the master keys, including key tuple
          as described in Section 7.1 (and as likely cached in the TCB).
          I.e., use of reasonable 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
   lengths, limited connection key sharing, tuple (and its
          derived traffic key) and limiting the duration portions of
   master key use [RFC3562]. This also includes the use of per-
   connection nonces, segment as suggested indicated
          in Section 4.2. 7.1.

           i. If the computed MAC differs from the TCP-AO supports rekeying MAC field
               value, silently discard the segment. Log and/or signal
               the event as indicated 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 Section 9.3.

       f. Compare the received NextKeyID value to the currently active
          outgoing KeyID value (Current_key).

           i. If they match, no further action is coordinated using required.

          ii. If they differ, determine whether the out-of-band
   mechanism 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 update the TSAD at both TCP endpoints. When only suggested NextKeyID if it
                    already has a 2*MSL timer set on it, i.e., to refuse
                    to 'backup' and use a
   single master key is used at once it has been
                    previously used.

                     a. Set a time, timer on the temporary use previous value of invalid current_key
                       to ensure that the corresponding master keys could result in packets being dropped; although 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
   already robust to such drops, suggested that TCP-AO uses the KeyID implementations validate a segment's
   Length field before computing a MAC, to avoid
   such drops. The TSAD can contain multiple concurrent master keys,
   where reduce the KeyID field is used to identify overhead incurred
   by spoofed segments with invalid TCP-AO fields.

   Additional reductions in MAC validation overhead can be supported in
   the master key MAC algorithms, e.g., by using a computation algorithm that
   corresponds
   prepends a fixed value to the connection key used for computed portion and a segment, to avoid corresponding
   validation algorithm that verifies the
   need for expensive trial-and-error testing of master keys fixed value before investing
   in
   sequence.

   TCP-AO does not currently provide an explicit key coordination
   mechanism. the computed portion. Such a mechanism is useful when new keys are installed, or
   when keys optimizations would be contained in the
   MAC algorithm specification, and thus are changed, to determine when to commence using installed
   keys. not specified in TCP-AO
   explicitly. Note that the KeyID cannot be used for connection
   validation per se, because it is not assumed random.

9.6. Impact on TCP Header Size

   The TCP-AO option typically uses directional keys, a total of 17-19 bytes of TCP header
   space. TCP-AO is no larger than and typically 3 bytes smaller than
   the receive-
   side keys can be installed TCP MD5 option (assuming a 96-bit MAC).

   Note that TCP option space is most critical in advance SYN segments, because
   flags in those segments could potentially increase the option space
   area in other segments. Because TCP ignores unknown segments,
   however, it is not possible to extend the option space of SYNs
   without breaking backward-compatibility.

   TCP's 4-bit data offset requires that the send side, avoiding options end 60 bytes (15
   32-bit words) after the
   need header begins, including the 20-byte header.
   This leaves 40 bytes for tight coordination between endpoints.

   The KeyID field is also useful options, of which 15 are expected in coordinating master keys used current
   implementations (listed below), leaving at most 25 for other uses.
   Assuming a 96-bit MAC, TCP-AO consumes 16 bytes, leaving up to 9
   bytes for
   new connections. A TSAD entry may be configured that matches the
   unbound source port, additional SYN options (depending on implementation
   dependant alignment padding, which would return could consume another 2 bytes at
   most).

   o  SACK permitted (2 bytes) [RFC2018][RFC3517]

   o  Timestamps (10 bytes) [RFC1323]

   o  Window scale (3 bytes) [RFC1323]

   After a set of possible master
   keys. The KeyID would then indicate the specific master key, allowing
   more efficient connection establishment; otherwise, SYN, the master keys
   could have been tried in sequence. See also Section 9.1.

   Users following options are advised expected in current
   implementations of TCP:

   o  SACK (10bytes) [RFC2018][RFC3517] (18 bytes if D-SACK [RFC2883]

   o  Timestamps (10 bytes) [RFC1323]
   TCP-AO continues to manage master keys following the spirit consume 16 bytes in non-SYN segments, leaving a
   total of 24 bytes for other options, of which the
   advice timestamp consumes
   10. This leaves 14 bytes, of which 10 are used for key management when using TCP MD5 [RFC3562], notably a single SACK
   block. When two SACK blocks are used, such as to
   use appropriate key lengths (12-24 bytes), handle D-SACK, a
   smaller TCP-AO MAC would be required to avoid sharing master
   keys among multiple BGP peering arrangements, and make room for the additional
   SACK block (i.e., to change master
   keys every 90 days. This requires that leave 18 bytes for 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 D-SACK variant of a socket pair within a host.
   In either case, replay protection is maintained.

   Master keys reused across different socket pairs cannot enable replay
   attacks because the TCP socket pair
   SACK option) [RFC2883]. Note that D-SACK is included not supportable in the MAC, as well
   as TCP-
   MD5 in the generation of the connection key. Master keys reused across
   repeated instances presence of a given socket pair cannot enable replay
   attacks timestamps, because the connection ISNs are included in the connection
   key generation algorithm, TCP MD5's MAC length is
   fixed and ISN pairs are unlikely too large to repeat over
   useful periods.

9.2. Master Key Use Within a Long-lived Connection leave sufficient option space.

   Although TCP option space is limited, we believe TCP-AO uses extended sequence numbers (ESNs) to prevent replay
   attacks within long-lived connections. Explicit master key rollover,
   accomplished by external means and indexed using is consistent
   with the KeyID field, can
   be used desire to change keying material authenticate TCP at the connection level for various reasons (e.g.,
   personnel turnover), but is not required to support long-lived
   connections.
   similar uses as were intended by TCP MD5.

10. Obsoleting TCP MD5 and Legacy Interactions

   TCP-AO obsoletes TCP MD5. As we have noted earlier:

   >> TCP implementations MUST support TCP-AO.

   Systems implementing TCP MD5 only are considered legacy, and ought to
   be upgraded when possible. In order to support interoperation with
   such legacy systems until upgrades are available:

   >> TCP MD5 SHOULD be supported where interactions with legacy systems
   is needed.

   >> A system that supports both TCP-AO and TCP MD5 MUST use TCP-AO for
   connections unless not supported by its peer, at which point it MAY
   use TCP MD5 instead.

   >> 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
   simultaneously for different connections (notably to support legacy
   use of TCP MD5).

   The Kind value explicitly indicates whether TCP-AO or TCP MD5 is used
   for a particular connection in TCP segments.

   It is possible that the TSAD TAPD could be augmented to support TCP MD5,
   although use of a TSAD-like TAPD-like system is not described in RFC2385.

   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
   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
   requirements prohibit the speculative use of both options for a given
   connection, e.g., to be decided by the other end of the connection.

11. Interactions with Middleboxes

   TCP-AO may interact with middleboxes, depending on their behavior
   [RFC3234]. Some middleboxes either alter TCP options (such as TCP-AO)
   directly or alter the information TCP-AO includes in its MAC
   calculation. TCP-AO may interfere with these devices, exactly where
   the device modifies information TCP-AO is designed to protect.

11.1. Interactions with non-NAT/NAPT Middleboxes

   TCP-AO supports middleboxes that do not change the IP addresses or
   ports of segments. Such middleboxes may modify some TCP options, in
   which case TCP-AO would need to be configured to ignore all options
   in the MAC calculation on connections traversing that element.

   Note that ignoring TCP options may provide less protection, i.e., TCP
   options could be modified in transit, and such modifications could be
   used by an attacker. Depending on the modifications, TCP could have
   compromised efficiency (e.g., timestamp changes), or could cease
   correct operation (e.g., window scale changes). These vulnerabilities
   affect only the TCP connections for which TCP-AO is configured to
   ignore TCP options.

11.2. Interactions with NAT/NAPT Devices

   TCP-AO cannot interoperate natively across NAT/NAPT devices, which
   modify the IP addresses and/or port numbers. We anticipate that
   traversing such devices will require variants of existing NAT/NAPT
   traversal mechanisms, e.g., encapsulation of the TCP-AO-protected
   segment in another transport segment (e.g., UDP), as is done in IPsec
   [RFC2766][RFC3947]. Such variants can be adapted for use with TCP-AO,
   or IPsec NAT traversal can be used instead in such cases [RFC3947].

12. Evaluation of Requirements Satisfaction

   TCP-AO satisfies all the current requirements for a revision to TCP
   MD5, as summarized below [Be07].

   1. Protected Elements

      A solution to revising TCP MD5 should protect (authenticate) the
      following elements.

      This is supported - see Section 4.2. 7.1.

       a. TCP pseudoheader, including IPv4 and IPv6 versions.

          Note that we do not allow optional coverage because IP
          addresses define a connection. If they can be coordinated
          across a NAT/NAPT, the sender can compute the MAC based on the
          received values; if not, a tunnel is required, as noted in
          Section 11.2.

       b. TCP header.

          Note that we do not allow optional port coverage because ports
          define a connection. If they can be coordinated across a
          NAT/NAPT, the sender can compute the MAC based on the received
          values; if not, a tunnel is required, as noted in Section
          11.2.

       c. TCP options.

          Note that TCP-AO allows exclusion of TCP options from
          coverage, to enable use with middleboxes that modify options
          (except when they modify TCP-AO itself). See Section 11.

       d. TCP payload data.

   2. Option Structure Requirements

      A solution to revising TCP MD5 should use an option with the
      following structural requirements.

      This is supported - see Section 4.2. 7.1.

       a. Privacy.

          The option should not unnecessarily expose information about
          the TCP-AO mechanism. The additional protection afforded by
          keeping this information private may be of little value, but
          also helps keep the option size small.

          TCP-AO exposes only the master key index, MAC, and overall
          option length on the wire. Note that short MACs could be
          obscured by using longer option lengths but specifying a short
          MAC length (this is equivalent to a different MAC algorithm,
          and is specified in the TSAD TAPD entry). See Section 4.2.

       b. Allow optional per connection.

          The option should not be required on every connection; it
          should be optional on a per connection basis.

          This is supported - see Sections 8.3, 8.4, 9.3, 9.4, and 8.5. 9.5.

       c. Require non-optional.

          The option should be able to be specified as required for a
          given connection.

          This is supported - see Sections 8.3, 8.4, 9.3, 9.4, and 8.5. 9.5.

       d. Standard parsing.

          The option should be easily parseable, i.e., without
          conditional parsing, and follow the standard RFC 793 option
          format.

          This is supported - see Section 4.2.

       e. Compatible with Large Windows and SACK.

          The option should be compatible with the use of the Large
          Windows and SACK options.

          This is supported - see Section 8.6. 9.6. The size of the option is
          intended to allow use with Large Windows and SACK. See also
          Section 2.1, which indicates that TCP-AO is 3 bytes shorter
          than TCP MD5 in the default case, assuming a 96-bit MAC.

   3. Cryptography requirements

      A solution to revising TCP MD5 should support modern cryptography
      capabilities.

       a. Baseline defaults.

          The option should have a default that is required in all
          implementations.

          TCP-AO uses a default required algorithm as specified in [RFC-
          TBD], [ao-
          crypto], as noted in Section 4.2. 7.1.

       b. Good algorithms.

          The option should use algorithms considered accepted by the
          security community, which are considered appropriately safe.
          The use of non-standard or unpublished algorithms should be
          avoided.

          TCP-AO uses MACs as indicated in [RFC-TBD]. [ao-crypto]. The PRF is also
          specified in [RFC-TBD]. [ao-crypto]. The PRF input string follows the
          typical design (in Section 6). (see [ao-crypto]).

       c. Algorithm agility.

          The option should support algorithms other than the default,
          to allow agility over time.

          TCP-AO allows any desired algorithm, subject to TCP option
          space limitations, as noted in Section 4.2. The TSAD TAPD allows
          separate connections to use different algorithms, both for the
          MAC and the PRF.

       d. Order-independent processing.

          The option should be processed independently of the proper
          order, i.e., they should allow processing of TCP segments in
          the order received, without requiring reordering. This avoids
          the need for reordering prior to processing, and avoids the
          impact of misordered segments on the option.

          This is supported - see Sections 8.3, 8.4, 9.3, 9.4, and 8.5. 9.5. Note that
          pre-TCP processing is further required, because TCP segments
          cannot be discarded solely based on a combination of
          connection state and out-of-window checks; many such segments,
          although discarded, cause a host to respond with a replay of
          the last valid ACK, e.g. [RFC793]. See also the derivation of
          the ESN, which is reconstituted at the receiver using a
          demonstration algorithm that avoids the need for reordering
          (in Section 5). 8.2).

       e. Security parameter changes require key changes.

          The option should require that the key change whenever the
          security parameters change. This avoids the need for
          coordinating option state during a connection, which is
          typical for TCP options. This also helps allow "bump in the
          stack" implementations that are not integrated with endpoint
          TCP implementations.

          TSAD

          TAPD parameters that should not change during a connection (by
          defininition, e.g., TCP connection ID, receiver TCP connection
          ID, TCP option exclusion list) cannot change. Other parameters
          change only when a master key is changed, using the master key
          tuple mechanism in the TSAD. TAPD. See Section 7. 5.

   4. Keying requirements.

      A solution to revising TCP MD5 should support manual keying, and
      should support the use of an external automated key management
      system (e.g., a protocol or other mechanism).

      Note that TCP-AO does not specify a master key management system,
      but does indicate a proposed interface to the TSAD, TAPD, allowing a
      completely separate master key system, as noted in Section 7. 5.

       a. Intraconnection rekeying.

          The option should support rekeying during a connection, to
          avoid the impact of long-duration connections.

          This is supported by the KeyID and multiple master key tuples
          in a TSAD TAPD entry; see Section 7. 5.

       b. Efficient rekeying.

          The option should support rekeying during a connection without
          the need to expend undue computational resources. In
          particular, the options should avoid the need to try multiple
          keys on a given segment.

          This is supported by the use of the KeyID. See Section 9. 8.1.

       c. Automated and manual keying.

          The option should support both automated and manual keying.

          The use of a separate TSAD TAPD allows external automated and
          manual keying. See Section 9. 5. This capability is enhanced by
          the generation of unique per-connection keys, which enables
          use of manual master keys with automatically generated
          connection keys as noted in Section 6. 7.2.

       d. Key management agnostic.

          The option should not assume or require a particular key
          management solution.

          This is supported by use of a separate TSAD. TAPD. See Section 9.1. 5.

   5. Expected Constraints

      A solution to revising TCP MD5 should also abide by typical safe
      security practices.

       a. Silent failure.

          Receipt of segments failing authentication must result in no
          visible external action and must not modify internal state,
          and those events should be logged.

          This is supported - see Sections 8.3, 8.4, 9.3, 9.4, and 8.5. 9.5.

       b. At most one such option per segment.

          Only one authentication option can be permitted per segment.

          This is supported by the protocol requirements - see Section
          4.2.

       c. Outgoing all or none.

          Segments out of a TCP connection are either all authenticated
          or all not authenticated.

          This is supported - see Section 8.4. 9.4.

       d. Incoming all checked.

          Segments into a TCP connection are always checked to determine
          whether their authentication should be present and valid.

          This is supported - see Section 8.5. 9.5.

       e. Non-interaction with TCP MD5.

          The use of this option for a given connection should not
          preclude the use of TCP MD5, e.g., for legacy use, for other
          connections.

          This is supported - see Section 10.

       f. Optional ICMP discard.

          The option should allow certain ICMPs to be discarded, notably
          Type 3, 3 (destination unreachable), Codes 2-4. 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.

       g. Maintain TCP connection semantics, in which the socket pair
          alone defines a TCP association and all its security
          parameters.

          This is supported - see Sections 7 5 and 11.

13. Security Considerations

   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
   by transmitting segments with invalid MACs. Attackers would need to
   know only the TCP connection ID and TCP-AO Length value to
   substantially impact the host's processing capacity. This is similar
   to the susceptibility of IPsec to on-path attacks, where the IP
   addresses and SPI would be visible. For IPsec, the entire SPI space
   (32 bits) is arbitrary, whereas for routing protocols typically only
   the source port (16 bits) is arbitrary. As a result, it would be
   easier for an off-path attacker to spoof a TCP-AO segment that could
   cause receiver validation effort. However, we note that between
   Internet routers both ports could be arbitrary (i.e., determined a-
   priori out of band), which would constitute roughly the same off-path
   antispoofing protection of an arbitrary SPI.

   TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets
   typically occur after peer crashes, either in response to new
   connection attempts or when data is sent on stale connections; in
   either case, the recovering endpoint may lack the connection key
   required (e.g., if lost during the crash). This may result in time-
   outs, rather than more responsive recovery after such a crash. As
   noted in Section 6, 7.2, such cases may also result in persistent TCP
   state for old connections that cannot be cleared, and so
   implementations should be capable of detecting an excess of such
   connections and clearing their state if needed to protect memory
   utilization [Je07].

   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
   is quickly reset or aborted. Normal TCP operation will retry and
   timeout, which is what should be expected when the intended receiver
   is not capable of the TCP variant required anyway. Backoff is not
   optimized because it would present an opportunity for attackers on
   the wire to abort authenticated connection attempts by sending
   spoofed SYN-ACKs without the TCP-AO option.

   TCP-AO is intended to provide similar protections to IPsec, but is
   not intended to replace the use of IPsec or IKE either for more
   robust security or more sophisticated security management.

   TCP-AO does not address the issue of ICMP attacks on TCP. IPsec makes
   recommendations regarding dropping ICMPs in certain contexts, or
   requiring that they are endpoint authenticated in others [RFC4301].
   There are other mechanisms proposed to reduce the impact of ICMP
   attacks by further validating ICMP contents and changing the effect
   of some messages based on TCP state, but these do not provide the
   level of authentication for ICMP that TCP-AO provides for TCP [Go07].

   >> A TCP-AO implementation MUST allow the system administrator to
   configure whether TCP will ignore incoming ICMP messages of Type 3
   (destination unreachable) Codes 2-4 (protocol unreachable, port
   unreachable, and fragmentation needed - 'hard errors') intended for
   connections that match TSAD TAPD entries with non-NONE inbound MACs. An
   implementation SHOULD allow ignored ICMPs to be logged.

   This control affects only ICMPs that currently require 'hard errors',
   which would abort the TCP connection [RFC1122]. This recommendation
   is intended to be similar to how IPsec would handle those messages
   [RFC4301].

   TCP-AO includes the TCP connection ID (the socket pair) in the MAC
   calculation. This prevents different concurrent connections using the
   same connection key (for whatever reason) from potentially enabling a
   traffic-crossing attack, in which segments to one socket pair are
   diverted to attack a different socket pair. When multiple connections
   use the same master key, it would be useful to know that packets
   intended for one ID could not be (maliciously or otherwise) modified
   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 TAPD index
   was unique in both directions (ID->key and key->ID). That requirement
   would place an additional burden of uniqueness on master keys within
   endsystems, and potentially across endsystems. Although the resulting
   attack is low probability, the protection afforded by including the
   received ID warrants its inclusion in the MAC, and does not unduly
   increase the MAC calculation or master key management system.

   The use of any security algorithm can present an opportunity for a
   CPU DOS attack, where the attacker sends false, random segments that
   the receiver under attack expends substantial CPU effort to reject.
   In IPsec, such attacks are reduced by the use of a large Security
   Parameter Index (SPI) and Sequence Number fields to partly validate
   segments before CPU cycles are invested validated the Integrity Check
   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
   attacks, isn't needed in all cases due to TCP's Sequence Number, which is used to
   reorder received segments. segments (provided the sequence number doesn't wrap
   around, which is why TCP-AO adds the ESN in Section 8.2). TCP already
   protects itself from replays of authentic segment data as well as
   authentic explicit TCP control (e.g., SYN, FIN, ACK bits, but even
   authentic replays could affect TCP congestion control [Sa99]. TCP-AO
   does not protect TCP congestion control from such attacks this last form of attack
   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.

   Further, it is not useful to validate TCP's Sequence Number before
   performing a TCP-AO authentication calculation, because out-of-window
   segments can still cause valid TCP protocol actions (e.g., ACK
   retransmission) [RFC793]. It is similarly not useful to add a
   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.

14. IANA Considerations

   [NOTE: This section be removed prior to publication as an RFC]

   The TCP-AO option defines no new namespaces.

   The TCP-AO option requires that IANA allocate a value from the TCP
   option Kind namespace, to be replaced for TCP-IANA-KIND throughout
   this document.

   To specify MAC and PRF algorithms, TCP-AO refers to a separate
   document that may involve IANA actions [RFC-TBD]. [ao-crypto].

15. References

15.1. Normative References

   [RFC793]  Postel, J., "Transmission Control Protocol," STD-7,
             RFC-793, Standard, Sept. 1981.

   [RFC1122] Braden, R., "Requirements for Internet Hosts --
             Communication Layers," RFC-1122, Oct. 1989.

   [RFC2018] Mathis, M., J. Mahdavi, J., Floyd, S. and Floyd, A. Romanow, "TCP
             Selective Acknowledgement Options", RFC-2018, Proposed
             Standard, April 1996.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP-14, RFC-2119, Best Current
             Practice, March 1997.

   [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
             Signature Option," RFC-2385, Proposed Standard, Aug. 1998.

   [RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP
             and AH," RFC-2403, Proposed Standard, Nov. 1998.

   [RFC2460] Deering, S., R. Hinden, R., "Internet Protocol, Version 6
             (IPv6) Specification," RFC-2460, Proposed Standard, Dec.
             1998.

   [RFC2883] Floyd, S., J. Mahdavi, M. Mathis, M. Podolsky, "An
             Extension to the Selective Acknowledgement (SACK) Option
             for TCP", RFC-2883, Proposed Standard, July 2000.

   [RFC3517] Blanton, E., M. Allman, M., K. Fall, K., and 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,"
             RFC-4306, Proposed Standard, Dec. 2005.

   [RFC-TBD]

   [ao-crypto] Lebovitz, G., "MAC Algorithms "Cryptographic Algorithms, Use, &
             Implementation Requirments for TCP-AO," RFC-TBD, date
             TBD. TCP Authentication Option",
             draft-lebovitz-ietf-tcpm-tcp-ao-crypto, Mar. 2009.

15.2. Informative References

   [Be07]    Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem
             Statement and Requirements for a TCP Authentication
             Option," draft-bellovin-tcpsec-01, (work in progress), Jul.
             2007.

   [Bo07]    Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler,
             "Authentication for TCP-based Routing and Management
             Protocols," draft-bonica-tcp-auth-06, (work in progress),
             Feb. 2007.

   [Go07]    Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp-
             attacks-04, (work in progress), Oct. 2008.

   [Je07]    Jethanandani, M., and M. Bashyam, "TCP Robustness in Persist
             Condition," draft-mahesh-persist-timeout-02, (work in
             progress), Oct. 2007.

   [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321,
             Informational, April 1992.

   [RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for
             High Performance," RFC-1323, May 1992.

   [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks,"
             RFC-1948, Informational, May 1996.

   [RFC2104] Krawczyk, H., M. Bellare, M., R. Canetti, R., "HMAC: Keyed-
             Hashing Keyed-Hashing
             for Message Authentication," RFC-2104, Informational, Feb.
             1997.

   [RFC2766] Tsirtsis, G., P. Srisuresh, P., "Network Address Translation -
             Protocol Translation (NAT-PT)," RFC-2766, Proposed
             Standard, Feb. 2000.

   [RFC3234] Carpenter, B., S. Brim, "Middleboxes: Taxonomy and Issues,"
             RFC-3234, Informational, Feb. 2002.

   [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
             Signature Option," RFC-3562, Informational, July 2003.

   [RFC3947] Kivinen, T., B. Swander, A. Huttunen, V. Volpe,
             "Negotiation of NAT-Traversal in the IKE," RFC-3947,
             Proposed Standard, Jan. 2005.

   [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet
             Protocol," RFC-4301, Proposed Standard, Dec. 2005.

   [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5,"
             RFC-4808, Informational, Mar. 2007.

   [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks,"
             RFC-4953, Informational, Jul. 2007.

   [Sa99]    Savage, S., N. Cardwell, D. Wetherall, T. Anderson, "TCP
             Congestion Control with a Misbehaving Receiver," ACM
             Computer Communications Review, V29, N5, pp71-78, October
             1999.

   [SDNS88]  Secure Data Network Systems, "Security Protocol 4 (SP4),"
             Specification SDN.401, Revision 1.2, July 12, 1988.

   [To06]    Touch, J., A. Mankin, "The TCP Simple Authentication
             Option," draft-touch-tcpm-tcp-simple-auth-03, (expired work
             in progress), Oct. 2006.

   [Wa05]    Wang, X., H. Yu, "How to break MD5 and other hash
             functions," Proc. IACR Eurocrypt 2005, Denmark, pp.19-35.

   [We05]    Weis, B., "TCP Message Authentication Code Option," draft-
             weis-tcp-mac-option-00, (expired work in progress), Dec.
             2005.

16. Acknowledgments

   Alfred Hoenes, Charlie Kaufman, and Adam Langley provided substantial
   feedback on this document.

   This document was prepared using 2-Word-v2.0.template.dot.

Authors' Addresses

   Joe Touch
   USC/ISI
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695
   U.S.A.

   Phone: +1 (310) 448-9151
   Email: touch@isi.edu
   URL:   http://www.isi.edu/touch

   Allison Mankin
   Johns Hopkins Univ.
   Washington, DC
   U.S.A.

   Phone: 1 301 728 7199
   Email: mankin@psg.com
   URL:   http://www.psg.com/~mankin/

   Ronald P. Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, VA  20171
   U.S.A.

   Email: rbonica@juniper.net