From owner-ipsec-policy@mail.vpnc.org Thu Mar 1 08:28:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02847 for ; Thu, 1 Mar 2001 08:28:42 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id EAA11100 for ipsec-policy-bks; Thu, 1 Mar 2001 04:19:33 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA11096 for ; Thu, 1 Mar 2001 04:19:32 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00267; Thu, 1 Mar 2001 07:18:45 -0500 (EST) Message-Id: <200103011218.HAA00267@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec-policy@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsp-ipsec-conf-mib-00.txt Date: Thu, 01 Mar 2001 07:18:40 -0500 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Policy Working Group of the IETF. Title : IPsec Policy Configuration MIB Author(s) : M. Baer et al. Filename : draft-ietf-ipsp-ipsec-conf-mib-00.txt Pages : 67 Date : 28-Feb-01 This document defines a configuration MIB for IPsec/IKE policy. It does not define MIBs for monitoring the state of an IPsec device. It does not define MIBs for configuring other policy related actions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsec-conf-mib-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsp-ipsec-conf-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsp-ipsec-conf-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010228145420.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsp-ipsec-conf-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsp-ipsec-conf-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010228145420.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec-policy@mail.vpnc.org Fri Mar 2 18:19:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24397 for ; Fri, 2 Mar 2001 18:19:32 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA08119 for ipsec-policy-bks; Fri, 2 Mar 2001 13:42:21 -0800 (PST) Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA08113 for ; Fri, 2 Mar 2001 13:42:20 -0800 (PST) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id VAA27019 for ; Fri, 2 Mar 2001 21:42:12 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 02 Mar 2001 21:42:09 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Mar 2001 13:42:08 -0800 Message-ID: <794826DE8867D411BAB8009027AE9EB904DD7B38@FMSMSX38> From: "Jason, Jamie" To: ipsec-policy@vpnc.org Subject: New policy model draft. Date: Fri, 2 Mar 2001 13:42:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A request has been made to post a new version of the policy model draft. Since I don't know when the announcement will be made, try the following link: ftp://ftp.intel.com/pub/incoming/draft-ietf-ipsp-config-policy-model-02.txt Jamie ---------------------------------------------------------------- Jamie Jason email: jamie.jason@intel.com Intel Architecture Labs phone: 503-264-9531 2111 NE 25th Avenue fax: 503-264-9428 Hillsboro, OR 97124 "A lot of people run a race to see who is fastest. I run to see who has the most guts..." - Steve Prefontaine All opinions expressed are: 1. Entirely my own. 2. Not necessarily shared by my employer. 3. Unencumbered by the thought process. ---------------------------------------------------------------- From owner-ipsec-policy@mail.vpnc.org Mon Mar 5 08:42:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14453 for ; Mon, 5 Mar 2001 08:42:54 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id DAA14623 for ipsec-policy-bks; Mon, 5 Mar 2001 03:42:02 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA14611 for ; Mon, 5 Mar 2001 03:42:00 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10566; Mon, 5 Mar 2001 06:42:00 -0500 (EST) Message-Id: <200103051142.GAA10566@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec-policy@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsp-ipsecpib-02.txt Date: Mon, 05 Mar 2001 06:41:59 -0500 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Policy Working Group of the IETF. Title : IPSec Policy Information Base Author(s) : M. Li, D. Arneson, A. Doria, J. Jason, C. Wang Filename : draft-ietf-ipsp-ipsecpib-02.txt Pages : 65 Date : 02-Mar-01 This document specifies a set of policy rule classes (PRC) for configuring IPSec policy at IPsec-enabled devices. Instances of these classes reside in a virtual information store called IPSec Policy Information Base (PIB). COPS protocol [COPS] with the extensions for provisioning [COPS-PR] may be used to transmit this IPSec policy information to IPSec-enabled devices (e.g., gateways). The PRCs defined in this IPSec PIB are intended for use by the COPS- PR IPSec client type. They complement the PRCs defined in the Framework PIB [FR-PIB]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsecpib-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsp-ipsecpib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsp-ipsecpib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010302131452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsp-ipsecpib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsp-ipsecpib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010302131452.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec-policy@mail.vpnc.org Mon Mar 5 13:45:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27260 for ; Mon, 5 Mar 2001 13:45:52 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA08259 for ipsec-policy-bks; Mon, 5 Mar 2001 08:57:19 -0800 (PST) Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA08255 for ; Mon, 5 Mar 2001 08:57:18 -0800 (PST) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id QAA27668 for ; Mon, 5 Mar 2001 16:57:19 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 05 Mar 2001 16:57:19 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Mar 2001 08:57:18 -0800 Message-ID: <794826DE8867D411BAB8009027AE9EB904DD7B40@FMSMSX38> From: "Jason, Jamie" To: ipsec-policy@vpnc.org Subject: New policy model draft - New Link Date: Mon, 5 Mar 2001 08:57:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ooops. Please try the following link instead: ftp://ftp.intel.com/pub/outgoing/draft-ietf-ipsp-config-policy-model-02.txt Hopefully, this one will work. Let me know if it doesn't. Jamie > -----Original Message----- > From: Jason, Jamie [mailto:jamie.jason@intel.com] > Sent: Friday, March 02, 2001 1:42 PM > To: ipsec-policy@vpnc.org > Subject: New policy model draft. > > > A request has been made to post a new version of the policy > model draft. > Since I don't know when the announcement will be made, try > the following > link: > > ftp://ftp.intel.com/pub/incoming/draft-ietf-ipsp-config-policy > -model-02.txt > > Jamie > > ---------------------------------------------------------------- > Jamie Jason email: jamie.jason@intel.com > Intel Architecture Labs phone: 503-264-9531 > 2111 NE 25th Avenue fax: 503-264-9428 > Hillsboro, OR 97124 > > "A lot of people run a race to see who is fastest. I run to see > who has the most guts..." - Steve Prefontaine > > All opinions expressed are: > 1. Entirely my own. > 2. Not necessarily shared by my employer. > 3. Unencumbered by the thought process. > ---------------------------------------------------------------- > > From owner-ipsec-policy@mail.vpnc.org Wed Mar 7 08:41:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03782 for ; Wed, 7 Mar 2001 08:41:06 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id EAA12131 for ipsec-policy-bks; Wed, 7 Mar 2001 04:37:36 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA12126 for ; Wed, 7 Mar 2001 04:37:35 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00813; Wed, 7 Mar 2001 07:37:35 -0500 (EST) Message-Id: <200103071237.HAA00813@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec-policy@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsp-config-policy-model-02.txt Date: Wed, 07 Mar 2001 07:37:35 -0500 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Policy Working Group of the IETF. Title : IPsec Configuration Policy Model Author(s) : J. Jason, L. Rafalow, E. Vyncke Filename : draft-ietf-ipsp-config-policy-model-02.txt Pages : 112 Date : 06-Mar-01 This document presents an object-oriented model of IPsec policy designed to: o facilitate agreement about the content and semantics of IPsec policy o enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec- enabled endpoints The schema described in this document models the IKE phase one parameters as described in [IKE] and the IKE phase two parameters for the IPsec Domain of Interpretation as described in [COMP, ESP, AH, DOI]. It is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) [PCIM]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsp-config-policy-model-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsp-config-policy-model-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsp-config-policy-model-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010306125327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsp-config-policy-model-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsp-config-policy-model-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010306125327.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec-policy@mail.vpnc.org Thu Mar 8 14:18:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09250 for ; Thu, 8 Mar 2001 14:18:18 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA18393 for ipsec-policy-bks; Thu, 8 Mar 2001 10:12:42 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA18386 for ; Thu, 8 Mar 2001 10:12:40 -0800 (PST) Received: from megisto.com (loaner1.megisto.com [192.168.20.95]) by megisto-sql1.megisto.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1LC2CN38; Thu, 8 Mar 2001 13:07:46 -0500 Message-ID: <3AA7CB3D.69EC70@megisto.com> Date: Thu, 08 Mar 2001 13:11:09 -0500 From: "Luis A. Sanchez" Organization: Megisto Systems X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-policy@vpnc.org Subject: Agenda Items Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, Hilarie and I are preparing the agenda for this coming meeting. Please send your requests to us before March 14th. Thanks, Luis From owner-ipsec-policy@mail.vpnc.org Fri Mar 16 20:28:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17054 for ; Fri, 16 Mar 2001 20:28:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA27372 for ipsec-policy-bks; Fri, 16 Mar 2001 16:34:28 -0800 (PST) Received: from tpeweb03.netbizsoft.com ([210.59.226.111]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA27368 for ; Fri, 16 Mar 2001 16:34:26 -0800 (PST) From: b4h443@arabia.com Received: from ns.rdc.cl (1Cust24.tnt34.dfw9.da.uu.net [63.62.253.24]) by tpeweb03.netbizsoft.com (8.9.3/8.8.7) with SMTP id IAA31670; Sat, 17 Mar 2001 08:29:41 +0800 Message-ID: <00003a707255$0000258a$000020a4@ns.rdc.cl> To: Subject: I CAN HELP !!! Date: Fri, 16 Mar 2001 17:19:06 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: b4h443@arabia.com Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable





















Can't get email out to the masses without losing your ISP???


Don't know how
to get sales for your product???

Can't get traffic to your
site???


