| Internet-Draft | Bearer Handover | June 2026 |
| van de Meent & AI | Expires 23 December 2026 | [Page] |
This document describes identity-anchored bearer handover: a method for keeping a live, authenticated real-time media session (such as a voice call) running uninterrupted while the underlying network bearer changes - for example a device moving from Wi-Fi to cellular. The session is bound to a cryptographic identity and a media-encryption key, never to an IP address. When the bearer changes, the endpoint detects the new local address and emits an authenticated re-anchor over a stable control channel; the media path is re-established to the same cryptographic context, so the far end can relearn the new transport source without exposing the session to source-substitution (latching) attacks. No central media relay is required: a default-routed media anchor plus an authenticated re-anchor is sufficient. Each handover MAY emit a signed transport-rebind event for an auditable trail. This protocol is transport-agnostic and complements JIS [JIS], the MUX Status Frame [MUX], the Semantic Surface Manifest [SSM], and TIBET provenance [TIBET].¶
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 23 December 2026.¶
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.¶
Real-time media sessions break when the network bearer underneath them changes. A device that places a call on Wi-Fi and then leaves the coverage area moves to cellular; its IP address changes; the media stream, addressed to the old transport, stops. The signalling dialog may survive (if it rides a stable, address-independent control channel), yet audio is dead in one or both directions, and an in-dialog teardown sent over the now-defunct transport never arrives.¶
The common mitigation is a central media relay (for example TURN [RFC8656]): both endpoints send media to a fixed rendezvous, so a change of local address is absorbed by the relay. This works, but it reintroduces a central dependency in the media path - a single operator-run waypoint that sees, and can interrupt, every call. For a decentralized, identity-first system that is precisely the property to avoid.¶
This document takes a different anchor. The session is bound to a cryptographic identity and to the media-encryption key, not to the transport address. The transport is free to change; the key is the constant. On a bearer change the endpoint re-anchors the existing session onto the fresh transport over a stable control channel, and the encrypted media context continues. The maxim is: identity anchors, transport hops.¶
A correct handover mechanism must achieve all of the following at once:¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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.¶
An identity-anchored session is described by three independent planes:¶
Continuity is the property that the identity and control planes persist across a media-plane transport change. The session key is shared in the identity/control plane and is not renegotiated on a mere transport change; only the transport binding is refreshed.¶
When an endpoint in an active session detects that its default bearer or local transport address has changed, it performs the following:¶
Because the dialog's transport is refreshed (not just a parallel re-registration), an in-dialog teardown after the change travels over the live transport and reaches the far end, avoiding stuck sessions.¶
Permitting the far end to relearn the media source from a new address (symmetric source latching) is unsafe over unauthenticated media: an attacker who can send packets from a new address could capture the stream. This document REQUIRES that media be encrypted and authenticated (for example SRTP [RFC3711] or an equivalent AEAD media profile) for source relearning to be enabled.¶
With authenticated media, source relearning is safe: a substituted or injected stream fails the media authentication and is discarded, while the legitimate endpoint - which holds the session key - continues to verify. The key, not the address, is therefore the anchor. The session key-exchange material travels in the control plane (carried inside the authenticated, address-independent control channel), so a bearer change does not require a new key exchange.¶
A handover MAY be recorded as a signed control event so that the set of transport transitions for a session is auditable: who moved, between which bearer classes, at what point in the media sequence, signed by the moving device's identity key. Such events are an instance of a semantic surface manifest [SSM] and MAY be sealed into a provenance trail [TIBET]. A non-normative shape:¶
{
"type": "transport.rebind",
"session_id": "...",
"reason": "wifi_to_cellular",
"old_path": { "bearer": "wifi" },
"new_path": { "bearer": "cellular" },
"media_window": { "last_seq": 19420, "resume_seq": 19421 },
"auth": { "device": "jis:device:...", "signed_at": "..." }
}
¶
The signed event is a proof-plane artifact; it MUST NOT be required to carry media and MUST NOT gate the media handover itself. A failure to record the event MUST NOT interrupt the live session.¶
The same authenticated re-anchor MAY be invoked deliberately rather than only in response to a bearer change. Because the key is the anchor, rotating the media transport mid-session presents a moving target: an observer has no fixed transport binding to lock onto. Each deliberate re-anchor incurs the same brief media interruption as a bearer-driven one; this is a defensive option, not a default behaviour, and its cadence is an implementation and policy choice.¶
Source-substitution (latching): as stated in [RFC3711]-protected operation above, source relearning MUST be enabled only for authenticated media. Without media authentication, an endpoint MUST NOT relearn the media source from a new address mid-session.¶
Re-anchor authentication: a re-anchor request MUST be authenticated to the session's identity anchor over the control channel; an unauthenticated "move my media to address X" is an obvious hijack primitive and MUST be rejected. A failed authentication SHOULD be treated as an offence, not as a retriable transient, so the mechanism cannot be abused as a denial of service.¶
Privacy of transition metadata: a signed transport-rebind event reveals coarse bearer-class transitions (for example Wi-Fi to cellular). Such events SHOULD carry only bearer-class hints in any outward-visible surface and keep finer detail in the sealed manifest, consistent with [SSM].¶
Relay avoidance: by not mandating a central media relay, this method removes a single interception/interruption point from the media path. When a relay is unavoidable (for example endpoints behind symmetric NAT with no reachable anchor), it is a last-resort fallback and SHOULD be authenticated to the same identity anchor.¶
This document has no IANA actions.¶