Summary

  • An LTP cookie is mutable, session-local state. Once a longer value is accepted, the old shorter value is no longer good, and a retransmitted segment must use the value current at retransmission time.
  • A cookie raises the cost of blind denial-of-service traffic but does not authenticate origin. LTP authentication can validate one of several AuthVals during key overlap, while key distribution, KeyID meaning and retirement remain outside RFC 5327.

A retransmission is a new security act

Picture an original segment leaving an engine just before a long contact gap. Its cookie is correct when it enters the link. During the delay, the peer extends that cookie by appending fresh random bits. A timer later causes the sender to retransmit the same protocol data.

The safe operation is not a byte-for-byte replay. RFC 5327 says the retransmission needs the cookie value correct at the time of retransmission, and notes that this can differ from the value used originally. The segment's payload may be unchanged while its security envelope must be rebuilt against a newer session state.

This detail matters because many systems treat a retry as evidence-free repetition: recover the stored packet, enqueue it again and preserve the original hash. That model is wrong when acceptance depends on mutable state. The audit record must distinguish payload identity from encoded-segment identity, original-cookie state from current-cookie state, and the cause of retransmission from the cause of rejection.

A receiver that silently discards the replay may be behaving exactly as specified. The old cookie was once valid but ceased to be good when the extended value became current. Without the transition history, operations can misdiagnose a correct rejection as corruption, remote instability or attack.

A good cookie is a prefix relation with a deadline

RFC 5327 does not define the cookie as a fixed token negotiated before data transfer. Either engine may introduce one at any time. After an allowance for communications delay, all segments in both directions for that session must carry a good cookie. Before that allowance expires, a receiver may still need to accept segments that could not yet have learned the value.

The implementation chooses the acceptable delay. That turns light time, contact scheduling and local policy into inputs to the security decision. A missing cookie at one instant may be an admissible in-flight segment; the same segment later may require silent discard. The packet alone does not contain the clock authority that separates those outcomes.

A cookie may be extended by concatenating random bits. A value is good if it starts with the stored cookie, or if it is a new value when no cookie has yet been seen. Once a longer value is accepted, the previous value is no longer good. This is not ordinary equality and it is not an unordered set of accepted tokens. It is a monotonic prefix transition.

The transition record therefore needs the predecessor, the appended portion or its protected hash, the actor that introduced it, the receive time, the calculated effective deadline and the first segments accepted under the new value. Saving only the latest cookie explains neither the grace decision nor a late retransmission failure.

Two engines can create two simultaneous obligations

Delay allows both peers to introduce an initial cookie before either sees the other's. RFC 5327 does not merge them. Once traffic catches up, subsequent segments carry two cookie extension fields, and sender and recipient cookies are checked independently.

Both values must be good after the relevant delay. The peer's initial cookie also has to arrive within a finite window, before the locally introduced cookie has propagated far enough that a second initial value can no longer be admitted. A model with one session_cookie column cannot represent this state.

Multiplicity matters elsewhere too. The LTP extension mechanism permits repeated tags in headers or trailers. Normalizing repeated fields into a map can overwrite the very instance that caused acceptance. An evidence system must preserve order, count, direction and the verification result for each instance.

This is a practical authority boundary. The receiver decides whether a newly observed value is a valid second initial cookie, an extension of known state or an incorrect prefix. That decision depends on locally calculated delay and previously stored observations. It should not be narrated as a fact created solely by the sender.

Silence does not identify the failed condition

After the grace condition, a missing or incorrect cookie is silently discarded. Silence is appropriate for resisting resource attacks, but it is weak diagnostic evidence. The sender sees no protocol message distinguishing a stale cookie, a missed extension, an expired grace window, malformed encoding, authentication failure or an unavailable peer.

Operational tooling must produce local counters without turning them into remote assertions. A receiver can report that it discarded a segment because the presented value failed its stored-prefix rule at a particular time. It cannot conclude from that event alone that the sender was malicious, that the link replayed traffic or that a specific operator failed to rotate state.