COLOR=3D"#ffffff">Call
1-888-242-5082





















Can't get email out to the masses without losing your ISP???


Don't know how
to get sales for your product???

Can't get traffic to your
site???


COLOR=3D"#ffffff">Call
1-888-242-5082

I have plenty of fresh verified
email names and can get you results.



BORDER=3D"0">




CELLSPACING=3D"0" >




SIZE=3D"+2">Price List
COLOR=3D"#008040">Discounts for larger
orders

FACE=3D"Times New Roman">100
Thousand - $200
500 Thousand -
$875
1 Million -
$1500
















It
is this easy!
COLOR=3D"#004080" SIZE=3D"+1">You simply furnish your message and I
do the rest. I guarantee you
100% delivery. It can even be done in full color at no
extra cost







COLOR=3D"#ffffff">NOTICE

Roman">Under
Bill s.1618 TITLE III passed by the 105th US Congress this letter
cannot be
considered spam as long as the sender includes contact information
and a method
of removal. To be removed, hit reply and type remove in the
subject
line.

/FONT>

I have plenty of fresh verified
email names and can get you results.



BORDER=3D"0">




CELLSPACING=3D"0" >




SIZE=3D"+2">Price List
COLOR=3D"#008040">Discounts for larger
orders

FACE=3D"Times New Roman">100
Thousand - $200
500 Thousand -
$875
1 Million -
$1500
















It
is this easy!
COLOR=3D"#004080" SIZE=3D"+1">You simply furnish your message and I
do the rest. I guarantee you
100% delivery. It can even be done in full color at no
extra cost







COLOR=3D"#ffffff">NOTICE

Roman">Under
Bill s.1618 TITLE III passed by the 105th US Congress this letter
cannot be
considered spam as long as the sender includes contact information
and a method
of removal. To be removed, hit reply and type remove in the
subject
line.



