[[ This message has gotten no replies. I am far from a PF_KEY expert, and need to hear from the WG before proceeding. --Paul Hoffman ]]
At 4:34 PM -0500 3/2/10, Dan McDonald wrote: >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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
