Summary

  • RFC 3554 adapts IPsec and IKE to an SCTP association whose endpoints can use sets of addresses. Every address in the negotiated selectors must be validated; a successful Phase 1 identity check is not enough.
  • The decisive operational object is a versioned, authorized address set that remains identical across IKE negotiation, the Security Policy Database, the Security Association Database and actual SCTP path use.

Security systems prefer a single principal. Networks keep presenting them with sets. A multihomed SCTP endpoint can legitimately say, in effect, “all of these addresses are me.” IPsec then has to protect one association across several source and destination pairs without confusing convenience, identity and authority.

RFC 3554 was published in July 2003 as a Proposed Standard. Its immediate engineering problem was efficient: ordinary protocol and port selectors did not describe an SCTP association spread across independently placed addresses. Installing a separate policy for every source-and-destination pair could become expensive. A selector capable of carrying an address set was more compact.

Compactness, however, concentrates trust. The list becomes an authorization surface. If one member is wrong, traffic protected by a perfectly good SA can still travel to the wrong place.

An authenticated peer is not an authorized address set

IKE Phase 1 establishes who is at the other end of the negotiation under the accepted credential and policy. RFC 3554 says that result alone is insufficient. The responder needs evidence that the initiator is authorized to receive traffic at every address it includes in the Phase 2 selectors.

The distinction is easy to lose because identity and location often arrive together. A certificate may carry several subject alternative names. Several certificates may share one public key. An out-of-band rule may bind a peer to a collection of addresses. Each arrangement can supply useful evidence, but none makes “valid peer” a wildcard for any address the peer names.

The security consequence is direct. If any authenticated peer could add another peer's address, it could invite protected traffic onto a path it does not own. Encryption would not repair the routing decision. The wrong address would have entered before the cryptographic protection was applied.

An audit therefore needs two receipts: one for the authenticated peer and one for the authority of each address. The second should say which evidence was used, who evaluated it, its scope and lifetime, and which version of the address set it approved.

One association becomes several routable claims

SCTP represents a logical association, yet multihoming gives that association several locators. Those locators may not share a subnet or fit a range. A policy engine that sees only SCTP's protocol number and ports cannot infer which arbitrary addresses belong together.

The brute-force answer is one SPD entry for every pair. That preserves explicitness but creates a multiplication problem. Four local addresses and four remote addresses already produce sixteen combinations; growth on either side expands the matrix again. More entries also mean more installation, retirement and drift surfaces.

RFC 3554's suggested answer is an address-set selector in one SPD entry. It also changes how the SA should be found: any negotiated destination address, combined with the SPI and security protocol, must return the same SA. Conceptually the identity is the set, not the single destination used for the lookup.

This is where agreement can fragment in implementation. IKE may record the complete set while the SPD omits one member. The SAD may accept the primary address but fail a lookup on an alternate. SCTP may select a path that the policy layer never installed. A successful handshake says little about those projections unless each one has its own observable receipt.

The first proposal may be knowingly incomplete

At the start of Quick Mode, the initiator may not know the responder's complete address set. The responder is often the better authority for its own side of the association. RFC 3554 does not paper over that asymmetry.

It provides a correction path. If the proposed selectors are insufficient or inaccurate, the responder reverses roles and starts another Quick Mode exchange. It copies the relevant SA and selector state, then changes its own selector set to match reality. Implementations supporting SCTP are required to handle this reversal.

That is more than a retry. A retry repeats a proposition; this exchange repairs it. The first proposal, the responder's diagnosis, the selector delta and the final accepted set should therefore remain connected. If only the final IKE success survives, a reviewer cannot tell whether the initiator knew the right addresses, whether the responder corrected them, or whether an unexamined member passed through both rounds.

The ID_LIST payload created by RFC 3554 gives the protocol a way to carry several identification payloads as one selector. Nested lists are prohibited, keeping the shape bounded. But a well-formed list is only syntax. It does not prove completeness, ownership or installation.

Address changes reopen the authority question

The SCTP base document current in 2003 did not support changing the address set while an association was active. RFC 3554 nevertheless anticipated that capability and warned that mobility creates a redirection attack: an attacker can claim that an address it controls should join an existing association, then receive traffic sent on the new path.

Later RFC 5061 specified Dynamic Address Reconfiguration and authenticated control chunks. That later machinery is useful context, not retroactive proof about any deployment. It also illustrates why authentication of the change message is necessary but not sufficient.

An authenticated endpoint may still ask for an address outside its authority. A valid add-address request must lead to fresh per-address authorization, a new address-set version, synchronized policy and SA projection, and retirement of superseded selectors. Until the old and new states are reconciled, “update accepted” is not “transition complete.”

High change frequency also matters. RFC 3554 notes that a full Phase 1 and Phase 2 exchange can handle changed sets unless they change extremely often. That boundary is operational: fast churn can turn an occasional negotiation into a continuous control-plane workload and can shorten the window for proving which set was effective for any packet.

What a defensible receipt chain records

Start with the Phase 1 identity: credential, chain, authenticated name, key binding, policy domain, validation time and revocation state. Then enumerate the claimed addresses. For each member, preserve the evidence that binds the peer to that address and the decision that accepted or rejected it.

Record the SCTP association separately: endpoints, ports, verification context, local and remote address sets and an immutable set version. Preserve the initial Phase 2 proposal, every ID_LIST member, transforms, protocol and port selectors, SPI request and proposer.

If the responder corrects the proposal, keep the reversal as a derived transaction rather than overwriting the first. Store the list delta, validation results and final agreement. Then require installation receipts from the SPD and SAD. A useful SAD test repeats the lookup for every negotiated destination address and verifies that each resolves to the same expected SA.

Finally observe the data plane. Which destination did SCTP choose? Which SA protected the packet? Did the intended peer authenticate and decrypt it? Were non-members rejected? A successful packet on the primary path does not attest for dormant alternates. The negative test is part of the proof.

Adjacent standards do not collapse the layers

RFC 2960 supplied the SCTP base used by RFC 3554; RFC 4960 later replaced it. RFC 2401 and RFC 2409 supplied the contemporary IPsec and IKE architecture; RFC 4301 later revised IPsec architecture. Their status histories matter because this article does not report a current implementation profile.

RFC 2407 provides neighboring DOI and identification context. RFC 5061 provides later address-reconfiguration context. None of these documents proves that a named stack implemented RFC 3554, used an address-set SPD entry, validated all addresses or prevented a redirection. They define mechanisms and boundaries.

The bounded claim is nevertheless strong. RFC 3554 explicitly refuses to let an authenticated Phase 1 peer claim arbitrary addresses. Operations should preserve the same refusal after the handshake, through policy installation, association changes and traffic observation.

Evidence boundary

This Article names no operator, endpoint, vendor, certificate, address, security association, exploit, outage or affected user. It asserts no deployment rate, observed attack, measured overhead or production failure. The examples are protocol-derived possibilities and governance inferences.

Heng Lu's Running-Code Primacy and Minimum Initial Specification essays are disclosed editorial lenses. They motivate separating a published negotiation mechanism from deployed behavior and keeping the shared selector language small while local actors retain responsibility for authorization and outcome. They are not evidence of RFC authorship, intent or any network event.

The conclusion ends at the observable boundary: IKE can authenticate a peer and negotiate a syntactically valid SCTP address list. Only per-address authorization, consistent policy and SA projection, and path-level observation can show that every member was entitled to receive the traffic.

Sources