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

<Pasi.Eronen@nokia.com> Wed, 17 March 2010 08:21 UTC

Return-Path: <Pasi.Eronen@nokia.com>
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 D3ED23A63C9 for <ipsec@core3.amsl.com>; Wed, 17 Mar 2010 01:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.974
X-Spam-Level:
X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 A6+ciJh5+0eI for <ipsec@core3.amsl.com>; Wed, 17 Mar 2010 01:21:24 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 322333A691B for <ipsec@ietf.org>; Wed, 17 Mar 2010 01:20:56 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o2H8KauP029966; Wed, 17 Mar 2010 10:21:02 +0200
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 10:20:44 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 10:20:40 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 17 Mar 2010 09:20:39 +0100
From: <Pasi.Eronen@nokia.com>
To: <paul.hoffman@vpnc.org>, <danmcd@sun.com>, <ipsec@ietf.org>
Date: Wed, 17 Mar 2010 09:20:37 +0100
Thread-Topic: [IPsec] Still incorrect understanding of PF_KEY in ikev2bis-08
Thread-Index: AcrFLXvFUJgMvPKYTQWoROZdFbAW4gAfSewA
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758484CF315@NOK-EUMSG-01.mgdnok.nokia.com>
References: <20100302213439.GJ11824@kebe.East.Sun.COM> <p06240819c7c567b968e9@[10.20.30.163]>
In-Reply-To: <p06240819c7c567b968e9@[10.20.30.163]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 17 Mar 2010 08:20:40.0175 (UTC) FILETIME=[BAC02FF0:01CAC5AA]
X-Nokia-AV: Clean
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: Wed, 17 Mar 2010 08:21:28 -0000

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