On the Use of Stream Control Transmission Protocol (SCTP) with IPsec
Extracted elements (18)
Rather than creating one SPD entry per source/destination address pair (which is straightforward but expensive), the preferred approach associates sets of addresses with source and destination selectors in each SPD entry. This accommodates SCTP's multi-homing without combinatorial SA explosion.
The ID_LIST ID type was introduced because IKE Phase 2 Quick Mode requires the Initiator to propose all Selectors upfront, but SCTP associations can span many address pairs. Without ID_LIST, each pair would require a separate SA negotiation, wasting time and memory.
Although SCTP does not currently support mid-association address modification, if it does in the future, a full Phase 1 and Phase 2 re-exchange is sufficient to update the IPsec selectors and SAs when the address set changes.
If an ID type included in an ID_LIST payload is invalid in the context it is used (e.g., an ID_FQDN during Quick Mode), the entire ID_LIST must be considered faulty and the Responder should signal a fault and stop processing, mirroring behavior for a plain invalid ID.
A lookup in the Security Association Database (SADB) using the triplet (Destination Address, SPI, Security Protocol), where Destination Address is any of the negotiated peer addresses, MUST return the same SA.
All addresses presented in Phase 2 selectors MUST be validated. Sufficient evidence must be presented to the Responder that the Initiator is authorized to receive traffic for every address in the Phase 2 selectors, derived from Phase 1 certificates or out-of-band means.
Conformant implementations MUST support encoding multiple Phase 1 IDs in the SubjAltName field of a certificate as an ASN.1 sequence, as the preferred method for authenticating multiple SCTP endpoint addresses.
ID_LIST IDs cannot appear inside another ID_LIST ID payload (no recursive nesting). Any ID type defined in RFC 2407 may be included, and each must carry a complete Identification Payload header.
If the proposed set of Phase 2 Selectors is inaccurate from the Responder's perspective, the Responder may initiate a new Quick Mode exchange with roles reversed. The new Initiator MUST copy SA and Selectors from the old Quick Mode and modify Selectors to match reality. All SCTP-supporting IKE implementations MUST support this.
IKE implementations MUST support the new ID_LIST ID type to efficiently negotiate multiple source and destination addresses for SCTP associations in Phase 2 (Quick Mode).
Multiple certificates MAY be passed during Phase 1 in multiple CERT payloads; if so, all certificates must contain the same key as their Subject since only one signature may be issued per IKE Phase 1 exchange.
The Next Payload field in any ID included inside an ID_LIST MUST be ignored by the Responder. The Protocol ID and Port fields of the enclosing ID_LIST Payload must be set to zero by the Initiator and MUST be ignored by the Responder.
A new IKE ID type, ID_LIST, is defined to allow recursive inclusion of IDs. An ID_LIST payload can contain multiple ID_IPV4_ADDR or other ID types to describe all addresses of an SCTP endpoint in a single Phase 2 exchange.
SCTP is treated as a standard transport protocol over IP when using AH or ESP. The SCTP transport protocol number (assigned by IANA) and SCTP source/destination port numbers serve as selectors in the Security Policy Database (SPD).
IANA assigned number 12 for the ID_LIST identification type in the 'IPSEC Identification Type' registry within the ISAKMP Identifiers table.
SCTP's multi-homing feature enables traffic-redirection attacks where an attacker claims an address for an existing SCTP session, allowing interception of traffic. IKE MUST validate all addresses attached to an SCTP endpoint via Phase 1 certificate validation or an out-of-band method to mitigate this threat.
The Responder in a Phase 2 exchange MUST verify the Initiator's authority to receive traffic for all addresses in the Initiator's Phase 2 selectors. Failure allows any valid Phase 1 peer to claim another peer's addresses and intercept their traffic.
The ID_LIST payload consists of a standard IKE payload header (Next Payload, RESERVED, Payload Length, ID Type, Protocol ID, Port) followed by a sequence of complete Identification Payload structures, each with their own header. Nested ID_LIST payloads are not permitted.