Soft Migration (Tunnel Alive)

PALISADE v1.2 — Informative Appendix

This document describes the soft migration flow for PALISADE v1.2, which uses a two-phase candidate-commit model to safely update path bindings while preserving cryptographic state.

This diagram is informative and should be read together with the normative text of the main specification (Section 13). If a discrepancy appears, the normative text wins.

1. Two-Phase Migration Flow (v1.2)

PALISADE v1.2 uses a two-phase candidate-commit model to prevent delayed/reordered MIGRATE frames from causing path flips.

Client                                                Server
------                                                ------

             === ESTABLISHED on IP1:Port1 ===
             (Session identified by RID, not 5-tuple)

(Network change: IP1:Port1 → IP2:Port2)

[Encrypted packet with CTRL_MIGRATE frame]
  MigrateFrame payload (40 bytes):
    migrate_nonce (32 bytes)
    peer_epoch_observed (4 bytes, diagnostic only)
    reason (1 byte, normalized to 0x01)
    reserved (3 bytes)
  epoch_id (from EncryptedHeader)
  sequence (from EncryptedHeader)          ------->

                                         Phase 1: Set Candidate
                                         - Observe new source: IP2:Port2
                                         - Validate epoch matches current
                                         - Validate sequence (anti-replay)
                                         - Validate migrate_nonce (not seen before)
                                         - Validate reason = 0x01
                                         - Set candidate_path = IP2:Port2
                                         - Do NOT update primary_path yet
                                         
                                         Phase 2: Promote Candidate
                                         (Option A: Packet threshold)
                                         - Receive N authenticated packets
                                           from candidate within window T
                                         - Promote candidate → primary
                                         
                                         (Option B: Path challenge)
                                         - Send PATH_CHALLENGE to candidate
                                         - Receive PATH_RESPONSE
                                         - Promote candidate → primary

                               <-------  [Normal data packet or PATH_CHALLENGE]

             === ESTABLISHED on IP2:Port2 ===
             (Primary path updated, RID unchanged)

[Encrypted Data]               <------>  [Encrypted Data]

2. MigrateFrame Structure (v1.2)

The MigrateFrame is sent as the ctrl_data payload of a CTRL_MIGRATE control frame.

Field	Size	Description
migrate_nonce	32 bytes	Cryptographically random nonce for replay protection
peer_epoch_observed	4 bytes (uint32)	Diagnostic only - MUST NOT be used for epoch decisions
reason	1 byte	MUST be 0x01 (normalized to prevent fingerprinting)
reserved	3 bytes	MUST be 0x000000 on transmission
Total	40 bytes	Fixed size per PALISADE Spec Section 8.3

3. Validation Rules (Section 13.2.2)

The server MUST perform the following validation checks before accepting a migration:

Check	Requirement	Rationale
Epoch Consistency	Packet `epoch_id` MUST equal current epoch	Prevents cross-epoch replay attacks
Sequence Check	MUST pass anti-replay window check	Prevents short-term replay within epoch
Nonce Check	`migrate_nonce` MUST not have been seen before	Prevents duplicate processing of same migration
Reason Validation	`reason` MUST equal 0x01	Normalized to prevent fingerprinting
Early Data Check	MIGRATE MUST NOT be in early data (`epoch_id != 0xFFFFFFFF`)	Early data is replayable, migration causes durable state
Rate Limiting	Excessive migration attempts MUST be rate-limited	Prevents migration-based DoS attacks
Concurrency	Only one migration per session at a time	Prevents race conditions and state corruption

4. Candidate Promotion Criteria

The candidate path is promoted to primary only after meeting one of the following criteria:

Option A: Packet Threshold

Receive N authenticated packets from candidate path within time window T
Packets must pass normal decryption and replay window checks
Promotion occurs automatically when threshold is met

Option B: Path Challenge/Response

Server sends PATH_CHALLENGE control frame to candidate
Client responds with PATH_RESPONSE containing challenge data
Upon successful validation, candidate is promoted immediately
This accelerates validation for faster migration

5. Migration Principles (Section 13.1)

Migration does not change cryptographic identity (RID remains unchanged)
Migration does not derive new keys (same epoch keys continue)
Migration does not reset replay windows (sequence counters continue)
Migration MUST NOT weaken authentication, replay protection, or key separation
Migration events MUST be indistinguishable on the wire with respect to cause (reason normalization)
Rekeying and migration are orthogonal mechanisms (migration does not trigger rekey)
Session is identified by RID, not 5-tuple (enables NAT rebinding tolerance)

6. Hard Migration (Path Broken)

If the old path is no longer usable (e.g., extended network outage, NAT mapping expired):

Client                                                Server
------                                                ------

             === Path broken, no connectivity ===

(Network restored on new path: IP3:Port3)

ClientHelloResume:
  resume_ticket
  new_ephemeral_KEM_pub
  resume_nonce                                    ------->

                                         Validate ResumeTicket
                                         Extract PSK
                                         Derive new keys (resumption)
                                         Establish new session

                               <-------  ServerHelloResume:
                                           server_nonce
                                           CT'_c
                                           server_certificate
                                           server_signature

             === NEW SESSION ESTABLISHED ===
             (New RID, new keys, new replay state)

[Encrypted Data]               <------>  [Encrypted Data]

Hard migration requires a full resumption handshake and results in a new session with new cryptographic state.

PALISADE Protocol Specification Draft 00

INFORMATIONAL