[IPsec] Still incorrect understanding of PF_KEY in ikev2bis-08

[Dan McDonald <[e-mail]>]

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