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

[Ballot comment]
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.

[Ballot comment]
[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.

[Ballot comment]
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 ]==

[Ballot comment]
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.

[Ballot comment]
The datatracker state does not indicate consensus 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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-tcpm-ao-test-vectors-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-02-01):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tcpm-ao-test-vectors@ietf.org, martin.h.duke@gmail.com, michael.scharf@hs-esslingen.de, tcpm-chairs@ietf.org, tcpm@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (TCP-AO Test Vectors) to Informational RFC


The IESG has received a request from the TCP Maintenance and Minor Extensions
WG (tcpm) to consider the following document: - 'TCP-AO Test Vectors'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-02-01. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document provides test vectors to validate implementations of
  the two mandatory authentication algorithms specified for the TCP
  Authentication Option over both IPv4 and IPv6. This includes
  validation of the key derivation function (KDF) based on a set of
  test connection parameters as well as validation of the message
  authentication code (MAC). Vectors are provided for both currently
  required pairs of KDF and MAC algorithms: one based on SHA-1 and the
  other on AES-128. The vectors also validate both whole TCP segments
  as well as segments whose options are excluded for middlebox
  traversal.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-ao-test-vectors/



No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Michael Scharf .

The responsible Area Director is Martin Duke .

This document provides test vectors to validate implementations of the TCP Authentication Option (TCP-AO) over both IPv4 and IPv6. With the test vectors multiple TCP-AO implementations can be validated against each other to ensure interoperability.

The TCPM working group requests publication as Informational RFC, as indicated on the title page.


2. Review and Consensus

This document has been reviewed by several contributors in the TCPM working group and is considered ready for publication. The WGLC has passed successfully without any comments.

As TCP-AO is in particular relevant for routers, the document is only of interest to a small subset of the TCPM working group. As a result, there has been less working group discussion than for other documents. Nonetheless, there has always been strong consensus in TCPM that documenting test vectors is useful for those implementers that need TCP-AO. And there has never been any controversy regarding the content of this informational document.

Tests with several different closed source TCP-AO implementations have been reported by the authors. This should ensure that the test vectors are indeed correct.

There have also been recent announcements of further planned TCP-AO implementations, including open source code. As a result, the publication of test vectors is very timely work.


3. Intellectual Property

Each author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

There are no IPR disclosures.


4. Other Points

Idnits reports that private range IPv4 addresses are used instead of documentation addresses according to RFC 6890. Yet, this seems appropriate as actual TCP-AO validation tests would typically indeed use private addresses.

1. Summary

The document shepherd is Michael Scharf .

The responsible Area Director is Martin Duke .

This document provides test vectors to validate implementations of the TCP Authentication Option (TCP-AO) over both IPv4 and IPv6. With the test vectors multiple TCP-AO implementations can be validated against each other to ensure interoperability.

The TCPM working group requests publication as Informational RFC, as indicated on the title page.


2. Review and Consensus

This document has been reviewed by several contributors in the TCPM working group and is considered ready for publication. The WGLC has passed successfully without any comments.

As TCP-AO is in particular relevant for routers, the document is only of interest to a small subset of the TCPM working group. As a result, there has been less working group discussion than for other documents. Nonetheless, there has always been strong consensus in TCPM that documenting test vectors is useful for those implementers that need TCP-AO. And there has never been any controversy regarding the content of this informational document.

Tests with several different closed source TCP-AO implementations have been reported by the authors. This should ensure that the test vectors are indeed correct.

There have also been recent announcements of further planned TCP-AO implementations, including open source code. As a result, the publication of test vectors is very timely work.


3. Intellectual Property

Each author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

There are no IPR disclosures.


4. Other Points

Idnits reports that private range IPv4 addresses are used instead of documentation addresses according to RFC 6890. Yet, this seems appropriate as actual TCP-AO validation tests would typically indeed use private addresses.