| Internet-Draft | Applicability of TCP-AO for Securing NET | October 2025 |
| Bedford | Expires 4 April 2026 | [Page] |
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.¶
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.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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.¶
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.¶
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.¶
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:¶
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.¶
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.¶
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 [RFC5926] for required MACs/KDFs. Operators SHOULD prefer modern, efficient MACs consistent with implementation guidance.¶
Deployment notes:¶
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.¶
This document has no IANA actions.¶
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.¶
The author thanks reviewers and operators who provided early feedback on applicability and deployment considerations.¶