SNMP Profile for Deep Space

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 30 March 2027.¶

Copyright Notice

Copyright (c) 2026 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.¶

Table of Contents

1. Introduction

Deep space networks based on IP, as described in [I-D.ietf-tiptop-ip-architecture], contain routers, relays, and end nodes whose health and configuration must be monitored and managed. SNMP [RFC3410] is the most widely deployed IP network management protocol and its agents are small enough for constrained flight computers, which makes it a natural candidate for deep space network management. However, parts of its specifications' constants and mechanisms, and the defaults of common implementations, assume terrestrial round-trip times.¶

The key characteristics of deep space communications, the connectivity scenarios, and the derived requirements are described in [I-D.ietf-tiptop-usecase]. In summary, one-way delays range from 1.3 seconds (Moon) to 4-24 minutes (Mars) and beyond, links may be intermittent with scheduled contacts, and bandwidth is scarce.¶

2. Deployment Model: Managers on Earth, Agents in Deep Space

In the deployments considered here, the command generator and notification receiver (the manager, acting as the client) run on Earth, in a mission operations center. The command responder and notification originator (the agent, acting as the server) run on the remote assets in deep space: orbiters, relays, landers, rovers. The Earth-side manager is easy to modify, reconfigure, upgrade, restart. The deep-space agent is much harder to modify.¶

3. Cost of Operations in Round Trips

In deep space, the primary concern of a management operation is the number of round trips it needs if it is greater than 1RTT. Table 1 summarizes the minimum number of round trips for a single operation (e.g., a GetRequest read of one object, Section 4.2.1 of [RFC3416]), derived from the specifications in the sections that follow, for a "cold" manager that has no prior state for the agent and for a "warm" manager that has. Note that some code bases may require more RTTs if, for example, they separate engineID discovery and clock synchronization into two phases for SNMPv3/USM bootstrapping. Other implementations may attempt to calculate expected engineIDs or obtain local clock synchronization values for collaborating local stations, thus further minimizing the potential RTTs needed.¶

SNMP protocol operations imposes no timing constraints on the request/response exchange and leaves timeout and retransmission policy to the implementation. Common implementation defaults are for terrestrial Internet case. Two client-side requirements therefore apply to every version and are prerequisites for every row of Table 1:¶

• The manager's request timeout must exceed the number of round trips the operation needs times the maximum RTT of the mission (propagation plus any scheduled contact gap, as computed in [I-D.ietf-tiptop-usecase]), plus margin.¶
• Retries should be 0 on links whose loss is negligible or handled below IP, and otherwise retry spacing must be at least one RTT. Link model and loss patterns on deep space path are described in [I-D.ietf-tiptop-usecase].¶

4. SNMP versions

SNMP offers multiple versions of the protocol, with the most recent being SNMPv3 [RFC3411] that supports a number of new features, including support for multiple security models (see sections Section 6 and Section 7).¶

5. SNMPv2c

Community-based SNMPv2[RFC3416] has no handshake, no session state, and no time synchronization: a read or write is a single request/response exchange, and nothing in the specification bounds the interval between request and response. The protocol is therefore indifferent to path delay at any distance. Therefore, SNMPv2c is deep space ready without any protocol or agent change; the only required changes are the manager-side timeout and retry settings of Section 3.¶

However, SNMP communities in the SNMPv1 and SNMPv2c protocols are transmitted in cleartext and provide no integrity, or confidentiality (see Section 14). SNMP v1 and SNMP v2c have been declared as historic versions of the protocol, but are still used in practice, typically with older equipment."¶

6. SNMPv3 with the User-based Security Model (USM)

SNMPv3 [RFC3411] with USM [RFC3414] adds authentication and privacy without certificates or a transport handshake. A cold manager first performs the discovery procedure of Section 4 of [RFC3414] (one round trip) to learn the agent's snmpEngineID, snmpEngineBoots and snmpEngineTime, then issues the authenticated request (one round trip): two round trips cold, one warm.¶

