[tcpm] Roman Danyliw's Discuss on draft-ietf-tcpm-yang-tcp-07: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-tcpm-yang-tcp-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-yang-tcp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** B.2.  Thanks for providing an example of a TCP-AO configuration. 
Unfortunately, this isn’t a valid example example and it seems to be making
citations that don’t match.  Specifically:

-- “<crypto-algorithm>hmac-sha-256</crypto-algorithm>”

The algorithms usable by TCP-AO come from
https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-3.
 Only SHA1 and AES128 are registered.  As far as I tell, the only work to add
SHA256 is in an unadopted and expired draft
(https://datatracker.ietf.org/doc/draft-nayak-tcp-sha2/).

As aside, I think the algorithm name would have been SHA-256 or SHA256 (no
HMAC).

--    Per the link to RFC9235:

    The following example demonstrates how to model a TCP-AO [RFC5925]
   configuration for the example in TCP-AO Test Vectors [RFC9235].  The
   IP addresses and other parameters are taken from the test vectors.

RFC9235 doesn’t use SHA256; and uses KeyID 61 and 84.  Different KeyIDs are
used in this example.  Which parameters are being used from the test-vector?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Hilarie Orman for the SECDIR review.

I concur with the SECDIR observation that “there are no statistics kept for
authentication failures.  If a shared key falls out of synch, the statistics
might help detect that.”  I appreciate the response
(https://mailarchive.ietf.org/arch/msg/secdir/BnjVJ7_IgN7mSNaGi3H2ujVYvn0/)
which recommends that this should be generically modeled.  I disagree that this
should be deferred. There is a very specific TCP-level primitive being
described here and it makes sense to me to provide a corresponding logging
primitive.