From ???@??? Thu May 13 17:21:13 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id RAA10653 for ; Thu, 13 May 1999 17:11:55 -0700 (PDT) Received: from relay.gw.tislabs.com [192.94.214.100] by mail.timestep.com [209. 47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Thu, 13 M ay 1999 20:01:08 -0400 Received: by relay.gw.tislabs.com; id UAA03242; Thu, 13 May 1999 20:13:02 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by relay.gw.tislabs.com via sm ap (4.1) id xma003218; Thu, 13 May 99 20:12:32 -0400 Received: from balenson.gw.tislabs.com (balenson.gw.tislabs.com [10.33.80.11]) by clipper.gw.tislabs.com (8.9.1/8.9.1) with SMTP id TAA11651; Thu, 13 May 1999 19:57:16 -0400 (EDT) Message-ID: X-Sender: balenson@pop.gw.tislabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 13 May 1999 19:56:57 -0400 To: rpereira@TimeStep.com, lsanchez@bbn.com From: "David M. Balenson" Subject: RE: test Cc: ipsec-policy@mail.timestep.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: balenson@tislabs.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 46426f0cdfce394b6950d169b19a74f4 At 04:05 PM 3/26/99 -0500, Roy Pereira wrote: >As for lack of content, Luis and I will be posting the proposed charter very >soon. Roy, Luis- How are you guys making out with the IPSP proposed charter?? Thanks, -DB ----------------------------------------David M. Balenson, Cryptographic Techno logies Group NAI Labs, The Security Research Division of Network Associates, Inc. 3060 Washington Road, Glenwood, MD 21738 USA David_Balenson@nai.com; 443_259.2358; fax 301_854.4731 PGP fingerprint FD53 918E 097A 2579 C1A8 34F8 E05D E74F AC1D E184 From ???@??? Fri May 14 14:37:00 1999 Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA12657 for ; Fri, 14 May 1999 13:11:14 -0700 (PDT) Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i d <55637-17937>; Fri, 14 May 1999 16:12:31 -0400 Received: from ganymede.or.intel.com [134.134.248.3] by mail.timestep.com [209. 47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Fri, 14 M ay 1999 16:00:13 -0400 Received: from orsmsx29.jf.intel.com (orsmsx29.jf.intel.com [192.168.65.29]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id TAA28370; Fri, 14 May 1999 19:58:59 GMT Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 14 May 1999 12:58:59 -0700 Message-ID: From: "Jason, Jamie" To: "'Ricky Charlet'" , ".MailList, ipsec" , "Jeronimo, Michael" , ipsec-policy@mail.timestep.com Subject: RE: draft-ietf-ipsec-policy-schema-00.txt Date: Fri, 14 May 1999 15:58:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: jamie.jason@intel.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: eafa2babc0ef85de1048d57d7aa0afa8 > Architectural Question: > Where should "action" fit into the class hierarchy? My expectation is > that the general IETF Policy WG (different from the IPSec Policy WG) > will be forming a generalized condition <-> action schema. Under that, > IPSec would fit in as a particular instantiation of an > action. Agreed. It is our expectation that the policy WG will develop the core schema necessary. Other working groups would deveolop domain-dependent conditions and actions as necessary. In our particular schema, we don't have any domain specific conditions, but obviously we have domain-specific actions. > Have you thought about merging your polices, rules, and conditions > work into the policy working group and then forming a draft to detail out an > instantiation of a particular (IPSec) policy action. That is the direction we would like to see this go. The reason for our presenation at Minneapolis IETF and this draft is to stimulate discussion about policy in general as well as policy for IPSEC. It is our belief that what you state is what will eventually transpire. > What an IPSec proposal contains seems to have left out > compression...oversight? Yes. Our particular work didn't include compression, but to be complete it should indeed include compression. > In your draft you seem to imply that the absence of a Permit > or Deny means Secure. At this time, we have 4 unique IPSEC actions: (1) deny (or block), (2) permit (or bypass), (3) tunnel action, or (4) transport action. I agree that there may be some ambiguity with the terms (as you may be able to tell, my first experience in the industry was with firewalls) and will make a note of it. In our current system, there is a requirement that there be an action object associated with the condition - so the absence of a permit or deny action means that there is a transport or tunnel action (i.e., secure action). We could have been clearer about it, but if I were to draw the permit and deny actions in the class diagram, they would derive from the IPSecAction (in other words, peers to the secure actions). I will make a note for the next rev of the draft. Jamie From ???@??? Mon Jun 07 09:02:55 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id EAA02269 for ; Mon, 7 Jun 1999 04:45:46 -0700 (PDT) Received: from wolfe.bbn.com [128.89.2.232] by mail.timestep.com [209.47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Mon, 07 Jun 1999 0 7:35:42 -0400 Received: (from mcondell@localhost) by wolfe.bbn.com (8.8.8/8.8.6) id HAA22396; Mon, 7 Jun 1999 07:34:32 -0400 (EDT) Date: Mon, 7 Jun 1999 07:34:32 -0400 (EDT) Message-ID: From: Matthew Condell To: ipsec-policy@mail.timestep.com Subject: Proposed IPSP Charter X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: mcondell@bbn.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: c35ff30f50980e57c98dd76631789556 [Sent for Luis] Here is a proposed charter for the IPsec Policy WG. Comments, suggestions and flames are welcome. Luis Description of Working Group ---------------------------- The rapid growth of the Internet and the need to control access to network resources (bandwidth, routers, hosts, etc.) has quickly generated the need for representing, discovering, exchanging and managing the policies that control access to these resources in a scalable, secured and reliable fashion. Current IP security protocols and algorithms [RFCs 2401-2412, 2085, 2104 and 2451] can exchange keying material using IKE [RFC2409] and protect data flows using the AH [RFC2402] and/or ESP protocols [RFC2406]. The scope of IKE limits the protocol to the authenticated exchange of keying material and associated policy information between the end-points of a security association. However, along the path of a communication, there may be administrative entities that need to impose policy constraints on entities such as security gateways and router filters. There also is a need for end-points of a security association and/or, for their respective administrative entities, to securely discover and negotiate access control information for the end hosts and for the policy enforcement points (security gateways, routers, etc.) along the path of the communication. Finally, there also is a need for establishing security associations efficiently (i.e., minimize public-key operations, payload exchanges, round-trips, etc.) across multiple intermediaries to support iterated tunneling. To address these problems the IPSP Working Group will: 1) Specify a data model for supporting IP security policies, 2) adopt an extensible IPsec policy specification language, 3) adopt or develop a policy exchange and negotiation protocol. The protocol must be capable of discovering, distributing and resolving policy conflicts in both intra/inter domain environments. The protocol must be independent of any security protocol suite and key management protocol, 4) provide guidelines for secure storage and handling of security policies, and; 5) develop IKE extensions to support efficient SA establishment for iterated tunneling. The proposed work item for this group would yield standards that are compatible with the existing IPsec architecture [RFC 2401] and IKE [RFC 2409], complementing the standards work achieved by the IPsec Working Group. The data model, specification language and exchange protocol will evolve from some of the work previously published in the following documents: draft-ietf-ipsec-policy-model-00.txt draft-ietf-ipsec-vpn-policy-schema-00.txt draft-ietf-ipsec-spsl-00.txt draft-ietf-ipsec-sps-00.txt draft-ietf-ipsec-secconf-00.txt This group will look at existing IETF standard work in the area of policy distribution. In particular, the group will look at the possibility of using/enhancing existing intra-domain policy distribution protocols such as the one developed in the RAP WG, if feasible. This group will also coordinate with other IETF working groups working on specifying policies and policies schemas in order to maintain compatibility and interoperability. In particular, this working group will work closely with the Policy Framework WG to ensure that the IPsec data model fits and can be supported within the general Policy Framework. From ???@??? Mon Jun 07 15:15:10 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id NAA03006 for ; Mon, 7 Jun 1999 13:41:17 -0700 (PDT) Received: from adk.gr [158.130.6.141] by mail.timestep.com [209.47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Mon, 07 Jun 1999 16:31:1 0 -0400 Received: from dsl.cis.upenn.edu (localhost [127.0.0.1]) by adk.gr (8.9.3/8.9.1) with ESMTP id QAA20548 for ; Mon, 7 Jun 1999 16:30:20 -0400 (E DT) Message-ID: To: ipsec-policy@mail.timestep.com Subject: Re: Proposed Charter Date: Mon, 07 Jun 1999 16:30:20 -0400 From: "Angelos D. Keromytis" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: angelos@dsl.cis.upenn.edu Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 543a6fca7bae36f6b4a2c9397c5fa510 -----BEGIN PGP SIGNED MESSAGE----- To: ipsec-policy@mail.timestep.com Subject: Re: Proposed Charter Cc: Date: 06/07/99, 16:30:18 I think the proposed charter is too ambitious, unless we really want to have an IPsec-WG-like saga again. A data model and a policy handling mechanism is clearly needed, along with a method of discovering security endpoints/gateways. That should be enough for a first pass, IMNSHO. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQEVAwUBN1wr23crsxJuc7vBAQHc6Af/Qfl6SiNGjkk1k79pplaVw20h1E5CM1dF lt685QksVM6p/rEQ9oHr5x0IE7pujLSbIO+vO6LNtdwzSOVmW1GHdvoMS6JSDfgh mAzMJxe1jBXU6Tv5rRdJHYDi8HblopKugnV7dDmnfhm2XkogB8iMcHUJdSuarxSh mYeAV3je8xNAco/MeD4tICkjr7nF2GB0oqErWQJnU0Kj3fzhajrgOsoMqj2JhyFE jlE7FbfK/P7wE3AzJ5PL7dGfniSEyGEIsWM5gEDM1TePMOYIHFG4WKdFrJXPqkX4 UWSn6kR7CYWdNu0QUg+Eb3a4fBO8TXyg2mxdRJ6Uh2VRk3BpCBIttw== =PiNI -----END PGP SIGNATURE----- From ???@??? Mon Jun 07 15:15:10 1999 Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id OAA03078 for ; Mon, 7 Jun 1999 14:47:24 -0700 (PDT) Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i d <49968-7112>; Mon, 7 Jun 1999 17:50:42 -0400 Received: from thalia.fm.intel.com [132.233.247.11] by mail.timestep.com [209.4 7.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Mon, 07 Ju n 1999 17:39:09 -0400 Received: from fmsmsx29.FM.INTEL.COM (fmsmsx29.fm.intel.com [132.233.42.29]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22 :10:56 iwep Exp iwep $) with ESMTP id OAA09615 for ; Mon, 7 Jun 1999 14:38:00 -0700 (P DT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Jun 1999 14:37:59 -0700 Message-ID: From: "Jeronimo, Michael" To: ipsec-policy@mail.timestep.com Subject: RE: Proposed IPSP Charter Date: Mon, 7 Jun 1999 17:37:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: michael.jeronimo@intel.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 5508a16163a96bdc804eef0703470682 I suggest first defining the IPsec policy data model in the abstract, then deriving from that the representations for specification (policy specification language), storage (LDAP schema), and distribution (COPS). I think that policy negotiation (assuming I'm even willing to adjust my policy given information about another's policy) is separate from policy distribution. As for the rest of #3, I'm not clear on: "The protocol must be capable of discovering, distributing and resolving policy conflicts in both intra/inter domain environments." Does this mean discovering conflicts distributing conflicts resolving conflicts or discovering policy servers distributing policy resolving policy conflicts or discovering policy conflicts distributing policy resolving policy conflicts -Mike From ???@??? Tue Jun 08 08:38:39 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id HAA05176 for ; Tue, 8 Jun 1999 07:20:14 -0700 (PDT) Received: from wolfe.bbn.com [128.89.2.232] by mail.timestep.com [209.47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Tue, 08 Jun 1999 1 0:09:52 -0400 Received: (from mcondell@localhost) by wolfe.bbn.com (8.8.8/8.8.6) id KAA02800; Tue, 8 Jun 1999 10:08:48 -0400 (EDT) Date: Tue, 8 Jun 1999 10:08:48 -0400 (EDT) Message-ID: From: Matthew Condell To: ipsec-policy@mail.timestep.com Subject: RE: Proposed IPSP Charter X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: mcondell@bbn.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 773c2b03f1238f9c38d087fce3286cbf Michael Jeronimo said: >I suggest first defining the IPsec policy data model in the abstract, >then deriving from that the representations for specification (policy >specification language), storage (LDAP schema), and distribution (COPS). I have a question about using COPS as the distrubution method. As I read COPS, it seems well designed for intra-domain policy distribution but does not seem to have the server discovery, server-to-server communication, enforcement point signalling, and policy negotiation mechanisms needed to support inter-domain policy negotiation. >I think that policy negotiation (assuming I'm even willing to adjust >my policy given information about another's policy) is separate from >policy distribution. Policy negotiation isn't about adjusting your policy, it's about determining where your policy overlaps another policy and determining if that overlap will allow or deny a communication and what security services that overlap allows. It also includes a more complicated resolution process since the communication that will be passing though an enforcement point may not be the same as the policy requested. For example, two hosts H1 and H2 would like to commuicate on port 79, so H1 needs to negotiate the policies for this communication. If, for example, H2 requires ESP to be used for the communication (and H1's policy allows it), the policy negotiated with a gateway GW1 between H1 and H2, not only has to include whether or not H1 and H2 can be allowed to communicate on port 79, but whether or not they can use ESP. This becomes even more complex when there are more nested gateways. It may be possible to separate this processing from the distribution of the policies. My initial feeling is that doing so would increase the processing required for the negotiation since every entitity involved would have to do it. However, it would probably be useful to investigate the pros and cons of separating the processing and distribution and keeping them together as is proposed in draft-ietf-ipsec-sps-00.txt >As for the rest of #3, I'm not clear on: > > "The protocol must be capable of discovering, > distributing and resolving policy conflicts in both > intra/inter domain environments." > >Does this mean [...] > discovering policy servers discovering policy and policy servers > distributing policy > resolving policy conflicts I think this is what was meant. Matt Condell BBN Technologies (speaking for himself this time.) From ???@??? Tue Jun 08 11:57:11 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id LAA05415 for ; Tue, 8 Jun 1999 11:57:12 -0700 (PDT) Received: from thalia.fm.intel.com [132.233.247.11] by mail.timestep.com [209.4 7.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Tue, 08 Ju n 1999 14:47:01 -0400 Received: from fmsmsx18.intel.com (fmsmsx18.fm.intel.com [132.233.233.232]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22 :10:56 iwep Exp iwep $) with ESMTP id LAA07069 for ; Tue, 8 Jun 1999 11:45:58 -0700 (P DT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 8 Jun 1999 11:45:58 -0700 Message-ID: From: "Jeronimo, Michael" To: ipsec-policy@mail.timestep.com Subject: RE: Proposed IPSP Charter Date: Tue, 8 Jun 1999 11:45:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: michael.jeronimo@intel.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 9bfc6b565822428d9e2c009c183b193c >I have a question about using COPS as the distrubution method. As I >read COPS, it seems well designed for intra-domain policy distribution >but does not seem to have the server discovery, server-to-server >communication, enforcement point signalling, and policy negotiation >mechanisms needed to support inter-domain policy negotiation. Yes, you're right - it currently does intra-domain policy distribution. It also allows asynchronous policy updates as well as reports from the enforcement point. It doesn't handle server discovery, but I don't think a distribution protocol necessarily should. I also think the inter-domain policy issues should be tackled separately. But, I didn't mean to necessarily advocate any particular protocol. My point was that we should just define IPsec policy in the abstract, then derive the task-specific representations - policy definition languages, LDAP schema, COPS objects, etc. >It also includes a more complicated resolution process since the >communication that will be passing though an enforcement point >may not be the same as the policy requested. For example, two >hosts H1 and H2 would like to commuicate on port 79, so H1 needs >to negotiate the policies for this communication. If, for example, >H2 requires ESP to be used for the communication (and H1's policy >allows it), the policy negotiated with a gateway GW1 between >H1 and H2, not only has to include whether or not H1 and H2 can >be allowed to communicate on port 79, but whether or not they >can use ESP. This becomes even more complex when there are more >nested gateways. So, you're finding out if H1 is going to be able to communicate with H2, given the intermediate security requirements (policy), before the actual IKE negotiation takes place and communication is attempted. How is this information going to be used? Is H1 going to adjust its proposal based on the feedback? -Mike From ???@??? Wed Jun 09 08:01:47 1999 Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id GAA06835 for ; Wed, 9 Jun 1999 06:35:13 -0700 (PDT) Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i d <50969-16460>; Wed, 9 Jun 1999 09:38:29 -0400 Received: from wolfe.bbn.com [128.89.2.232] by mail.timestep.com [209.47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Wed, 09 Jun 1999 0 9:30:47 -0400 Received: (from mcondell@localhost) by wolfe.bbn.com (8.8.8/8.8.6) id JAA07397; Wed, 9 Jun 1999 09:29:14 -0400 (EDT) Date: Wed, 9 Jun 1999 09:29:14 -0400 Message-ID: From: Matthew Condell To: ipsec-policy@mail.timestep.com Subject: RE: Proposed IPSP Charter X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: mcondell@bbn.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 64848173762fa52336fd9708853b0555 >>It also includes a more complicated resolution process since the >>communication that will be passing though an enforcement point >>may not be the same as the policy requested. For example, two >>hosts H1 and H2 would like to commuicate on port 79, so H1 needs >>to negotiate the policies for this communication. If, for example, >>H2 requires ESP to be used for the communication (and H1's policy >>allows it), the policy negotiated with a gateway GW1 between >>H1 and H2, not only has to include whether or not H1 and H2 can >>be allowed to communicate on port 79, but whether or not they >>can use ESP. This becomes even more complex when there are more >>nested gateways. > >So, you're finding out if H1 is going to be able to communicate >with H2, given the intermediate security requirements (policy), before >the actual IKE negotiation takes place and communication is attempted. >How is this information going to be used? Is H1 going to adjust its >proposal based on the feedback? Yes and yes. Policy discovery and negotiation must occur before the IKE negotiation to determine with which gateways H1 will have to set up SAs. It will also inform intermediate gateways which SAs they will need to support the communication. So, only after the policy negotiation occurs will H1 know with which entities it will have to do IKE negotiations. Now that the policy negotiations have occurred, H1 should use the policy information to adjust its proposal, since it has that additional information. This process is explained in draft-ietf-ipsec-sps-00.txt. Matt Condell BBN Technologies From ???@??? Wed Jun 09 15:45:57 1999 Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA07132 for ; Wed, 9 Jun 1999 11:15:02 -0700 (PDT) Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i d <55643-28600>; Wed, 9 Jun 1999 14:18:15 -0400 Received: from po1.bbn.com [192.1.50.38] by mail.timestep.com [209.47.58.12] wi th SMTP (MDaemon.v2.7.SP4.R) for ; Wed, 09 Jun 1999 13:4 5:33 -0400 Received: from jzao.bbn.com (DHCP030-187.BBN.COM [171.78.30.187]) by po1.bbn.com (8.9.1/8.9.1) with SMTP id NAA22900 for ; Wed, 9 Jun 1999 13:44:00 -0400 (E DT) Message-ID: X-Sender: jzao@po1.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 9 Jun 1999 13:38:45 -0400 To: ipsec-policy@mail.timestep.com From: "John K. Zao" Subject: Re: Proposed IPSP Charter In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: jzao@bbn.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: c77ff682cdd356d8a67febad6bf686bb At 07:34 AM 6/7/99 -0400, Matthew Condell wrote: > >Description of Working Group >---------------------------- > ... >To address these problems the IPSP Working Group will: > ... > 4) provide guidelines for secure storage and handling of > security policies, and; > (4) is rather vague. I suggest we replace the word "handling" with the actual issues we should be concerned with, such as: + authentication (proof to policy consumers of policy origin and integrity), + access control (granting policy consumers of read and/or modify rights), + authorization (determining the relevance of policies to policy consumers) where policy consumers include both policy management agents and enforcement agents. In my opinion, some or all of these issues should be addressed, and their mechanisms will be closely related to the policy management architectures (hierarchical domain vs group based) and the policy distribution mechanisms (protocol vs directory based) we choose to adopt. > 5) develop IKE extensions to support efficient SA > establishment for iterated tunneling. > This is more an IKE design issue than a policy management issue. I won't object if we decide that this working group is the proper place for discussing future work of IKE, but I wonder if there are plans to stand up other IP Second BOFs in the near future. John From ???@??? Wed Jun 09 15:45:57 1999 Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id PAA07347 for ; Wed, 9 Jun 1999 15:19:52 -0700 (PDT) Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i d <53155-2545>; Wed, 9 Jun 1999 18:23:03 -0400 Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12 ] with SMTP (MDaemon.v2.7.SP4.R) for ; Wed, 09 Jun 1999 18:20:41 -0400 Received: (from lsanchez@localhost) by nutmeg.bbn.com (8.8.8/8.8.7) id SAA01533 for ipsec-policy@mail.timestep.com; Wed, 9 Jun 1999 18:19:12 -0400 (EDT ) (envelope-from lsanchez) From: "Luis A. Sanchez" Message-ID: Subject: Re: Proposed IPSP Charter To: ipsec-policy@mail.timestep.com Date: Wed, 9 Jun 1999 18:19:12 -0400 Reply-To: ipsec-policy@mail.timestep.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: lsanchez@nutmeg.bbn.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] X-UIDL: c1882e5a449231185d3c53df62a26a67 Mike, > As for the rest of #3, I'm not clear on: > > "The protocol must be capable of discovering, > distributing and resolving policy conflicts in both > intra/inter domain environments." > Thank you for pointing this out. The previous sentence should have read: > "The protocol must be capable of: 1) discovering policy > servers, 2) distributing and negotiating security > policies, and; 3) resolving policy conflicts in both > intra/inter domain environments." Luis From ???@??? Thu Jun 10 10:26:18 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id HAA08610 for ; Thu, 10 Jun 1999 07:18:41 -0700 (PDT) Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12 ] with SMTP (MDaemon.v2.7.SP4.R) for ; Thu, 10 Jun 1999 10:05:41 -0400 Received: (from lsanchez@localhost) by nutmeg.bbn.com (8.8.8/8.8.7) id KAA00404 for ipsec-policy@mail.timestep.com; Thu, 10 Jun 1999 10:04:17 -0400 (ED T) (envelope-from lsanchez) From: "Luis A. Sanchez" Message-ID: Subject: Re: Proposed IPSP Charter To: ipsec-policy@mail.timestep.com Date: Thu, 10 Jun 1999 10:04:17 -0400 (EDT) Reply-To: ipsec-policy@mail.timestep.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: lsanchez@nutmeg.bbn.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] X-UIDL: 42c3c686b856d38ba3e35daa531e72ca Mike, > inter-domain policy issues should be tackled separately. But, I didn't > mean to necessarily advocate any particular protocol. My point was that > we should just define IPsec policy in the abstract, then derive > the task-specific representations - policy definition languages, LDAP > schema, COPS objects, etc. I think most of us agree that this soon-to-be WG should define an IPsec data model and adopt a Policy Specification Language. However, I don't think we should state in the charter that this group will define COPS Objects if it implies that this group will use COPS for policy distribution. Especially, when we know that COPS as it stands today doesn't meet the requirements. Unless, there is strong opposition I prefer using the following text in the charter: "This group will look at existing IETF standard work in the area of policy distribution. In particular, the group will look at the possibility of using/enhancing existing intra-domain policy distribution protocols such as the one developed in the RAP WG, if feasible." The goal is to do a _fair_ evaluation of what COPS has to offer and _then_ determine if it could be used to distribute/negotiate inter-domain security policies and to resolve policy conflicts. Also, why should this WG dictate one specific format (LDAP Schema) for storing security policies? Why can't we allow several storage formats provided we define a policy data model, adopt a language to represent such policies and specify how such policies will look on the wire? Luis From ???@??? Thu Jun 10 10:26:18 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id JAA08763 for ; Thu, 10 Jun 1999 09:53:14 -0700 (PDT) Received: from ganymede.or.intel.com [134.134.248.3] by mail.timestep.com [209. 47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Thu, 10 J un 1999 12:42:42 -0400 Received: from orsmsx28.jf.intel.com (orsmsx28.jf.intel.com [192.168.65.28]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id JAA02781 for ; Thu, 10 Jun 1999 09:41:15 -0700 ( PDT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Jun 1999 09:41:15 -0700 Message-ID: From: "Jeronimo, Michael" To: "'ipsec-policy@mail.timestep.com'" Subject: RE: Proposed IPSP Charter Date: Thu, 10 Jun 1999 09:41:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: michael.jeronimo@intel.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 7831c6b71493818eb328dd204a417fd8 >I think most of us agree that this soon-to-be WG should define an >IPsec data model and adopt a Policy Specification Language. However, I >don't think we should state in the charter that this group will define >COPS Objects if it implies that this group will use COPS for policy >distribution. Especially, when we know that COPS as it stands today >doesn't meet the requirements. Unless, there is strong opposition I >prefer using the following text in the charter: > >"This group will look at existing IETF standard work in the area of >policy distribution. In particular, the group will look at the >possibility of using/enhancing existing intra-domain policy >distribution protocols such as the one developed in the RAP WG, if >feasible." > >The goal is to do a _fair_ evaluation of what COPS has to offer and >_then_ determine if it could be used to distribute/negotiate >inter-domain security policies and to resolve policy conflicts. > >Also, why should this WG dictate one specific format (LDAP Schema) for >storing security policies? Why can't we allow several storage formats >provided we define a policy data model, adopt a language to represent >such policies and specify how such policies will look on the wire? Luis, I see a policy system consisting of at least: - Authoring - Storage - Distribution - Enforcement - Feedback Each of these tasks are relative to a cannonical form (the core model), that describes the semantics of the policy. I don't see a policy specification language as any more important than a storage schema or a distribution method. I think each of these representations should be well-defined for purposes of interoperability. I may choose to implement my policy authoring tool as a whiz-bang GUI that doesn't even use a policy specification language, but outputs a storage schema that the downstream tools can understand. Perhaps you see a multi-purpose policy specification language used for authoring and then also storage (store the text of the specification). I was thinking of a PSL used for authoring, but another representation for storage (as in a directory). I agree completely about doing a fair evaluation of existing protocols. -Mike From ???@??? Fri Jun 11 16:23:26 1999 Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id QAA11049 for ; Fri, 11 Jun 1999 16:14:11 -0700 (PDT) Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i d <50131-19906>; Fri, 11 Jun 1999 19:17:47 -0400 Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12 ] with SMTP (MDaemon.v2.7.SP4.R) for ; Fri, 11 Jun 1999 19:04:51 -0400 Received: (from lsanchez@localhost) by nutmeg.bbn.com (8.8.8/8.8.7) id TAA01126 for ipsec-policy@mail.timestep.com; Fri, 11 Jun 1999 19:03:29 -0400 (ED T) (envelope-from lsanchez) From: "Luis A. Sanchez" Message-ID: Subject: Re: Proposed IPSP Charter In-Reply-To: from "Je ronimo, Michael" at "Jun 10, 99 09:41:13 am" To: ipsec-policy@mail.timestep.com Date: Fri, 11 Jun 1999 19:03:29 -0400 Reply-To: ipsec-policy@mail.timestep.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: lsanchez@nutmeg.bbn.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] X-UIDL: 6dd6c02c11e085fd254c49010ca441ee Mike, Like you, I was thinking more along the lines of a PSL separate from any of the several possible representation schemes for storage. On the other hand, Angelos brought up a good point: the original proposed charter might be to extensive. Taking this into consideration and for the sake of time it might be better if the WG begins working on: 1) specifying a data model for supporting IP security policies, 2) adopting an extensible IPsec policy specification language, 3) developing a protocol capable of: o discovering policy servers o distributing and negotiating security policies o resolving policy conflicts in both intra/inter domain environments Once we *show* some progress we can attack issues such as storage, IKE mods, etc. We can fine tune how the charter is executed as we move along. Is this reasonable for starters? If so, Roy and I will submit the charter to the Sec Area directors for their revision and approval. Luis > > Luis, > > I see a policy system consisting of at least: > > - Authoring > - Storage > - Distribution > - Enforcement > - Feedback > > Each of these tasks are relative to a cannonical form (the core model), that > describes the semantics of the policy. I don't see a policy specification > language as any more important than a storage schema or a distribution > method. > I think each of these representations should be well-defined for purposes of > interoperability. I may choose to implement my policy authoring tool as a > whiz-bang GUI that doesn't even use a policy specification language, but > outputs a storage schema that the downstream tools can understand. > > Perhaps you see a multi-purpose policy specification language used for > authoring > and then also storage (store the text of the specification). I was thinking > of a > PSL used for authoring, but another representation for storage (as in a > directory). > > I agree completely about doing a fair evaluation of existing protocols. > > -Mike > > > > From ???@??? Fri Jun 11 17:01:41 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id QAA11070 for ; Fri, 11 Jun 1999 16:46:09 -0700 (PDT) Received: from research.solidum.com [216.13.130.242] by mail.timestep.com [209. 47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Fri, 11 J un 1999 19:35:51 -0400 Received: from venus.solidum.com (venus.solidum.com [192.168.1.1]) by research.solidum.com (8.8.4/8.8.4) with ESMTP id TAA25239 for ; Fri, 11 Jun 1999 19 :27:27 -0400 Received: from phobos.solidum.com (mcr@phobos.solidum.com [192.168.1.13]) by venus.solidum.com (8.8.7/8.8.7) with ESMTP id TAA03633 for ; Fri, 11 Jun 1999 19:34:33 -0400 Message-ID: To: ipsec-policy@mail.timestep.com Subject: Re: Proposed IPSP Charter In-reply-to: Your message of "Fri, 11 Jun 1999 19:03:29 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 11 Jun 1999 19:34:33 -0400 From: Michael Richardson X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: mcr@solidum.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: b532ea9ef11dbb3036bfb7d5bb06e6fb >>>>> "Luis" == Luis A Sanchez writes: Luis> Like you, I was thinking more along the lines of a PSL Luis> separate from any of the several possible representation schemes for Luis> storage. On the other hand, Angelos brought up a good point: the Luis> original proposed charter might be to extensive. Taking this into Luis> consideration and for the sake of time it might be better if the WG Luis> begins working on: I would suggest that if it is important that the charter list it, but make it clear in the charter that these issues come later. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: mcr@solidum.com. From ???@??? Mon Jun 14 08:08:49 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id HAA16955 for ; Mon, 14 Jun 1999 07:51:17 -0700 (PDT) Received: from ganymede.or.intel.com [134.134.248.3] by mail.timestep.com [209. 47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Mon, 14 J un 1999 10:41:11 -0400 Received: from orsmsx29.jf.intel.com (orsmsx29.jf.intel.com [192.168.65.29]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id HAA23013 for ; Mon, 14 Jun 1999 07:40:04 -0700 ( PDT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 14 Jun 1999 07:40:02 -0700 Message-ID: From: "Jeronimo, Michael" To: "'ipsec-policy@mail.timestep.com'" Subject: RE: Proposed IPSP Charter Date: Mon, 14 Jun 1999 07:39:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: michael.jeronimo@intel.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 2fe6077a2418aeb6168c64809ecfe7d1 Luis, I think this is a good list to start with. In the interest of forward progress, we should stay focused. -Mike -----Original Message----- From: Luis A. Sanchez [mailto:lsanchez@bbn.com] Sent: Friday, June 11, 1999 4:03 PM To: ipsec-policy@mail.timestep.com Subject: Re: Proposed IPSP Charter Mike, Like you, I was thinking more along the lines of a PSL separate from any of the several possible representation schemes for storage. On the other hand, Angelos brought up a good point: the original proposed charter might be to extensive. Taking this into consideration and for the sake of time it might be better if the WG begins working on: 1) specifying a data model for supporting IP security policies, 2) adopting an extensible IPsec policy specification language, 3) developing a protocol capable of: o discovering policy servers o distributing and negotiating security policies o resolving policy conflicts in both intra/inter domain environments Once we *show* some progress we can attack issues such as storage, IKE mods, etc. We can fine tune how the charter is executed as we move along. Is this reasonable for starters? If so, Roy and I will submit the charter to the Sec Area directors for their revision and approval. Luis > > Luis, > > I see a policy system consisting of at least: > > - Authoring > - Storage > - Distribution > - Enforcement > - Feedback > > Each of these tasks are relative to a cannonical form (the core model), that > describes the semantics of the policy. I don't see a policy specification > language as any more important than a storage schema or a distribution > method. > I think each of these representations should be well-defined for purposes of > interoperability. I may choose to implement my policy authoring tool as a > whiz-bang GUI that doesn't even use a policy specification language, but > outputs a storage schema that the downstream tools can understand. > > Perhaps you see a multi-purpose policy specification language used for > authoring > and then also storage (store the text of the specification). I was thinking > of a > PSL used for authoring, but another representation for storage (as in a > directory). > > I agree completely about doing a fair evaluation of existing protocols. > > -Mike > > > > From ???@??? Mon Jun 14 09:39:39 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id JAA17067 for ; Mon, 14 Jun 1999 09:30:52 -0700 (PDT) Received: from calliope1.fm.intel.com [132.233.247.10] by mail.timestep.com [20 9.47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Mon, 14 Jun 1999 12:20:50 -0400 Received: from fmsmsx19.fm.intel.com (fmsmsx19.fm.intel.com [132.233.222.210]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id JAA01059 for ; Mon, 14 Jun 1999 09:19:45 -0700 ( PDT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 14 Jun 1999 09:19:44 -0700 Message-ID: From: "Jason, Jamie" To: "'ipsec-policy@mail.timestep.com'" Subject: RE: Proposed IPSP Charter Date: Mon, 14 Jun 1999 09:19:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: jamie.jason@intel.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: d51244b16bfb2ab003541913762374d3 > Also, why should this WG dictate one specific format (LDAP Schema) for > storing security policies? Why can't we allow several storage formats > provided we define a policy data model, adopt a language to represent > such policies and specify how such policies will look on the wire? I have been out of town for a few days, so haven't had a chance to read all of my email, but I believe that Mike was only giving examples of what you can derive from an IPSEC policy model. I don't think that he was advocating one storage or distribution mechanism over another. I think that the point is that the IPSEC policy model should be derived completely independent of any storage or distribution mechanism. This is the same thing that the policy WG is now going through - they are going over their charter again. They are going to develop an storage independent policy information model and then they will use that to develop LDAP schema, etc. By doing this, they will always have the core policy information model, whereas if they had continued on with just defining an LDAP schema, going back to the core policy information model would have been impossible and other storage mechanisms would have had to jump through hoops to represent policy information because they would be hamstrung by the way in which LDAP works. Jamie From ???@??? Mon Jun 14 10:07:26 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id KAA17095 for ; Mon, 14 Jun 1999 10:03:49 -0700 (PDT) Received: from calliope1.fm.intel.com [132.233.247.10] by mail.timestep.com [20 9.47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Mon, 14 Jun 1999 12:52:29 -0400 Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id JAA09490 for ; Mon, 14 Jun 1999 09:51:23 -0700 ( PDT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 14 Jun 1999 09:51:22 -0700 Message-ID: From: "Jason, Jamie" To: "'ipsec-policy@mail.timestep.com'" Subject: RE: Proposed IPSP Charter Date: Mon, 14 Jun 1999 09:51:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: jamie.jason@intel.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: bb39128ff837825494dec4224df84e07 Agreed. I would much rather see this group start with a smaller task and be successful. I do agree with M. Richardson that we should still keep the other tasks in the back of our minds. Jamie > -----Original Message----- > From: Jeronimo, Michael [mailto:michael.jeronimo@intel.com] > Sent: Monday, June 14, 1999 7:40 AM > To: 'ipsec-policy@mail.timestep.com' > Subject: RE: Proposed IPSP Charter > > > Luis, > > I think this is a good list to start with. In the interest > of forward progress, we should stay focused. > > -Mike > > -----Original Message----- > From: Luis A. Sanchez [mailto:lsanchez@bbn.com] > Sent: Friday, June 11, 1999 4:03 PM > To: ipsec-policy@mail.timestep.com > Subject: Re: Proposed IPSP Charter > > > Mike, > > Like you, I was thinking more along the lines of a PSL > separate from any of the several possible representation schemes for > storage. On the other hand, Angelos brought up a good point: the > original proposed charter might be to extensive. Taking this into > consideration and for the sake of time it might be better if the WG > begins working on: > > 1) specifying a data model for supporting IP security policies, > > 2) adopting an extensible IPsec policy specification language, > > 3) developing a protocol capable of: > o discovering policy servers > o distributing and negotiating security policies > o resolving policy conflicts in both intra/inter domain > environments > > Once we *show* some progress we can attack issues such as storage, IKE > mods, etc. We can fine tune how the charter is executed as we move > along. Is this reasonable for starters? If so, Roy and I will submit > the charter to the Sec Area directors for their revision and approval. > > Luis > > > > > > > > Luis, > > > > I see a policy system consisting of at least: > > > > - Authoring > > - Storage > > - Distribution > > - Enforcement > > - Feedback > > > > Each of these tasks are relative to a cannonical form (the > core model), > that > > describes the semantics of the policy. I don't see a > policy specification > > > language as any more important than a storage schema or a > distribution > > method. > > I think each of these representations should be > well-defined for purposes > of > > interoperability. I may choose to implement my policy > authoring tool as a > > > whiz-bang GUI that doesn't even use a policy specification > language, but > > outputs a storage schema that the downstream tools can understand. > > > > Perhaps you see a multi-purpose policy specification > language used for > > authoring > > and then also storage (store the text of the specification). I was > thinking > > of a > > PSL used for authoring, but another representation for > storage (as in a > > directory). > > > > I agree completely about doing a fair evaluation of > existing protocols. > > > > -Mike > > > > > > > > > > > From ???@??? Tue Jun 15 07:04:58 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id XAA17784 for ; Mon, 14 Jun 1999 23:19:43 -0700 (PDT) Received: from sm9ul021.aircanada.ca [209.89.122.37] by mail.timestep.com [209. 47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Tue, 15 J un 1999 02:10:55 -0400 Received: from aircanada.ca ([159.206.100.95]) by sm9ul021.aircanada.ca (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-0U10L2S100) with SMTP id AAA242 for ; Tue, 15 Jun 1999 02:14:15 -0400 Received: from ccMail by aircanada.ca (ccMail Link to SMTP R8.00.01) id AA929426966; Tue, 15 Jun 99 02:09:33 -0500 Message-ID: X-Mailer: ccMail Link to SMTP R8.00.01 Date: Tue, 15 Jun 99 01:00:49 -0500 From: "Benoit Hotte" To: Subject: Benoit Hotte est absent/is in vacation MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: bhotte@aircanada.ca Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by mail.vpnc.org id XAA1778 4 X-UIDL: b7279eb9e75808727693e0673b1738bb I will be out of the office from 12/06/99 until 21/06/99. I will respond to your message when I return. I case of emergency please contact my manager Laurent Hébert Je répondrai à mes messages à mon retour. En cas d'urgence svp contacter Laurent Hébert From ???@??? Fri Jun 25 09:10:53 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id GAA15202 for ; Fri, 25 Jun 1999 06:41:17 -0700 (PDT) Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12 ] with SMTP (MDaemon.v2.7.SP4.R) for ; Fri, 25 Jun 1999 09:32:51 -0400 Received: (from lsanchez@localhost) by nutmeg.bbn.com (8.8.8/8.8.7) id JAA00589 for ipsec-policy@mail.timestep.com; Fri, 25 Jun 1999 09:31:36 -0400 (ED T) (envelope-from lsanchez) From: "Luis A. Sanchez" Message-ID: Subject: 45th IETF: IPSP Meeting To: ipsec-policy@mail.timestep.com Date: Fri, 25 Jun 1999 09:31:36 -0400 (EDT) Reply-To: ipsec-policy@mail.timestep.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: lsanchez@nutmeg.bbn.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] X-UIDL: 620f05cfe459b7bd17d06ee5517234ac Folks, IPSP will be meeting in Oslo Wednesday, July 14 at 1530-1730. If you would like to present during the meeting send email to Roy and myself. Include a _short_ description of your presentation and time needed. The deadline for submitting the agenda is July 1 at 1200 ET so we need your input by no later than June 30th. Luis From ???@??? Tue Jun 29 09:48:36 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id GAA23856 for ; Tue, 29 Jun 1999 06:54:48 -0700 (PDT) Received: from po1.bbn.com [192.1.50.38] by mail.timestep.com [209.47.58.12] wi th SMTP (MDaemon.v2.7.SP4.R) for ; Tue, 29 Jun 1999 09:4 6:57 -0400 Received: from jzao.bbn.com (DHCP030-187.BBN.COM [171.78.30.187]) by po1.bbn.com (8.9.1/8.9.1) with SMTP id JAA24657; Tue, 29 Jun 1999 09:45:49 -0400 (EDT) Message-ID: X-Sender: jzao@po1.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 29 Jun 1999 09:37:57 -0400 To: "Luis A. Sanchez" , "Roy Pereira" From: "John K. Zao" Subject: Presentation proposal for IPSP WG Meeting at 45th IETF Cc: ipsec-policy@mail.timestep.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: jzao@bbn.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 98cb588d1bf7b33515a3f30049e8a62c At 09:31 AM 6/25/99 -0400, Luis A. Sanchez wrote: >Folks, > > IPSP will be meeting in Oslo Wednesday, July 14 at >1530-1730. If you would like to present during the meeting send email >to Roy and myself. Include a _short_ description of your presentation >and time needed. The deadline for submitting the agenda is July 1 at >1200 ET so we need your input by no later than June 30th. > >Luis > Luis and Roy, I would like to have 20 minutes in IPSP WG meeting to present a Semantic Model of IPSec Policy. Following is a brief description of the presentation. ----- A semantic model of IPSec policies is needed to specify ways that two or more IPSec policies -- enforced by same or different devices -- may interact with one another. The representation will focus on the following three types of policy interactions: 1. decorrelation of IPSec policies of same enforcement device with overlapping selector values, 2. composition of IPSec policies of peer communicating devices, 3. inference of sequences of packet header transformations caused by en-route enforcement of IPSec policies. A semantic algebra based on the IPSec Policy Data Model proposed by Pereira and Bhattacharya will be introduced and its algebra in determining the effects of the three interactions will be explained in the presentation. ----- An Internet-Draft of the same title was submitted to IPSec Working Group. A revised version will be posted to the IPSP mailing list. Thanks for your attention and looking forward to your reply. John John K. Zao GTE / BBN Technologies 10 Fawcett St., Cambridge, MA, USA 02139 Tel: (617) 873-2438 Fax: (617) 873-4086 Email: jzao@bbn.com From ???@??? Wed Jun 30 17:32:07 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id PAA27621 for ; Wed, 30 Jun 1999 15:23:39 -0700 (PDT) Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12 ] with SMTP (MDaemon.v2.7.SP4.R) for ; Wed, 30 Jun 1999 18:16:24 -0400 Received: (from lsanchez@localhost) by nutmeg.bbn.com (8.8.8/8.8.7) id SAA01055; Wed, 30 Jun 1999 18:15:40 -0400 (EDT) (envelope-from lsanchez) From: "Luis A. Sanchez" Message-ID: Subject: Re: Presentation proposal for IPSP WG Meeting at 45th IETF In-Reply-To: from "Jo hn K. Zao" at "Jun 29, 99 09:37:57 am" To: ipsec-policy@mail.timestep.com Date: Wed, 30 Jun 1999 18:15:40 -0400 (EDT) Cc: lsanchez@bbn.com, rpereira@timestep.com Reply-To: ipsec-policy@mail.timestep.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: lsanchez@nutmeg.bbn.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] X-UIDL: 145cbcbc0f5437c6550fe651052ce136 John, Please plan for 15 mins. Luis > At 09:31 AM 6/25/99 -0400, Luis A. Sanchez wrote: > >Folks, > > > > IPSP will be meeting in Oslo Wednesday, July 14 at > >1530-1730. If you would like to present during the meeting send email > >to Roy and myself. Include a _short_ description of your presentation > >and time needed. The deadline for submitting the agenda is July 1 at > >1200 ET so we need your input by no later than June 30th. > > > >Luis > > > > Luis and Roy, > > I would like to have 20 minutes in IPSP WG meeting to present a Semantic > Model of IPSec Policy. Following is a brief description of the presentation. > > ----- > A semantic model of IPSec policies is needed to specify ways that two or > more IPSec policies -- enforced by same or different devices -- may > interact with one another. The representation will focus on the following > three types of policy interactions: > > 1. decorrelation of IPSec policies of same enforcement device with > overlapping selector values, > > 2. composition of IPSec policies of peer communicating devices, > > 3. inference of sequences of packet header transformations caused by > en-route enforcement of IPSec policies. > > A semantic algebra based on the IPSec Policy Data Model proposed by Pereira > and Bhattacharya will be introduced and its algebra in determining the > effects of the three interactions will be explained in the presentation. > ----- > > An Internet-Draft of the same title was submitted to IPSec Working Group. A > revised version will be posted to the IPSP mailing list. > > Thanks for your attention and looking forward to your reply. > > John > > John K. Zao > GTE / BBN Technologies > 10 Fawcett St., Cambridge, MA, USA 02139 > Tel: (617) 873-2438 > Fax: (617) 873-4086 > Email: jzao@bbn.com > > > From ???@??? Tue Jul 06 07:49:47 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id HAA06265 for ; Tue, 6 Jul 1999 07:41:36 -0700 (PDT) Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58 .12] with SMTP (MDaemon.v2.7.SP4.R) for ; Tue, 06 Jul 19 99 10:19:19 -0400 Received: from netx1.nei.com (netx1.nei.com [209.69.28.17]) by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id KAA13958 for ; Tue, 6 Jul 1999 10:04:00 -0400 (E DT) From: ron_carter@netx1.nei.com Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00) id AA931270235; Tue, 06 Jul 99 10:10:36 -0500 Message-ID: X-Mailer: ccMail Link to SMTP R8.00.00 Date: Tue, 06 Jul 99 10:10:35 -0500 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: ron_carter@netx1.nei.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 9a3a337b3dfd6777579903751b79599c Message is undeliverable. Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory. Original text follows: --------------------- Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00 ) ; Tue, 06 Jul 99 10:10:30 -0500 Return-Path: <> Received: from stax05.cubis.de [194.112.101.49] by mail.timestep.com [209.47.58 .12] with SMTP (MDaemon.v2.7.SP4.R) for ; Tue, 06 Jul 1999 09:5 9:31 -0400 Received: from sn-dd003 ([10.182.4.161]) by stax05.cubis.de (8.7.5/8.7.3) with SMTP id PAA06774; Tue, 6 Jul 1999 15:56:22 +0200 (MET DST) Message-ID: X-Sender: martius@stmail01.cubis.de X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 06 Jul 1999 15:56:47 +0200 To: ipsec@lists.tislabs.com From: Kai Martius Subject: New Internet Draft - MIKE Cc: ipsec-policy@mail.timestep.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: rpluth@nei.com X-Return-Path: kai@secunet.de Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com Greetings, [Due to submission deadline I can only make my new Draft available this way for now - submission to internet-drafts registry follows] Abstract This document describes a protocol which allows to authenticate systems and establish Security Associations in networks with different domains of security. The protocol is not only end-to-end, but it involves all participating systems in a single exchange. Further it allows security gateways to derive sub-policies for crossing (encrypted) IPSec-traffic from "conventional" packet filtering rules in a trusted manner. The draft does not only specify a protocol, but it also describes the requireme nts in complex network environments for a surrounding security policy managemen t. Feel free to get a copy from http://www.imib.med.tu-dresden.de/imib/Internet/ike/draft-martius-ipsec-mike-00 .txt (if you have problems reaching this site, I'll send you a copy directly) The draft comes (late ;-) after a presentation in Minneapolis at the IPSec Poli cy BoF http://www.ietf.org/proceedings/99mar/44th-99mar-ietf-118.html Kai ------------------------------------ Kai Martius secunet Security Networks AG, Dresden (previous) homepage, IPSec-related stuff and PGP keys under: http://www.imib.med.tu-dresden.de/imib/personal/kai.html From ???@??? Tue Jul 06 09:27:25 1999 Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id IAA06339 for ; Tue, 6 Jul 1999 08:09:18 -0700 (PDT) Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i d <49766-10317>; Tue, 6 Jul 1999 11:09:59 -0400 Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58 .12] with SMTP (MDaemon.v2.7.SP4.R) for ; Tue, 06 Jul 19 99 10:45:39 -0400 Received: from netx1.nei.com (netx1.nei.com [209.69.28.17]) by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id KAA17680 for ; Tue, 6 Jul 1999 10:30:19 -0400 (E DT) From: ron_carter@netx1.nei.com Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00) id AA931271812; Tue, 06 Jul 99 10:36:56 -0500 Message-ID: X-Mailer: ccMail Link to SMTP R8.00.00 Date: Tue, 6 Jul 1999 11:36:52 -0400 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: ron_carter@netx1.nei.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: fcbe94aef5a4c0615e0715c86bfcd7d0 Message is undeliverable. Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory. Original text follows: --------------------- Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00 ) ; Tue, 06 Jul 99 10:36:49 -0500 Return-Path: <> Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58 .12] with SMTP (MDaemon.v2.7.SP4.R) for ; Tue, 06 Jul 1999 10:1 9:22 -0400 Received: from netx1.nei.com (netx1.nei.com [209.69.28.17]) by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id KAA13958 for ; Tue, 6 Jul 1999 10:04:00 -0400 (E DT) From: ron_carter@netx1.nei.com Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00) id AA931270235; Tue, 06 Jul 99 10:10:36 -0500 Message-ID: X-Mailer: ccMail Link to SMTP R8.00.00 Date: Tue, 06 Jul 99 10:10:35 -0500 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" X-MDaemon-Deliver-To: rpluth@nei.com X-Return-Path: ron_carter@netx1.nei.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com Message is undeliverable. Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory. Original text follows: --------------------- Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00 ) ; Tue, 06 Jul 99 10:10:30 -0500 Return-Path: <> Received: from stax05.cubis.de [194.112.101.49] by mail.timestep.com [209.47.58 .12] with SMTP (MDaemon.v2.7.SP4.R) for ; Tue, 06 Jul 1999 09:5 9:31 -0400 Received: from sn-dd003 ([10.182.4.161]) by stax05.cubis.de (8.7.5/8.7.3) with SMTP id PAA06774; Tue, 6 Jul 1999 15:56:22 +0200 (MET DST) Message-ID: X-Sender: martius@stmail01.cubis.de X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 06 Jul 1999 15:56:47 +0200 To: ipsec@lists.tislabs.com From: Kai Martius Subject: New Internet Draft - MIKE Cc: ipsec-policy@mail.timestep.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: rpluth@nei.com X-Return-Path: kai@secunet.de Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com Greetings, [Due to submission deadline I can only make my new Draft available this way for now - submission to internet-drafts registry follows] Abstract This document describes a protocol which allows to authenticate systems and establish Security Associations in networks with different domains of security. The protocol is not only end-to-end, but it involves all participating systems in a single exchange. Further it allows security gateways to derive sub-policies for crossing (encrypted) IPSec-traffic from "conventional" packet filtering rules in a trusted manner. The draft does not only specify a protocol, but it also describes the requireme nts in complex network environments for a surrounding security policy managemen t. Feel free to get a copy from http://www.imib.med.tu-dresden.de/imib/Internet/ike/draft-martius-ipsec-mike-00 .txt (if you have problems reaching this site, I'll send you a copy directly) The draft comes (late ;-) after a presentation in Minneapolis at the IPSec Poli cy BoF http://www.ietf.org/proceedings/99mar/44th-99mar-ietf-118.html Kai ------------------------------------ Kai Martius secunet Security Networks AG, Dresden (previous) homepage, IPSec-related stuff and PGP keys under: http://www.imib.med.tu-dresden.de/imib/personal/kai.html From ???@??? Sun Jul 11 16:07:30 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id QAA13096 for ; Fri, 9 Jul 1999 16:45:14 -0700 (PDT) Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12 ] with SMTP (MDaemon.v2.7.SP4.R) for ; Fri, 09 Jul 1999 19:33:51 -0400 Received: (from lsanchez@localhost) by nutmeg.bbn.com (8.8.8/8.8.7) id TAA01414 for ipsec-policy@mail.timestep.com; Fri, 9 Jul 1999 19:32:49 -0400 (EDT ) (envelope-from lsanchez) From: "Luis A. Sanchez" Message-ID: Subject: IPSP Agenda (fwd) To: ipsec-policy@mail.timestep.com Date: Fri, 9 Jul 1999 19:32:49 -0400 (EDT) Reply-To: ipsec-policy@mail.timestep.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: lsanchez@nutmeg.bbn.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] X-UIDL: a591a1f122272d852a0592cc9f8186ba ----- Forwarded message from Luis A. Sanchez ----- >From POPmail Thu Jul 1 16:55:43 1999 From: "Luis A. Sanchez" Message-Id: <199907012054.QAA02568@nutmeg.bbn.com> Subject: IPSP Agenda To: agenda@ietf.org Date: Thu, 1 Jul 1999 16:54:34 -0400 (EDT) Cc: rpereira@timestep.com, lsanchez@bbn.com Reply-to: lsanchez@bbn.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] Enclosed you will find the preliminary agenda for IPSP. Thanks! Luis Preliminary Agenda ------------------ - Agenda Bashing 5 mins o Unified IPsec policy model 15 mins o Semantic Model of IPsec Policy 15 mins o Multi-Domain IKE 15 mins - Charter Discussions 30 mins - Collect feedback and modify charter 15 mins - Adjourn ----- End of forwarded message from Luis A. Sanchez ----- From ???@??? Sun Jul 11 16:07:30 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id RAA13112 for ; Fri, 9 Jul 1999 17:05:17 -0700 (PDT) Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58 .12] with SMTP (MDaemon.v2.7.SP4.R) for ; Fri, 09 Jul 19 99 19:48:47 -0400 Received: from netx1.nei.com (netx1.nei.com [209.69.28.17]) by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id TAA14955 for ; Fri, 9 Jul 1999 19:33:38 -0400 (E DT) From: ron_carter@netx1.nei.com Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00) id AA931563619; Fri, 09 Jul 99 19:40:22 -0500 Message-ID: X-Mailer: ccMail Link to SMTP R8.00.00 Date: Fri, 09 Jul 99 19:40:19 -0500 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: ron_carter@netx1.nei.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 1036f143c707a3f0b3b649a52dbef451 Message is undeliverable. Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory. Original text follows: --------------------- Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00 ) ; Fri, 09 Jul 99 19:40:15 -0500 Return-Path: <> Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12 ] with SMTP (MDaemon.v2.7.SP4.R) for ; Fri, 09 Jul 1999 19:33:5 4 -0400 Received: (from lsanchez@localhost) by nutmeg.bbn.com (8.8.8/8.8.7) id TAA01414 for ipsec-policy@mail.timestep.com; Fri, 9 Jul 1999 19:32:49 -0400 (EDT ) (envelope-from lsanchez) From: "Luis A. Sanchez" Message-ID: Subject: IPSP Agenda (fwd) To: ipsec-policy@mail.timestep.com Date: Fri, 9 Jul 1999 19:32:49 -0400 (EDT) Reply-To: ipsec-policy@mail.timestep.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: rpluth@nei.com X-Return-Path: lsanchez@nutmeg.bbn.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] ----- Forwarded message from Luis A. Sanchez ----- >From POPmail Thu Jul 1 16:55:43 1999 From: "Luis A. Sanchez" Message-Id: <199907012054.QAA02568@nutmeg.bbn.com> Subject: IPSP Agenda To: agenda@ietf.org Date: Thu, 1 Jul 1999 16:54:34 -0400 (EDT) Cc: rpereira@timestep.com, lsanchez@bbn.com Reply-to: lsanchez@bbn.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] Enclosed you will find the preliminary agenda for IPSP. Thanks! Luis Preliminary Agenda ------------------ - Agenda Bashing 5 mins o Unified IPsec policy model 15 mins o Semantic Model of IPsec Policy 15 mins o Multi-Domain IKE 15 mins - Charter Discussions 30 mins - Collect feedback and modify charter 15 mins - Adjourn ----- End of forwarded message from Luis A. Sanchez ----- From ???@??? Sun Jul 11 16:07:30 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id RAA13148 for ; Fri, 9 Jul 1999 17:26:24 -0700 (PDT) Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58 .12] with SMTP (MDaemon.v2.7.SP4.R) for ; Fri, 09 Jul 19 99 20:09:02 -0400 Received: from netx1.nei.com (netx1.nei.com [209.69.28.17]) by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id TAA16223 for ; Fri, 9 Jul 1999 19:53:51 -0400 (E DT) From: ron_carter@netx1.nei.com Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00) id AA931564833; Fri, 09 Jul 99 20:00:35 -0500 Message-ID: X-Mailer: ccMail Link to SMTP R8.00.00 Date: Fri, 09 Jul 99 20:00:33 -0500 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: ron_carter@netx1.nei.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: d6def00daf0333f7ad1e73f8db85a89a Message is undeliverable. Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory. Original text follows: --------------------- Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00 ) ; Fri, 09 Jul 99 20:00:30 -0500 Return-Path: <> Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58 .12] with SMTP (MDaemon.v2.7.SP4.R) for ; Fri, 09 Jul 1999 19:4 8:51 -0400 Received: from netx1.nei.com (netx1.nei.com [209.69.28.17]) by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id TAA14955 for ; Fri, 9 Jul 1999 19:33:38 -0400 (E DT) From: ron_carter@netx1.nei.com Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00) id AA931563619; Fri, 09 Jul 99 19:40:22 -0500 Message-ID: X-Mailer: ccMail Link to SMTP R8.00.00 Date: Fri, 09 Jul 99 19:40:19 -0500 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" X-MDaemon-Deliver-To: rpluth@nei.com X-Return-Path: ron_carter@netx1.nei.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com Message is undeliverable. Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory. Original text follows: --------------------- Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00 ) ; Fri, 09 Jul 99 19:40:15 -0500 Return-Path: <> Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12 ] with SMTP (MDaemon.v2.7.SP4.R) for ; Fri, 09 Jul 1999 19:33:5 4 -0400 Received: (from lsanchez@localhost) by nutmeg.bbn.com (8.8.8/8.8.7) id TAA01414 for ipsec-policy@mail.timestep.com; Fri, 9 Jul 1999 19:32:49 -0400 (EDT ) (envelope-from lsanchez) From: "Luis A. Sanchez" Message-ID: Subject: IPSP Agenda (fwd) To: ipsec-policy@mail.timestep.com Date: Fri, 9 Jul 1999 19:32:49 -0400 (EDT) Reply-To: ipsec-policy@mail.timestep.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: rpluth@nei.com X-Return-Path: lsanchez@nutmeg.bbn.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] ----- Forwarded message from Luis A. Sanchez ----- >From POPmail Thu Jul 1 16:55:43 1999 From: "Luis A. Sanchez" Message-Id: <199907012054.QAA02568@nutmeg.bbn.com> Subject: IPSP Agenda To: agenda@ietf.org Date: Thu, 1 Jul 1999 16:54:34 -0400 (EDT) Cc: rpereira@timestep.com, lsanchez@bbn.com Reply-to: lsanchez@bbn.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] Enclosed you will find the preliminary agenda for IPSP. Thanks! Luis Preliminary Agenda ------------------ - Agenda Bashing 5 mins o Unified IPsec policy model 15 mins o Semantic Model of IPsec Policy 15 mins o Multi-Domain IKE 15 mins - Charter Discussions 30 mins - Collect feedback and modify charter 15 mins - Adjourn ----- End of forwarded message from Luis A. Sanchez ----- From ???@??? Mon Jul 12 17:09:47 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id HAA17176 for ; Mon, 12 Jul 1999 07:52:57 -0700 (PDT) Received: from POP3.tu-dresden.de [141.30.2.83] by mail.timestep.com [209.47.58 .12] with SMTP (MDaemon.v2.7.SP4.R) for ; Mon, 12 Jul 19 99 10:38:13 -0400 Received: from rmail.urz.tu-dresden.de by rks3 with SMTP (PP); Mon, 12 Jul 1999 16:36:03 +0200 Received: from rcs12.urz.tu-dresden.de by rmail with SMTP (IC-PP); Mon, 12 Jul 1999 16:26:38 +0200 Received: by rcs12.urz.tu-dresden.de (8.8.8) id QAA29020; Mon, 12 Jul 1999 16:36:36 +0200 (MET DST) From: martius Message-ID: Subject: Re: IPSP Agenda (fwd) In-Reply-To: from "Lu is A. Sanchez" at "Jul 9, 99 07:32:49 pm" To: ipsec-policy@mail.timestep.com Date: Mon, 12 Jul 1999 16:36:36 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: martius@rcs.urz.tu-dresden.de Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: b01cd2fab83eb38927115e7ea57064f8 Hi Luis, saw you put MIKE on the agenda... great. (I recognized it early enough to update my slides) I met a lot of people here already, except you and Roy. Are you already here in Oslo? We should make an appointment for Tuesday. CU Kai From ???@??? Mon Jul 12 17:16:12 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id IAA17215 for ; Mon, 12 Jul 1999 08:22:35 -0700 (PDT) Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58 .12] with SMTP (MDaemon.v2.7.SP4.R) for ; Mon, 12 Jul 19 99 10:57:05 -0400 Received: from netx1.nei.com (netx1.nei.com [209.69.28.17]) by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id KAA28480 for ; Mon, 12 Jul 1999 10:42:04 -0400 ( EDT) From: ron_carter@netx1.nei.com Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00) id AA931790931; Mon, 12 Jul 99 10:48:54 -0500 Message-ID: X-Mailer: ccMail Link to SMTP R8.00.00 Date: Mon, 12 Jul 99 10:48:51 -0500 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: ron_carter@netx1.nei.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 05f160deb56ae88eb76f8634ec2ee2f5 Message is undeliverable. Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory. Original text follows: --------------------- Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00 ) ; Mon, 12 Jul 99 10:48:45 -0500 Return-Path: <> Received: from POP3.tu-dresden.de [141.30.2.83] by mail.timestep.com [209.47.58 .12] with SMTP (MDaemon.v2.7.SP4.R) for ; Mon, 12 Jul 1999 10:3 8:15 -0400 Received: from rmail.urz.tu-dresden.de by rks3 with SMTP (PP); Mon, 12 Jul 1999 16:36:03 +0200 Received: from rcs12.urz.tu-dresden.de by rmail with SMTP (IC-PP); Mon, 12 Jul 1999 16:26:38 +0200 Received: by rcs12.urz.tu-dresden.de (8.8.8) id QAA29020; Mon, 12 Jul 1999 16:36:36 +0200 (MET DST) From: martius Message-ID: Subject: Re: IPSP Agenda (fwd) In-Reply-To: from "Lu is A. Sanchez" at "Jul 9, 99 07:32:49 pm" To: ipsec-policy@mail.timestep.com Date: Mon, 12 Jul 1999 16:36:36 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: rpluth@nei.com X-Return-Path: martius@rcs.urz.tu-dresden.de Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com Hi Luis, saw you put MIKE on the agenda... great. (I recognized it early enough to update my slides) I met a lot of people here already, except you and Roy. Are you already here in Oslo? We should make an appointment for Tuesday. CU Kai From ???@??? Mon Jul 12 17:16:12 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id IAA17232 for ; Mon, 12 Jul 1999 08:47:10 -0700 (PDT) Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58 .12] with SMTP (MDaemon.v2.7.SP4.R) for ; Mon, 12 Jul 19 99 11:26:47 -0400 Received: from netx1.nei.com (netx1.nei.com [209.69.28.17]) by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id LAA03178 for ; Mon, 12 Jul 1999 11:11:44 -0400 ( EDT) From: ron_carter@netx1.nei.com Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00) id AA931792711; Mon, 12 Jul 99 11:18:34 -0500 Message-ID: X-Mailer: ccMail Link to SMTP R8.00.00 Date: Mon, 12 Jul 99 11:18:31 -0500 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: ron_carter@netx1.nei.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: baac021c9d05de5fadfeca259988f2f8 Message is undeliverable. Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory. Original text follows: --------------------- Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00 ) ; Mon, 12 Jul 99 11:18:26 -0500 Return-Path: <> Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58 .12] with SMTP (MDaemon.v2.7.SP4.R) for ; Mon, 12 Jul 1999 10:5 7:07 -0400 Received: from netx1.nei.com (netx1.nei.com [209.69.28.17]) by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id KAA28480 for ; Mon, 12 Jul 1999 10:42:04 -0400 ( EDT) From: ron_carter@netx1.nei.com Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00) id AA931790931; Mon, 12 Jul 99 10:48:54 -0500 Message-ID: X-Mailer: ccMail Link to SMTP R8.00.00 Date: Mon, 12 Jul 99 10:48:51 -0500 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" X-MDaemon-Deliver-To: rpluth@nei.com X-Return-Path: ron_carter@netx1.nei.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com Message is undeliverable. Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory. Original text follows: --------------------- Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00 ) ; Mon, 12 Jul 99 10:48:45 -0500 Return-Path: <> Received: from POP3.tu-dresden.de [141.30.2.83] by mail.timestep.com [209.47.58 .12] with SMTP (MDaemon.v2.7.SP4.R) for ; Mon, 12 Jul 1999 10:3 8:15 -0400 Received: from rmail.urz.tu-dresden.de by rks3 with SMTP (PP); Mon, 12 Jul 1999 16:36:03 +0200 Received: from rcs12.urz.tu-dresden.de by rmail with SMTP (IC-PP); Mon, 12 Jul 1999 16:26:38 +0200 Received: by rcs12.urz.tu-dresden.de (8.8.8) id QAA29020; Mon, 12 Jul 1999 16:36:36 +0200 (MET DST) From: martius Message-ID: Subject: Re: IPSP Agenda (fwd) In-Reply-To: from "Lu is A. Sanchez" at "Jul 9, 99 07:32:49 pm" To: ipsec-policy@mail.timestep.com Date: Mon, 12 Jul 1999 16:36:36 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: rpluth@nei.com X-Return-Path: martius@rcs.urz.tu-dresden.de Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com Hi Luis, saw you put MIKE on the agenda... great. (I recognized it early enough to update my slides) I met a lot of people here already, except you and Roy. Are you already here in Oslo? We should make an appointment for Tuesday. CU Kai From ???@??? Thu Jul 15 16:20:17 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id FAA01244 for ; Thu, 15 Jul 1999 05:49:29 -0700 (PDT) Received: from ctron-dnm.ctron.com [12.25.1.120] by mail.timestep.com [209.47.5 8.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Thu, 15 Jul 1 999 08:38:12 -0400 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id IAA15765 for ; Thu, 15 Jul 1999 08:38:51 -0400 ( EDT) Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via s map (4.1) id xma015718; Thu, 15 Jul 99 08:38:40 -0400 Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id IAA19918 for ; Thu, 15 Jul 1999 08:42:15 -0400 ( EDT) Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id <38L7042H>; Thu, 15 Jul 1999 13:36:19 +0100 Message-ID: From: "Waters, Stephen" To: ipsec-policy@mail.timestep.com Subject: FW: Policy management, COPS, and SCVP Date: Thu, 15 Jul 1999 13:36:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: Stephen.Waters@cabletron.com Sender: BadMsgQ@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: [trash] Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 9d4387e1826b773f9366bf14a60b65bf > Hi, > > Is anyone thinking much about policy management for IPSEC VPN > clients? I've > been reading a bit about Common Open Policy Service (COPS) > which seems to > offer a solution with 'dynamic' policy decisions. > > One thought I had when reading it, is that the COPS server (The Policy > Decision Point - PDP), could be passed the client certificate > to start the > policy look-up. This would then allow the COPS server to do > the job of SCVP > as well: > > 1) check the certificate > 2) return the appropriate policy, or reject. > > Steve. -----Original Message----- From: Tim Jenkins [mailto:tjenkins@TimeStep.com] Sent: Thursday, July 15, 1999 10:54 AM To: Waters, Stephen Subject: RE: Policy management, COPS, and SCVP Steve, Just a comment on distribution; Are you reading the ipsp mailing list? It's likely to become (or perhaps already has become) a WG, chaired by Luis Sanchez and Roy Periera. It's at ipsec-policy@mail.timestep.com Your posting is perfect for that forum. Tim --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Waters, Stephen [mailto:Stephen.Waters@cabletron.com] > Sent: July 15, 1999 11:45 AM > To: ipsec@lists.tislabs.com > Subject: Policy management, COPS, and SCVP > > > > Hi, > > Is anyone thinking much about policy management for IPSEC VPN > clients? I've > been reading a bit about Common Open Policy Service (COPS) > which seems to > offer a solution with 'dynamic' policy decisions. > > One thought I had when reading it, is that the COPS server (The Policy > Decision Point - PDP), could be passed the client certificate > to start the > policy look-up. This would then allow the COPS server to do > the job of SCVP > as well: > > 1) check the certificate > 2) return the appropriate policy, or reject. > > Steve. > From ???@??? Tue Jul 20 09:35:34 1999 Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id EAA04009 for ; Tue, 20 Jul 1999 04:36:25 -0700 (PDT) Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i d <49639-29186>; Tue, 20 Jul 1999 07:37:53 -0400 Received: from zaphod.axion.bt.co.uk [132.146.5.1] by mail.timestep.com [209.47 .58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Tue, 20 Jul 1999 07:34:03 -0400 Received: from msn.bt.co.uk (actually goofy.msn.bt.co.uk) by zaphod.axion.bt.co .uk with SMTP (PP); Tue, 20 Jul 1999 12:32:54 +0100 Received: from msn.bt.co.uk by msn.bt.co.uk (SMI-8.6/SMI-SVR4) id MAA13511; Tue , 20 Jul 1999 12:37:55 +0100 Message-ID: Date: Tue, 20 Jul 1999 07:32:48 -0400 From: Steve Forrester Reply-To: ipsec-policy@mail.timestep.com Organization: British Telecommunications plc X-Mailer: Mozilla 4.6 [en-gb] (Win95; U) X-Accept-Language: en-GB,en,en-* MIME-Version: 1.0 To: ipsec-policy@mail.timestep.com Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: steve@msn.bt.co.uk Sender: rpereira@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: rpereira@mail.timestep.com X-UIDL: d3196ce10805477fe1fe64994d1cb2ca subscribe From ???@??? Fri Jul 23 15:49:32 1999 Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id PAA07647 for ; Fri, 23 Jul 1999 15:43:09 -0700 (PDT) Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i d <49735-17812>; Fri, 23 Jul 1999 18:45:08 -0400 Received: from ns.newbridge.com [192.75.23.67] by mail.timestep.com [209.47.58. 12] with SMTP (MDaemon.v2.7.SP4.R) for ; Fri, 23 Jul 199 9 15:35:17 -0400 Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id PAA11882 for ipsec-policy@mail.timestep.com; Fri, 23 Jul 1999 15:34:26 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1. ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdBAAa11855; Fri Jul 23 15:34:17 1999 Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Fri, 23 Jul 1999 15:34:16 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Fri, 23 Jul 1999 15:37:10 -0400 Message-ID: From: Andrew Milne To: ipsec-policy@mail.timestep.com Cc: "'mcondell@bbn.com'" , "'clynn@bbn.com'" , "'jzao@bbn.com'" Subject: SPSL draft V1 -- ipseccipher, ipsecintegrity formats Date: Fri, 23 Jul 1999 15:37:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: amilne@TimeStep.com Sender: rpereira@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: rpereira@mail.timestep.com Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 07a3b159797108ad0b96284843245e5a Hi. I'm reading SPSL V1 (July 1, 1999, and yes, I know it wasn't posted to this list, but it seems to me this is probably where I should be asking this anyway), and I read in 5.3. IPSecPolicy Class, for ipseccipher: is a list of one or more of: [keylen ] [rounds ] is one of "any", "blowfish", "cast", "des", "des3", "idea", "idea3", "none", "rc4", "rc5", "rfc1829-iv32", "rfc1829-iv64", or an as defined in [rfc2407], optionally preceded by "not" ... and and for ipsecintegrityalg: is a list of one or more of: [keylen ] is one of "any", "hmacdes","hmacmd5", "hmacsha1", "kpdk", or an as defined in [rfc2407], optionally preceded by "not" ... but for the definition of ipcomp: is "any", or one or more of: "deflate", "lzs", "oui", or an as defined in [rfc2407], optionally preceded by "not" ... and for hashalg: is "any", or one or more of: "md5", "sha1", "tiger", or an as defined in [rfc2409], optionally preceded by "not" So I get, legal for hashalg: a. any b. md5, tiger c. not (md5, tiger) ... which makes a certain amount of sense to me. And similarily, legal for ipcomp: a. any b. deflate, oui c. not (deflate, oui) ... which also kinda makes sense. In contrast, for ipsecintegrity, I get, all legal: a. any b. hmacdes, not hmacdes, hmacmd5 c. hmacsha1, not kpdk... ... and similar for ipseccipher. My point being, for ipcomp and hashalg, the spec seems successfully to rule out much that is contradictory or merely annoying, whereas for ipseccipher and ipsecintegrityalg, it does not seem to do so. I'd have pictured something like: is "any", or a list of one or more of: [keylen ] [rounds ], optionally preceded by "not" is one of "blowfish", "cast", "des", "des3", "idea", "idea3", "none", "rc4", "rc5", "rfc1829-iv32", "rfc1829-iv64", or an as defined in [rfc2407] ... or if the intent is to be able to specify a minimum keylength independent of cipher algorithm: is "any" [keylen ], or a list of one or more of: [keylen ] [rounds ], optionally preceded by "not" ... similar for ipsecintegrity. Or am I missing something here? (Should say, seein' as I'm just delurking -- awesome spec, overall, thanks.) Andrew Milne Computer Systems Analyst TimeStep Inc. 593 Herndon Parkway Herndon, VA, USA 20170 From ???@??? Mon Jul 26 09:14:50 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id GAA28589 for ; Mon, 26 Jul 1999 06:33:44 -0700 (PDT) Received: from wolfe.bbn.com [128.89.2.232] by mail.timestep.com [209.47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Mon, 26 Jul 1999 0 9:22:51 -0400 Received: (from mcondell@localhost) by wolfe.bbn.com (8.8.8/8.8.6) id JAA24273; Mon, 26 Jul 1999 09:21:11 -0400 (EDT) Date: Mon, 26 Jul 1999 09:21:11 -0400 (EDT) Message-ID: From: Matthew Condell To: ipsec-policy@mail.timestep.com Cc: Andrew Milne , clynn@bbn.com, jzao@bbn.com Subject: Re: SPSL draft V1 -- ipseccipher, ipsecintegrity formats X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: mcondell@bbn.com Sender: rpereira@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: rpereira@mail.timestep.com Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 4362d87dafb27bb178f35d40148b519a >Hi. I'm reading SPSL V1 (July 1, 1999, and yes, I know it wasn't posted to >this list, but it seems to me this is probably where I should be asking this >anyway), and I read in 5.3. IPSecPolicy Class, for ipseccipher: ... > is "any", or one or more of: "md5", "sha1", "tiger", > or an as defined in [rfc2409], optionally > preceded by "not" > >So I get, legal for hashalg: > > a. any > b. md5, tiger > c. not (md5, tiger) Actually, the text was meant to describe: c. not md5, not tiger It's written into the BNF in this fashion. ... >... and similar for ipseccipher. My point being, for ipcomp and hashalg, the >spec seems successfully to rule out much that is contradictory or merely >annoying, whereas for ipseccipher and ipsecintegrityalg, it does not seem to >do so. I'd have pictured something like: But, yes this is a problem. We make note of it in section 5.1 talking about addresses where there is a similar problem. Your interpretation of c. above seems like a good solution to me. If there are no objections, I'll change all the occurances of 'list of [not] ' to '[not] list of element'. That should handle this problem everywhere it occurs in the document. Thanks for pointing this out. Matt Condell BBN Technologies From ???@??? Wed Jul 28 09:15:48 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id FAA19438 for ; Wed, 28 Jul 1999 05:43:33 -0700 (PDT) Received: from wolfe.bbn.com [128.89.2.232] by mail.timestep.com [209.47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Wed, 28 Jul 1999 0 8:33:26 -0400 Received: (from mcondell@localhost) by wolfe.bbn.com (8.8.8/8.8.6) id IAA05664; Wed, 28 Jul 1999 08:31:57 -0400 (EDT) Date: Wed, 28 Jul 1999 08:31:57 -0400 (EDT) Message-ID: From: Matthew Condell To: policy@raliegh.ibm.com Cc: ipsec-policy@mail.timestep.com Subject: Policy framework and IPsec policy X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: mcondell@bbn.com Sender: rpereira@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: rpereira@mail.timestep.com Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 4d18d6272dec01ae0879a88ee60b7006 Hi, I've been reviewing the policy WG drafts from the perspective of IPsec policy. My interest is more in framework issues than data model/schema issues. Most of my comments are based on draft-ietf-policy-terms-02.txt. In general, I believe the general policy framework works well with the security policy framework, except it one basic assumption. The general policy framework is based on an intra-domain model where as IPsec policy MUST deal with inter-domain issues. However, I think a few modifications to the model would allow IPsec policy to fit in the framework, without disturbing the intra-domain model that is already present. In draft-ietf-policy-terms-02.txt: Section 4.1: For inter-domain policy negotiation, different domains will not share a policy repository, so it is necessary for the PDPs to be able to communicate with each other. We should make sure that the architecture does not prohibit this. Section 5.10: Inter-domain policy conflicts are not necessarily resolvable, since it is not really possible to choose one conflicting policy over the other. Additionally, to allow inter-domain policy caching, it is necessary to be able to maintain (either in the repository or PDP) policies in a non-overlapping form. (draft-ietf-ipsec-spp-00.txt refers to non-overlapping policies as decorrelated.) In decorrelated form, the conditions of no two policies can be simultaneously satisfied. The framework must be able to support such a set of policies to enable it to support IPsec policy. This example shows why decorrelation is necessary for an inter-domain policy framework. (The example is from the Security Policy Sytem Architecture draft which is not yet published.) >Caching correlated policies can lead to incorrect policy >implementation based on those cached policies, as the following >example shows. > > H1 --- SG1 --------- SG2 --- H2 > | | \__ H3 > | | > PS1 PS2 > >PS2 contains the following policies in its master file: > src dst proto direction action > 1) * H2 * inbound permit > 2) * * * inbound deny > >These two policies are correlated since all the selectors (src, dst, >proto, and direction) overlap. The following SPP exchanges occur: > > 1) PS1 requests policy for H3. > 2) PS2 returns policy #2 to PS1 which then caches policy #2. > 3) PS1 now looks up the policy for H2 and discovers that it already > has a matching policy (policy #2) and uses that. > >This is clearly wrong, since policy #2 indicates that the >communication to H2 should be denied, though PS2's policy actually >indicates that it should be allowed. > > The solution is to remove the ambiguities that may exist in >the master file. The policies of the master file MUST be decorrelated >before they are entered into the Local Policy Database. That is, the >policies must be rewritten so that for every pair of policies there >exists a selector for which there is a nil intersection between the >values in both of the policies. > >The policies in the above example could be decorrelated as follows: > src dst proto direction action > 1') * H2 * inbound permit > 2') * not H2 * inbound deny > >Now the exchange is a bit different: > 1) PS1 requests policy for H3. > 2) PS2 returns policy #2' to PS1 which then caches policy #2'. > 3) PS1 now looks up the policy for H2, doesn't have a matching > policy, so it requests a policy for H2. > 4) PS2 returns policy #1' to PS1 which then caches policy #1', > which is the correct policy for H2. > These are the main points where I believe an IPsec policy framework diverges from general policy framework. Matthew Condell BBN Technologies From ???@??? Wed Jul 28 09:15:48 1999 Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id GAA19486 for ; Wed, 28 Jul 1999 06:07:38 -0700 (PDT) Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i d <55981-9983>; Wed, 28 Jul 1999 09:09:59 -0400 Received: from wolfe.bbn.com [128.89.2.232] by mail.timestep.com [209.47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Wed, 28 Jul 1999 0 8:36:48 -0400 Received: (from mcondell@localhost) by wolfe.bbn.com (8.8.8/8.8.6) id IAA05692; Wed, 28 Jul 1999 08:35:17 -0400 (EDT) Date: Wed, 28 Jul 1999 08:35:17 -0400 Message-ID: From: Matthew Condell To: policy@raleigh.ibm.com Cc: ipsec-policy@mail.timestep.com Subject: Policy Framework and IPsec policy X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: mcondell@bbn.com Sender: rpereira@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: rpereira@mail.timestep.com Reply-To: ipsec-policy@mail.timestep.com X-UIDL: b6c856fb15cfbc58b7f3b2f36b3467da [Sorry for the repeated message to ipsec-policy. The policy address is now spelled correctly] Hi, I've been reviewing the policy WG drafts from the perspective of IPsec policy. My interest is more in framework issues than data model/schema issues. Most of my comments are based on draft-ietf-policy-terms-02.txt. In general, I believe the general policy framework works well with the security policy framework, except it one basic assumption. The general policy framework is based on an intra-domain model where as IPsec policy MUST deal with inter-domain issues. However, I think a few modifications to the model would allow IPsec policy to fit in the framework, without disturbing the intra-domain model that is already present. In draft-ietf-policy-terms-02.txt: Section 4.1: For inter-domain policy negotiation, different domains will not share a policy repository, so it is necessary for the PDPs to be able to communicate with each other. We should make sure that the architecture does not prohibit this. Section 5.10: Inter-domain policy conflicts are not necessarily resolvable, since it is not really possible to choose one conflicting policy over the other. Additionally, to allow inter-domain policy caching, it is necessary to be able to maintain (either in the repository or PDP) policies in a non-overlapping form. (draft-ietf-ipsec-spp-00.txt refers to non-overlapping policies as decorrelated.) In decorrelated form, the conditions of no two policies can be simultaneously satisfied. The framework must be able to support such a set of policies to enable it to support IPsec policy. This example shows why decorrelation is necessary for an inter-domain policy framework. (The example is from the Security Policy Sytem Architecture draft which is not yet published.) >Caching correlated policies can lead to incorrect policy >implementation based on those cached policies, as the following >example shows. > > H1 --- SG1 --------- SG2 --- H2 > | | \__ H3 > | | > PS1 PS2 > >PS2 contains the following policies in its master file: > src dst proto direction action > 1) * H2 * inbound permit > 2) * * * inbound deny > >These two policies are correlated since all the selectors (src, dst, >proto, and direction) overlap. The following SPP exchanges occur: > > 1) PS1 requests policy for H3. > 2) PS2 returns policy #2 to PS1 which then caches policy #2. > 3) PS1 now looks up the policy for H2 and discovers that it already > has a matching policy (policy #2) and uses that. > >This is clearly wrong, since policy #2 indicates that the >communication to H2 should be denied, though PS2's policy actually >indicates that it should be allowed. > > The solution is to remove the ambiguities that may exist in >the master file. The policies of the master file MUST be decorrelated >before they are entered into the Local Policy Database. That is, the >policies must be rewritten so that for every pair of policies there >exists a selector for which there is a nil intersection between the >values in both of the policies. > >The policies in the above example could be decorrelated as follows: > src dst proto direction action > 1') * H2 * inbound permit > 2') * not H2 * inbound deny > >Now the exchange is a bit different: > 1) PS1 requests policy for H3. > 2) PS2 returns policy #2' to PS1 which then caches policy #2'. > 3) PS1 now looks up the policy for H2, doesn't have a matching > policy, so it requests a policy for H2. > 4) PS2 returns policy #1' to PS1 which then caches policy #1', > which is the correct policy for H2. > These are the main points where I believe the IPsec policy framework diverges from general policy framework. Matthew Condell BBN Technologies From ???@??? Wed Jul 28 10:48:26 1999 Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA19929 for ; Wed, 28 Jul 1999 10:31:10 -0700 (PDT) Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i d <56493-23520>; Wed, 28 Jul 1999 13:33:08 -0400 Received: from smtprtp1.nortel.net [137.118.22.14] by mail.timestep.com [209.47 .58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Wed, 28 Jul 1999 13:15:51 -0400 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprtp1.nortel.net; Wed, 28 Jul 1999 13:13:17 -0400 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448. 0) id PYN10R7T; Wed, 28 Jul 1999 12:13:15 -0500 Received: from americasm01.nt.com (wppkhc0b.us.nortel.com [47.39.57.22]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448. 0) id P3LNXN4M; Wed, 28 Jul 1999 13:13:17 -0400 Sender: "He Huang" Message-ID: Date: Wed, 28 Jul 1999 13:13:15 -0400 From: "He Huang" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (X11; U; HP-UX B.10.20 9000/712) MIME-Version: 1.0 To: Matthew Condell , policy@raleigh.ibm.com, ipsec-policy@mail.timestep.com Subject: Re: Policy Framework and IPsec policy References: <199907281235.IAA05692@wolfe.bbn.com> Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: huanghe@nortelnetworks.com Sender: rpereira@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: rpereira@mail.timestep.com Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 930ebedee47d0d9b373dbc79abc758b0 Hi, Certainly, before one policy is saved in policy repository/master database, it's necessary to do conflict detection and resolution. The question is that who is responsible for that work, PolicyFramework or LDAP itself(Assume repository is LDAP directory). In addition, Policy Framework suggests two solutions for policy conflict( draft-strassner-policy- terms-00.txt): first matching rule and priority rule. It seems not to work well in some situations. Any new solution for policy conflict? Matthew Condell wrote: > > [Sorry for the repeated message to ipsec-policy. The policy address > is now spelled correctly] > > Hi, > > I've been reviewing the policy WG drafts from the perspective > of IPsec policy. My interest is more in framework issues than > data model/schema issues. Most of my comments are based on > draft-ietf-policy-terms-02.txt. > > In general, I believe the general policy framework works well > with the security policy framework, except it one basic assumption. > The general policy framework is based on an intra-domain model > where as IPsec policy MUST deal with inter-domain issues. > > However, I think a few modifications to the model would allow > IPsec policy to fit in the framework, without disturbing the > intra-domain model that is already present. > > In draft-ietf-policy-terms-02.txt: > > Section 4.1: > > For inter-domain policy negotiation, different domains will not > share a policy repository, so it is necessary for the PDPs to > be able to communicate with each other. We should make sure > that the architecture does not prohibit this. > > Section 5.10: > > Inter-domain policy conflicts are not necessarily resolvable, > since it is not really possible to choose one conflicting > policy over the other. > > Additionally, to allow inter-domain policy caching, it is necessary to > be able to maintain (either in the repository or PDP) policies in a > non-overlapping form. (draft-ietf-ipsec-spp-00.txt refers to > non-overlapping policies as decorrelated.) In decorrelated form, the > conditions of no two policies can be simultaneously satisfied. The > framework must be able to support such a set of policies to enable it > to support IPsec policy. > > This example shows why decorrelation is necessary for an inter-domain > policy framework. (The example is from the Security Policy Sytem > Architecture draft which is not yet published.) > > >Caching correlated policies can lead to incorrect policy > >implementation based on those cached policies, as the following > >example shows. > > > > H1 --- SG1 --------- SG2 --- H2 > > | | \__ H3 > > | | > > PS1 PS2 > > > >PS2 contains the following policies in its master file: > > src dst proto direction action > > 1) * H2 * inbound permit > > 2) * * * inbound deny > > > >These two policies are correlated since all the selectors (src, dst, > >proto, and direction) overlap. The following SPP exchanges occur: > > > > 1) PS1 requests policy for H3. > > 2) PS2 returns policy #2 to PS1 which then caches policy #2. > > 3) PS1 now looks up the policy for H2 and discovers that it already > > has a matching policy (policy #2) and uses that. > > > >This is clearly wrong, since policy #2 indicates that the > >communication to H2 should be denied, though PS2's policy actually > >indicates that it should be allowed. > > > > The solution is to remove the ambiguities that may exist in > >the master file. The policies of the master file MUST be decorrelated > >before they are entered into the Local Policy Database. That is, the > >policies must be rewritten so that for every pair of policies there > >exists a selector for which there is a nil intersection between the > >values in both of the policies. > > > >The policies in the above example could be decorrelated as follows: > > src dst proto direction action > > 1') * H2 * inbound permit > > 2') * not H2 * inbound deny > > > >Now the exchange is a bit different: > > 1) PS1 requests policy for H3. > > 2) PS2 returns policy #2' to PS1 which then caches policy #2'. > > 3) PS1 now looks up the policy for H2, doesn't have a matching > > policy, so it requests a policy for H2. > > 4) PS2 returns policy #1' to PS1 which then caches policy #1', > > which is the correct policy for H2. > > > > These are the main points where I believe the IPsec policy framework > diverges from general policy framework. > > Matthew Condell > BBN Technologies From ???@??? Wed Jul 28 12:01:48 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id KAA20004 for ; Wed, 28 Jul 1999 10:59:25 -0700 (PDT) Received: from wolfe.bbn.com [128.89.2.232] by mail.timestep.com [209.47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Wed, 28 Jul 1999 1 3:48:15 -0400 Received: (from mcondell@localhost) by wolfe.bbn.com (8.8.8/8.8.6) id NAA07663; Wed, 28 Jul 1999 13:46:40 -0400 (EDT) Date: Wed, 28 Jul 1999 13:46:40 -0400 (EDT) Message-ID: From: Matthew Condell To: "He Huang" Cc: policy@raleigh.ibm.com, ipsec-policy@mail.timestep.com References: <379F3A2B.9AC82B6D@americasm01.nt.com> Subject: Re: Policy Framework and IPsec policy X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: mcondell@bbn.com Sender: rpereira@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: rpereira@mail.timestep.com Reply-To: ipsec-policy@mail.timestep.com X-UIDL: d6d650301ba0c836c594bf10e367bd1b Hi, >Certainly, before one policy is saved in policy repository/master >database, it's necessary to do conflict detection and resolution. The >question is that who is responsible for that work, PolicyFramework or >LDAP itself(Assume repository is LDAP directory). In addition, Policy >Framework suggests two solutions for policy conflict( >draft-strassner-policy- terms-00.txt): first matching rule and priority >rule. It seems not to work well in some situations. Any new solution for >policy conflict? There are really two levels of conflict resolution when dealing with inter-domain policy. The intra-domain conflict resolution which can be solved using first match or priorities. Inter-domain conflict resolution is different, however. If two policies that are from different domains conflict about a particular communication, there is no appropriate resolution since the two policies are established by two different administrative domains. The communication may just not be possible. The framework should acknowledge this possiblility to not exclude inter-domain policy from fitting withing the framework. Matthew Condell BBN Technologies From ???@??? Wed Jul 28 12:01:48 1999 Received: from mail.timestep.com ([209.47.58.12]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id LAA20057 for ; Wed, 28 Jul 1999 11:23:27 -0700 (PDT) Received: from alms1.fw.att.com [192.128.167.146] by mail.timestep.com [209.47. 58.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Wed, 28 Jul 1999 14:11:50 -0400 Received: from qsun.ho.att.com ([135.16.30.2]) by alms1.fw.att.com (AT&T IPNS/MS-2.2) with SMTP id OAA00742; Wed, 28 Jul 1999 14:10:21 -0400 (EDT) Received: from schooner.local.windrose.omaha.ne.us by qsun.ho.att.com (SMI-8.6/ EMS-1.2 sol2) id OAA17595; Wed, 28 Jul 1999 14:10:19 -0400 From: "Ryan Moats" To: "Matthew Condell" , "He Huang" Cc: , Subject: RE: Policy Framework and IPsec policy Date: Wed, 28 Jul 1999 13:08:16 -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 8.5, Build 4.71.2377.0 In-Reply-To: <199907281746.NAA07663@wolfe.bbn.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: jayhawk@att.com Sender: rpereira@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: rpereira@mail.timestep.com Reply-To: ipsec-policy@mail.timestep.com X-UIDL: b37904072c2b981c1ec44f300e07944c | Hi, | | >Certainly, before one policy is saved in policy repository/master | >database, it's necessary to do conflict detection and resolution. The | >question is that who is responsible for that work, PolicyFramework or | >LDAP itself(Assume repository is LDAP directory). In addition, Policy | >Framework suggests two solutions for policy conflict( | >draft-strassner-policy- terms-00.txt): first matching rule and priority | >rule. It seems not to work well in some situations. Any new solution for | >policy conflict? | | There are really two levels of conflict resolution when dealing with | inter-domain policy. The intra-domain conflict resolution which can | be solved using first match or priorities. | | Inter-domain conflict resolution is different, however. If two | policies that are from different domains conflict about a particular | communication, there is no appropriate resolution since the two | policies are established by two different administrative domains. The | communication may just not be possible. The framework should | acknowledge this possiblility to not exclude inter-domain policy from | fitting withing the framework. Just a technology note. LDAP is not going to do conflict resolution beyond anything provided by LDUP (replication conflict resolution). Conflict resolution that involves syntactical interpretation of the data is not something LDAP does (or was ever intended to do). Ryan From ???@??? Thu Jul 29 13:45:00 1999 Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA00667 for ; Thu, 29 Jul 1999 13:02:10 -0700 (PDT) Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i d <50308-5253>; Thu, 29 Jul 1999 16:04:39 -0400 Received: from diablo.cisco.com [171.68.224.210] by mail.timestep.com [209.47.5 8.12] with SMTP (MDaemon.v2.7.SP4.R) for ; Thu, 29 Jul 1 999 15:47:41 -0400 Received: from jschnizl1-pc.cisco.com (jschnizl-isdn.cisco.com [171.70.238.115] ) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA271 70; Thu, 29 Jul 1999 12:45:36 -0700 (PDT) Message-ID: X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 29 Jul 1999 15:45:06 -0400 To: "He Huang" , Matthew Condell , policy@raleigh.ibm.com, ipsec-policy@mail.timestep.com From: John Schnizlein Subject: Re: Policy Framework and IPsec policy In-Reply-To: <379F3A2B.9AC82B6D@americasm01.nt.com> References: <199907281235.IAA05692@wolfe.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: paul.hoffman@vpnc.org X-Return-Path: jschnizl@cisco.com Sender: rpereira@mail.timestep.com X-MDMailing-List: ipsec-policy@mail.timestep.com X-MDSend-Notifications-To: rpereira@mail.timestep.com Reply-To: ipsec-policy@mail.timestep.com X-UIDL: 598702fa343cbb9a3ccf472cd522d3d9 At 01:13 PM 07/28/1999 -0400, He Huang wrote: > >Certainly, before one policy is saved in policy repository/master >database, it's necessary to do conflict detection and resolution. The >question is that who is responsible for that work, PolicyFramework or >LDAP itself (Assume repository is LDAP directory)... This is not the question. An LDAP (repository) cannot be responsible for detecting and resolving conflicts in the semantics of a policy. Its capability is limited to detecting conflicts (most would call these attribute or syntax violation rather than conflicts) between input attributes/values and the schema. Matthew's point is that there are potential semantic conflicts between different administrative domains even after all internal conflicts are resolved in each domain. The assumption is that some negotiation is necessary between the domains. If I understand his proposal, this negotiation is easier if those rules that might conflict (are relevant to the other domain) are separated and disambiguated with those of the other domain as early in the process as possible. Even though this proposal requires an explicit negotiation cycle, in addition to a distinction in the policy store we have not considered in the policy framework WG, is much more attractive than surprises when the execution of policy is other than what was intended. Have security folks determined if there is sufficient value in keeping policy for different domains in separate subtrees of the DIT? John From ???@??? Fri Jul 30 07:58:05 1999 Received: from mail.timestep.