USM's replay protection rests on a timeliness check: the receiver of an authenticated message rejects it as not in the time window if the msgAuthoritativeEngineTime it carries differs from the receiver's notion of snmpEngineTime by more than 150 seconds, a constant fixed by the specification (Sections 2.2.3 and 3.2 step 7 of [RFC3414]). Measurements show that the manager abandons after three round trips of retries (see Appendix A).¶

To be deep space ready, USM requires the timeliness window to be at least the maximum RTT of the mission (propagation plus scheduled contact gaps) for both agent and manager.¶

Because discovery costs one full round trip, managers should cache the agent's snmpEngineID, snmpEngineBoots and snmpEngineTime across requests and restarts, and should allow the engineID to be configured, reducing steady-state USM to one round trip per operation.¶

7. SNMPv3 with the Transport Security Model over (D)TLS

The Transport Security Model [RFC5591] over the TLS Transport Model [RFC6353] replaces USM's clock-based replay protection with transport security: DTLS [RFC9147] over UDP, or TLS over TCP. Since TCP is not practical in deep space [I-D.ietf-tiptop-usecase], only DTLS is discussed here.¶

Starting cold, the setup of TLS (ClientHello, ServerHello, Certificates, Key Exchanges, see Section 5.7 of [RFC9147]) uses 3 RTT (or 2 RTT for a previously established connection), and the contextEngineID discovery(Section 3.2 of [RFC5343]) uses 1 RTT. Then an SNMP request and response could be sent over the secured channel. Therefore, a real cold start costs 4 RTT before any SNMP transactions.¶

The retransmission timers of DTLS can be adjusted based on the application, as described in Section 5.8.2 of [RFC9147], and default to terrestrial values: 1 second. Timer values must be scaled to the maximum RTT of the mission.¶

The manager's session timeout for the first operation must either cover the full cold sequence: five (with the timer caveat above, six) times the maximum RTT, or not start the timeout timer until after the base DTLS session has been established.¶

No protocol change is required for correctness: with a session timeout budgeted as above and retries per Section 3, DTLS-protected SNMPv3 completes over a Mars-class scenario, as confirmed by the measurements (Appendix A). The following reduce the cost of RTTs if applicable to the mission:¶

• Session reuse (both sides): once established, each further operation costs one round trip, identical to SNMPv2c. Sessions should be kept alive for the duration of a mission phase, and session resumption should be supported and provisioned with lifetimes long enough to span contact gaps(Section 13). With effective session reuse the establishment cost is paid once per mission phase, not per operation.¶
• Cookie exchange (agent side, pre-launch): The protection offered (denial of service) may or may not be useful for some missions and costs one round trip.¶
• ContextEngineID probing (manager side): the probe of [RFC5343] exists to discover a value that a mission knows in advance. Managers should allow the agent's contextEngineID to be configured, eliminating the probe.¶

8. Engine Identifiers

SNMPv3 introduced a "snmpEngineID" protocol parameter allowing managers to access different aspects of an implementation, if needed. When managers are not sure of an agent's snmpEngineID, they can discover it either by assuming the SNMPv3 USM module's securityEngineID or through a discovery process [RFC5343].¶

Alternatively, it is possible to make an assumption about what a remote snmpEngineID might be based on, for example, a database look up or because the expected value is derived from an IP address or MAC address, which are two of the default methods that devices may use to create snmpEngineID values upon first boot. Because deep-space networking suffers from significant delays in round trip times, efforts should be made to minimize the discovery process, potentially by making an assumption on what the snmpEngineID value is likely to be. At best, this possibly reduces the number of round trips for bootstrapping SNMPv3 communication and in the worst case, this will only cause an extra round trip if the guess is incorrect.¶

Given highly managed missions, it is expected that in most cases, the discovery process will not be needed and that engineIDs will be statically configured prior to launch.¶

9. Notifications: Traps and Informs

