TCP-AO satisfies all the current requirements for a revision to TCP MD5, as summarized below [Ed07].
1. Protected Elements
A solution to revising TCP MD5 should protect (authenticate) the following elements.
This is supported -- see Section 5.1.
a. IP pseudoheader, including IPv4 and IPv6 versions.
Note that optional coverage is not allowed 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 9.2.
b. TCP header.
Note that optional port coverage is not allowed 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 9.2.
c. TCP options.
Note that TCP-AO allows the exclusion of TCP options from coverage, to enable use with middleboxes that modify options (except when they modify TCP-AO itself). See Section 9.
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 5.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 MKT IDs, 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 MKT). See Section 2.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 because the set of MKTs can be installed to match some connections and not others. Connections not
matching any MKT do not require TCP-AO. Further, incoming segments with TCP-AO are not discarded solely because they include the option, provided they do not match any MKT.
c. Require non-optional.
The option should be able to be specified as required for a given connection.
This is supported because the set of MKTs can be installed to match some connections and not others. Connections matching any MKT require TCP-AO.
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 2.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 7.6. The size of the option is intended to allow use with Large Windows and SACK. See also Section 1.3, which indicates that TCP-AO is 2 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 [RFC5926] and as noted in Section 5.1 of this document.
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 [RFC5926]. The KDF is also specified in [RFC5926]. The KDF input string follows the typical design (see [RFC5926]).
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 2.2. The use of a set of MKTs allows separate connections to use different
algorithms, both for the MAC and the KDF.
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 7.3, 7.4, and 7.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 SNE, which is reconstituted at the receiver using a demonstration algorithm that avoids the need for reordering (in Section 6.2).
e. Security parameter changes require key changes.
The option should require that the MKT 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.
Parameters change only when a new MKT is used. See Section 3.
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 an MKT management system.
a. Intraconnection rekeying.
The option should support rekeying during a connection, to avoid the impact of long-duration connections.
This is supported by the use of IDs and multiple MKTs; see Section 3.
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 6.1.
c. Automated and manual keying.
The option should support both automated and manual keying.
The use of MKTs allows external automated and manual keying.
See Section 3. This capability is enhanced by the generation of unique per-connection keys, which enables use of manual MKTs with automatically generated traffic keys as noted in Section 5.2.
d. Key management agnostic.
The option should not assume or require a particular key management solution.
This is supported by use of a set of MKTs. See Section 3.
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 7.3, 7.4, and 7.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 2.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 7.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 7.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 8.
f. "Hard" ICMP discard.
The option should allow certain ICMPs to be discarded, notably Type 3 (destination unreachable), Codes 2-4 (transport protocol unreachable, port unreachable, or fragmentation needed and IP DF field set), i.e., the ones indicating the failure of the endpoint to communicate.
This is supported - see Section 7.8.
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 3 and 9.