Internet-Draft Applicability of TCP-AO for Securing NET October 2025
Bedford Expires 4 April 2026 [Page]
Workgroup:
TCP Maintenance and Minor Extensions (TCPM)
Internet-Draft:
draft-bedford-tcpm-ao-for-gnmi-netconf-00
Published:
Intended Status:
Informational
Expires:
Author:
K.W. Bedford
Juniper Networks

Applicability of TCP-AO for Securing NETCONF and gNMI

Abstract

This document analyzes the applicability of the TCP Authentication Option (TCP-AO) to secure TCP-based network management protocols, specifically NETCONF and gNMI. It describes deployment profiles in which TCP-AO provides per-connection integrity and peer authentication with low operational overhead, either as an alternative to or in combination with TLS/SSH. This document gives guidance on key management (e.g., static keys and operational "key chains") and documents expected behaviors and benefits. No new protocol bits are defined and there are no IANA actions.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 4 April 2026.

Table of Contents

1. Introduction and Motivation

The TCP Authentication Option (TCP-AO) [RFC5925] provides connection- oriented integrity and peer authentication for TCP segments with cryptographic agility [RFC5926]. TCP-AO has seen deployment primarily with routing/control protocols; however, its applicability to network management and telemetry protocols is under-documented.

This document specifies practical applicability guidance for using TCP-AO with two widely used TCP-based management protocols: NETCONF [RFC6241] (commonly over SSH [RFC6242] or TLS [RFC7589]) and gNMI (as specified by the OpenConfig community, see [OC-GNMI]). TCP-AO can be used: (a) as a lightweight hop-by-hop integrity mechanism when TLS/SSH are operationally impractical; or (b) in defense-in-depth alongside TLS/SSH to harden the TCP substrate against spoofed resets and option tampering.

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. TCP-AO Recap

TCP-AO (TCP option kind 29; see TCP specification [RFC9293]) protects selected TCP header fields, options, and payload using per-connection traffic keys derived from a Master Key Tuple (MKT). It supports algorithm agility and hitless rekey via KeyIDs, as specified in [RFC5925] and [RFC5926]. TCP-AO provides integrity and peer authentication only; it does not provide confidentiality. When confidentiality is required, it SHOULD be used in combination with an encryption mechanism such as TLS.

4. Limitations of Existing Solutions (TLS/SSH and IPsec)

TLS/SSH:

IPsec:

In contrast, TCP-AO offers a lightweight, hop-by-hop protection model with explicit per-connection association and zero-loss rekey semantics.

5. Applicability to NETCONF

NETCONF servers typically listen on TCP port 830 (SSH) or use TLS per [RFC7589]. Operators MAY deploy TCP-AO to protect the underlying TCP transport for NETCONF sessions when:

Guidance:

6. Applicability to gNMI

gNMI commonly runs over TCP with gRPC and often with TLS. Streaming telemetry subscriptions can be long-lived and bandwidth-efficient, but the control channel remains sensitive to spoofed resets and tampering on the TCP path.

Guidance:

7. Key Management and Deployment

Static keys vs. dynamic keys:

Algorithm selection:

Deployment notes:

8. Security Considerations

TCP-AO provides integrity and peer authentication at the transport layer and mitigates off-path spoofing, forged resets, and tampering with protected TCP options and payload. It does not provide confidentiality; when secrecy is required, AO SHOULD be combined with TLS. Key hygiene is critical: per-peer unique MKTs SHOULD be used, rotated regularly, and tracked operationally. Algorithm agility as defined in [RFC5926] SHOULD be maintained.

9. IANA Considerations

This document has no IANA actions.

10. Appendix A. Non-Normative Notes and Examples

11. Acknowledgments

The author thanks reviewers and operators who provided early feedback on applicability and deployment considerations.

12. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5925]
Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, , <https://www.rfc-editor.org/info/rfc5925>.
[RFC5926]
Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option", RFC 5926, , <https://www.rfc-editor.org/info/rfc5926>.
[RFC6241]
Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, , <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242]
Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, , <https://www.rfc-editor.org/info/rfc6242>.
[RFC7589]
Badra, M. and J. Schoenwaelder, "Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication", RFC 7589, , <https://www.rfc-editor.org/info/rfc7589>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC9293]
Eddy, W., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, , <https://www.rfc-editor.org/info/rfc9293>.

13. Informative References

[OC-GNMI]
Group, O. W., "gNMI Specification", GitHub repository, , <https://github.com/openconfig/gnmi>.

Author's Address

Kenneth Wignarajah Bedford
Juniper Networks
Basingstoke
United Kingdom