SNMPv3 have two types of notification PDUs: TRAPs and INFORMs, while SNMPv1/2c has only TRAPs. TRAPs are one-way, unacknowledged transmissions. INFORMs are essentially the same as TRAPs, except that they are confirmed with acknowledgment response which allows a notification generator to resend a notification after a perceived delivery failure.¶

Unconfirmed notifications (TRAPs) are particularly well suited to deep space telemetry on near lossless networks: a TRAP costs a single one-way transmission, half the cost of any polled read, and tolerates any delay. Agents should be provisioned to push state changes as traps rather than relying on Earth-side polling for routine monitoring, consistent with the minimize-signaling requirement of [I-D.ietf-tiptop-usecase].¶

Confirmed notifications (INFORMs) cost one round trip and, under SNMPv3 with the USM, invert the authoritative roles: for a message that expects a response, the receiver is authoritative (Section 1.5.1 of [RFC3414]), so for INFORMs the (Earth-side) manager is the authoritative engine and the (deep-space) agent must hold a synchronized notion of the manager's clock. Under USM, the widened window is required on both sides for USM informs as well. Under TSM, INFORMs simply reuse the established (D)TLS session.¶

10. Proxies

Another feature of the SNMPv3 protocol relates to the use of the contextEngineID and its ability to be used in proxy operations for devices behind a fronting agent.¶

Essentially, the device’s default contextEngineID is used just to talk to the agent that the management station is communicating with over a particular IP address and transport. However, the contextEngineID can also be different than the main agent that a management station, but rather is an agent behind the fronting proxy agent. The fronting proxy agent must be configured to support prophesying communication to the other agents, potentially through the use of the SNMP-PROXY-MIB and its snmpProxyTable [RFC3413].¶

SNMP proxies are used somewhat frequently in networks today in order to proxy secure SNMPv3 protected communications between a management station and an agent without SNMPv3 support. By using a fronting proxy that is connected to a secured management network, a manager can talk with the proxy that transfers requests using an insecure protocol like SNMPv2c.¶

In deep space deployments, an additional advantage can be gained as it could achieve significant communication benefits by transmitting management commands through a proxy that is capable of proxying commands to the rest of the infrastructure around it. This will reduce or eliminate most of the round-trip overheads associated with communicating with a large number of distant agents, as only the round-trip bootstrapping is needed with the proxy agent. Furthermore, because the proxy itself can handle retries and retransmissions, it can significantly reduce round trips for lossy situations as well since the retries will be confined to short-distant terrestrial networks. However, note that the proxy agent must be a trusted device capable of passing sensitive commands and information. For many deep space deployments, proxies are placed at space edge on celestial body surface networks[I-D.ietf-tiptop-usecase].¶

11. Bulk Operations

High latency and low bandwidth environments, like deep space communications, require efficient protocol usage. When a mission prefers minimizing the number of packets and round trips, aggregating as much information as possible into single network management operations is possible in SNMP.¶

When fetching data from large sets of scalers, they should be combined into a single GET operation, or at least multiple GETs should be sent in parallel. When fetching data from remote agents, network managers should use GETBULK PDUs or the experimental Bulk Table Retrieval [RFC1187] method for fetching data from tables, which often have an unknown number of rows and values to fetch. Accordingly, implementations should allow for large SNMPv3 maxMsgSize settings to ensure efficient transfer of large datasets.¶

12. Implementation Requirements for Flight

Every delay-sensitive element identified in this profile is a constant or default in today's specifications and implementations. Implementations intended for deep space use, on either side, should expose all of the following as runtime configuration:¶

• request timeout and retry count/spacing (manager side; Section 3);¶
• the USM timeliness window (both sides; Section 6);¶
• the remote snmpEngineID / contextEngineID, to avoid discovery and probe round trips (manager side; Section 6, Section 7);¶
• DTLS handshake retransmission timer initial and maximum values (both sides; Section 7);¶
• the DTLS cookie exchange / HelloRetryRequest (agent side; Section 7);¶
• (D)TLS session and ticket lifetimes, long enough to span contact gaps and conjunction (both sides; Section 7, Section 13).¶

