Subject: [IPsec] IKEv2bis: Variant on issue #64 (PF_KEY text), plus better SAD intro

From: Dan McDonald <[email-masked]>
Date: Thu, 17 Dec 2009 10:28:17 -0500

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