GDOI: Why the Key Server Is Not on Your Data Path

The group key server distributes policy and keys to members, and the members protect the traffic themselves. That sentence sounds like a formality until a design treats the controller as a relay for every protected packet, at which point the topology grows a hop it never needed and the traffic path depends on a device that was only ever meant to hand out state. Saying where the key server sits and where the data flows are two different diagrams, and GDOI is built around that difference. Getting it backwards is not a small modelling error, because it changes what you monitor and what you scale. The sections below follow the protocol's own split.

Two kinds of security state

RFC 6407 defines the member's pull exchange for requesting policy and keying material, and a push exchange that distributes policy and key updates to authorized members. Both manage security associations. Neither is the application's data stream, so a successful exchange proves the control channel worked and nothing else. A member can register cleanly, hold valid keys, and still fail to protect or forward traffic if its data policy is wrong. The two failures look nothing alike once you know which exchange carries them.

The standard also names a rekey security association that protects key-update messages, separate from the data-security associations that describe how members protect traffic.

Follow the exchanges, not the diagram

Look at what each message is for. A registration tells the controller which member is asking and establishes state; a rekey tells members that policy or keys have changed; protected application traffic then flows between members using the installed data-security association. The controller's address appears in the first two and need not appear in the third at all.

That is why an interface diagram drawn by physical adjacency misleads here. The controller's interface is a control source, not automatically the next hop for every encrypted packet.

Three records worth keeping

Write down the member's authenticated registration and the control source it can reach, the path that delivers subsequent key updates, and the routes and attachments that carry protected application traffic. Three records, three owners, and a failure in any one of them produces a different symptom. A member that registers and then never receives an update looks identical to a member that registered with stale policy, unless you have both records.

Keep these beside the configuration rather than in someone's memory. Membership changes are infrequent enough that the reasoning is always gone by the time it is needed.

Interface, service attachment, processing path

On a services-based gateway there is a further distinction: the physical underlay address is not the same thing as the local service attachment, and the platform's implementation decides how traffic reaches its IPsec processing path. Moving a service onto a physical interface or adding unrelated translation because an error message mentioned a service-interface rule is a guess dressed as a fix.

Read the platform's own documentation for how the service attachment receives traffic. The mechanism is vendor-specific even when the protocol is standard.

Standardized protocol messages also do not establish cross-vendor compatibility. Compare required features, policy and association attributes, authentication method, and the exact platform and release before assuming two implementations will interoperate.

Control availability and data forwarding are separate checks

Plan controller reachability for ordinary operation, for membership changes, and for key updates. An application exchange that succeeds on already-installed state does not prove the next registration or rekey can reach the member, and the gap typically appears hours later as a tunnel that stops accepting new members. Test a fresh registration, not just a working session.

Then test forwarding separately, with the controller out of the picture. Two checks, two results, and a much shorter argument about which half is broken.