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

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-bounces@ietf.org [mailto:ipsec-bounces@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