13. Applicability to the Deep Space Connectivity Scenarios

This section maps the profiles above to the connectivity scenarios of [I-D.ietf-tiptop-usecase]: Earth to cruising spacecraft (CS), Earth-Moon with full (LF) or intermittent (LI) connectivity, Earth-Mars with full (MF) or intermittent (MI) connectivity, and solar conjunction (SC).¶

Scenario notes:¶

• LF and LI: at a 2.6-second Moon RTT every version works with unmodified protocol machinery; only the timeout and retry settings of Section 3 need attention, and in LI they must cover the contact gap rather than the propagation delay. USM's 150-second window comfortably exceeds the Moon RTT, so USM is usable unmodified; this is the last scenario class where that is true.¶
• CS: the one-way delay grows continuously over the mission. Manager-side timeouts should be derived from the ephemeris rather than fixed. USM crosses its structural limit the day the mission RTT exceeds 150 seconds (about 0.15 astronomical units of round-trip light time); missions intending to use USM beyond that point must launch with a configurable or pre-widened window, per Section 2.¶
• MF and MI: SNMPv2c and, with the widened window on both ends, USM cost one to two round trips per operation. TSM/DTLS is correct but its cold establishment of five round trips is a very high price at 8-48 minutes per round trip; in MI, where a contact window may be shorter than a single round trip, a cold establishment spread across passes and buffering relays multiplies the calendar time further. DTLS at Mars distances is practical only where sessions are established once, especially at launch, and kept alive across the mission phase, and not recommended for ad hoc or frequently re-established management associations.¶
• SC: management traffic ceases for weeks. Traps generated during conjunction are queued by buffering relays per [I-D.ietf-tiptop-ip-architecture]. On resumption, SNMPv2c resumes trivially; USM resumes if the widened window also absorbs the blackout-induced staleness of cached engine time (or the manager re-discovers, one round trip); (D)TLS session tickets and session lifetimes must be provisioned to outlive the longest conjunction, or the mission pays the cold establishment again at maximum distance, its most expensive point.¶

14. Security Considerations

SNMPv2c provides no authentication, integrity, or confidentiality, therefore it is not recommended unless it is used where the layer below has adequate protection, such as end-to-end tunneling using IPsec[RFC4301] or QUIC[RFC9298], and if it fits the security requirements of the mission. Note that tunneling any version of SNMP, including SNMPv2c, over other protocols need to take further RTT analysis into account due to the bootstrapping of the outer layered tunnelling protocol.¶

If SNMP is only used to retrieve data from the agent, then it should be configured read-only.¶

Increasing the USM timeliness window (Section 6) widens the replay-acceptance interval by the same amount: an attacker who captures an authenticated request can replay it for up to the window duration. Implementations may partly compensate with request-ID checking and application-level idempotency of write operations.¶

TSM over DTLS provides the strongest protection of the three profiles, at a session-establishment cost. Long-lived sessions, required to amortize that cost, in turn increase the value of the session keys: mission key- and certificate-lifetime policies must account for sessions that may intentionally live for months, and certificate expiry and revocation checking must be workable without timely access to Earth-side infrastructure. These key/certificate lifetimes issues are discussed in [I-D.ietf-tiptop-ip-architecture].¶

15. IANA Considerations

This document has no IANA actions.¶

16. Acknowledgements

The following people have provided useful comments, prior to this draft, that helped shape this draft: Saumya Dikshit, Ran Atkinson.¶

Appendix A. Measurement Campaign Summary

A measurement campaign using VMs and an open-source SNMP implementation is backing the analysis of this document. Full inputs, exact commands, captured packets, per-run outputs and analysis are published at [deepspace_simulations] (scenarios S45 through S50). All scenarios used Net-SNMP 5.9.4 [NETSNMP], built unmodified from source. The single source modification used in the campaign (scenario S48) widened the USM timeliness window; a fork making that window a runtime option on both agent and manager is available [NETSNMP_FORK].¶

Authors' Addresses