I think the text proposed by Dan is OK (and it's more accurate about PF_KEY than the current text in -08).
Best regards, Pasi > -----Original Message----- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of ext Paul Hoffman > Sent: 16 March, 2010 18:53 > To: Dan McDonald; ipsec@ietf.org > Subject: Re: [IPsec] Still incorrect understanding of PF_KEY in > ikev2bis-08 > > [[ 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
