Skip to main content

Last Call Review of draft-ietf-tcpm-tcp-auth-opt-

Request Review of draft-ietf-tcpm-tcp-auth-opt
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-03-09
Requested 2010-02-25
Authors Dr. Joseph D. Touch , Ron Bonica , Allison J. Mankin
Draft last updated 2010-03-15
Completed reviews Secdir Last Call review of -?? by Radia Perlman
Assignment Reviewer Radia Perlman
State Completed
Review review-ietf-tcpm-tcp-auth-opt-secdir-lc-perlman-2010-03-15
Completed 2010-03-15
I have reviewed this document as part of the security directorate's

ongoing effort to review all IETF documents being processed by the

IESG.  These comments were written primarily for the benefit of the

security area directors.  Document editors and WG chairs should treat

these comments just like any other last call comments.

This protocol is essentially a lightweight special purpose version of the
Authentication Header (AH) protocol (RFC 4302). It is intended as a
generalization, improvement, and replacement of the TCP-MD5 protocol documented
in RFC2385. RFC2385 only proposed using TCP-MD5 for BGP, which had certain
unique requirements (like keeping a TCP connection up through crashes of one or
both endpoints). The proposal does not explicitly limit the applicability.

One question that leaps to mind is why there is both this and AH (not to
mention ESP).

The primary differences between TCP-AO and AH are:

TCP-AO can only be used to protect TCP connections (because the integrity
checksum is included in a TCP extension header).

TCP-AO only increases the packet length by 16 bytes with default crypto (AH
adds 24 bytes with default crypto).

While both are technically independent of any particular keying mechanism, AH
was designed to be keyed using IKE (RFC 4306) while TCP-AO was designed for
manual keying. In particular, TCP-AO includes an in-band protocol for signally
when a new key is available so that when new keys are configured at the two
ends of a connection, both ends will start using the new key only when it is
available at both ends.

Review of the document:

Section 4.2 under KeyID (and repeated in section 5.1 under IDs), the document
says that KeyID values are arbitrary. This is not quite true. The same KeyID
value cannot be used for two different valid keys. (So an implementation must
assure that all nodes have deconfigured or expired keys with a particular KeyID
value before assigning that KeyID value to a new key.

Section 4.2 also implies that the KeyID for the same master key used to
generate different encryption keys for the two different directions of TCP can
have different KeyIDs in the two different directions. That seems like a
useless generality.

Section 8.1 specifies how to choose the key to use in a next packet based on
the RNextKeyID in the last received packet. It does not specify how to choose
the key when starting a new connection (i.e. sending a SYN). I would assume
that there is some non-connection state saved on the node (and preserved across
crashes) that remembers the last RNextKeyID received on any connection, and
this is used to open new connections. The first time a connection is opened to
a node that has never successfully been connected to, the sender would cycle
through all valid keys until finding one the other end will accept. In any
case, the spec should say.

Section 8.2 paragraph 5 says the implementation of SNEs (extended sequence
numbers) is not specified in this document. This seems entirely unacceptable,
since the two ends must implement them identically for the protocol to work and
they aren't specified anywhere else. Further, it appears that they *are*
specified in the paragraphs that follow (though stated as an example rather
than a spec).

Sections 9.3-9.5 appear to be dealing with the case where one end of the
connection has been configured to use TCP-AO but the other has not. This should
probably be modeled as having a special "no authentication" key configured as a
valid key for the connection. The initiator would not use that key when sending
a SYN, but would switch to that key if he got an unsigned ACK from the other
end or he got an unsigned SYN from the other end. There is an implication that
existing implementations will ignore the TCP-AO extension if they don't support
TCP-AO. Is that true? (When in this mode, there is no security, but it is a way
to add initial keys to the two endpoints without breaking connectivity during
the period when one end has been keyed and the other has not. Once both ends
have received a correctly signed message from the other end, they should stop
accepting unsigned ones.

Section 10 says "TCP implementations MUST support TCP-AO". What does this mean?
Implementations of this spec MUST implement this spec. It is not reasonable to
expect *all* TCP implementations to support TCP-AO.

Section 11.2 suggests use of IPsec NAT traversal instead of TCP-AO if NATs are
present, but does not suggest how that would be negotiated. Or is this saying
that IPsec NAT traversal is preferred in any scenario where NAT traversal
*might* be needed?


Page 4 2nd to last paragraph: There is a badly structured sentence that could
be fixed in multiple ways. One way would be: "This document obsoletes the TCP
MD5 option with a more general TCP Authentication Option (TCP-AO). The new
design supports the use of other (stronger) hash functions, provides replay
protection for long-lived connections and across repeated instances of a single
connection, coordinates key changes between endpoints, and provides a more
structured recommendation for external key management."

Section 3 paragraph 3: "proceeding -> preceding"

Page 13 3rd to last line: "match at exactly" -> "match exactly"

Page 21 3rd to last line: "when is" -> "when it is"