Skip to main content

Telechat Review of draft-ietf-tcpm-yang-tcp-07

Request Review of draft-ietf-tcpm-yang-tcp
Requested revision No specific revision (document currently at 09)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2022-06-28
Requested 2022-06-23
Authors Michael Scharf , Mahesh Jethanandani , Vishal Murgai
I-D last updated 2022-07-23
Completed reviews Genart Last Call review of -06 by Stewart Bryant (diff)
Yangdoctors Early review of -06 by Ebben Aries (diff)
Opsdir Last Call review of -06 by Gyan Mishra (diff)
Secdir Last Call review of -06 by Hilarie Orman (diff)
Tsvart Last Call review of -06 by Gorry Fairhurst (diff)
Secdir Telechat review of -07 by Hilarie Orman (diff)
Opsdir Telechat review of -07 by Gyan Mishra (diff)
Assignment Reviewer Hilarie Orman
State Completed
Request Telechat review on draft-ietf-tcpm-yang-tcp by Security Area Directorate Assigned
Posted at
Reviewed revision 07 (document currently at 09)
Result Has issues
Completed 2022-07-17
                    Security review of 
A YANG Model for Transmission Control Protocol (TCP) Configuration

Do not be alarmed.  I generated this review of 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
with the intent of improving security requirements and considerations
in IETF drafts.  Comments not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

(This is a re-review, post -06, perhaps long overdue).

The document describes a YANG module for TCP connection attributes,
including authentication.

The TCP AO hash algorithms are described in RFC5926.  They include
a SHA-1 scheme and an AES scheme.  SHA-1, like MD5, is a broken
algorithm.  Although SHA-1 can still be used safely in the keyed
hash constructions of RFC5925, it is a security liability to
maintain it in a code base.  Similarly for MD5, and particularly the
way it is used per RFC2385.

While I realize that my recommendations amount to windmill tilting,
this is a security review, and bad algorithms in a code base are a
security issue, deriving new drafts based on flawed earlier drafts is
a generic IETF RFC problem.  It would be unfair to ask the authors of
this draft to change the TCP AO drafts, but someone should.

The document under discussion here should not support MD5, even at the
risk of failing to support legacy BGP.  That's a security opinion, not
a "we have to keep things running smoothly" opinion.

The document should also note that SHA-1 is not recommended.  The
provided example should use AES, not SHA-1.  Someone, someday, should
revise RFC5926 and get rid of SHA-1.

I do not know why there are no statistics about authentication
failures.  If a shared key falls out of synch or is subject to
injections attacks, the statistics might help detect that.