13. Migration / Roaming

PALISADE supports limited session migration to preserve session continuity across network path changes. Migration is an opportunistic optimization and does not provide seamless mobility guarantees. Implementations MUST treat migration as best-effort behavior and MUST NOT assume reliable delivery, ordering, or success.

PALISADE defines two migration modes:

• Soft Migration — In-tunnel migration while the existing cryptographic session remains active
• Hard Migration — Resumption-based migration when the existing path is no longer usable

13.1 Migration Principles

Migration in PALISADE is governed by the following principles:

• Migration does not change cryptographic identity.
• Migration does not derive new keys.
• Migration does not reset replay windows.
• Migration MUST NOT weaken authentication, replay protection, or key separation.
• Migration events MUST be indistinguishable on the wire with respect to cause.
• Rekeying and migration are orthogonal mechanisms.
• CTRL_MIGRATE and related migration frames MUST NOT be accepted in early data. Migration frames received with epoch_id=0xFFFFFFFF MUST be ignored. See Section 12.8 for early data allowlist.

Rationale: Migration causes durable state changes (path binding). Early data is replayable and must not cause durable state changes (see Section 12.8, O2).

13.2 Soft Migration (In-Tunnel)

Soft migration is used when encrypted packets are still successfully exchanged and the peer's cryptographic state remains valid.

Soft migration is signaled using an encrypted control frame transmitted within the existing session.

13.2.1 Migration Signaling

Soft migration is conveyed using a CTRL_MIGRATE control frame. The migration payload (ctrl_data) uses MigrateFrame as specified in Section 8.3.

The migration payload (ctrl_data) MUST use the following wire format:

MigrateFrame =
    migrate_nonce         (32 bytes)
    peer_epoch_observed  (4 bytes, uint32, big-endian)
    reason               (1 byte)
    reserved             (3 bytes)

Note: Field renamed from new_epoch_hint to peer_epoch_observed to clarify advisory nature.

Field requirements:

migrate_nonce

• MUST be generated using a cryptographically secure random number generator.
• Used for migration replay protection.

peer_epoch_observed

• Receipt of peer_epoch_observed MUST NOT by itself cause an epoch transition, key derivation, or replay-window advancement. This field is diagnostic context only.
• Permitted uses: Logging and metrics, challenge generation decisions, debugging information
• Prohibited uses: Epoch advancement, key precomputation based on hinted epoch, replay window modification

reason

• MUST be set to 0x01. All other values are reserved and MUST be rejected.

reserved

• MUST be set to zero on transmission and ignored on receipt.

The control frame:

• MUST be encrypted and authenticated like all other control frames.
• MUST NOT modify cryptographic keys.
• MUST NOT encode migration cause or context beyond the normalized reason value.

13.2.2 Validation Requirements

Upon receiving a migration control frame, the receiver MUST perform the following checks before acting on it:

Epoch Consistency

The enclosing packet's epoch_id MUST equal the receiver's current epoch.

Migration frames from previous epochs MUST be rejected.

Replay Protection

Migration frames are subject to the normal epoch/sequence anti-replay window.

Replayed packets MUST be rejected.

In addition, implementations MUST enforce nonce-based replay protection:

• The receiver MUST track the most recently accepted migrate_nonce
• A migration frame with a previously accepted nonce MUST be rejected

Reason Normalization

The reason field MUST equal 0x01. Any other value MUST be rejected.

If any validation step fails, the migration request MUST be ignored.

13.2.3 Migration Semantics

Migration MUST follow a two-phase model:

1. Upon receiving authenticated CTRL_MIGRATE from a new source address, set candidate_path but do not update primary_path
2. Promote candidate_path to primary_path only after: (a) receiving N authenticated packets from that path within window T, OR (b) successful PATH_CHALLENGE/PATH_RESPONSE exchange

Terms:

• candidate_path: Potential new path, not yet committed
• primary_path: Committed path for sending responses

Rationale: Single-frame binding allows delayed/reordered valid MIGRATE frames to flip paths. Two-phase model requires confirmation before commit.

If a migration request is accepted:

• The receiver MUST set candidate_path to the source address observed on the authenticated packet.
• The receiver MUST NOT update primary_path until promotion criteria are met.
• The receiver MUST NOT derive new keys.
• The receiver MUST NOT reset replay state.
• Any peer_epoch_observed value MUST be treated as advisory only and MUST NOT override the rekeying mechanism.

Soft migration updates transport-level addressing only.

Cryptographic state remains unchanged.

13.2.4 Concurrency and Rate Limiting

Implementations MUST ensure that migration processing does not destabilize session state:

• Only one migration operation per session may be processed at a time.
• Migration requests received while another migration is in progress MAY be rejected.
• Excessive migration attempts MUST be rate-limited.

Exact rate-limit thresholds and queuing behavior are implementation-defined, but implementations MUST prevent migration-based denial-of-service.

13.3 Metadata Leakage Considerations

Soft migration inherently reveals limited metadata:

• Observers may detect a change in network path.
• Observers may infer the timing of migration events.

However:

• Migration causes are indistinguishable on the wire.
• No application data or cryptographic material is exposed.

This leakage is inherent to path migration and cannot be fully eliminated without disabling migration entirely.

13.4 Hard Migration (Resumption-Based)

Hard migration is used when the existing network path is no longer usable (e.g., NAT mapping expiration, prolonged disconnection).

In hard migration:

• The client initiates session resumption from the new network path.
• The server validates the resumption ticket.
• A new cryptographic session is established.

Hard migration is equivalent to session resumption and follows all rules defined in Section 12.

13.5 Migration Mode Selection

Endpoints MUST select migration mode as follows:

• If encrypted packets can still be exchanged, soft migration SHOULD be attempted.
• If the existing path is unusable, hard migration MUST be used.
• Endpoints MUST NOT attempt soft migration if no authenticated packets can be delivered.

13.6 Security Properties

Migration in PALISADE provides the following guarantees:

• Authentication: Only authenticated peers can trigger migration.
• Replay Resistance: Migration frames are protected by existing replay mechanisms.
• Fingerprinting Resistance: Migration causes are normalized and indistinguishable.
• Key Safety: Soft migration never derives or weakens keys.
• Fail-Safe Behavior: Failed migration attempts do not compromise session integrity.

Migration does not bypass rekeying, replay protection, or authentication mechanisms and does not weaken PALISADE's security model.