Likewise, a sender that times out after an unacknowledged retransmission knows only that its expected response did not arrive. It does not know whether the peer silently rejected the cookie, failed authentication, lacked the extension, was outside the contact window or never received the segment.

The useful incident timeline joins both sides when evidence becomes available: cookie transitions, calculated deadlines, segment hashes before and after rewrapping, silent-discard reasons, authentication results and contact opportunities. A single timeout label cannot substitute for that chain.

The cookie is not origin authentication

A hard-to-predict cookie makes blind traffic more expensive. It does not prove who extended the session state. RFC 5327 warns that without origin authentication, a man in the middle can extend an existing cookie and lock out the legitimate peer. The receiver would then reject the shorter legitimate value precisely because its state machine is working.

This is why the document recommends using cookies with authentication where lower layers provide neither integrity nor freshness. The two extensions answer different questions. The cookie asks whether a segment carries current session-local state. AuthVal asks whether the encoded segment verifies under a selected cryptographic context.

Neither question reaches application authority. A correct cookie and AuthVal do not prove that an operator approved the action carried by the payload, that the key remains authorized, that the engine maps to a claimed organization, that a Bundle reached its destination or that a mission objective succeeded.

RFC 5327 also says cookies do not outlast the LTP session. They are not a durable anti-replay database across sessions or restarts. Reusing the same higher-layer content in a new session requires new reasoning about identity and freshness; the old cookie cannot supply it.

A valid AuthVal can leave the key epoch unresolved

The authentication header contains an eight-bit ciphersuite and an optional KeyID represented as raw octets. The specification deliberately leaves the KeyID's interpretation outside scope. It could point into a deployment's key store, but the protocol does not say how the key arrived, who authorized it, when it became active or when it must be removed.

The first segment of an authenticated session must carry the auth header; later segments may omit it. Because loss of the first segment can leave the peer without context, implementations should repeat the header when bandwidth permits, and a retransmission of the first segment must include it. An observer who captures a later headerless segment cannot infer absence of authentication without the session history.

Key upgrade creates another bounded rule. A sender can protect one segment with old and new keys by including multiple auth extensions. The receiver must search and may deem authentication valid if any one AuthVal verifies. That supports overlap, but valid=true no longer identifies which key succeeded.

If the old key is still configured, every segment may verify even though the new key is absent, wrong or unknown. A rollover dashboard that records only overall success can therefore declare a new epoch healthy while traffic continues to rely on the key intended for retirement. Record the successful AuthVal instance, ciphersuite, KeyID, verifier context and policy state separately.

The inverse also matters. One failed AuthVal does not make the segment invalid if another verifies. Counting every failed candidate as an attack exaggerates expected overlap behavior. The decision is a set of per-instance results followed by an acceptance rule, not one undifferentiated cryptographic event.

Ciphersuite numbers are not security verdicts

RFC 5327 originally assigned HMAC-SHA1-80, RSA-SHA256 and NULL. NULL uses a hard-coded key and is explicitly described as a strong checksum rather than authentication, vulnerable to active attack. A syntactically correct 255 and matching AuthVal cannot be labeled authenticated merely because verification code returned success.

The IANA registry records numeric assignments. It does not attest that a ciphersuite is appropriate for a present risk, that a deployment negotiated it, or that a key is managed safely. RFC status and current registry state should be reported as provenance, not converted into claims of implementation fitness.

RFC 5327 is Experimental. It addresses specific LTP extension mechanics and notes that DTN key management was an open research question. Its discussion of HMAC-SHA1 reflected the document's publication context. A present deployment needs an explicit cryptographic and lifecycle assessment beyond repeating the RFC's original table.

Sources and evidence boundary

These sources establish protocol rules, registry assignments, publication status and surrounding security concepts. They do not establish a live implementation, configured key, attack, interoperability result, session history, destination receipt or application outcome.