While re-reading the introductory paragraph in 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).
the part about "only applies to IKEv1" struck me as just plain wrong. Also, while this paragraph re-introduces the 4301-described SPD, it doesn't mention the SAD at all, and later the SAD just appears nearly out of nowhere. For better conceptual coverage here's a proposed replacement first paragraph for section 2.9: When an RFC4301-compliant IPsec subsystem receives an outgoing 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. How the IPsec subsystem explicitly interacts with IKE is beyond the scope of this document (see [PFKEY] for an example programming interface). IKE obviously must manipulate the Security Association Database (SAD) as it derives child SAs, but also, some implementations might update their SPD in connection with the running of IKE as well (for an example scenario, see Section 1.1.3). Thanks, Dan _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
