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

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 16 March 2010 17:22 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4173A6816 for <ipsec@core3.amsl.com>; Tue, 16 Mar 2010 10:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.664
X-Spam-Level:
X-Spam-Status: No, score=-4.664 tagged_above=-999 required=5 tests=[AWL=-1.032, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEMy4AEWfKWO for <ipsec@core3.amsl.com>; Tue, 16 Mar 2010 10:22:25 -0700 (PDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B5D133A6A42 for <ipsec@ietf.org>; Tue, 16 Mar 2010 10:22:24 -0700 (PDT)
Received: from [10.20.30.163] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2GGqrTw030915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Mar 2010 09:52:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240819c7c567b968e9@[10.20.30.163]>
In-Reply-To: <20100302213439.GJ11824@kebe.East.Sun.COM>
References: <20100302213439.GJ11824@kebe.East.Sun.COM>
Date: Tue, 16 Mar 2010 09:52:51 -0700
To: Dan McDonald <danmcd@sun.com>, ipsec@ietf.org
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [IPsec] Still incorrect understanding of PF_KEY in ikev2bis-08
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Mar 2010 17:22:29 -0000

[[ 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