From owner-ipsec-policy@mail.vpnc.org Mon Jan 7 12:42:44 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22220 for ; Mon, 7 Jan 2002 12:42:44 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g07GeuW28713 for ipsec-policy-bks; Mon, 7 Jan 2002 08:40:56 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Get328709 for ; Mon, 7 Jan 2002 08:40:55 -0800 (PST) Received: by sentry.gw.tislabs.com; id LAA18076; Mon, 7 Jan 2002 11:46:10 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma018065; Mon, 7 Jan 02 11:45:54 -0500 Received: (from balenson@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g07Gedn29869 for ipsec-policy@vpnc.org; Mon, 7 Jan 2002 11:40:39 -0500 (EST) Date: Mon, 7 Jan 2002 11:40:39 -0500 (EST) Message-Id: <200201071640.g07Gedn29869@raven.gw.tislabs.com> From: balenson@tislabs.com To: ipsec-policy@vpnc.org Subject: ANNOUNCE: NDSS'02 Early Registration Deadlines Approaching Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: R E G I S T E R N O W ! ! EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 HOTEL RESERVATIONS MUST BE MADE BY January 8, 2002 FINAL PROGRAM available at http://www.isoc.org/isoc/conferences/ndss/02/final.shtml. 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) hosted by THE INTERNET SOCIETY February 6 - 8, 2002 Catamaran Resort Hotel, San Diego, California NDSS is the premier event for security experts around the world. Come to the 9th Annual NDSS and share in the latest concepts on the Internet security front. Southern California's Catamaran Resort Hotel offers spectacular views of Mission Bay and the Pacific Ocean, and is a warm sunny getaway with opportunities to confer with your security counterparts from across the globe. For more information and on line registration go to the NDSS'02 web site: http://www.isoc.org/ndss02. Questions about registration? Contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org. Interested in sponsoring a give-away or meal? Contact Martin Kupres at +1 41 22 807 1444 or send e-mail to sponsorndss@isoc.org. From subs-reminder@vpnc.org Mon Jan 7 23:05:23 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06235 for ; Mon, 7 Jan 2002 23:05:22 -0500 (EST) From: subs-reminder@vpnc.org Received: by above.proper.com (8.11.6/8.11.3) id g0845Lk04315; Mon, 7 Jan 2002 20:05:21 -0800 (PST) Date: Mon, 7 Jan 2002 20:05:21 -0800 (PST) Message-Id: <200201080405.g0845Lk04315@above.proper.com> To: ipsp-archive@ietf.org Subject: [[422184910]] Subscription to ipsec-policy for ipsp-archive@lists.ietf.org Greetings. This message is a periodic reminder that ipsp-archive@lists.ietf.org is subscribed to the ipsec-policy mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ipsec-policy mailing list, you do not need to do anything. On the other hand, if you want to unsubscribe from this list, go to the following link: You can also unsubscribe by email. To do so, you can respond to this message and I will unsubscribe you by hand in the next few days. Alternatively, you can send a plain-text message to: ipsec-policy-request@vpnc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "ipsp-archive@lists.ietf.org". If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ipsec-policy@mail.vpnc.org Tue Jan 8 05:45:01 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18748 for ; Tue, 8 Jan 2002 05:45:00 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g089mWw11114 for ipsec-policy-bks; Tue, 8 Jan 2002 01:48:32 -0800 (PST) Received: from proxy.intech.ru (core.intech.ru [213.24.18.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g089mT311105 for ; Tue, 8 Jan 2002 01:48:30 -0800 (PST) Received: from valley.srcc.intech.ru (eth0-2-10m.core.srcc.intech.ru [192.168.2.1]) by proxy.intech.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZKM7QQ8W; Tue, 8 Jan 2002 12:48:41 +0300 Received: from stasws ([192.168.3.133]) by valley.srcc.intech.ru (8.9.3/8.9.3) with SMTP id MAA14027 for ; Tue, 8 Jan 2002 12:58:32 +0300 Message-ID: <002b01c19829$d7dc61b0$8503a8c0@ppo.intech.ru> From: "Stanislav Dergatchev" To: Subject: Using Hierarchical Colored Petri Nets for modelling of IP/IPSec and Denial Service Attack on TCP Date: Tue, 8 Jan 2002 12:50:02 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C19842.FD0C9BD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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_0028_01C19842.FD0C9BD0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hello all, I would greatly appreciate receiving an electronic copy of the paper regarding using Hierarchical Colored Petri Nets for modelling of = IP/IPSec and Denial Service Attack on TCP and any other papers of similar nature. Thank you for any suggestions. Stanislav Dergachev ------=_NextPart_000_0028_01C19842.FD0C9BD0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hello all,

I=20 would greatly appreciate receiving an electronic copy of the = paper
regarding=20 using Hierarchical Colored Petri Nets for modelling of IP/IPSec and = Denial=20 Service Attack on TCP
and any = other papers=20 of similar nature.
Thank you for any suggestions.
Stanislav=20 Dergachev

------=_NextPart_000_0028_01C19842.FD0C9BD0-- From owner-ipsec-policy@mail.vpnc.org Mon Jan 14 13:23:02 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11055 for ; Mon, 14 Jan 2002 13:23:01 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0EHUSt12853 for ipsec-policy-bks; Mon, 14 Jan 2002 09:30:28 -0800 (PST) Received: from jxmls03.se.mediaone.net (jxmls03.se.mediaone.net [24.129.0.111]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0EHUQ312847 for ; Mon, 14 Jan 2002 09:30:26 -0800 (PST) Received: from [192.168.1.68] (att-98-5-36.atl.mediaone.net [24.98.5.36]) by jxmls03.se.mediaone.net (8.11.1/8.11.1) with ESMTP id g0EHVOv14091 for ; Mon, 14 Jan 2002 12:31:25 -0500 (EST) Mime-Version: 1.0 Message-Id: Date: Mon, 14 Jan 2002 12:27:21 -0500 To: ipsec-policy@vpnc.org From: Robert Story Subject: questions on model/MIB Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1) IKE Identity and IP Endpoints are both used to describe the local side of things, right? 2) The policy model contains a PeerGateway and PeerIdentity, but I can't find a corresponding table in the MIB. How would one define a gateway for a peer using the MIB? 3) In the MIB, I also couldn't find an equivalent to the IPsecPolicyGroup. The closest thing is the ipsecProposalTable, which I think is not the best way to group policies. It seems to me that having a primary index of ipsecActionName limits reuse of rows. I also don't understand why the second index is the proposal name, instead of priority. I think this table needs major reconstruction. I have a few ideas, unless someone has a good explanation for the current incarnation of the table. From owner-ipsec-policy@mail.vpnc.org Tue Jan 22 13:42:49 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04232 for ; Tue, 22 Jan 2002 13:42:49 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0MI1Vp26872 for ipsec-policy-bks; Tue, 22 Jan 2002 10:01:31 -0800 (PST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0MI1T326868 for ; Tue, 22 Jan 2002 10:01:29 -0800 (PST) Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA102818; Tue, 22 Jan 2002 11:57:09 -0600 Received: from lrafalow (dyn9-27-16-134.raleigh.ibm.com [9.27.16.134]) by southrelay01.raleigh.ibm.com (8.11.1m3/NCO v5.01) with SMTP id g0MI1S1135276; Tue, 22 Jan 2002 13:01:28 -0500 Message-ID: <000701c1a36e$bbaece10$86101b09@lrafalow> Reply-To: "Lee Rafalow" From: "Lee Rafalow" To: , "Robert Story" References: Subject: Re: questions on model/MIB Date: Tue, 22 Jan 2002 13:00:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > 1) IKE Identity and IP Endpoints are both used to describe the local side > of things, right? Yes. Lee M. Rafalow Voice: 1-919-254-4455, Fax: 1-919-254-6243 IBM Internet Technology Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709 USA Alternate email: rafalow@us.ibm.com Personal email: lrafalow@mindspring.com From owner-ipsec-policy@mail.vpnc.org Wed Jan 23 14:21:10 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21380 for ; Wed, 23 Jan 2002 14:21:04 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0NIYIZ08121 for ipsec-policy-bks; Wed, 23 Jan 2002 10:34:18 -0800 (PST) Received: from rebma.mikesoffice.com (adsl-64-165-72-146.dsl.scrm01.pacbell.net [64.165.72.146]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NIYH308117 for ; Wed, 23 Jan 2002 10:34:17 -0800 (PST) Received: by rebma.mikesoffice.com (Postfix, from userid 1001) id 8F62B1C0CF; Wed, 23 Jan 2002 10:34:05 -0800 (PST) To: ipsec-policy@vpnc.org Subject: config-policy-mib TransformOfPreconfiguredAction Question From: Michael Baer Organization: NAI Labs Date: Wed, 23 Jan 2002 10:33:58 -0800 Message-ID: <861ygg6hnt.fsf@mikesoffice.com> User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Civil Service, powerpc-unknown-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 25 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I am not understanding how the TransformOfPreconfiguredAction class works and I have a couple questions. The description says it associates a preconfiguredSAAction class to 1 to 3 SATransforms. The properties show an association in the Antecedent of 2..6 SATransforms. These don't seem to match? But Also, the properties include an SPI value and a Direction value. It is my understanding that you need a unique SPI and Direction value for every SATransform (i.e. for an IPsec AH, ESP, or IPcomp transform). But this class (TransformOfPreconfiguredAction) would seem to indicate the use of one value of SPI and Direction for up to 6 transforms? Any help would be appreciate, thanks, Mike -- Michael Baer baerm@mikesoffice.com NAI Labs From owner-ipsec-policy@mail.vpnc.org Wed Jan 23 14:26:17 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21531 for ; Wed, 23 Jan 2002 14:26:17 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0NITfD07953 for ipsec-policy-bks; Wed, 23 Jan 2002 10:29:41 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NITe307949 for ; Wed, 23 Jan 2002 10:29:40 -0800 (PST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0NIVIQ00537 for ; Wed, 23 Jan 2002 12:31:18 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 23 Jan 2002 12:29:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 23 Jan 2002 12:28:35 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Granularity in IPsec config model X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 23 Jan 2002 13:28:35 -0500 Message-ID: Thread-Topic: questions on model/MIB Thread-Index: AcGjc4PubLiKQrMWRoSCE/FodN7uIwAxhr6Q From: To: X-OriginalArrivalTime: 23 Jan 2002 18:28:35.0935 (UTC) FILETIME=[C51136F0:01C1A43B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g0NITe307950 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, Section 6.11.4 of draft-ietf-ipsp-config-policy-model-04.txt describes the Granularity property. It seems to me that if one would like to use only the source and protocol of the triggering packet or only the source address of the triggering packet, this cannot be done with any of the Granularity values. Is there a reason that the Granularity property is limited to the four values only? Best regards Man From owner-ipsec-policy@mail.vpnc.org Fri Jan 25 12:38:20 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08502 for ; Fri, 25 Jan 2002 12:38:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0PGdL313092 for ipsec-policy-bks; Fri, 25 Jan 2002 08:39:21 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0PGdJ313088 for ; Fri, 25 Jan 2002 08:39:19 -0800 (PST) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 17:04:20 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D829DE34E@lat3721.rd.francetelecom.fr> From: MORAND Pierrick FTRD/DMI/CAE To: "IPSEC-POLICY (E-mail)" , "RAP (E-mail)" Subject: COPS-PR and IPSec PIB implementation Date: Fri, 25 Jan 2002 17:04:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-74498d10-1169-11d6-b1e4-00508b69ab48" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-74498d10-1169-11d6-b1e4-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A5B9.F2B6BEC0" ------_=_NextPart_001_01C1A5B9.F2B6BEC0 Content-Type: text/plain; charset="iso-8859-1" Hi, We've implemented a COPS-PR prototype architecture (COPS-PR, PDP, PEP Proxies Server, in Java) for the dynamic provisioning of an IPSec-based IP VPN service offering, based on version 05 of the Framework PIB and on version 03 of the IPSec PIB drafts, respectively. We're therefore interested if any equipment vendor representative who has subscribed to this mailing list has the same kind of implementation experience (or intends to do so), and if he/she would like to share some information with us. If so, please contact me directly, and my apologies for any disturbance this message may have caused. Cheers, Pierrick. Pierrick Morand france telecom R&D/DMI/SIR/IPI Tel : +33 2 31 75 91 79 - Fax : +33 2 31 73 56 26 Email :pierrick.morand@rd.francetelecom.com ------_=_NextPart_001_01C1A5B9.F2B6BEC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable COPS-PR and IPSec PIB implementation

Hi,

We've implemented a COPS-PR = prototype architecture (COPS-PR, PDP, PEP Proxies Server, in Java) for = the dynamic provisioning of an IPSec-based IP VPN service offering, = based on version 05 of the Framework PIB and on version 03 of the IPSec = PIB drafts, respectively.

We're therefore interested if = any equipment vendor representative who has subscribed to this mailing = list has the same kind of implementation experience (or intends to do = so), and if he/she would like to share some information with = us.

If so, please contact me = directly, and my apologies for any disturbance this message may have = caused.

Cheers,

Pierrick.

Pierrick = Morand
france = telecom R&D/DMI/SIR/IPI
Tel   = : +33 2 31 75 91 79 -  Fax : +33 2 31 73 56 26
Email = :pierrick.morand@rd.francetelecom.com


------_=_NextPart_001_01C1A5B9.F2B6BEC0-- ------=_NextPartTM-000-74498d10-1169-11d6-b1e4-00508b69ab48-- From owner-ipsec-policy@mail.vpnc.org Sat Jan 26 21:27:44 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13540 for ; Sat, 26 Jan 2002 21:27:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0R1nwf02754 for ipsec-policy-bks; Sat, 26 Jan 2002 17:49:58 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0R1nv302748 for ; Sat, 26 Jan 2002 17:49:57 -0800 (PST) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g0R1nqn24085 for ; Sat, 26 Jan 2002 17:49:52 -0800 (PST) Received: from sfluhrer-hpc (sjc-vpn1-625.cisco.com [10.21.98.113]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id ADL20124; Sat, 26 Jan 2002 17:38:44 -0800 (PST) Message-Id: <4.0.2.20020111095628.00aab1a0@mira-sjcm-3> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Sat, 26 Jan 2002 17:47:15 -0800 To: ipsec-policy@vpnc.org From: Scott Fluhrer Subject: TED discussion at SLC IETF, and future directions 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, My apologies for being *extremely* tardy with this -- I was out of town the month after the IETF, and then, well, you can imagine... In any case, the goal of this memo is to summarize the discussion of TED at the Salt Lake City IETF, and to foster further discussions as to its future directions. Of course, the author welcomes any and all comments, corrections and rotten tomatoes. I presented the Tunnel Endpoint Discovery (TED) protocol at Salt Lake City, which is a protocol designed to allow different IPSec peers to communicate with each other in a manner that avoids the O(N^2) configuration problem, by finding remote peers in an automatic fashion. It works by, when one security gateway needs to establish an encrypted connection to protect a particular traffic flow, it sends a probe to the flow's destination, which is intercepted by the remote security gateway, which sends a reply which supplies enough information to allow to IKE negotiation to proceed. The general sense of the working group was they were interested in this approach, however they preferred to make changes in the exact protocol. However, before I make any specific changes, I would like to assert two criteria: - This is a protocol that is actually working in the field. Therefore, I would prefer not to make any gratuitous changes -- that is, any change to the protocol would be to achieve some distinct improvement in the protocol. - I would prefer to rule out drastic changes. TED is, for example, an entirely distributed approach, with no central controllers. While the idea of a central controller may have merit, if the working group decide to pursue that, I would prefer it be recognized as a different protocol. And, in keeping in line with the first criteria, before I make any changes in the protocol, I would need to know what in the existing protocol needs improvement. Here are several mentioned at the IETF, along with my initial comments: - TED works only if the protected addresses are publicly routable. This means it is unusable in a number of common scenarios. Comments: well, yes. This would be very nice to fix, however, it would appear to be innate in the approach TED takes. If anyone has any ideas, I'll be glad to listen. - TED does not do load balancing with redundant remote peers cleanly. Comments: well, yes. One thing we've considered is having the remote peers know about each other (since they are protecting the same subnet, that is reasonable), and put the intelligence in how they handle the TED probe (e.g. TED probes are forwarded to the peer that has the lightest load). If the working group considers this a concern, this can certainly be pursued. - TED ought not design its own protocol for doing discovery, but reuse an existing protocol (such as RSVP). Comments: possibly. I do not know enough about RSVP to say anything intelligent about it. However, if people think this is important, I can look into it. -- scott From owner-ipsec-policy@mail.vpnc.org Mon Jan 28 01:38:27 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11007 for ; Mon, 28 Jan 2002 01:38:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0S5la616086 for ipsec-policy-bks; Sun, 27 Jan 2002 21:47:36 -0800 (PST) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0S5lY316082 for ; Sun, 27 Jan 2002 21:47:34 -0800 (PST) Received: from marajade.sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g0S5l6x12289 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 28 Jan 2002 00:47:14 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g0S5l2M07614; Mon, 28 Jan 2002 00:47:06 -0500 (EST) Message-Id: <200201280547.g0S5l2M07614@marajade.sandelman.ottawa.on.ca> To: Scott Fluhrer cc: ipsec-policy@vpnc.org Subject: Re: TED discussion at SLC IETF, and future directions In-reply-to: Your message of "Sat, 26 Jan 2002 17:47:15 PST." <4.0.2.20020111095628.00aab1a0@mira-sjcm-3> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 28 Jan 2002 00:47:01 -0500 From: Michael Richardson Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott Fluhrer writes: Scott> However, before I make any specific changes, I would like to Scott> assert two criteria: Scott> - This is a protocol that is actually working in the field. Scott> Therefore, I would prefer not to make any gratuitous changes -- Scott> that is, any change to the protocol would be to achieve some Scott> distinct improvement in the protocol. In that case, please submit your draft as an Informational RFC on the protocol and then let's go on with discussing the requirements. Scott> - I would prefer to rule out drastic changes. TED is, for Scott> example, an entirely distributed approach, with no central Scott> controllers. While the idea of a central controller may have Scott> merit, if the working group decide to pursue that, I would Scott> prefer it be recognized as a different protocol. I agree with you here. Scott> And, in keeping in line with the first criteria, before I make Scott> any changes in the protocol, I would need to know what in the Scott> existing protocol needs improvement. Here are several Scott> mentioned at the IETF, along with my initial comments: In other words, we need a requirement draft. please see draft-ietf-ipsp-requirements-00.txt (expired in May 2001, recently resubmitted as 01, also at: http://www.sandelman.ottawa.on.ca/SSW/ietf/ipsp/) This should, I think, be the major topic of discussion at Minneapolis. Scott> - TED ought not design its own protocol for doing discovery, but Scott> reuse an existing protocol (such as RSVP). Scott> Comments: possibly. I do not know enough about RSVP to say Scott> anything intelligent about it. However, if people think this Scott> is important, I can look into it. You need to at least read the RFCs on RSVP. {Luis, if you can, get us a 1 hour slot on Tuesday or Wednesday. Monday evening is really tough after a long day. If we need time for PIB stuff, do it seperately.} ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPFTl0oqHRg3pndX9AQFHagQAz3xQOTzHKAny7OBcJrihkGlK/XKHMQ94 lQTbg2OUXurd0rbUD4qOldByEZ2ATf9NdjGOTAUOel/gJ32G8m/duEt85a5tXmgj cSFZ9NgsCTeKEEoOqNqYlMI2uzGThhyNDHO4OmpXtzkqJQBjupAdB4Xsj6uiEnj6 bii+UtFgXPw= =Rq4H -----END PGP SIGNATURE----- From owner-ipsec-policy@mail.vpnc.org Mon Jan 28 06:52:17 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22669 for ; Mon, 28 Jan 2002 06:52:17 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0SB30220636 for ipsec-policy-bks; Mon, 28 Jan 2002 03:03:00 -0800 (PST) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SB2w320626 for ; Mon, 28 Jan 2002 03:02:58 -0800 (PST) Received: from EVYNCKE-W2K.cisco.com (ams-vpdn-client-19.cisco.com [144.254.46.20]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA15889; Mon, 28 Jan 2002 12:02:50 +0100 (MET) Message-Id: <4.3.2.7.2.20020128114948.026c0980@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 28 Jan 2002 11:54:01 +0100 To: Scott Fluhrer From: Eric Vyncke Subject: Re: TED discussion at SLC IETF, and future directions Cc: ipsec-policy@vpnc.org In-Reply-To: <4.0.2.20020111095628.00aab1a0@mira-sjcm-3> 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: At 17:47 26/01/2002 -0800, Scott Fluhrer wrote: ..%<......%<....... >- TED ought not design its own protocol for doing discovery, but > reuse an existing protocol (such as RSVP). > > Comments: possibly. I do not know enough about RSVP to say > anything intelligent about it. However, if people think this > is important, I can look into it. My understanding of RSVP is that it is mandatory for all routers in the path of RSVP packets to process the RSVP packets. Which is of course quite normal for QoS (which is enforced on all routers in the path) but not the expected behavior for IPSec (which is end to end). Also, we could expect some ISP to simply drop all RSVP packets because they do not want their customers either using RSVP for QoS or running a DoS attack by sending thousands of RSVP packets that will be processed by the router (processing a RSVP packet will take much more time than switching a simple IP packet). So, while I do not say 'do not use RSVP for TED', I really wonder whether it is the best approach. Just my 0.01 EUR -eric From owner-ipsec-policy@mail.vpnc.org Mon Jan 28 13:15:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04807 for ; Mon, 28 Jan 2002 13:15:06 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0SHDiK13026 for ipsec-policy-bks; Mon, 28 Jan 2002 09:13:44 -0800 (PST) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SHDg313022 for ; Mon, 28 Jan 2002 09:13:42 -0800 (PST) Received: from marajade.sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g0SHCgx12974 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 28 Jan 2002 12:12:44 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g0SHCbH14740; Mon, 28 Jan 2002 12:12:41 -0500 (EST) Message-Id: <200201281712.g0SHCbH14740@marajade.sandelman.ottawa.on.ca> To: ipsec-policy@vpnc.org cc: Eric Vyncke Subject: Re: TED discussion at SLC IETF, and future directions In-reply-to: Your message of "Mon, 28 Jan 2002 11:54:01 +0100." <4.3.2.7.2.20020128114948.026c0980@brussels.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 28 Jan 2002 12:12:36 -0500 From: Michael Richardson Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Eric" == Eric Vyncke writes: Eric> At 17:47 26/01/2002 -0800, Scott Fluhrer wrote: Eric> ..%<......%<....... >> - TED ought not design its own protocol for doing discovery, but >> reuse an existing protocol (such as RSVP). >> >> Comments: possibly. I do not know enough about RSVP to say >> anything intelligent about it. However, if people think this >> is important, I can look into it. Eric> My understanding of RSVP is that it is mandatory for all routers in the Eric> path of RSVP packets to process the RSVP packets. No. If the router doesn't do QoS, then the router doesn't do QoS. You may not get end-to-end QoS guarantees if you don't have end-to-end RSVP capable routers, but to do anything else would require a flag day! Eric> Which is of course quite normal for QoS (which is enforced on all routers Eric> in the path) but not the expected behavior for IPSec (which is end to end). Eric> Also, we could expect some ISP to simply drop all RSVP packets because they Eric> do not want their customers either using RSVP for QoS or running a DoS Eric> attack by sending thousands of RSVP packets that will be processed by the Eric> router (processing a RSVP packet will take much more time than switching a Eric> simple IP packet). I'd really like to see an ISP that has enough core routers that are RSVP capable for this to be real. Please - you should have the data. If that is really the case, then you should trivially be able to find out about this situation from your customer support people. I think that otherwise, RSVP has gotten a very bad FUD experience. RSVP doesn't scale because teach IOS how to do SET (so that each ISP can collect from my credit card) was a total loss. The forwarding plane issues were solved *long* ago. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPFWGg4qHRg3pndX9AQE7QQP7B2GaGZmBH9KpbqTiCgJHsLdIS0F25onf Z0O3ZCqyDUA0FPcfzkUvOxRsMhsiwoNFH+W4N9p6O4CEBwEr+/jAm37XX1Uwzlkd 0nP49AhqHHn2AbHM0TwHCKg6vA6ftvBIPQrU4M4+xyKmVW9U6D4DC3B/DBLq7AW5 TRTjOSUe0Os= =mgWs -----END PGP SIGNATURE----- From owner-ipsec-policy@mail.vpnc.org Mon Jan 28 14:11:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06211 for ; Mon, 28 Jan 2002 14:11:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SI59x14320 for ipsec-policy-bks; Mon, 28 Jan 2002 10:05:09 -0800 (PST) Received: from smtp2.coqui.net ([196.28.61.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SI57314316 for ; Mon, 28 Jan 2002 10:05:07 -0800 (PST) Received: from megisto.com (ppp-196-42-29-222.coqui.net [196.42.29.222]) by smtp2.coqui.net (8.12.1/8.12.1) with ESMTP id g0SA5UVY014161; Mon, 28 Jan 2002 14:05:31 +0400 (GMT) Message-ID: <3C5592B5.5040402@megisto.com> Date: Mon, 28 Jan 2002 13:04:37 -0500 From: "Luis A. Sanchez" Organization: LASC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: MORAND Pierrick FTRD/DMI/CAE CC: "IPSEC-POLICY (E-mail)" , "Man.M.Li" Subject: Re: COPS-PR and IPSec PIB implementation References: <91A311FF6A85D3118DDF0060080C3D829DE34E@lat3721.rd.francetelecom.fr> 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 Pierrick, Please contact Man Li at the email address above. -luis MORAND Pierrick FTRD/DMI/CAE wrote: > Hi, > > We've implemented a COPS-PR prototype architecture (COPS-PR, PDP, PEP > Proxies Server, in Java) for the dynamic provisioning of an > IPSec-based IP VPN service offering, based on version 05 of the > Framework PIB and on version 03 of the IPSec PIB drafts, respectively. > > We're therefore interested if any equipment vendor representative who > has subscribed to this mailing list has the same kind of > implementation experience (or intends to do so), and if he/she would > like to share some information with us. > > If so, please contact me directly, and my apologies for any > disturbance this message may have caused. > > Cheers, > > Pierrick. > > Pierrick Morand > france tele com R&D/DMI/SIR/IPI > Tel : +33 2 31 75 91 79 - Fax : +33 2 31 73 56 26 > Email :pierrick.morand@rd.francetelecom.com > > From owner-ipsec-policy@mail.vpnc.org Mon Jan 28 17:13:41 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10038 for ; Mon, 28 Jan 2002 17:13:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SL0HK18934 for ipsec-policy-bks; Mon, 28 Jan 2002 13:00:17 -0800 (PST) Received: from smtp2.coqui.net ([196.28.61.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SL0F318930 for ; Mon, 28 Jan 2002 13:00:15 -0800 (PST) Received: from megisto.com (ppp-196-42-29-222.coqui.net [196.42.29.222]) by smtp2.coqui.net (8.12.1/8.12.1) with ESMTP id g0SD0oVY003048; Mon, 28 Jan 2002 17:00:50 +0400 (GMT) Message-ID: <3C55BBCC.4030102@megisto.com> Date: Mon, 28 Jan 2002 15:59:56 -0500 From: "Luis A. Sanchez" Organization: LASC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Scott Fluhrer CC: ipsec-policy@vpnc.org Subject: Re: TED discussion at SLC IETF, and future directions References: <4.0.2.20020111095628.00aab1a0@mira-sjcm-3> 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 Scott, If i recall correctly the idea/suggestion behind following the "RSVP model" of operation for discovery and path selection was to provide embedded security gateway discovery in TED. TED seems to assume a SG to SG scenario only which is fine for that scenario. However, it would be nice to enhance the protocol to support discovery of multiple security gateways. For example, assume a scenario where a large enterprise (foo) may isolate both their engineering and marketing organizations from the larger organization using a security gateway for each organization, SG2 and SG3 respectively. Further assume that both security gateways are behind the security gateway of the larger organization (SG1). The idea would be for the TED probe received at SG1 to flow through the network to SG2 assuming the the SA was intended between some host1 and some host2 in the engineering organization and, that the security policy of the site **requires** SG2 and perhaps SG1 to be involved in the end2end secure communication. host1 -------------------SG1-----SG2----host2 SG2 may want to (at least) authenticate host1 just like SG1 and host2 would like to. Also, TED queries and replies should be authentic. Signatures may be the way to go here using cert payloads too. I believe the ipsp requirements document may include these design preferences. thanks, -luis Scott Fluhrer wrote: >Hi, > > My apologies for being *extremely* tardy with this -- I was out of >town the month after the IETF, and then, well, you can imagine... > > In any case, the goal of this memo is to summarize the discussion >of TED at the Salt Lake City IETF, and to foster further discussions >as to its future directions. Of course, the author welcomes any and >all comments, corrections and rotten tomatoes. > > I presented the Tunnel Endpoint Discovery (TED) protocol at Salt >Lake City, which is a protocol designed to allow different IPSec >peers to communicate with each other in a manner that avoids the >O(N^2) configuration problem, by finding remote peers in an >automatic fashion. It works by, when one security gateway needs to >establish an encrypted connection to protect a particular traffic >flow, it sends a probe to the flow's destination, which is >intercepted by the remote security gateway, which sends a reply >which supplies enough information to allow to IKE negotiation to >proceed. > > The general sense of the working group was they were interested >in this approach, however they preferred to make changes in the >exact protocol. > > However, before I make any specific changes, I would like to >assert two criteria: > >- This is a protocol that is actually working in the field. > Therefore, I would prefer not to make any gratuitous changes -- > that is, any change to the protocol would be to achieve some > distinct improvement in the protocol. > >- I would prefer to rule out drastic changes. TED is, for > example, an entirely distributed approach, with no central > controllers. While the idea of a central controller may have > merit, if the working group decide to pursue that, I would > prefer it be recognized as a different protocol. > >And, in keeping in line with the first criteria, before I make >any changes in the protocol, I would need to know what in the >existing protocol needs improvement. Here are several >mentioned at the IETF, along with my initial comments: > >- TED works only if the protected addresses are publicly routable. > This means it is unusable in a number of common scenarios. > > Comments: well, yes. This would be very nice to fix, however, > it would appear to be innate in the approach TED takes. If > anyone has any ideas, I'll be glad to listen. > >- TED does not do load balancing with redundant remote peers > cleanly. > > Comments: well, yes. One thing we've considered is having the > remote peers know about each other (since they are protecting > the same subnet, that is reasonable), and put the intelligence > in how they handle the TED probe (e.g. TED probes are forwarded > to the peer that has the lightest load). If the working group > considers this a concern, this can certainly be pursued. > >- TED ought not design its own protocol for doing discovery, but > reuse an existing protocol (such as RSVP). > > Comments: possibly. I do not know enough about RSVP to say > anything intelligent about it. However, if people think this > is important, I can look into it. > > From owner-ipsec-policy@mail.vpnc.org Tue Jan 29 10:23:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05815 for ; Tue, 29 Jan 2002 10:23:07 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TEOqs17926 for ipsec-policy-bks; Tue, 29 Jan 2002 06:24:52 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TEOp317922 for ; Tue, 29 Jan 2002 06:24:51 -0800 (PST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0TEOlI18818; Tue, 29 Jan 2002 06:24:47 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACQ81449; Tue, 29 Jan 2002 06:23:03 -0800 (PST) Message-Id: <5.1.0.14.0.20020129092540.00a87ec0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Jan 2002 09:28:08 -0500 To: "Luis A. Sanchez" From: Melinda Shore Subject: Re: TED discussion at SLC IETF, and future directions Cc: ipsec-policy@vpnc.org In-Reply-To: <3C55BBCC.4030102@megisto.com> References: <4.0.2.20020111095628.00aab1a0@mira-sjcm-3> 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: At 03:59 PM 1/28/02 -0500, Luis A. Sanchez wrote: >If i recall correctly the idea/suggestion behind following the "RSVP model" of operation for discovery and path selection was to provide embedded security gateway discovery in TED. TED seems to assume a SG to SG scenario only which is fine for that scenario. However, it would be nice to enhance the protocol to support discovery of multiple security gateways. It also has the advantage of being able to cope with topological complexity - I've proposed this model for firewall/NAT discovery and traversal in the draft http://search.ietf.org/internet-drafts/draft-shore-friendly-midcom-00.txt Melinda From owner-ipsec-policy@mail.vpnc.org Wed Jan 30 05:16:27 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13901 for ; Wed, 30 Jan 2002 05:16:27 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0U9guW07645 for ipsec-policy-bks; Wed, 30 Jan 2002 01:42:56 -0800 (PST) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0U9gs307637 for ; Wed, 30 Jan 2002 01:42:54 -0800 (PST) Received: from EVYNCKE-W2K.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA10019; Wed, 30 Jan 2002 10:42:42 +0100 (MET) Message-Id: <4.3.2.7.2.20020130104030.0272ebc8@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Jan 2002 10:42:46 +0100 To: From: Eric Vyncke Subject: Re: Granularity in IPsec config model Cc: 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: Hello Man, See in-line At 13:28 23/01/2002 -0500, Man.M.Li@nokia.com wrote: >Hi, > >Section 6.11.4 of draft-ietf-ipsp-config-policy-model-04.txt describes the >Granularity property. It seems to me that if one would like to use only >the source and protocol of the triggering packet or only the source >address of the triggering packet, this cannot be done with any of the >Granularity values. Correct, the ID assumes a symmetrical approach (please note that the subnet value actually relies on the defined IPHeaderFilter --> you can probably get what you want by using specific IPHeaderFilter) >Is there a reason that the Granularity property is limited to the four >values only? We simply assumed that this would cover 99.9% of the configuration and used this property for simplicity sake. Nothing prevent you to extend the model Regards -eric >Best regards >Man From owner-ipsec-policy@mail.vpnc.org Wed Jan 30 07:31:49 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16295 for ; Wed, 30 Jan 2002 07:31:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UC1hG18884 for ipsec-policy-bks; Wed, 30 Jan 2002 04:01:43 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UC1f318876 for ; Wed, 30 Jan 2002 04:01:41 -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 HAA15449; Wed, 30 Jan 2002 07:01:35 -0500 (EST) Message-Id: <200201301201.HAA15449@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-spp-01.txt Date: Wed, 30 Jan 2002 07:01: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 : Security Policy Protocol Author(s) : L. Sanchez, M. Condell Filename : draft-ietf-ipsp-spp-01.txt Pages : 92 Date : 29-Jan-02 This document describes a protocol for discovering, accessing and processing security policy information of hosts, subnets or networks of a security domain. The Security Policy Protocol defines how the policy information is exchanged, processed, and protected by clients and servers. The protocol is extensible and flexible. It allows the exchange of complex policy objects between clients and servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsp-spp-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-spp-01.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-spp-01.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: <20020129135733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsp-spp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsp-spp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020129135733.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec-policy@mail.vpnc.org Wed Jan 30 07:55:14 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16745 for ; Wed, 30 Jan 2002 07:55:13 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0UCRYv20263 for ipsec-policy-bks; Wed, 30 Jan 2002 04:27:34 -0800 (PST) Received: from squatch.ir.bbn.com (squatch.ir.bbn.com [192.1.98.166]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0UCRW320259 for ; Wed, 30 Jan 2002 04:27:32 -0800 (PST) Received: (qmail 8423 invoked by uid 20813); 30 Jan 2002 12:27:32 -0000 Date: 30 Jan 2002 12:27:32 -0000 Message-ID: <20020130122732.8422.qmail@squatch.ir.bbn.com> From: Matthew Condell To: ipsec-policy@vpnc.org Subject: Re: I-D ACTION:draft-ietf-ipsp-spp-01.txt Reply-to: mcondell@bbn.com Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Just a quick note about this draft. It is basically the same as the -00 draft, with only minor changes. Any previous strengths or weaknesses are still the same. It was suggested at the last IETF meeting that I resubmit it since the old draft is long expired and we are just starting discussions in the protocol area again. Matt Condell From owner-ipsec-policy@mail.vpnc.org Wed Jan 30 12:33:00 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26460 for ; Wed, 30 Jan 2002 12:33:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UGHdP03579 for ipsec-policy-bks; Wed, 30 Jan 2002 08:17:39 -0800 (PST) Received: from mail4.nc.rr.com ([24.93.67.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UGHc303575 for ; Wed, 30 Jan 2002 08:17:38 -0800 (PST) Received: from casey ([66.26.63.121]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 30 Jan 2002 11:16:26 -0500 From: "Casey Carr" To: "IPSec Policy WG" Subject: Address ranges Date: Wed, 30 Jan 2002 11:15:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Could someone please give me some guidance on how the IPSec policy model addresses (no pun intended) filtering on a range of IPv4 addresses? The IPSec library we are using supports defining filters based on address ranges but it doesn't appear to me that the model supports this. I've reviewed the PCIMe. This is my interpretation: 1) PCIMe defines the PolicyIPv4AddrValue which supports the definition of an address range. 2) The HdrSrcAddress and HdrDestAddress properties of the IpHeadersFilter are defined as OctetStrings Should I be interpreting that the OctectString can be a PolicyIPv4AddrValue? The description of the properties in the IpHeadersFilter leads me to believe that this would NOT be an appropriate interpretation. Thanks in advance. Casey From owner-ipsec-policy@mail.vpnc.org Wed Jan 30 17:19:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03582 for ; Wed, 30 Jan 2002 17:19:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0ULIMh10879 for ipsec-policy-bks; Wed, 30 Jan 2002 13:18:22 -0800 (PST) Received: from mgr2.xmission.com (mgr2.xmission.com [198.60.22.202]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0ULIK310874 for ; Wed, 30 Jan 2002 13:18:21 -0800 (PST) Received: from [198.60.22.22] (helo=mail.xmission.com) by mgr2.xmission.com with esmtp (Exim 3.22 #1) id 16W27W-0007HX-00; Wed, 30 Jan 2002 14:18:18 -0700 Received: from shell.xmission.com ([198.60.22.20] helo=xmission.xmission.com) by mail.xmission.com with esmtp (Exim 3.22 #1) id 16W27V-0001LI-00; Wed, 30 Jan 2002 14:18:17 -0700 Received: from hilarie by xmission.xmission.com with local (Exim 3.16 #3) id 16W27V-00070O-00; Wed, 30 Jan 2002 14:18:17 -0700 From: "Hilarie Orman, Purple Streak Development" To: mshore@cisco.com Cc: ipsec-policy@vpnc.org In-reply-to: Yourmessage <5.1.0.14.0.20020129092540.00a87ec0@localhost> Subject: Re: TED discussion at SLC IETF, and future directions Message-Id: Date: Wed, 30 Jan 2002 14:18:17 -0700 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think this is a very good high-level description of what is needed and why. If we replace the NAT discussion with Security Associations, it seems to be an IPSP model. Hilarie > At 03:59 PM 1/28/02 -0500, Luis A. Sanchez wrote: > >If i recall correctly the idea/suggestion behind following the "RSVP model" of operation for discovery and path selection was to provide embedded security gateway discovery in TED. TED seems to assume a SG to SG scenario only which is fine for that scenario. However, it would be nice to enhance the protocol to support discovery of multiple security gateways. > It also has the advantage of being able to cope with > topological complexity - I've proposed this model for > firewall/NAT discovery and traversal in the draft > http://search.ietf.org/internet-drafts/draft-shore-friendly-midcom-00.txt > Melinda From owner-ipsec-policy@mail.vpnc.org Thu Jan 31 13:26:08 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06974 for ; Thu, 31 Jan 2002 13:26:07 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VHc2620036 for ipsec-policy-bks; Thu, 31 Jan 2002 09:38:02 -0800 (PST) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VHc1320032 for ; Thu, 31 Jan 2002 09:38:01 -0800 (PST) Received: from EVYNCKE-W2K.cisco.com (confmad-isdn.cisco.com [10.49.42.193]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA01657; Thu, 31 Jan 2002 18:37:48 +0100 (MET) Message-Id: <4.3.2.7.2.20020131183702.02832b18@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 Jan 2002 18:37:47 +0100 To: "Casey Carr" From: Eric Vyncke Subject: Re: Address ranges Cc: "IPSec Policy WG" 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: At 11:15 30/01/2002 -0500, Casey Carr wrote: >Could someone please give me some guidance on how the IPSec policy model >addresses (no pun intended) filtering on a range of IPv4 addresses? > >The IPSec library we are using supports defining filters based on address >ranges but it doesn't appear to me that the model supports this. I've This is correct as ICPM tried to re-use as much as possible of PCIM/PCIMe which does not understand IP address ranges -eric >reviewed the PCIMe. This is my interpretation: > >1) PCIMe defines the PolicyIPv4AddrValue which supports the definition of an >address range. >2) The HdrSrcAddress and HdrDestAddress properties of the IpHeadersFilter >are defined as OctetStrings > >Should I be interpreting that the OctectString can be a PolicyIPv4AddrValue? >The description of the properties in the IpHeadersFilter leads me to believe >that this would NOT be an appropriate interpretation. > >Thanks in advance. > >Casey From owner-ipsec-policy@mail.vpnc.org Thu Jan 31 18:22:39 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15392 for ; Thu, 31 Jan 2002 18:22:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VMugI06231 for ipsec-policy-bks; Thu, 31 Jan 2002 14:56:42 -0800 (PST) Received: from USEXCH3.us.sonicwall.com (users.sonicwall.com [216.217.36.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0VMud306225 for ; Thu, 31 Jan 2002 14:56:39 -0800 (PST) Received: from usexch2.us.sonicwall.com ([10.0.0.86]) by USEXCH3.us.sonicwall.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 31 Jan 2002 14:56:43 -0800 Received: from sonicwall.com ([10.0.200.150]) by usexch2.us.sonicwall.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 31 Jan 2002 14:56:41 -0800 Message-ID: <3C59CBAB.D8995CE3@sonicwall.com> Date: Thu, 31 Jan 2002 14:56:43 -0800 From: "Scott G. Kelly" Organization: SonicWall X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Vyncke CC: Casey Carr , IPSec Policy WG Subject: Re: Address ranges References: <4.3.2.7.2.20020131183702.02832b18@brussels.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2002 22:56:41.0356 (UTC) FILETIME=[8C07ACC0:01C1AAAA] Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Eric Vyncke wrote: > > At 11:15 30/01/2002 -0500, Casey Carr wrote: > > >Could someone please give me some guidance on how the IPSec policy model > >addresses (no pun intended) filtering on a range of IPv4 addresses? > > > >The IPSec library we are using supports defining filters based on address > >ranges but it doesn't appear to me that the model supports this. I've > > This is correct as ICPM tried to re-use as much as possible of PCIM/PCIMe > which does not understand IP address ranges > > -eric Since RFC2401 mandates support for address ranges, shouldn't the policy model support them? Scott