From owner-ipsec-policy@mail.vpnc.org Mon Mar 19 14:05:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18569 for ; Mon, 19 Mar 2001 14:05:50 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA25859 for ipsec-policy-bks; Mon, 19 Mar 2001 10:01:08 -0800 (PST) Received: from rc_westlake.interdyn.com ([205.147.53.144]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA25855 for ; Mon, 19 Mar 2001 10:01:06 -0800 (PST) Received: by RC_WESTLAKE with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Mar 2001 09:59:40 -0800 Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HHYBLTRK; Mon, 19 Mar 2001 10:00:21 -0800 Message-ID: <3AB63C6F.12EF1123@redcreek.com> Date: Mon, 19 Mar 2001 10:05:51 -0700 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: ".ipsec-policy" Subject: granularity property in Common Information Model Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Howdy, I can't be at the IETF this week. But I would like to bring up an old argument about the granularity property in draft-ietf-ipsp-config-policy-model-02.txt. I hope that someone will persue this topic in the meeting today. The granluarity property is associated with an IPsecAction. It defines whether or not the SA will use port/protocol filtering. If granularity is "ON". then the ports/protocols are sucked out of the passing packet (which has already matched an ipaddress subnet filter) and the SA is built to filter on those ports/protocols. (WARNING: this has been a simplification of how granularity is really defined for the sake of clarity... granularity is reall just a bit more flexible than this.) I want to see port and protocol filtering moved away from the 'action' branch of the model and into the 'condition' branch. I strongly believe that Administrators should have control over the construction of port/protocol filters in just the same was as address filters. My reading of the architecture documets would require this admistrative control capability. My sence of the customer problem I am trying to solve requires this adminstrative control capability. And generalized view of modeling would suggest that granularity is a 'filtering' related property belonging with the other filtering properties in a model. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Mon Mar 19 16:34:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22466 for ; Mon, 19 Mar 2001 16:34:03 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA04166 for ipsec-policy-bks; Mon, 19 Mar 2001 12:13:42 -0800 (PST) Received: from strange-brew.cisco.com (odd-brew.cisco.com [144.254.15.119]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA04159 for ; Mon, 19 Mar 2001 12:13:39 -0800 (PST) Received: from EVYNCKE-W2K.cisco.com (rtp-vpn-84.cisco.com [10.82.192.84]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA22218; Mon, 19 Mar 2001 21:13:04 +0100 (MET) Message-Id: <4.3.2.7.2.20010319210605.00b9f6e8@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Mar 2001 21:13:01 +0100 To: Ricky Charlet From: Eric Vyncke Subject: Re: granularity property in Common Information Model Cc: ".ipsec-policy" In-Reply-To: <3AB63C6F.12EF1123@redcreek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ricky, I do believe that granularity belongs to the action, when a packet matches your filter, you start a negotiation using some phase 2 ID based on the original packet and the granularity property. So, it really belongs to the action side. But, you raise a good point for the DMTF information model which also models the state of the SA. When a fine granularity is applied and an SA is eventually created, a filter object will need to be created and associated through FilterOfSecurityAssociation with SecurityAssociation. Hope this helps, Regards -eric At 10:05 19/03/2001 -0700, Ricky Charlet wrote: >Howdy, > > I can't be at the IETF this week. But I would like to bring up an old >argument about the granularity property in >draft-ietf-ipsp-config-policy-model-02.txt. I hope that someone will >persue this topic in the meeting today. > > > The granluarity property is associated with an IPsecAction. It > defines >whether or not the SA will use port/protocol filtering. If granularity >is "ON". then the ports/protocols are sucked out of the passing packet >(which has already matched an ipaddress subnet filter) and the SA is >built to filter on those ports/protocols. (WARNING: this has been a >simplification of how granularity is really defined for the sake of >clarity... granularity is reall just a bit more flexible than this.) > > I want to see port and protocol filtering moved away from the > 'action' >branch of the model and into the 'condition' branch. I strongly believe >that Administrators should have control over the construction of >port/protocol filters in just the same was as address filters. My >reading of the architecture documets would require this admistrative >control capability. My sence of the customer problem I am trying to >solve requires this adminstrative control capability. And generalized >view of modeling would suggest that granularity is a 'filtering' related >property belonging with the other filtering properties in a model. > > >-- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 Eric Vyncke Distinguished Engineer Cisco Systems EMEA Phone: +32-2-778.4677 Fax: +32-2-778.4300 E-mail: evyncke@cisco.com Mobile: +32-475-312.458 (CHANGED) PGP fingerprint: D35F BEF9 643F 656F 90F5 76C5 9CA1 C289 D398 B141 From owner-ipsec-policy@mail.vpnc.org Tue Mar 20 00:06:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07380 for ; Tue, 20 Mar 2001 00:06:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id TAA27257 for ipsec-policy-bks; Mon, 19 Mar 2001 19:49:32 -0800 (PST) Received: from nyarlathotep.keromytis.org (pcp017546pcs.wireless.meeting.ietf.org [135.222.64.27]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA27252 for ; Mon, 19 Mar 2001 19:49:30 -0800 (PST) Received: from keromytis.org (localhost [127.0.0.1]) by nyarlathotep.keromytis.org (8.11.3/8.10.1) with ESMTP id f2K3nUC08917; Mon, 19 Mar 2001 22:49:30 -0500 (EST) Message-Id: <200103200349.f2K3nUC08917@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: ipsec-policy@vpnc.org Subject: IETF-50 (Minneapolis) IPSP WG minutes Cc: horman@novell.com, lsanchez@megisto.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Mar 2001 22:49:30 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: (I walked in 10 minutes late, so I may have missed something -- still, Luis insisted that I keep minutes.) Matt Blaze -- requirements draft Matt discussed the the requirements for IPSP. Since the draft hasn't changed since the last IETF, he just re-iterated the main points of the requirements draft: - policy model - gateway discovery mechanism - policy languages for nodes - means for distributing responsibility - protocol for discovering policy - method for resolving SA parameters - semantics for compliance checking SA parameters & gateways against each node's policy - no changes to anything else (IKE, IPsec, etc) The slides are online at http://www.crypto.com/talks Desperate plea for comments on the document. William Dixon asked about compliance checking and what that meant in terms of the policy model -- response: we have requirements for the policy model, but the WG has not decided on one yet. Lee Rafalow -- IPsec Configuration Policy Model Lee talked about PCIM extension proposals and convergence with IPSP and QPIM (see Policy Framework WG). The main points were: - Rules may contain groups and rules - Match first & all decision strategies - Simplified priorities - Refinements in the use of PolicyRoles - Compound conditions & actions - Variables & values, both for conditions & actions - Common packet filtering representation Remaining issues were: - Declarative vs. procedural policies (rule actions early in policy may affect rules later on) - Implicit & hierarchical contexts - Deterministic vs. non-deterministic evaluation - Transaction semantics were removed - Implicit variables - Use of regular expressions in conditions (currently not supported) Draft does not yet reflect PCIM extensions, or note required/optional functions. Lee then gave a quick overview of the model (using diagrams) -- giving the relations between rules, conditions, actions, and their components as they've been updated since the last meeting. The document seems to be pretty stable at this point, so there may be a last call in August. Dixon: customers ask for things like ICMP type/code handled by IPsec, which are not part of the IPsec spec but would be useful to be supported. Reponse: it's not in the model, but it's possible to add as an extension and could be mentioned in the spec as a MAY. Other questions on reconciliation of the requirements draft and the PCIM model. The answer is that we can use a subset of the PCIM model that fits the requirements. Will this model be driven down to the device ? Yes. It is intended to be used by all elements that can participate in an IKE negotiations. What the relation of the model with other work like COPS that tries to do similar things ? This work is based on the PCIM model, as is similar work in the other working groups. Unclear what the overlap should/will be at this point. The goal is to make it possible to use either a PIB or a MIB-based mechanism (up to the vendor) to configure an element. They will both be consistent with each other (and the model). There is an issue with policies that are more restrictive than an element's policy (currently, rules have to match exactly). There are no plans to address this at this stage. Wes Hardaker -- IPsec Configuration MIB Wes discussed the architectural overview and the diffrences with the PCIM model, as well as things to be done. The MIB uses a hierarchy of tables, and follows the PCIM-derived model Lee presented. The tables are: policyEndpointToGroupTable: maps endpoint address to groupname policyIKERulesInGroupTable, policyIPsecRulesInGroupTable: map groupname to ordered list of rule names, and/or conditions in rules (there is some difference with the DMTF white papers). Rule processing is first-match. conditionsInRuleTable: maps a rule name to an ordered condition name list, defines condition negation filtersInConditionTable: maps a condition name to an ordered filter name list filterTable: defines filters, multiple filter types in one row actionsInRulesTable: maps rule names to a dual-ordered list of actions, multiple actions/fallbacks are specifiable (the actions/fallbacks may be in different "domains", e.g., QoS and IPsec) saStaticActionTable: implements non-negotiated IPsec action (bypass, discard, rejectIKE, preconfigured) saNegotiationActionTable: implements negotiation actions, points to ikeActionTable and ipsecActionTable, and contains parameters common to both ikeProposalTable, ipsecProposalTable, ahTransformTable, espTransformTable, ipcompTransformTable, ikeIdentityTable: ipsec/ike parameters for negotiated actions Differences form the data model: - packet classification is independent of the action - groups of groups are not implemented (too complicated) - rules contain multiple actions (ordered by sequence number, with multiple possible fallback actions) - Rule actions are specified by RowPoints - Filter object-oriented objects combined into one table - Conditions modified to be of multiple types To be done: - Clarify use/configuration of IKE identities - Clarify use/configuration of identity contexts (credential filters) - Catch up to new changes in policy model draft - Resolve differences between MIB and policy model - Move packet classification somewhere else - Group in group (PCIM may want to support this as well, since it allows an administrator to construct coherent sets of rules that can be applied together -- comment from Lee Rafalow) - Notifications - Compliance - English text (editorial issues with the draft) - Row dependency issues (half-done at this point) - Integration with snmpconf - Authority/level classifications (IPSO labels -- contiguous or discrete) - Local administrative realms (local policies that augment but don't conflict with "global" policies) Question: can the MIB be used to specify port filters for applications that assign their ports dynamically ? No. (Hilarie:) Implementations ? NAI will be doing one. Man Li -- IPsec PIB Man Li gave an overview of the PIB, and talked about new developments in the draft, and described differences with the information model. IPsec PIB is used by policy servers to distribute IPsec policy to IPsec enabled devices using the COPS protocol. CredentialTable and CredentialFieldsTable were added in the draft; the specify (respectively) the acceptable credentials types for the peer and the fields/values to be matched in these credentials. The PIB currently supports multiple actions that can be applied in sequence to one packet. The information model uses "try until success" semantics, additional actions are used as fallbacks. Things to do: add policy target IPsec capabilities, and align with the information model. Luis Sanchez -- Next Steps - WG last call for the following drafts: IPsec Policy Management Roadmap, IPSP Requirements, IPsec Policy Configuration Model. - We should start detailed discussions of PIB and MIB, and see who is doing implementations (and what feedback we can get from them) - Publish PF_POLICY draft - Begin SG Discovery Protocol design - Security Policy Specification Language - Core Design Team volunteers - SG Discovery Protocol End of session. From owner-ipsec-policy@mail.vpnc.org Tue Mar 20 00:27:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07952 for ; Tue, 20 Mar 2001 00:27:05 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id UAA27780 for ipsec-policy-bks; Mon, 19 Mar 2001 20:32:34 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA27776 for ; Mon, 19 Mar 2001 20:32:33 -0800 (PST) Received: from megisto.com (linux.hq.megisto.com [192.168.20.5]) by megisto-sql1.megisto.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1LC2CT50; Mon, 19 Mar 2001 23:27:14 -0500 Message-ID: <3AB6DCFE.F5EBB5B5@megisto.com> Date: Mon, 19 Mar 2001 22:30:54 -0600 From: "Luis A. Sanchez" Organization: Megisto Systems X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Vyncke CC: Ricky Charlet , ".ipsec-policy" Subject: Re: granularity property in Common Information Model References: <4.3.2.7.2.20010319210605.00b9f6e8@brussels.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Eric, The granularity you described seems associated with actions but are based on parameters used for creating/evaluate conditions. RFC2401 says "The following selector parameters MUST be supported for SA management to facilitate control of SA granularity." THe model supports this already from a condition point of view. Can you further explain this? > Ricky, > > I do believe that granularity belongs to the action, when a packet > matches your filter, you start a negotiation using some phase 2 ID > based on the original packet and the granularity property. So, it really > belongs to the action side. > > But, you raise a good point for the DMTF information model which > also models the state of the SA. When a fine granularity is applied and > an SA is eventually created, a filter object will need to be created > and associated through FilterOfSecurityAssociation with SecurityAssociation. > > Hope this helps, > > Regards > > -eric > > At 10:05 19/03/2001 -0700, Ricky Charlet wrote: > >Howdy, > > > > I can't be at the IETF this week. But I would like to bring up an old > >argument about the granularity property in > >draft-ietf-ipsp-config-policy-model-02.txt. I hope that someone will > >persue this topic in the meeting today. > > > > > > The granluarity property is associated with an IPsecAction. It > > defines > >whether or not the SA will use port/protocol filtering. If granularity > >is "ON". then the ports/protocols are sucked out of the passing packet > >(which has already matched an ipaddress subnet filter) and the SA is > >built to filter on those ports/protocols. (WARNING: this has been a > >simplification of how granularity is really defined for the sake of > >clarity... granularity is reall just a bit more flexible than this.) > > > > I want to see port and protocol filtering moved away from the > > 'action' > >branch of the model and into the 'condition' branch. I strongly believe > >that Administrators should have control over the construction of > >port/protocol filters in just the same was as address filters. My > >reading of the architecture documets would require this admistrative > >control capability. My sence of the customer problem I am trying to > >solve requires this adminstrative control capability. And generalized > >view of modeling would suggest that granularity is a 'filtering' related > >property belonging with the other filtering properties in a model. > > > > > >-- > > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 > > Eric Vyncke > Distinguished Engineer Cisco Systems EMEA > Phone: +32-2-778.4677 Fax: +32-2-778.4300 > E-mail: evyncke@cisco.com Mobile: +32-475-312.458 (CHANGED) > PGP fingerprint: D35F BEF9 643F 656F 90F5 76C5 9CA1 C289 D398 B141 From owner-ipsec-policy@mail.vpnc.org Tue Mar 20 09:12:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06675 for ; Tue, 20 Mar 2001 09:12:39 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id FAA13948 for ipsec-policy-bks; Tue, 20 Mar 2001 05:08:18 -0800 (PST) Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA13943 for ; Tue, 20 Mar 2001 05:08:16 -0800 (PST) Received: from oleane (dyn-1-1-134.Vin.dialup.oleane.fr [195.25.4.134]) by smtp2.cluster.oleane.net with SMTP id f2KD8Df31381 for ; Tue, 20 Mar 2001 14:08:14 +0100 (CET) Message-ID: <005d01c0b13e$c8c4c000$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IP Policy Conference: call for proposals Date: Tue, 20 Mar 2001 14:07:53 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01C0B147.28147E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_005A_01C0B147.28147E80 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How will policies encourage the creation of new services?=20 Which services need resort to policy management? SNMPconf, COPS, SNMPV3 issues : the second edition of IP Policy will be = organized in Paris next September 11-14. A call for proposals is online at: http://www.upperside.fr/ippol01/ippolcfp.htm ------=_NextPart_000_005A_01C0B147.28147E80 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

How will policies encourage = the creation=20 of new services?
Which=20 services need resort to policy management?
SNMPconf, COPS, SNMPV3 issues : the = second=20 edition of IP Policy will be organized in Paris next September=20 11-14.
A call for = proposals is=20 online at:
http://www.uppersid= e.fr/ippol01/ippolcfp.htm
 
 
------=_NextPart_000_005A_01C0B147.28147E80-- From owner-ipsec-policy@mail.vpnc.org Tue Mar 20 13:38:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17756 for ; Tue, 20 Mar 2001 13:38:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA05261 for ipsec-policy-bks; Tue, 20 Mar 2001 09:31:33 -0800 (PST) Received: from rc_westlake.interdyn.com ([205.147.53.144]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA05256 for ; Tue, 20 Mar 2001 09:31:30 -0800 (PST) Received: by RC_WESTLAKE with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Mar 2001 09:30:12 -0800 Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H2ZKB8K6; Tue, 20 Mar 2001 09:30:56 -0800 Message-ID: <3AB78753.1E346DAE@redcreek.com> Date: Tue, 20 Mar 2001 09:37:39 -0700 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Vyncke CC: ".ipsec-policy" Subject: Re: granularity property in Common Information Model References: <4.3.2.7.2.20010319210605.00b9f6e8@brussels.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks Eric, I see your point that the phase 2 ID needs to be specified as to type. I had not thought of that before. But, the granularity property in the IPsecAction (what do we call it, object, group, table, thingie?) seems to me to be mismatched with the set of possible 2 ID types. Specifically, we do not need ports and protocols in phase 2 IDs but on the other hand, we do need specific addresses, subnets, and ranges of addresses in IPv4 and IPv6. (I don't know if FQDN, user@FQDN, DN, GN, and keyID are supportable as phase 2 IDs, could someone else inform our disussion here. I don't see any thing saying they can not be used at phase 2, but I also don't see how data, not verifiable in a packet, could be used as a phase 2 ID.) In the case of subnets and ranges of addresses, these cannot be inferred from a packet-on-hand and a granularity property. So now I am left with my original request and a new question. Can we please provide filtering control for ports and protocols? And now, how should we know what client ID to use in (and the type of) the phase 2 Identification payload? -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 Eric Vyncke wrote: > > Ricky, > > I do believe that granularity belongs to the action, when a packet > matches your filter, you start a negotiation using some phase 2 ID > based on the original packet and the granularity property. So, it really > belongs to the action side. > > But, you raise a good point for the DMTF information model which > also models the state of the SA. When a fine granularity is applied and > an SA is eventually created, a filter object will need to be created > and associated through FilterOfSecurityAssociation with SecurityAssociation. > > Hope this helps, > > Regards > > -eric > > At 10:05 19/03/2001 -0700, Ricky Charlet wrote: > >Howdy, > > > > I can't be at the IETF this week. But I would like to bring up an old > >argument about the granularity property in > >draft-ietf-ipsp-config-policy-model-02.txt. I hope that someone will > >persue this topic in the meeting today. > > > > > > The granluarity property is associated with an IPsecAction. It > > defines > >whether or not the SA will use port/protocol filtering. If granularity > >is "ON". then the ports/protocols are sucked out of the passing packet > >(which has already matched an ipaddress subnet filter) and the SA is > >built to filter on those ports/protocols. (WARNING: this has been a > >simplification of how granularity is really defined for the sake of > >clarity... granularity is reall just a bit more flexible than this.) > > > > I want to see port and protocol filtering moved away from the > > 'action' > >branch of the model and into the 'condition' branch. I strongly believe > >that Administrators should have control over the construction of > >port/protocol filters in just the same was as address filters. My > >reading of the architecture documets would require this admistrative > >control capability. My sence of the customer problem I am trying to > >solve requires this adminstrative control capability. And generalized > >view of modeling would suggest that granularity is a 'filtering' related > >property belonging with the other filtering properties in a model. > > > > > >-- > > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 > > Eric Vyncke > Distinguished Engineer Cisco Systems EMEA > Phone: +32-2-778.4677 Fax: +32-2-778.4300 > E-mail: evyncke@cisco.com Mobile: +32-475-312.458 (CHANGED) > PGP fingerprint: D35F BEF9 643F 656F 90F5 76C5 9CA1 C289 D398 B141 From owner-ipsec-policy@mail.vpnc.org Wed Mar 21 02:02:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00023 for ; Wed, 21 Mar 2001 02:02:29 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id WAA08765 for ipsec-policy-bks; Tue, 20 Mar 2001 22:05:29 -0800 (PST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA08761 for ; Tue, 20 Mar 2001 22:05:28 -0800 (PST) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Wed, 21 Mar 2001 00:54:53 -0500 Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G975HRG3; Wed, 21 Mar 2001 00:54:52 -0500 Received: from nortelnetworks.com (artpt30e.us.nortel.com [47.140.68.1]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HJCWZYNB; Wed, 21 Mar 2001 00:54:51 -0500 Message-ID: <3AB84222.C7E9BD26@nortelnetworks.com> Date: Tue, 20 Mar 2001 23:54:42 -0600 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Advanced Routing Technology X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: ipsec-policy@vpnc.org, horman@novell.com, lsanchez@megisto.com Subject: Re: IETF-50 (Minneapolis) IPSP WG minutes References: <200103200349.f2K3nUC08917@nyarlathotep.keromytis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Angelos D. Keromytis" wrote: > ... > > Luis Sanchez -- Next Steps > > - WG last call for the following drafts: IPsec Policy Management > Roadmap, IPSP Requirements, IPsec Policy Configuration Model. ... Hi, I wasn't able to attend the WG meeting otherwise I would have suggested this at the time. I think that the PIB should also go through working group last call at the same time as the Config Model. The work has been tracking the model and has seen at least one implementation so far with a few others rumored to be under consideration (of course I understand that implementations aren't required before going to proposed). a. -- Avri Doria +1 401 663 5024 From owner-ipsec-policy@mail.vpnc.org Thu Mar 22 14:59:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19492 for ; Thu, 22 Mar 2001 14:59:48 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA12875 for ipsec-policy-bks; Thu, 22 Mar 2001 10:27:39 -0800 (PST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [209.151.24.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA12871 for ; Thu, 22 Mar 2001 10:27:37 -0800 (PST) Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id NAA22941 for ; Thu, 22 Mar 2001 13:27:37 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (pcp000805pcs.wireless.meeting.ietf.org [135.222.65.49]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f2MIRY100652 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 22 Mar 2001 13:27:39 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f2MILCV25595 for ; Thu, 22 Mar 2001 13:21:13 -0500 (EST) Message-Id: <200103221821.f2MILCV25595@marajade.sandelman.ottawa.on.ca> To: ipsec-policy@vpnc.org From: mcrietf@sandelman.ottawa.on.ca (Michael Richardson) Subject: Michael Richardson: middle boxes vs security Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 22 Mar 2001 13:21:12 -0500 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To: midtax@lists.hactrn.net Subject: middle boxes vs security In-reply-to: Your message of "Wed, 21 Mar 2001 10:52:27 EST." <200103211552.KAA17534@clipper.gw.tislabs.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 22 Mar 2001 03:30:14 -0500 From: Michael Richardson It is interesting that the inability to deploy security due to presence of middle boxes, such as security gateways, has prevented deployment of voice services. (Frankly, I think that the overly complicated H.323 that has been the culprit for years... H.323 was designed without reference to security gateways at all, but perhaps this is simply a good example of the problem)a I would invite people to take a look at the SPP drafts that are part of the IPsec Security Policy WG as background for a new protocol. In this case, the SPP attempts to discovery security gateways along the forwarding path, determine appropriate security policies for traversing them, and resolve conflicts in the policies. With the config model, MIB and PIB going to last call now, IPSP expects to make progress now on a new security gateway/policy discovery protocol. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec-policy@mail.vpnc.org Thu Mar 22 23:15:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06761 for ; Thu, 22 Mar 2001 23:15:11 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id TAA14936 for ipsec-policy-bks; Thu, 22 Mar 2001 19:12:37 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA14932 for ; Thu, 22 Mar 2001 19:12:35 -0800 (PST) Received: from megisto.com (linux.hq.megisto.com [192.168.20.5]) by megisto-sql1.megisto.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1LC2CW1L; Thu, 22 Mar 2001 22:07:11 -0500 Message-ID: <3ABABEC0.A03964BC@megisto.com> Date: Thu, 22 Mar 2001 21:10:57 -0600 From: "Luis A. Sanchez" Organization: Megisto Systems X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Avri Doria CC: ipsec-policy@vpnc.org, horman@novell.com Subject: Re: IETF-50 (Minneapolis) IPSP WG minutes References: <200103200349.f2K3nUC08917@nyarlathotep.keromytis.org> <3AB84222.C7E9BD26@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Avri, I want the IPsec PIB to move to PS status. However, I think it may be a bit earlier for this. First, I would like to see people discussing it. Second, I would like to see at least two independent implementations and some level of interoperability first. I'm also checking with the OPS/MAN area directors for the exact requirements on PIBs. Even if two implementations are not required we need to discuss the PIB more. I believe that you folks can help with this. Thanks, Luis From owner-ipsec-policy@mail.vpnc.org Fri Mar 23 12:44:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28020 for ; Fri, 23 Mar 2001 12:44:25 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA22982 for ipsec-policy-bks; Fri, 23 Mar 2001 08:09:38 -0800 (PST) Received: from itesec.hsc.fr (itesec.hsc.fr [192.70.106.33]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA22973 for ; Fri, 23 Mar 2001 08:09:36 -0800 (PST) Received: from zeus.hsc.fr (zeus.hsc.fr [192.70.106.72]) by itesec.hsc.fr (Postfix) with ESMTP id AC15010E05; Fri, 23 Mar 2001 17:09:06 +0100 (CET) Received: by zeus.hsc.fr (Postfix, from userid 200) id 0B1FA40030; Fri, 23 Mar 2001 17:10:06 +0100 (CET) Subject: Re: Michael Richardson: middle boxes vs security In-Reply-To: <200103221821.f2MILCV25595@marajade.sandelman.ottawa.on.ca> from Michael Richardson at "Mar 22, 2001 01:21:12 pm" To: Michael Richardson Date: Fri, 23 Mar 2001 17:10:06 +0100 (CET) Cc: ipsec-policy@vpnc.org Organization: Herve Schauer Consultants X-Address: 4bis Rue de la Gare, F-92300 Levallois-Perret, France X-Phone: +33 141 409 700 X-Fax: +33 141 409 709 X-Web: http://www.hsc.fr/ X-Mailer: ELM [version 2.4ME+ PL56 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20010323161006.0B1FA40030@zeus.hsc.fr> From: Herve.Schauer@hsc.fr (Herve Schauer) Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In his/her message, Michael Richardson wrote: > It is interesting that the inability to deploy security due to presence of >middle boxes, such as security gateways, has prevented deployment of voice >services. I do not understand. In draft-lear-middlebox-arch-01.txt, a middle box can be a NAT box or a firewall. I think this is a mistake to think you can caracterize some network devices as middle boxes this way, and others network devices not being middle boxes. Any switch-router is always able to do NAT, and always have firewalling capabilities like IP filtering. In most case the usage of IP access-lists if not only for access-control, but also routing, QoS, VLANs, etc. So, in the real world, all IP network devices are middle boxes with such a definition. I think we should reserve middle box definition for boxes working at the application layer like boxes between WAP and HTTP. What is you definition of the middle box ? Why security gateways (id a network device building IPsec tunnels) has prevented deployment of voice services ? Regards, HERVE From owner-ipsec-policy@mail.vpnc.org Fri Mar 23 14:11:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01083 for ; Fri, 23 Mar 2001 14:11:54 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA28631 for ipsec-policy-bks; Fri, 23 Mar 2001 09:55:27 -0800 (PST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@[209.151.24.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA28626 for ; Fri, 23 Mar 2001 09:55:26 -0800 (PST) Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id MAA04936; Fri, 23 Mar 2001 12:55:22 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca ([2002:d11f:7141::20]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f2NHtK101976 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 23 Mar 2001 12:55:26 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f2NHmrQ03297; Fri, 23 Mar 2001 12:48:53 -0500 (EST) Message-Id: <200103231748.f2NHmrQ03297@marajade.sandelman.ottawa.on.ca> To: Herve.Schauer@hsc.fr (Herve Schauer) cc: ipsec-policy@vpnc.org Subject: Re: Michael Richardson: middle boxes vs security In-reply-to: Your message of "Fri, 23 Mar 2001 17:10:06 +0100." <20010323161006.0B1FA40030@zeus.hsc.fr> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 23 Mar 2001 12:48:53 -0500 From: Michael Richardson Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Herve" == Herve Schauer writes: Herve> In his/her message, Michael Richardson wrote: >> It is interesting that the inability to deploy security due to presence of >> middle boxes, such as security gateways, has prevented deployment of voice >> services. Herve> I do not understand. Herve> In draft-lear-middlebox-arch-01.txt, a middle box can be a NAT box or a Herve> firewall. I think this is a mistake to think you can caracterize some Herve> network devices as middle boxes this way, and others network devices Herve> not being middle boxes. I said "security gateway", not middle box --- that doesn't mean just VPN box. I means firewall as well. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec-policy@mail.vpnc.org Fri Mar 23 14:18:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01237 for ; Fri, 23 Mar 2001 14:18:20 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA28756 for ipsec-policy-bks; Fri, 23 Mar 2001 09:59:54 -0800 (PST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA28752 for ; Fri, 23 Mar 2001 09:59:52 -0800 (PST) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 23 Mar 2001 10:26:19 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H3N6G8MB; Fri, 23 Mar 2001 10:26:19 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HMHZD33G; Fri, 23 Mar 2001 10:26:20 -0500 Message-ID: <3ABB6BF8.1374072B@americasm01.nt.com> Date: Fri, 23 Mar 2001 10:30:00 -0500 From: "Abdallah Rayhan" Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: ipsec-policy@vpnc.org Subject: Re: Michael Richardson: middle boxes vs security References: <200103221821.f2MILCV25595@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael, You make a good point. It is one of the reasons why we are pushing to decouple distribution of IPsec policies from the discovery issues as each serves a different purpose. The discovery issue applies to several problems like the one you mentioned while the policy is focused on things related to IPSec. I admit that there is an advantage of coupling the two but far more advantages in the decoupled approach. my 2 cents regards Abdallah Michael Richardson wrote: > > To: midtax@lists.hactrn.net > Subject: middle boxes vs security > In-reply-to: Your message of "Wed, 21 Mar 2001 10:52:27 EST." > <200103211552.KAA17534@clipper.gw.tislabs.com> > Mime-Version: 1.0 (generated by tm-edit 7.108) > Content-Type: text/plain; charset=US-ASCII > Date: Thu, 22 Mar 2001 03:30:14 -0500 > From: Michael Richardson > > It is interesting that the inability to deploy security due to presence of > middle boxes, such as security gateways, has prevented deployment of voice > services. > (Frankly, I think that the overly complicated H.323 that has been the > culprit for years... H.323 was designed without reference to security > gateways at all, but perhaps this is simply a good example of the problem)a > > I would invite people to take a look at the SPP drafts that are part of the > IPsec Security Policy WG as background for a new protocol. > > In this case, the SPP attempts to discovery security gateways along the > forwarding path, determine appropriate security policies for traversing them, > and resolve conflicts in the policies. With the config model, MIB and PIB > going to last call now, IPSP expects to make progress now on a new security > gateway/policy discovery protocol. > > ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ > ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ > ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ > ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec-policy@mail.vpnc.org Fri Mar 23 17:07:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04928 for ; Fri, 23 Mar 2001 17:07:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA08322 for ipsec-policy-bks; Fri, 23 Mar 2001 12:45:08 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA08317 for ; Fri, 23 Mar 2001 12:45:07 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 23 Mar 2001 13:43:31 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Fri, 23 Mar 2001 13:43:30 -0700 From: "Hilarie Orman" To: , Cc: Subject: Re: granularity property in Common Information Model Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id MAA08318 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit It sounds to me as though the ID's are indeed mismatched. I don't know if anyone is using the larger set of ID types in Phase II, but the original idea had been that some ID's would be trusted to assert other ID's in phase 2. Hilarie >>> Ricky Charlet 03/20/01 09:37AM >>> Thanks Eric, I see your point that the phase 2 ID needs to be specified as to type. I had not thought of that before. But, the granularity property in the IPsecAction (what do we call it, object, group, table, thingie?) seems to me to be mismatched with the set of possible 2 ID types. Specifically, we do not need ports and protocols in phase 2 IDs but on the other hand, we do need specific addresses, subnets, and ranges of addresses in IPv4 and IPv6. (I don't know if FQDN, user@FQDN, DN, GN, and keyID are supportable as phase 2 IDs, could someone else inform our disussion here. I don't see any thing saying they can not be used at phase 2, but I also don't see how data, not verifiable in a packet, could be used as a phase 2 ID.) In the case of subnets and ranges of addresses, these cannot be inferred from a packet-on-hand and a granularity property. So now I am left with my original request and a new question. Can we please provide filtering control for ports and protocols? And now, how should we know what client ID to use in (and the type of) the phase 2 Identification payload? -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 Eric Vyncke wrote: > > Ricky, > > I do believe that granularity belongs to the action, when a packet > matches your filter, you start a negotiation using some phase 2 ID > based on the original packet and the granularity property. So, it really > belongs to the action side. > > But, you raise a good point for the DMTF information model which > also models the state of the SA. When a fine granularity is applied and > an SA is eventually created, a filter object will need to be created > and associated through FilterOfSecurityAssociation with SecurityAssociation. > > Hope this helps, > > Regards > > -eric > > At 10:05 19/03/2001 -0700, Ricky Charlet wrote: > >Howdy, > > > > I can't be at the IETF this week. But I would like to bring up an old > >argument about the granularity property in > >draft-ietf-ipsp-config-policy-model-02.txt. I hope that someone will > >persue this topic in the meeting today. > > > > > > The granluarity property is associated with an IPsecAction. It > > defines > >whether or not the SA will use port/protocol filtering. If granularity > >is "ON". then the ports/protocols are sucked out of the passing packet > >(which has already matched an ipaddress subnet filter) and the SA is > >built to filter on those ports/protocols. (WARNING: this has been a > >simplification of how granularity is really defined for the sake of > >clarity... granularity is reall just a bit more flexible than this.) > > > > I want to see port and protocol filtering moved away from the > > 'action' > >branch of the model and into the 'condition' branch. I strongly believe > >that Administrators should have control over the construction of > >port/protocol filters in just the same was as address filters. My > >reading of the architecture documets would require this admistrative > >control capability. My sence of the customer problem I am trying to > >solve requires this adminstrative control capability. And generalized > >view of modeling would suggest that granularity is a 'filtering' related > >property belonging with the other filtering properties in a model. > > > > > >-- > > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 > > Eric Vyncke > Distinguished Engineer Cisco Systems EMEA > Phone: +32-2-778.4677 Fax: +32-2-778.4300 > E-mail: evyncke@cisco.com Mobile: +32-475-312.458 (CHANGED) > PGP fingerprint: D35F BEF9 643F 656F 90F5 76C5 9CA1 C289 D398 B141 From owner-ipsec-policy@mail.vpnc.org Sun Mar 25 03:57:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05984 for ; Sun, 25 Mar 2001 03:57:28 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id AAA09023 for ipsec-policy-bks; Sun, 25 Mar 2001 00:03:55 -0800 (PST) Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA08999 for ; Sun, 25 Mar 2001 00:03:52 -0800 (PST) Received: from localhost (cs2773-200.houston.rr.com [24.27.73.200]) by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f2P81BZx013083 for ; Sun, 25 Mar 2001 02:02:00 -0600 Message-Id: <200103250802.f2P81BZx013083@sm10.texas.rr.com> X-Sender: hermag@excite.com From: "hermag@excite.com" To: ipsec-policy@vpnc.org Date: Sun, 25 Mar 2001 01:58:42 -0600 Subject: Would you like to recieve information on how to register your pet online for free? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__18477941_7122.46" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a Multipart MIME message. ------=_NextPart_000_001__18477941_7122.46 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__18477941_7122.46 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0 YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD1pc28tODg1OS0xIj4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4 dD0iIzAwMDAwMCI+DQo8cD5IZWxsbyE8L3A+DQo8cD5Xb3VsZCB5b3UgbGlrZSB0byBrbm93 IGhvdyB0byByZWdpc3RlciB5b3VyIHBldCBvbmxpbmUgZm9yIGZyZWU/PC9wPg0KPHA+SWYg eW91IHdvdWxkIGxpa2UgdG8gYmUgcmVtb3ZlZCBmcm9tIGV2ZXIgcmVjZWl2aW5nIGFub3Ro ZXIgZW1haWwgcGxlYXNlIHR5cGUgDQogIFJFTU9WRSBvbmx5IGluIHRoZSByZXR1cm4gc3Vi amVjdCBoZWFkZXIuIFdlIHJlc3BlY3QgeW91ciByaWdodCB0byBwcml2YWN5LjwvcD4NCjxw PklmIHlvdSB3b3VsZCBsaWtlIHRvIHJlY2VpdmUgbW9yZSBpbmZvcm1hdGlvbiBvbiBob3cg dG8gcmVnaXN0ZXIgeW91ciBwZXQgZm9yIA0KICBmcmVlIGp1c3QgcmVwbHkgdG8gdGhpcyBl bWFpbCBtZXNzYWdlIHdpdGggUExFQVNFIFNFTkQgSU5GTyBvbmx5IGluIHRoZSBzdWJqZWN0 IA0KICBoZWFkZXIuPC9wPg0KPHA+PC9wPg0KPHA+VGhhbmsgWW91PGJyPg0KPC9wPg0KPC9i b2R5Pg0KPC9odG1sPg0K ------=_NextPart_000_001__18477941_7122.46-- From owner-ipsec-policy@mail.vpnc.org Tue Mar 27 11:52:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22652 for ; Tue, 27 Mar 2001 11:52:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA19348 for ipsec-policy-bks; Tue, 27 Mar 2001 06:32:09 -0800 (PST) Received: from strange-brew.cisco.com (odd-brew.cisco.com [144.254.15.119]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA19344 for ; Tue, 27 Mar 2001 06:32:07 -0800 (PST) Received: from EVYNCKE-W2K.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA13412; Tue, 27 Mar 2001 16:31:34 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010327161340.01d40fe8@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Mar 2001 16:31:27 +0100 To: Ricky Charlet From: Eric Vyncke Subject: Re: granularity property in Common Information Model Cc: ".ipsec-policy" In-Reply-To: <3AB78753.1E346DAE@redcreek.com> References: <4.3.2.7.2.20010319210605.00b9f6e8@brussels.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rick, Obviously both the I-D and my previous email messages are not crystal clear :-( (I share your comment between parenthesis about the applicable phase 2 ID, for me this could possibly be IPV[46] address, subnet or range of addresses). Section 4.6.2 of RFC 2407 specifies the possible formats for an ID payload. While it clearly says that IP protocol type and port is to be set to 0 or to UDP port 500 for phase 1 ID, it also says that protocol type and port can be set to 0 (with 0 meaning wild card) or to a specific value for phase 2 ID. Let's do it with an example, the 'triggering' packet is from 192.168.1.1 TCP/1024 to 10.1.1.1 TCP/80, the SACondition filter is any source IP from 192.168.1.* to 10.*.*.*, then depending on the granularity, IKE should negotiate phase 2 SA for the following phase 2 ID: - subnet -> <192.168.1.*,protocol=0,port=0> & <10.*.*.*,protocol=0,port=0> for all protocols using ID_IPV4_ADDR_SUBNET format; - host -> <192.168.1.1,protocol=0,port=0> & <10.1.1.1,,protocol=0,port=0> for all protocols using ID_IPV4_ADDR format; - protocol -> <192.168.1.1,protocol=6,port=0> & <10.1.1.1,protocol=6,port=0> for all TCP ports using ID_IPV4_ADDR format; - port -> <192.168.1.1,protocol=6,port=1024> & <10.1.1.1,protocol=6,port=80) only for the triggering TCP flow using ID_IPV4_ADDR format; On purpose, we simplified the information model by removing some possible variations (like subnet on one side and address on the other side) because we feel that no implementation are using those variations. Of course, we can be wrong and the model could always be improved. NB: there is currently no provision in the IM to model a phase 2 of ID_IPV4_ADDR_RANGE which may be a concern if some implementations are using this kind of ID (and some recent troubleshooting between Cisco and Redcreek concentrators make believe that you are using address ranges ;-) ). If needed, we could also extend the IM to represent an address range as a phase 2 ID. Anyway, if you believe that the above explanation is clearer, I would be glad to augment the I-D with it. Hope this helps -eric At 09:37 20/03/2001 -0700, Ricky Charlet wrote: >Thanks Eric, > > I see your point that the phase 2 ID needs to be specified as to > type. >I had not thought of that before. > > But, the granularity property in the IPsecAction (what do we call it, >object, group, table, thingie?) seems to me to be mismatched with the >set of possible 2 ID types. Specifically, we do not need ports and >protocols in phase 2 IDs but on the other hand, we do need specific >addresses, subnets, and ranges of addresses in IPv4 and IPv6. (I don't >know if FQDN, user@FQDN, DN, GN, and keyID are supportable as phase 2 >IDs, could someone else inform our disussion here. I don't see any thing >saying they can not be used at phase 2, but I also don't see how data, >not verifiable in a packet, could be used as a phase 2 ID.) In the case >of subnets and ranges of addresses, these cannot be inferred from a >packet-on-hand and a granularity property. > > So now I am left with my original request and a new question. Can we >please provide filtering control for ports and protocols? And now, how >should we know what client ID to use in (and the type of) the phase 2 >Identification payload? Eric Vyncke Distinguished Engineer Cisco Systems EMEA Phone: +32-2-778-4677 Fax: +32-2-778-4300 E-mail: evyncke@cisco.com Mobile: +32-475-312-458 (CHANGED) PGP fingerprint: D35F BEF9 643F 656F 90F5 76C5 9CA1 C289 D398 B141 From owner-ipsec-policy@mail.vpnc.org Tue Mar 27 17:04:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01444 for ; Tue, 27 Mar 2001 17:04:46 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA14942 for ipsec-policy-bks; Tue, 27 Mar 2001 13:05:40 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA14935 for ; Tue, 27 Mar 2001 13:05:39 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA24183; Tue, 27 Mar 2001 13:05:33 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22124; Tue, 27 Mar 2001 16:05:32 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2RL5Q919665; Tue, 27 Mar 2001 16:05:26 -0500 (EST) Message-Id: <200103272105.f2RL5Q919665@thunk.east.sun.com> From: Bill Sommerfeld To: jari.arkko@piuha.net cc: ipsec-policy@vpnc.org, lsanchez@megisto.com, jari.arkko@ericsson.fi Subject: Re: pf_policy -- what is it? In-reply-to: Your message of "Wed, 28 Mar 2001 00:00:19 +0300." <3AC0FF63.3010008@piuha.net> Reply-to: sommerfeld@East.Sun.COM Date: Tue, 27 Mar 2001 16:05:26 -0500 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Is this perhaps related to PF_KEY extensions, to > cover policy (or to get rid of policy as I did > once upon time in a now-expired I-D)? Policy does not belong in PF_KEY. > Or a new PF interface for conveying policy to a kernel? Yes. From owner-ipsec-policy@mail.vpnc.org Tue Mar 27 17:08:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01589 for ; Tue, 27 Mar 2001 17:08:28 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA14375 for ipsec-policy-bks; Tue, 27 Mar 2001 12:57:45 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA14366 for ; Tue, 27 Mar 2001 12:57:43 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id E16ED6A901; Tue, 27 Mar 2001 23:57:35 +0300 (EEST) Message-ID: <3AC0FF63.3010008@piuha.net> Date: Wed, 28 Mar 2001 00:00:19 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-icclin i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: ipsec-policy@vpnc.org, lsanchez@megisto.com Cc: jari.arkko@ericsson.fi Subject: pf_policy -- what is it? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi. I couldn't make it to the IPSP WG meeting last monday due to some other meetings, but I noticed the following item in Luis Sanchez's "next steps" discussion: >- Publish PF_POLICY draft May I ask what this is, in more detail? I can't find anything related to in the look that I have taken to the archives, nor did I find anything from relating to this from the internet drafts directory. Is this perhaps related to PF_KEY extensions, to cover policy (or to get rid of policy as I did once upon time in a now-expired I-D)? Or a new PF interface for conveying policy to a kernel? Or something else? Jari From owner-ipsec-policy@mail.vpnc.org Tue Mar 27 17:39:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02130 for ; Tue, 27 Mar 2001 17:39:13 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA17380 for ipsec-policy-bks; Tue, 27 Mar 2001 13:34:50 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA17376 for ; Tue, 27 Mar 2001 13:34:48 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 24CD36A901; Wed, 28 Mar 2001 00:34:50 +0300 (EEST) Message-ID: <3AC1081A.2030406@piuha.net> Date: Wed, 28 Mar 2001 00:37:30 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-icclin i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: sommerfeld@East.Sun.COM Cc: jari.arkko@piuha.net, ipsec-policy@vpnc.org, lsanchez@megisto.com, jari.arkko@ericsson.fi Subject: Re: pf_policy -- what is it? References: <200103272105.f2RL5Q919665@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: >> Is this perhaps related to PF_KEY extensions, to >> cover policy (or to get rid of policy as I did >> once upon time in a now-expired I-D)? > > Policy does not belong in PF_KEY. > >> Or a new PF interface for conveying policy to a kernel? > > Yes. Aa. Do you have any more details? Is there anything written on this subject yet? Any requirements? What's the plan? Anything? [One conclusion that I've personally come to is that kernels shouldn't know too much of policy; only the necessary parts. For instance, I they should know which traffic patterns should trigger key management actions, but they do not necessarily need to to know proposal lists sent in km protocols etc.] Jari From owner-ipsec-policy@mail.vpnc.org Tue Mar 27 18:41:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03356 for ; Tue, 27 Mar 2001 18:41:40 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id OAA20835 for ipsec-policy-bks; Tue, 27 Mar 2001 14:42:09 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA20825 for ; Tue, 27 Mar 2001 14:42:06 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 27 Mar 2001 15:41:44 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 27 Mar 2001 15:41:38 -0700 From: "Hilarie Orman" To: , , Cc: Subject: Re: pf_policy -- what is it? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id OAA20827 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit PF_POLICY is like PF_KEY, but for policy. Hilarie >>> Jari Arkko 03/27/01 02:00PM >>> Hi. I couldn't make it to the IPSP WG meeting last monday due to some other meetings, but I noticed the following item in Luis Sanchez's "next steps" discussion: >- Publish PF_POLICY draft May I ask what this is, in more detail? I can't find anything related to in the look that I have taken to the archives, nor did I find anything from relating to this from the internet drafts directory. Is this perhaps related to PF_KEY extensions, to cover policy (or to get rid of policy as I did once upon time in a now-expired I-D)? Or a new PF interface for conveying policy to a kernel? Or something else? Jari From owner-ipsec-policy@mail.vpnc.org Tue Mar 27 22:10:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11954 for ; Tue, 27 Mar 2001 22:10:44 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id SAA01783 for ipsec-policy-bks; Tue, 27 Mar 2001 18:11:21 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA01778 for ; Tue, 27 Mar 2001 18:11:18 -0800 (PST) Received: from megisto.com (sanchez.megisto.com [192.168.20.89]) by megisto-sql1.megisto.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HQBRM50M; Tue, 27 Mar 2001 21:05:50 -0500 Message-ID: <3AC147E7.B27463EE@megisto.com> Date: Tue, 27 Mar 2001 20:09:43 -0600 From: "Luis A. Sanchez" Organization: Megisto Systems X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: sommerfeld@East.Sun.COM, ipsec-policy@vpnc.org, jari.arkko@ericsson.fi Subject: Re: pf_policy -- what is it? References: <200103272105.f2RL5Q919665@thunk.east.sun.com> <3AC1081A.2030406@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Bill Sommerfeld wrote: > > >> Is this perhaps related to PF_KEY extensions, to > >> cover policy (or to get rid of policy as I did > >> once upon time in a now-expired I-D)? > > > > Policy does not belong in PF_KEY. > > > >> Or a new PF interface for conveying policy to a kernel? > > > > Yes. > > Aa. Do you have any more details? Is > there anything written on this subject yet? > Any requirements? What's the plan? Anything? One step at the time. No, we don't have a first draft written yet. Bill Sommerfeld is the draft editor. The goal is to begin discussion of this work in this list. So, if you have done any work in this area please share this with the list. The plan is to have a first draft written before London. > > > [One conclusion that I've personally come > to is that kernels shouldn't know too much > of policy; only the necessary parts. For > instance, I they should know which traffic > patterns should trigger key management actions, > but they do not necessarily need to to know > proposal lists sent in km protocols etc.] - Agree. > > > Jari From owner-ipsec-policy@mail.vpnc.org Tue Mar 27 22:17:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12398 for ; Tue, 27 Mar 2001 22:17:55 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id SAA01412 for ipsec-policy-bks; Tue, 27 Mar 2001 18:05:56 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA01404 for ; Tue, 27 Mar 2001 18:05:52 -0800 (PST) Received: from megisto.com (sanchez.megisto.com [192.168.20.89]) by megisto-sql1.megisto.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HQBRM50G; Tue, 27 Mar 2001 21:00:24 -0500 Message-ID: <3AC146A1.F2C3A220@megisto.com> Date: Tue, 27 Mar 2001 20:04:17 -0600 From: "Luis A. Sanchez" Organization: Megisto Systems X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: ipsec-policy@vpnc.org, jari.arkko@ericsson.fi Subject: Re: pf_policy -- what is it? References: <3AC0FF63.3010008@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari, PF_POLICY would be a new socket protocol family used by privileged policy applications to communicate with an operating system's policy management internals. PF_KEY is analogous to PF_ROUTE and PF_KEY. Luis Jari Arkko wrote: > Hi. I couldn't make it to the IPSP WG meeting > last monday due to some other meetings, but > I noticed the following item in Luis Sanchez's > "next steps" discussion: > > >- Publish PF_POLICY draft > > May I ask what this is, in more detail? I can't > find anything related to in the look that I have > taken to the archives, nor did I find anything > from relating to this from the internet drafts > directory. > > Is this perhaps related to PF_KEY extensions, to > cover policy (or to get rid of policy as I did > once upon time in a now-expired I-D)? Or a > new PF interface for conveying policy to a > kernel? Or something else? > > Jari From owner-ipsec-policy@mail.vpnc.org Wed Mar 28 10:13:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00514 for ; Wed, 28 Mar 2001 10:13:43 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id GAA02142 for ipsec-policy-bks; Wed, 28 Mar 2001 06:12:44 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA02132 for ; Wed, 28 Mar 2001 06:12:42 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 323216A901; Wed, 28 Mar 2001 17:12:42 +0300 (EEST) Message-ID: <3AC1F1FD.8040401@piuha.net> Date: Wed, 28 Mar 2001 17:15:25 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-icclin i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: "Luis A. Sanchez" Cc: sommerfeld@East.Sun.COM, ipsec-policy@vpnc.org, jari.arkko@ericsson.fi Subject: Re: pf_policy -- what is it? References: <200103272105.f2RL5Q919665@thunk.east.sun.com> <3AC1081A.2030406@piuha.net> <3AC147E7.B27463EE@megisto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Luis A. Sanchez wrote: > work in this list. So, if you have done any work in this area please > share this with the list. Well, I haven't really worked exactly on this problem, but I have done some previous work on a related area. Namely, I had this idea about what should be in the kernel and what not, and based on that I modified the PF_KEY protocol in manner. I realize the PF_KEY as such isn't interesting in this discussion, but the model behind may be. The draft is expired but can be accessed at [1]. The basic idea was that kernels only store policy information regarding traffic patterns, and then use _opaque references_ to some policy identifiers, that are then treated on a higher level, in policy and key management apps. Only they would know about things like proposal lists and so on. The traffic patterns on the other hand, _have_ to be known by the kernel, otherwise they can't match a packet and decide what to do. The draft was partially also grown from frustration to current PF_KEY (RFC 2367) which doesn't completely support all features needed in IPsec, and extending it to do e.g. bundles seems to lead to a complicated design unless something drastic such as removal of policy information from it and the kernel is done. I think the discussion of what exactly should go to the kernel through this PF_POLICY is the first priority item in designing PF_POLICY. Maybe some of the ideas above could be reused here; in any case I'd be happy to participate in the discussion. Jari [1] http://www.arkko.com/publications/draft-arkko-pfkey-reference-00.txt From owner-ipsec-policy@mail.vpnc.org Wed Mar 28 17:43:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14304 for ; Wed, 28 Mar 2001 17:43:33 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA29996 for ipsec-policy-bks; Wed, 28 Mar 2001 13:08:04 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA29986 for ; Wed, 28 Mar 2001 13:08:02 -0800 (PST) From: Man.M.Li@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2SL87g15817 for ; Wed, 28 Mar 2001 15:08:07 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 28 Mar 2001 15:08:04 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 28 Mar 2001 15:08:04 -0600 Message-ID: To: ipsec-policy@vpnc.org Subject: nested SAs Date: Wed, 28 Mar 2001 15:08:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, To continue our discussions about nested SAs, I am referring to RFC 2401 Section 4.5 case 4: ====================================================== | | |============================== | || | | || ---|----------------------|--- || | | | | H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | ^ | Intranet) | | ------------------------------ could be dialup admin. boundary (optional) to PPP/ARA server H1 and H2 are hosts and SG2 is a security gateway. Two SAs are shown between H1 and H2 and between H1 and SG2. For the time being, let's assume that both SAs are tunnels. Call the tunnel between H1 and H2 T1 and between H1 and SG2 T2. From H1's point of view, it needs to take two actions for packets that go from H1 to H2: wrap the packet inside tunnel T1 and then wrap it again inside tunnel T2. There seem to be two solutions for the policy in H1's SPD (hence the policy pushed down from PDP): Solution #1: Single rule with multiple actions: selector: src addr = H1, dst addr = H2 actions: apply T1 and then apply T2 Solution #2: Multiple rules each with single action: rule #1 : selector: src addr = H1, dst addr = H2 action: apply T1 rule #2 : selector: src addr = H1, dst addr = H2, protocol = T1's protocol action: apply T2 If I understand it correctly, RFC 2401 seems to suggest solution #1 and I know that there are implementations out there for solution #1. It is also the solution proposed in IPsec PIB. The second solution is proposed in the ietf IPsec Information model. The issue with solution #2 is that it forces the implementation to make multiple searches of the SPD. In this case, the first search matches rule #1. After the action of that rule is applied, another search (with the T1 wrapped packet) of the SPD hits rule #2. After the action of rule #2 is applied, another search is necessary to make sure that there is no more rules to be applied before sending out this packet. This means that all SINGLE SA needs to go through two searches of the SPD in order to accomodate possible nested SAs. Since nested SAs are not as common as single SA, this does not seem to be an efficient solution. Let me know if I missed some important points. Man Li Nokia 5 Wayside Road, Burlington, MA 01803 man.m.li@nokia.com phone 1-781-993-3923 GSM 1-781-492-2850 From owner-ipsec-policy@mail.vpnc.org Thu Mar 29 09:28:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15362 for ; Thu, 29 Mar 2001 09:28:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA25727 for ipsec-policy-bks; Thu, 29 Mar 2001 05:23:17 -0800 (PST) Received: from mailgate.risccores.com ([194.202.198.225]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA25716 for ; Thu, 29 Mar 2001 05:23:15 -0800 (PST) From: Steve.Robinson@psti.com Subject: Re: nested SAs To: Man.M.Li@nokia.com Cc: ipsec-policy@vpnc.org, owner-ipsec-policy@mail.vpnc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 29 Mar 2001 09:25:46 -0400 X-MIMETrack: Serialize by Router on Notes1/ARC(Release 5.0.5 |September 22, 2000) at 29/03/2001 02:24:03 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi All, Well, that all depends on what you classify as simpler. While the second solution does result in two lookups, if your lookup algorithm is efficient, say O(log n), then two lookups are only 2 x O(log n) and your encryption and decryption of the packet will take much longer than the lookups will. The second alternative is also simpler from the point of view of implementation, as the first alternative is going to have quite a few complex cases to deal with. I suppose it really is a personal preference, and I should point out that part of the reason I support alternative two is that the IP routing table I am using lends itself easily to this alternative, due to the abstraction of some elements, also, the code size for the second alternative is smaller as a result. Depending on how your individual stack is set up, you may not agree with me -- however, I reread section 4.5 and I don't see the document leaning in either direction, from what I read the section only covers packet formats and required behaviour, not implementation issues. Section 5 refers to policy w.r.t. packet processing, but again, doesn't give specifics. You could, if you really wanted to be masochistic, have a separate SA lookup for each element in the packet (assuming that the tunnels used both AH and ESP) and still not violate the RFC. Man.M.Li@nokia.com Sent by: To: ipsec-policy@vpnc.org owner-ipsec-policy@mai cc: l.vpnc.org Subject: nested SAs 03/28/01 04:08 PM Hi, To continue our discussions about nested SAs, I am referring to RFC 2401 Section 4.5 case 4: ====================================================== | | |============================== | || | | || ---|----------------------|--- || | | | | H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | ^ | Intranet) | | ------------------------------ could be dialup admin. boundary (optional) to PPP/ARA server H1 and H2 are hosts and SG2 is a security gateway. Two SAs are shown between H1 and H2 and between H1 and SG2. For the time being, let's assume that both SAs are tunnels. Call the tunnel between H1 and H2 T1 and between H1 and SG2 T2. From H1's point of view, it needs to take two actions for packets that go from H1 to H2: wrap the packet inside tunnel T1 and then wrap it again inside tunnel T2. There seem to be two solutions for the policy in H1's SPD (hence the policy pushed down from PDP): Solution #1: Single rule with multiple actions: selector: src addr = H1, dst addr = H2 actions: apply T1 and then apply T2 Solution #2: Multiple rules each with single action: rule #1 : selector: src addr = H1, dst addr = H2 action: apply T1 rule #2 : selector: src addr = H1, dst addr = H2, protocol = T1's protocol action: apply T2 If I understand it correctly, RFC 2401 seems to suggest solution #1 and I know that there are implementations out there for solution #1. It is also the solution proposed in IPsec PIB. The second solution is proposed in the ietf IPsec Information model. The issue with solution #2 is that it forces the implementation to make multiple searches of the SPD. In this case, the first search matches rule #1. After the action of that rule is applied, another search (with the T1 wrapped packet) of the SPD hits rule #2. After the action of rule #2 is applied, another search is necessary to make sure that there is no more rules to be applied before sending out this packet. This means that all SINGLE SA needs to go through two searches of the SPD in order to accomodate possible nested SAs. Since nested SAs are not as common as single SA, this does not seem to be an efficient solution. Let me know if I missed some important points. Man Li Nokia 5 Wayside Road, Burlington, MA 01803 man.m.li@nokia.com phone 1-781-993-3923 GSM 1-781-492-2850 From owner-ipsec-policy@mail.vpnc.org Thu Mar 29 11:52:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23918 for ; Thu, 29 Mar 2001 11:52:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA07031 for ipsec-policy-bks; Thu, 29 Mar 2001 07:31:33 -0800 (PST) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA07021 for ; Thu, 29 Mar 2001 07:31:31 -0800 (PST) Received: from EVYNCKE-W2K.cisco.com (dhcp-nic-val-26-103.cisco.com [64.103.26.103]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA28957; Thu, 29 Mar 2001 17:30:56 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010329161113.01c8a210@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Mar 2001 16:12:43 +0200 To: Man.M.Li@nokia.com From: Eric Vyncke Subject: Re: nested SAs Cc: ipsec-policy@vpnc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Man, Your explanation is 100% correct. After the IPSP WG session, Jamie, Lee and myself agreed to change the information model. The -03 draft will have multiple actions in one rule :-) Regards -eric At 15:08 28/03/2001 -0600, Man.M.Li@nokia.com wrote: >Hi, > >To continue our discussions about nested SAs, I am referring to RFC 2401 >Section 4.5 case 4: > > ====================================================== > | | > |============================== | > || | | > || ---|----------------------|--- > || | | | | > H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | > ^ | Intranet) | > | ------------------------------ > could be dialup admin. boundary (optional) > to PPP/ARA server > >H1 and H2 are hosts and SG2 is a security gateway. Two SAs are shown between >H1 and H2 and between H1 and SG2. > >For the time being, let's assume that both SAs are tunnels. Call the tunnel >between H1 and H2 T1 and between H1 and SG2 T2. > > >From H1's point of view, it needs to take two actions for packets that go >from H1 to H2: wrap the packet inside tunnel T1 and then wrap it again >inside tunnel T2. > >There seem to be two solutions for the policy in H1's SPD (hence the policy >pushed down from PDP): > >Solution #1: Single rule with multiple actions: > selector: src addr = H1, dst addr = H2 > actions: apply T1 and then apply T2 > >Solution #2: Multiple rules each with single action: > rule #1 : > selector: src addr = H1, dst addr = H2 > action: apply T1 > rule #2 : > selector: src addr = H1, dst addr = H2, protocol = T1's protocol > action: apply T2 > >If I understand it correctly, RFC 2401 seems to suggest solution #1 and I >know that there are implementations out there for solution #1. It is also >the solution proposed in IPsec PIB. > >The second solution is proposed in the ietf IPsec Information model. The >issue with solution #2 is that it forces the implementation to make multiple >searches of the SPD. In this case, the first search matches rule #1. After >the action of that rule is applied, another search (with the T1 wrapped >packet) of the SPD hits rule #2. After the action of rule #2 is applied, >another search is necessary to make sure that there is no more rules to be >applied before sending out this packet. > >This means that all SINGLE SA needs to go through two searches of the SPD in >order to accomodate possible nested SAs. Since nested SAs are not as common >as single SA, this does not seem to be an efficient solution. > >Let me know if I missed some important points. > >Man Li >Nokia >5 Wayside Road, Burlington, MA 01803 >man.m.li@nokia.com >phone 1-781-993-3923 >GSM 1-781-492-2850 Eric Vyncke Distinguished Engineer Cisco Systems EMEA Phone: +32-2-778-4677 Fax: +32-2-778-4300 E-mail: evyncke@cisco.com Mobile: +32-475-312-458 (CHANGED) PGP fingerprint: D35F BEF9 643F 656F 90F5 76C5 9CA1 C289 D398 B141