TCP Authentication Option (TCP-AO) Test Vectors
draft-ietf-tcpm-ao-test-vectors-09

[S3.1, etc.; nit]

* I'm somewhat surprised that IETF standard documentation prefixes aren't
  being used (192.0.2.0/24, 2001:db8::/32).

  I do not feel strongly enough, however, to suggest that the examples need
  to be rewritten and the values recomputed.

[S3.1.4; nit]

* If these examples are typical of BGP sessions and GSTM (RFC 5082) is
  a typical BGP deployment practice I would have expected to see the IPv6
  hop limit in use also be 255, rather than 64.

  Again: no need to redo all the examples.

Thank you for making this document to help validate implementations.

Thank you to Christian Huitema for the SECDIR review.

I didn’t not validate all of the examples.

** Section 3.1.5.  Since ISNs are part of the context needed to make the traffic key (per Section 5.2 of RFC5925), should some statement be made about their values in these example packets?

** Given the observed implementation errors noted in Section 8, consider including a single detailed example per algorithm of how the appropriate traffic key and MAC would be computed in an appendix.  For example, considering Section 4.1.1, such a detailed example showing how to compute the traffic key could be:

(fixed format font required to read it)

==[ snip ]==
Master_key: "testvector" (74 65 73 74 76 65 63 74 6F 72)
KDF_Alg: KDF_HMAC_SHA1
IPv4/TCP Packet:

     45 e0 00 4c dd 0f 40 00 ff 06 bf 6b 0a 0b 0c 0d
     ac 1b 1c 1d e9 d7 00 b3 fb fb ab 5a 00 00 00 00
     e0 02 ff ff ca c4 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 00 15 5a b7 00 00 00 00 1d 10 3d 54
     2e e4 37 c6 f8 ed e6 d7 c4 d6 02 e7

Source IP (sip): 10.11.12.13 (0A 0B 0C 0D)
Destination IP (dip): 172.27.28.29 (AC 1B 1C 1D)
Source Port (sport): 59863 (E9 D7)
Destination Port (dport): 179 (00 B3)
Source ISN (sisn): FB FB AB 5A
Destination ISN (disn): 00 00 00 00


Send_SYN_traffic_key
= KDF_alg(master_key, input)
= HMAC-SHA1(master_key, i || Label || Context || Output_Length)

i = 1 (01)
Label= TCP-AO (54 43 50 2D 41 4F)
Context = sip || dip || sport || dport || sisn || disn
        = 0A 0B 0C 0D AC 1B 1C 1D E9 D7 00 B3 FB FB AB 5A 00 00 00 00
Output_Length = 160 bits (00 A0)


Send_SYN_traffic_key
= HMAC-SHA1 ( 74 65 73 74 76 65 63 74 6F 72,
              01 54 43 50 2D 41 4F 0A 0B 0C 0D AC 1B 1C 1D E9 D7 
              00 B3 FB FB AB 5A 00 00 00 00 00 A0 )
= 6d 63 ef 1b 02 fe 15 09 d4 b1 40 27 07 fd 7b 04 16 ab b7 4f
==[ snip ]==

Like many others, I have not actually validated all of the examples; this does, however, seem useful and I thank the authors and WG for their work on the document.

Thanks for the efforts here.

Should this specification still be referring (normative) to RFC793 while 793-bis is almost complete?

The datatracker state does not indicate whether to include the
consensus boilerplate for this document.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Terms "master" and "master_key"; alternatives might be "active",
   "central", "initiator", "leader", "main", "orchestrator", "parent",
   "primary", "server".

Thanks to Peter E. Yee for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/CHS1WZam2FsNmxLR2z9sutDZzj0).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License". The document boilerplate overall seems to be 10+ years out of date.