Skip to main content

The TCP Authentication Option
RFC 5925

Yes

Lars Eggert
(Magnus Westerlund)
(Ross Callon)

No Objection

(Dan Romascanu)
(Jari Arkko)
(Pasi Eronen)
(Robert Sparks)

Recuse

(Ron Bonica)

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

Lars Eggert Yes

(Magnus Westerlund; former steering group member) Yes

Yes ()

                            

(Ross Callon; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (2010-03-09)
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
s/implmentation/implementation/

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (2010-03-06)
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.

(Cullen Jennings; former steering group member) (was Discuss) No Objection

No Objection (2010-03-10)
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?

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Ralph Droms; former steering group member) No Objection

No Objection (2010-03-10)
Section 2.1, third para: s/TCP-AO not/TCP-AO is not/

(Robert Sparks; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (2010-03-10)
  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.

(Tim Polk; former steering group member) No Objection

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

(Ron Bonica; former steering group member) Recuse

Recuse ()