dscp46, aka isithran
dscp46, aka isithran
TCP/IP is known to perform poorly on conventional amateur packet radio links, notably due to retransmission and timing behavior that are incompatible with actual radio turnaround delay, especially on constrained channels (<= 1200bps).
As of today, and to the best of the author's knowledge, AX.25 does not define a security layer, to ensure traffic authenticity and integrity of conversations between endpoints.
KA2DDO has developed an APRS protocol extension to provide message authenticity and integrity. However, this mechanism is specific to APRS, and does not address the establishment or management of security associations.
The key words "MUST", "SHOULD", and "MAY" are to be interpreted as described in RFC 2119.
This document describes requirements and design considerations for providing authentication, integrity protection and replay resistance for AX.25 frames.
The following are explicitly out of scope:
Unlike APRS authentication extensions, the approach outlined in this document is not limited to APRS traffic and explicitly addresses the establishment of Security Associations at the AX.25 layer.
This document distinguishes between the open AX.25 environment and one or more Secure Domains. Security Functions operate at the boundary between these domains.
This document considers adversaries with the ability to interfere with AX.25 communications in the open AX.25 environment, including injecting, replaying, or modifying frames. In addition to external attackers, the threat model explicitly includes compromised or misconfigured endpoints located within a Secure Domain.
Attackers are assumed to be capable of:
In deployments where multiple endpoints reside on a secure domain, a compromised endpoint may be used as a pivot for lateral movement, including the injection of traffic, impersonating the security device, or other authenticated peers. Such attacks may occur even when cryptographic authentication mechanisms are correctly implemented, if network-level source address enforcement is insufficient.
This document therefore assumes that authentication alone is not sufficient to establish trust on a secure domain and that enforcement of source address integrity by the packet switching equipment (PSE) is required to mitigate impersonation and lateral movement threats.
In deployments where multiple endpoints reside on a secure domain, and one or more endpoints cannot establish a security association with that device, the PSE *MUST* enforce source address integrity to prevent the injection of traffic impersonating the security device.
Alternatively, peer identity information *MAY* be exchanged through a dedicated communication channel, such as a separate control plane, or a distinct KISS channel.
Upon successful authentication, the security function *SHOULD* configure the PSE to claim exclusive ownership of the authenticated peer's address. The PSE *MUST* drop ingress traffic of a claimed address originating from unauthorized ports, for the lifetime of the Security Association. The protocol to convey such configuration is out of the scope of this document.
In this publication, we outline a set of preliminary requirements for such a security protocol, including the following:
The protocol *MUST NOT* rely on a higher layer protocol.
Backward compatibility with existing AX.25/APRS digipeating infrastructure is considered a desirable, though non-mandatory, feature.
A key design trade-off involves choosing between:
The integrity of digipeated packets, whose critical fields (destination, source, encapsulated PID, encapsulated control, and payload) have not been altered *MUST* be considered preserved for the purposes of integrity verification regardless of any modification to the digipeating path.
The security layer *MUST* be integrable as a "bump in the wire", such that a security device can be transparently inserted between a data modem and a node that does not natively support the proposed AX.25 security mechanisms.
The security layer *MUST* support selective protection of traffic based on a configurable set of policy rules. For instance, a security function may block unauthenticated traffic to specific Callsign+SSID pairs, associated with management or control endpoints, while allowing other traffic by default.
The security layer *SHOULD* provide a protected endpoint, upon request, with metadata describing the current security state of a communication (e.g. unsecured, authenticated).
The security layer *MAY* share peer identity information with a protected node to enable implicit security association reuse, and reduce the number of required authentication handshakes across layers.
To comply with local regulations that supplement ITU RR 25.2A, confidentiality is deliberately left uncovered. Applications *SHOULD* handle specific cases (Over-the-Air provisioning/rotation of secrets, challenge-based authentication...) in a way that preserves the meaning of the conversation.
Security Associations are created as a result of a successful association establishment procedure, and are considered active only after all applicable security and enforcement checks have successfully completed. An SA is invalidated upon expiration, policy change, enforcement failure, or explicit teardown.
When authentication of a remote peer succeeds, but the security function is unable to enforce source address integrity for the associated Security Association (e.g. due to PSE limitations), or due to insufficient privileges, the security device *MUST* send a failure notification to the remote peer.
This notification indicates the authentication completed successfully, but that authorization, or network enforcement configuration has failed. In such cases, the Security Association *MUST NOT* be considered active for traffic protection. Traffic associated with such a Security Association *MUST* be discarded, or treated as unauthenticated according to the local security policy.
The security layer *SHOULD* provide replay protection mechanisms suitable for lossy and reordering AX.25 environments.
AX.25 control, PID and payload fields that are carried within a protected AX.25 UI frame, and are treated as opaque by intermediate digipeaters.
Any AX.25 communication domain in which frames may be injected, replayed, or modified by unauthenticated peers.
A logical AX.25 packet forwarding function that switches, forwards, or filters AX.25 frames between endpoints. A PSE may be implemented as a physical device, a software component, or a virtualized function, and may expose control interfaces to enforce traffic and source address policies.
A relationship between two entities, that describes how those entities will use security to communicate securely.
A table which contains all the active Security Associations for inbound and outbound traffic. Each entry will store the parameters for an individual SA.
A table which contains rules which determine whether or not a packet is subject to security processing. All traffic, including ingress and egress *MUST* be processed through this database. Actions are one of the following: DISCARD, BYPASS and PROTECT.
A set of AX.25 endpoints and functions that communicate over a restricted connectivity domain in which participation is controlled, and where some AX.25 frames cannot be injected by arbitrary external peers. A Secure Domain is distinct from the open AX.25 environment. Access control may be achieved through physical or logical separation, or administrative configuration.
A physical or virtual instantiation of a Security Function.
A logical function responsible for establishing or responding to Security Associations, maintaining the Security Association Database (SAD), and enforcing traffic security policies, including frame authentication, and integrity verification.
I'd like to thank François-Louis Zannettini for his helpful feedback on this document.
