Subject: [IPsec] PF_KEY is NOT for IKEv1 only...

From: Dan McDonald <[email-masked]>
Date: Thu, 30 Oct 2008 12:07:24 -0400

While checking for the -00 vs. -01 diffs, I saw this:

   Added a note in 2.9 that PFKEY applies only to IKEv1.  Also added
   that unknown traffic selector types are not returned in narrowed
   responses.

And then I see this:

   Maintenance of a system's SPD is outside the scope of IKE (see [PFKEY] for
   an example protocol, although it only applies to IKEv1)

which isn't even CLOSE to accurate.

Some PF_KEY implementations do implement SPD manipulation.  PF_KEY was
specifically DESIGNED to be KM-protocol independent.  Witness Racoon2 as an
example IKEv2 that continues to use PF_KEY.

Dan
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Oct 2008 09:21:24 -0700

Entered as a new issue.

Proposed text would be appreciated.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dan McDonald <[email-masked]>
Date: Thu, 30 Oct 2008 12:29:35 -0400

> Proposed text would be appreciated.

Sorry for not giving you some off the bat.  How 'bout this:

	2.9  Traffic Selector Negotiation

	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, but interaction between IKE and
|	the SPD needs to be considered.  See [PFKEY] for an example
|	interaction between IKE and the SPD (as well as the SAD), and section
|	1.1.3 contains an example of where IKE actually could update the
|	SPD.

Dan

---

From: <[email-masked]>
Date: Thu, 30 Oct 2008 18:43:13 +0200

I think it would be more accurate to say that interaction between 
IKE and the SPD relies on various implementation-specific mechanisms
(protocols/interfaces and/or extensions to them) -- PF_KEY as
specified in RFC 2367 doesn't do that.

Best regards,
Pasi 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of ext Dan McDonald
> Sent: 30 October, 2008 18:30
> To: [email-masked]
> Subject: Re: [IPsec] Issue #64: PF_KEY is NOT for IKEv1 only...
>