The TCP Authentication Option
RFC 5925

Note: This ballot was opened for revision 11 and is now closed.

(Ross Callon) Yes

(Lars Eggert) Yes

Magnus Westerlund Yes

(Jari Arkko) No Objection

(Ralph Droms) No Objection

Comment (2010-03-10 for -)
No email
send info
Section 2.1, third para: s/TCP-AO not/TCP-AO is not/

(Pasi Eronen) (was Discuss) No Objection

(Adrian Farrel) No Objection

Comment (2010-03-09 for -)
No email
send info
Thanks for this document. General sigh of "at last" :-)

A few small wrinklettes...

ISN is used in Section 1 without expansion.
(although it is subsequently expanded multiple times)


Section 4.2

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

"MUST be consistent" is a little vague. I can only assume that you 
mean that the length must not imply that the option extends beyond the
end of the header as specified by the header length.


MKT is used in Section 4.2 without expansion or reference.
Add a forward pointer to 5.1?


Semantic tautology.

I think the phrase "TCP-AO option" may include some redundancy.
Cf. the header to Section 4.2.


Section 9.1

(Russ Housley) (was Discuss) No Objection

Comment (2010-03-10)
No email
send info
  The Gen-ART Review by Wassim Haddad on 2010-03-09 included some
  editorial comments.  Please consider them if an update to this
  document is needed for any reason.

(Cullen Jennings) (was Discuss) No Objection

Comment (2010-03-10)
No email
send info
Give this disables much of ICMP, particularly destination unreachable, would it be worth mentioning in the applicability statement of situations when it was not appropriate to use it or timing consideration changes that needed to be made to applications using it?

(Alexey Melnikov) (was Discuss) No Objection

Comment (2010-03-06)
No email
send info
4.2. The TCP-AO Option

   o  RNextKeyID: An unsigned 1-byte field indicating the MKT that the
      sender is ready use to receive authenticated segments, i.e., the

"ready use to receive"?

      desired 'receive next' keyID.

14. IANA Considerations

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

I don't think this note is correct, the section is non empty.

(Tim Polk) No Objection

Comment (2010-03-11 for -)
No email
send info
I support the discuss positions regarding the conformance language ("MUST support") for
implementations of TCP.

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

(Ron Bonica) Recuse