Summary

  • RFC 5374 extended IPsec to multicast groups, but a MAC made with a shared group key authenticates membership in the key-holding set—not the individual sender named by a packet.
  • Individual data-origin assurance needs a separate mechanism such as a digital signature or TESLA; authenticating the GCKS likewise remains distinct from authorizing the groups and traffic selectors it may control.
  • Preserved outer addresses, successful IPsec processing and multicast routing are structural receipts. They do not prove a human author, trustworthy content, reception by every member or application outcome.

One green check covered a set, not a person

Unicast habits make a shared MAC look more specific than it is. Between two parties, a valid tag can be evidence that the other holder produced the message. In a multicast group, every admitted member may possess the authentication key. Every one of them can calculate a tag that every other member will accept.

RFC 5374 therefore distinguishes group-source authentication from data-origin authentication. The first establishes that traffic was protected by the group's shared state and was not altered without detection by an outsider lacking that state. It does not distinguish Alice's sender from Bob's compromised receiver if both hold the key.

This is not a defect hidden in an implementation. It is a property of the trust model. Recording a source IP beside a valid group MAC may identify the address carried by the packet, but an admitted insider can forge a peer-looking transmission. The audit statement must remain scoped: “valid under group SA X” is defensible; “sent by device Y” needs more evidence.

The limit becomes sharper as the group grows. RFC 5374 says the service is no stronger than the weakest member admitted by group key management. One compromised endpoint can disclose the group secret, leak protected data or create traffic that appears to originate from another member. Cryptographic acceptance cannot repair a poor admission decision after the fact.

Individual origin was a second service

When the application truly needs to know which Group Sender generated a packet, RFC 5374 points to mechanisms whose verification is not shared symmetrically across the whole group: digital signatures or TESLA. A receiver can then evaluate an origin claim that another ordinary member cannot reproduce merely by knowing the common group key.

That stronger proof has cost. Signature verification can be expensive enough to create a denial-of-service surface. The RFC describes nesting: an outer AH or ESP layer using a cheap shared MAC can reject unauthenticated outsiders before the packet crosses the IPsec boundary again for the more expensive origin check. The two successful checks still answer different questions.

The outer tag says the packet carries a credential available to the admitted group. The inner mechanism can bind it to a particular sender key or timed disclosure chain. Neither says the payload is accurate, that the sender had business authority for the instruction, or that an application accepted it. Content approval lives above packet origin.

Replay is another independent dimension. Multiple senders ordinarily require separate SAs so each has its own anti-replay state. A group may share one SA among senders only when it does not rely on IPsec anti-replay. At large any-source scale, maintaining state for every possible sender may be impractical; the RFC sends such requirements toward an application-layer protocol capable of rejecting replays. A valid current MAC is not automatically a unique, fresh act by one principal.

The controller was authenticated, then confined

RFC 5374 introduced the Group Peer Authorization Database because controller identity was not enough. A GPAD entry says which GCKS identities are trusted, how they are authenticated, which Group Identifiers they may administer and which source/destination traffic-selector ranges their policy may assert.

During registration, the member first locates and authenticates the asserted GCKS identity. Before presenting a Group Identifier, it confirms that the same local entry authorizes that controller for the group. When policy arrives, the member compares every proposed flow with its authorized ranges. Policy outside the local envelope is discarded, and the reason should enter the audit log.

This is a clean authority chain. A certificate proves control of a credential under a trust anchor. The GPAD decides the credential's jurisdiction on this device. A GKM message proposes policy. The local comparison accepts or rejects each flow. Collapsing those steps into “controller authenticated” grants a management plane more power than the architecture assigned it.

The distinction also protects delegation. A large operator can use different controllers for different groups without turning any one controller into a universal source of IPsec policy. Rotation of the credential need not silently expand the traffic ranges. A member can retain a narrow, reviewable mandate even when the group-key protocol changes.

Address preservation kept routing legible

Ordinary tunnel mode writes tunnel endpoints into the outer IP header. Multicast routing needs the destination group to remain visible, and source-specific trees or reverse-path checks may also depend on the original source. RFC 5374 therefore defined tunnel mode with address preservation: copy the inner destination, and where policy requires it the source, into the outer header.

On reception, an implementation must compare each preserved outer value with the corresponding inner value. A mismatch is discarded and treated as auditable. That check proves an encapsulation invariant: the protected packet did not claim one routed group outside and deliver a different protected group inside.

It does not prove ownership of the source address, the identity of a human sender or reception by a downstream application. Address preservation can even deprive a gateway of ICMP Path MTU messages aimed at itself because the outer source names the original sender instead. Routing compatibility has operational trade-offs; it is not an identity credential.

The SSM locator case shows why evidence must remain time-bound. NAT, mobility or multihoming may change a sender's source address. The stored GSPD selector can become stale. In the worst case, traffic from the new address could match BYPASS at a gateway and leak group data. RFC 5374 recommends default DISCARD for unauthorized sources to that SSM destination. A previously authorized sender is not authorization for every later locator.

Routing membership and cryptographic membership stayed separate

An IGMP or MLD join tells multicast routing that receivers exist behind an interface. It can trigger group-key registration policy, but it is not itself an authenticated application membership grant. RFC 5374 even notes that an unauthenticated message on a protected interface can cause an early receiver registration once.

Conversely, possession of group IPsec state does not prove that every multicast branch delivered the packet. Intermediate routers need not participate in IPsec. A compromised router can still corrupt or delete downstream traffic, and flooding remains possible. The security boundary protects packet processing at participating endpoints; it does not turn best-effort distribution into a receipt system.

Directionality also resists unicast assumptions. The GSPD can mark policy sender only, receiver only or symmetric. A receiver's permission to decrypt does not imply permission to transmit. A sender's membership does not imply that it should receive group data. Logs that store only “member” erase the role used in the authorization decision.

Evidence boundary

A defensible multicast record keeps these claims apart:

  1. the GCKS identity and authentication evidence;
  2. the local GPAD entry, group identifier and authorized selector envelope;
  3. the exact policy proposed, accepted or rejected, plus the reason;
  4. sender-only, receiver-only or symmetric role;
  5. GSA, SA, SPI, algorithm, key epoch and anti-replay configuration;
  6. group-MAC verification as evidence of shared-key possession;
  7. any distinct signature or TESLA evidence for individual origin;
  8. inner and outer address values and the address-preservation comparison;
  9. multicast routing observations, receiver reports and application acknowledgements as separate events;
  10. content approval and business consequence under their own authorities.

The narrow conclusion is valuable precisely because it is modest. RFC 5374 made secure group traffic possible without pretending that one shared secret could become nine individual signatures.