Summary

  • GAAP-25 requires confidential, integrity-protected encryption for encrypted Claims and explicitly rejects bare ChaCha20, yet the Marker says only that a record is encrypted—not who is entitled to claim an address.
  • Keyed and unkeyed nodes can become mutually invisible collision-detection populations; even a valid keyed Claim proves possession of acceptable key material, not ownership, authorization, or collision-free operation beyond the receiver’s view.

An encrypted packet arrives. Its integrity check passes. The receiver can read the Group Name, group address and timestamp, and it accepts the record into its local GAAP reasoning. In many systems, that green light would acquire more meaning than it deserves. “Authenticated” becomes “authoritative”; a sound message becomes a rightful claim.

The 25th revision of the Group Address Allocation Protocol draft does not make that leap. Its security changes are narrower and more valuable for being narrow. They protect a Claim against disclosure and undetected modification under a configured scheme. They do not establish title over a multicast address.

GAAP itself is deliberately light. An application hashes a Group Name to obtain a candidate address. If that address collides with a different name, it can try up to three further deterministic positions by appending 1, 2 or 3. The claimant sends an initial Claim, waits roughly one periodic interval, and then continues with periodic Claims. State is soft; release means simply stopping the Claims. The Datatracker record currently places the intended Experimental draft in IESG Evaluation, at AD Followup. Its revision history is a record of specification work, not proof of deployment.

That distinction matters because the draft says the decentralised hash-based method has not been deployed and its collision and scaling behaviour has not been measured. GAAP is a proposed coordination mechanism inside an administrative domain, not a global registry and not a production result.

What revision 25 actually secures

Revision 25 sharpens a security rule that was easier to misread in revision 23. An encrypted Claim must use a mechanism that provides confidentiality and integrity, such as authenticated encryption with associated data. ChaCha20 alone must not be used. RFC 8439 explains why the distinction matters: the stream cipher is one component of ChaCha20-Poly1305, while authentication is what detects tampering. Without it, malleability can turn a bit change in ciphertext into a controlled change in the decrypted address, timestamp or Group Name.

This is a real improvement. So are the requirements to avoid nonce reuse for a key across all senders, and for keyed receivers to reject unencrypted Claims. A deployment that has chosen the protected mode should not silently fall back to accepting an unprotected record.

But the protocol’s Marker is only an implicit encryption signal. It does not carry a universal algorithm negotiation, a public identity, a certificate chain or an authorization record. The encryption method, keys, record format, associated-data construction, nonce system and rekeying practice remain largely out of band. If decryption fails, the receiver discards the record. On the wire, a wrong key, an unknown mechanism, damaged ciphertext and deliberate manipulation can all end at the same closed door.

Encryption therefore creates a visibility boundary as well as a protection boundary. A keyed node rejects an unencrypted Claim. An unkeyed node cannot interpret the encrypted one. Put both populations on the same network and they can perform collision detection in parallel realities. Each may believe the address is uncontested because the competing Claim is invisible to it.

That is not a cryptographic flaw. It is a deployment fact. AEAD can tell a receiver that ciphertext was created by someone possessing acceptable key material and was not changed outside that authentication boundary. It cannot tell the receiver that every relevant operator shares the key, that the sender was entitled to make this allocation, or that no invisible population chose the same address.

A message can be valid while the allocation is not

GAAP’s collision test is intentionally mechanical: the same address paired with different Group Names constitutes a collision. The same name on the same address does not. The protocol does not adjudicate contracts, operating mandates, customer obligations or institutional ownership. Nor should a compact coordination protocol try to do so.

The same limitation holds inside the encrypted population. A shared key can exclude an outsider; it cannot stop a participant who already has that key from fabricating a plausible Claim. Timestamp comparison and deterministic tie-breaking can produce a protocol outcome, but they do not prove honest intent. The draft’s bounded local Bad Actor List is cautious for the same reason: network source addresses can be spoofed, and losing a timestamp contest is not evidence of wrongdoing.

RFC 1982 supplies serial-number arithmetic for bounded comparisons. RFC 8085 supplies UDP operational guidance. Neither converts packet validity into resource authority. The older multicast references—RFC 2365, RFC 5771, RFC 2730 and RFC 2909—document address scopes and earlier allocation mechanisms. The current multicast architecture and gap analysis in RFC 10019 and RFC 10028 explain why a lighter method is attractive. They still leave the operator responsible for deciding what evidence counts in its own environment.

This is the dividing line: cryptography can protect a statement; collision logic can compare visible statements; only an external authority model can decide who was allowed to make the statement.

The useful discipline is to keep the layers separate

Heng Lu’s argument for minimum initial specification and voluntary local evolution fits GAAP’s experimental posture. Start with a narrow coordination mechanism. Allow operators to learn. Avoid turning a preliminary technical convenience into a thick universal institution.

But minimalism works only if deployments name what the minimal protocol does not decide. Key issuance is membership power. Rekeying is revocation power. The set of nodes that can decrypt is the set whose collisions can be seen. A key server may therefore become the practical governor of the address pool even though GAAP has no such role in its packet format.

The companion doctrine of running-code primacy supplies the necessary test. Do not ask whether a record bears the reassuring label “encrypted.” Ask what the deployed receivers can actually see, what routers and applications actually accept, who can recover after a key failure, and which operator bears the consequence of a conflicting address.

BTW’s earlier article, “GAAP-23 fixes its address ranges but leaves convergence after partitions open”, examines a different failure boundary: equal Group Names can remain on different fallback addresses after a partition heals. Revision 25’s encryption language does not erase that question. More importantly, it reveals a separate one: participants can be logically partitioned by keys even while they share the same physical network.

GAAP-25 is better because it refuses weak encryption. It will be safer still when implementers refuse weak semantics. A verified Claim is a verified Claim. It is not ownership.

Sources