Applicability of TCP-AO for Securing NETCONF and gNMI

Introduction and Motivation The TCP Authentication Option (TCP-AO) provides connection- oriented integrity and peer authentication for TCP segments with cryptographic agility . 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 (commonly over SSH or TLS ) and gNMI (as specified by the OpenConfig community, see ). 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.

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 when, and only when, they appear in all capitals, as shown here.

TCP-AO Recap TCP-AO (TCP option kind 29; see TCP specification ) 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 and . 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.

Limitations of Existing Solutions (TLS/SSH and IPsec) TLS/SSH:

Provide end-to-end confidentiality and rich authentication, but require PKI, certificate lifecycle management, and consistent trust-store operations across heterogeneous fleets.
Do not protect the underlying TCP control plane itself against certain transport-level disruptions (e.g., off-path resets or option tampering on unencrypted segments prior to keying).

IPsec:

Offers strong security properties but introduces per-SA policy management, NAT traversal considerations, and often coarser granularity (per-host/per-subnet) than operators desire for per-connection management channels.

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

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

TLS/SSH are unavailable or impractical (e.g., brownfield devices lacking PKI support), OR
Additional hardening of the TCP substrate is desired in defense-in-depth.

Guidance:

AO policies SHOULD be enforced only between authorized client and server peers (e.g., NMS subnets).
Operators SHOULD configure overlapping MKTs (key chains) to enable predictable, hitless rekeys for long-lived sessions.
Where confidentiality is required, AO SHOULD be combined with TLS/SSH; AO by itself does not encrypt management content.

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:

AO MAY be applied beneath gNMI (with or without TLS) to provide hop-by-hop transport integrity and to resist TCP control-plane disruption.
When TLS is used for confidentiality/authentication, AO provides additional assurance that TCP segments (including control flags and negotiated options) are authenticated.

Key Management and Deployment Static keys vs. dynamic keys:

Operators MAY deploy static MKTs (pre-shared keys) at moderate scale. To avoid outages during rotation, operators SHOULD use key chains with overlapping lifetimes and planned KeyID transitions.
TCP-AO does not define in-band key management; dynamic keying occurs out-of-band. Existing automation systems (e.g., via NETCONF/TLS or gNMI/TLS) MAY distribute and rotate MKTs securely.

Algorithm selection:

Implementations MUST follow for required MACs/KDFs. Operators SHOULD prefer modern, efficient MACs consistent with implementation guidance.

Deployment notes:

TCP-AO is not compatible with address/port translation; the peers' IP addresses and ports are part of the authenticated context.
TCP-AO slightly reduces available MSS due to option bytes; PMTUD SHOULD be verified on management paths.

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 SHOULD be maintained.

IANA Considerations This document has no IANA actions.

Appendix A. Non-Normative Notes and Examples

Example policy: require AO on TCP/830 (NETCONF) and the gNMI port from NMS subnets; maintain two MKTs with 24-hour overlap for monthly rotations.
Lab validation: capture AO presence with a packet analyzer (TCP option kind 29) and test negative cases (wrong KeyID, wrong MAC) to verify expected failures.

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