Even as of draft-08, section 2.9: When an RFC4301-compliant IPsec subsystem receives an IP packet that matches a "protect" selector in its Security Policy Database (SPD), the subsystem protects that packet with IPsec. When no SA exists yet, it is the task of IKE to create it. Maintenance of a system's SPD is outside the scope of IKE (see [PFKEY] for an example programming interface, although it only applies to IKEv1), though some implementations might update their SPD in connection with the running of IKE (for an example scenario, see Section 1.1.3).
is entirely incorrect about PF_KEY. PF_KEY maintains the SADB and expresses the SPD and/or triggering packet when IPsec requires a new outbound SA. Some PF_KEY extensions (notably in any KAME/WIDE-derived implementations) also maintain the SPD. And it certainly is not applicable to just IKEv1 - it was intended to allow an ARBITRARY Key Management daemon to add/delete/etc. SAs. The PF_KEY SADB_ACQUIRE message is an expression of the SPD entry for the packet. So as not to just be a whiner, I will provide a replacement first two paragraphs: When an RFC4301-compliant IPsec subsystem receives an IP packet that matches a "protect" selector in its Security Policy Database (SPD), the subsystem protects that packet with IPsec. When no SA exists yet, it is the task of IKE to create it. Maintenance of a system's SPD is outside the scope of IKE, though some implementations might update their SPD in connection with the running of IKE (for an example scenario, see Section 1.1.3). Traffic Selector (TS) payloads allow endpoints to communicate some of the information from their SPD to their peers. These must be communicated to IKE from the SPD (for example the PF_KEY API [PFKEY] uses the SADB_ACQUIRE message). TS payloads specify the selection criteria for packets that will be forwarded over the newly set up SA. This can serve as a consistency check in some scenarios to assure that the SPDs are consistent. In others, it guides the dynamic update of the SPD. Thanks, Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
