From owner-ipsec-policy@mail.vpnc.org Wed Dec 5 17:16:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15974 for ; Wed, 5 Dec 2001 17:16:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5L0co26345 for ipsec-policy-bks; Wed, 5 Dec 2001 13:00:38 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5L0a226341 for ; Wed, 5 Dec 2001 13:00:36 -0800 (PST) Received: from megisto.com (63.113.114.131 [63.113.114.131]) by megisto-sql1.megisto.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XGZN402Y; Wed, 5 Dec 2001 15:56:28 -0500 Message-ID: <3C0E8AC6.BE9BA369@megisto.com> Date: Wed, 05 Dec 2001 15:59:50 -0500 From: "Luis A. Sanchez" Organization: Megisto Systems X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ipsec-policy@vpnc.org" Subject: tunnel endpoint discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit folks, those of you interested in security gateway discovery you may want to read and provide feedback to the wg on this draft. http://www.ietf.org/internet-drafts/draft-fluhrer-ted-00.txt From owner-ipsec-policy@mail.vpnc.org Wed Dec 5 18:11:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19449 for ; Wed, 5 Dec 2001 18:11:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5LxVf28967 for ipsec-policy-bks; Wed, 5 Dec 2001 13:59:31 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5LxT228960 for ; Wed, 5 Dec 2001 13:59:29 -0800 (PST) Received: from megisto.com (63.113.114.131 [63.113.114.131]) by megisto-sql1.megisto.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XGZN40MC; Wed, 5 Dec 2001 16:55:22 -0500 Message-ID: <3C0E9889.BCE46D43@megisto.com> Date: Wed, 05 Dec 2001 16:58:34 -0500 From: "Luis A. Sanchez" Organization: Megisto Systems X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ipsec-policy@vpnc.org" Subject: 52nd IETF - IP Security Policy WG (ipsp) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit IP Security Policy WG (ipsp) Monday, December 10 at 1930-2200 =================================== Chair(s): Hilarie Orman Luis Sanchez AGENDA: - Agenda Bashing L. Sanchez/H. Orman 5 mins - IPsec Policy Configuration Model E. Vyncke 15 mins - Tunnel Endpoint Discovery, S. Fluhrer 20 mins - IKE Extensions for Policy P. Srisuresh 15 mins - VPN Group Support for CE-based IPsec VPN C. Wang 20 mins - Multidimensional Security Policy Management and Enhancements for IP Security Policy M. Condell 15 mins - IPsec Policy Configuration MIB W. Hardaker 15 mins - IPSec Policy Information Base A. Doria 15 mins - Wrap-up L. Sanchez/H. Orman 5 mins Reading Material ---------------- http://www.ietf.org/internet-drafts/draft-ietf-ipsp-config-policy-model-04.txt http://www.ietf.org/internet-drafts/draft-fluhrer-ted-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsec-conf-mib-01.txt http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsecpib-03.txt http://www.ietf.org/internet-drafts/draft-srisuresh-ike-policy-extensions-00.txt http://www.ietf.org/internet-drafts/draft-wang-cevpn-group-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ipsp-msme-00.txt From owner-ipsec-policy@mail.vpnc.org Tue Dec 11 12:03:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20608 for ; Tue, 11 Dec 2001 12:03:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBBFskK24747 for ipsec-policy-bks; Tue, 11 Dec 2001 07:54:46 -0800 (PST) Received: from squatch.ir.bbn.com (217-198-131-12.bellhead.com [12.131.198.217]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBBFsi224740 for ; Tue, 11 Dec 2001 07:54:44 -0800 (PST) Received: (qmail 485 invoked by uid 20813); 11 Dec 2001 15:54:45 -0000 Date: 11 Dec 2001 15:54:45 -0000 Message-ID: <20011211155445.484.qmail@squatch.ir.bbn.com> From: Matthew Condell To: ipsec-policy@vpnc.org Subject: Draft Minutes from IPSP WG Mtg at 52st IETF Reply-to: mcondell@bbn.com Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: IPsec Security Policy WG DRAFT Minutes Monday December 10, 2001 IETF 52 E. Vyncke - IPsec Configuration Policy Model draft-ietf-ipsp-config-policy-model-04 PCIM is in last call, so the base for the config model is now stable. Changes have been mostly minor, the larger ones include: 1) Clarifications to compound actions with allow complex policies. A) If in a DoAll and one of the actions fail: - The aggregate action fails - Previously established SAs MAY be kept or MAY be removed B) Which selectors should be used with multiple action: - For last action, use IPHeader + Granularity - For all other actions IP Address to IP Address 2) Provision for non-IKE key negotiation - SANegotiation class is super class for all key negotiation protocols 3) Removed 50 pages of CIM Appendixes and replaced with pointers to appropriate documents on http://www.dmtf.org Document has been through WG last call and will be submitted to the IESG S. Fluhrer - Tunnel Endpoint Discovery draft-fluhrer-ted-00 Discovering gateways is necessary for scalability. Add and IKE TED message. Use routing to send a TED probe to endpoint. Peer gateway intercepts probe and sends a TED response which lists the peer identity and the appropriate selectors for IKE. Protocol is limited in many ways, such as requiring publicly addressable endpoints and is limited to IP address selectors, but addresses a common discovery situation. Concerns from the audience included: - Concern about using IKE - Applicability to nested gateways WG chairs asked for a show of hands: 1) Does IPSP need to address gateway discovery: Many hands for, few objections 2) Should the WG pursue TED as is? a few hands Should the WG pursue something beyond TED, which could be SPP? somewhat more hands There was a call to reintroduce SPP. P. Srisuresh - Policy Extensions to IKE no draft Motivation: - Policy negotiation in IKE is low granularity & needs two ID payloads - Policy parameters cannot change without requireing new SAs & keys Solution 1: - Define a policy payload for IKE with IPsec granularity and a policy ID. - Use IKE for dynamic policy updates - A Policy Agent coordinates updates Solution 2: - Define a policy payload for IKE with IPsec granularity and a policy ID. - A Policy Agent acts as a policy decision point that runs an exchange protocol. - Use IKE for establishing SAs/keys. Solution 2 prefered. C. Wang - IPsec Policy Groups draft-wang-cevpn-group-00 (submitted to ppvpn working group) There's currently a gap between device level IPsec configuration and provisioning large scal VPNs, so we need a mechanism to model, design, provision, and manage large, complex VPNs. It must take into consideration: - security - scalability - manageability - reachability Managing at the device level is not scalable Propose using IPsec groups: - a middle layer building block - can provision tunnels on group and device levels Group attributes are defined and applied to all tunnels by default Need group-level policy definition, negotiation, provisioning and management along with interaction with device level policy management. Question (from the audience) if this naturally leads to nested tunneling. WG chairs: more work is needed to determine if this belongs in IPSP. M. Condell - MSME: Policy Abstraction in IPSP draft-ietf-ipsp-msme-00 Mulidimensional Security Management and Enforcement (MSME) is security policy management for dynamic coalitions. Allows partners to negotiate mission-related policy before communications required. Accomplished by policy abstraction, resolution, exchange, and monitoring. Architecture based around Policy Level Agreement (PLA) which has abstract policy rules and bindings that map the abstract rules to concrete policy. Compilation provides consistency checking and pulls in needed bindings. Resolution, exchange similar to IPSP. Reconcilliation allows a partner to verify that a resolved PLA is consistent with its local policy. MSME/IPSP differences - MSME resolves policy before communications are needed. - MSME resolves all policy at once, instead of policy for one communication. - Supports multiple security contexts - Pre-IPSP step for coalitions Abstraction in MSME - Bindings map name to value - may map to multiple security contexts - Refer to name in policy rule - Coalition-wide names for assets allows other partners to use the name in their policies - Names mapped to values during resolution Why use abstraction in IPSP? - Late Name Binding - Idea from SPP/SPSL, though not well developed there - Names understood by both domains, defined during resolution - Enables domains to change enforcement points without other domains having to change policy - Generalization - May allow IPSP to support more than IPsec - One name maps to multiple security contexts - Resolution determines which contexts supported To support abstraction IPSP protcol needs to be able to define and transport binding names in policy rules and the bindings themselves. Also needs to support processing of bindings W. Hardaker - MIB draft-ietf-ipsp-ipsec-conf-mib-02 Changes: - text cleanup - endpoint maps to a single group instead of multiple Last call will be before March IETF * Please read the draft!! * A. Doria - PIB draft-ietf-ipsp-ipsecpib-(soon to be 04) -04 will be out within a month It's compliant with IPsec standard, configuration policy model. Mostly minor changes. - Only MUSTs are what's in the IPsec standards - Easy adding of other key negotiation protocols - many other small changes. There's a Nokia implementation and possibly one coming from SSH Last call after -04. Working group status: There was a 2 week WG last call on draft-ietf-ipsp-config-policy-model-04 Will submit for Proposed Standards to IESG: draft-ietf-ipsp-requirements-01 draft-ietf-ipsp-config-policy-model-04 draft-ietf-ipsp-ipsecpib-04 and possibly the MIB From owner-ipsec-policy@mail.vpnc.org Tue Dec 11 16:30:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25230 for ; Tue, 11 Dec 2001 16:30:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBBKQpZ12380 for ipsec-policy-bks; Tue, 11 Dec 2001 12:26:51 -0800 (PST) Received: from bhsi.com (ns.bhsi.com [199.180.18.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBKQo212375 for ; Tue, 11 Dec 2001 12:26:50 -0800 (PST) Received: by pcbhi266.bhsi.com id <119076>; Tue, 11 Dec 2001 15:23:40 -0500 Message-Id: <01Dec11.152340est.119076@pcbhi266.bhsi.com> From: "Little, Mike (BHS)" To: ipsec-policy@vpnc.org Subject: VPN Usage Policy Date: Tue, 11 Dec 2001 15:26:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, I've been managing our vpn access now for some time but our company currently has no usage policy in place. I think it's extremely important to get one implemented and I'm looking for a little assistance. Is anyone aware of a template or boilerplate example somewhere that I may reference to ensure I dot all the Is and cross the Ts? I'm looking for one (or two) that would cover both employed and non-employed (vendors, etc.) individuals. I appreciate any suggestions you may have. Mike Little Network Services Baptist Healthcare System Louisville, KY From owner-ipsec-policy@mail.vpnc.org Tue Dec 11 19:09:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28153 for ; Tue, 11 Dec 2001 19:09:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBBMmDa23206 for ipsec-policy-bks; Tue, 11 Dec 2001 14:48:13 -0800 (PST) Received: from redcreek4.redcreek.com (fw.redcreek.com [209.218.199.28] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBMlv223163 for ; Tue, 11 Dec 2001 14:48:12 -0800 (PST) Received: by redcreek4.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Dec 2001 14:47:49 -0800 Received: from redcreek.com (RICK98LAP [209.125.38.151]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YMSJDDAG; Tue, 11 Dec 2001 14:49:52 -0800 Message-ID: <3C168C29.7010405@redcreek.com> Date: Tue, 11 Dec 2001 14:43:53 -0800 From: Ricky Charlet Organization: SonicWall User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ipsec-policy@vpnc.org Subject: comments on ICPM Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Howdy, Apologies for my poor timeing. I should have done this a month ago. Eric, Lee, Jamie... I'd actually like to get together while we are at IETF so I can make sure I undersand some of these issues. I'm open any time there is no IPsec related meeting. 1. (editing trivia) there seems to be no section 4.5. The doc skips from 4.4 to 4.6. 2. Thanks for the SANegotiationAction!!!!! 3. (in section 4.) in the case where we have an egress unprotected packet which has been sucessfully matched to an ipsec rule and there is no current SADB entry, we are instructed to used the "corresponding IKE rule". But I cannot determine how to find an associated IKE rule. Is it associated at the policyGroup level? What I would strongly prefer, is to have an associate IKE action along side of the IPsecAction both contained simultaniously in the IKENegotiationAction. 4. (in section 4.2.1) we are inheriting a PolicyDecisionStrategy property from PCIM. This seems bad to me in the case of IPsec. The policyDecisionStrategy allows administrators to configure if they want to do all matching rules or do only the highest priority matching rule. IPsec specifically demands that we do only the highest priority matching rule. And I'd strongly like to see a priority property re-introduced to PolicyRule and PolicyGroup. Why on earth was it depricated based on input from ICPM? I'm currently very unclear about how to administrativly order policies. I do see that ICPM has added a priority property to the aggrigation classes RuleForIkeNegotiation and RuleForIpsecNegotiation, but these aggrigations can contain N rules and I don't see how to prioritize within them. What am I missing here?... 5. (in section 4.2.2) There are no examples of using the "Do until failure" execution strategy. And I can not imagine how to use it myself. What happens if there is a failure? Is that good in this case? What happens if there is no failure and we reach the end of our actions? Would we start over and do them again? 5. (in sect. 4.3.1) I think it is problematic to store individual context names in alphabetical order... could we do administrativly configured order instead? 7. (also in sect 4.3.1) I do not beleive that we need to make identity selection a function of (local-endpoint, type, and name). It seems to me that identity selection only needs to be a function of (type and name). 8. (sect s 4.8.1 and 4.9.1) Again, I'm unclear on why there are priorities on the aggrigation classes but no priorities in the SARule or IPsedPolicyGroup class. Some explanitory text may help here. 9. (sect 4.9.3 and 4.10.2) should be a cardinality of 1..n ? 10. (sect 5.2) why must an IPHeaderFilter match traffic symetrically? 11. (sect 5.3 and 5.5) what is the difference between a CredentialFilterEntry and a PeerIdPayloadFilterEntry? Would we use a CredentialFilterEntry when we specificall want to farm out the "good/bad" decision to a credentialManagement service? 12. (sect. 5.3.1) MatchFieldName seems underspecified. There is no 'stuff' under the 'value' deffinition. 13. (sect. 5.3.2) MatchFieldValue seems underspecified. If we are matching against DNs or GNs, we need a way to match the subparts of these subjectNames and subjectAltNames and to wildcard match parts of them also. 14. (sect 5.3.3) what about PSK? (or dare I ask... xauth) 15. (sect 5.4) who care?. Why are we doing Security Options filters? Thanks for making it a MAY. 16. (sect 5.5) We deffinatly need to strike the phrase "when acting as a responder" Both initiators and responders need to authenticate their respective peers and both need a way to associate identities with peers. Also the next sentence (beginning "Moreover, this filter can be ...) seems unnecessary to me. That behaviour is specified elsewhere... I move to stike it. 17. (sect 5.5.2) we need a way to match the subparts of a subjectName and subjectAltName (DN and GN) and a way to wildcard match the subparts. 18. (sect 6.) I'd like vendors to have the freedom to add new actions as siblings of SAAction. Specifically, I have in mind stuff like Firewall, QOS, NAT, drop, bypass. Could we introduce a note in the text to this effect? 19. (sect 6.1.1) the description of DoActionLogging seems vague to me. I'm not sure what is meant by the phrase "when the action is performed". Is this when a packet traverses this action, or is it when the action is instantiated? 20. (sect 6.2) The description of SAStaticAction mentions that it is a base class for IKE actions that do not require any negotiation. I don't think there is any such thing. 21. (sect 6.6) In the notes area of PreconfiguredSAAction there is an abbreviation "resp." used which I am guessing was meant to refer to "Responder". But the use of the IKE term "Responder" would make no sence in a description area of a static IPsec action. Can you clear this up for me. 22. (sect 6.11.1) UsePFS seems to refer to PFS with respect to keys. Where is a property to control PFS with respect to IDs? 23. (sect 6.14.2) could we use simple assending interger values to describe ExchangeMode instead of powers of 2? 24. (sect. 6.14.3) UseIKEIdentyType. The phrase "This information is to be used in conjunction with the IKE identities..." is too vague for me. I need to know how to find exactly which IKE identity is to be used in association with this IKEAction. 25. (sect 6.15) peer gateway. I'm fuzzy about how this class interacts with (or does not interact with) the CredentailFilterEntry and PeerIdaPayloadFilterEntry classes. I think we have an IPsec and IKE rule in hand by the time we get down to IPsecTunnelAction. Now the IKErule and the IPsecAction:PeerGateway both seem to offer ways to identify the peer. What are the distinctions between when these classes are applicable? 26. (sect 6.15.3) PeerIdentity seems underspecified. I think we would need an ID payload type and in the case of DN or GN, ways to match and wildcard match the subfields of the subjectName or subjectAltName. 27. (sect. 6.16.3) is a sequence nukmber on peer gateways still needed now that the ExecutionStrategy property has been introduce to the SARule? 28. (sect 6.18) Again, something I'm not understanding here. Do we need to keep a table of "systems" for all of our peers? And why do we care about associating our IKE peers with the information availabl in the "System" class? 29. (sect 7.2.4) the VALUE deffinition of PRFAlgorithm says "currently none defined". While this is true, I'd rather say "see IKE" (or see DOI, I didn't look up which was approprate for this). 30. (sect 7.2.5) setting groupID to the value "notNeeded" is poor configuration design. It puts two knobs in the hands of an adminstrator (both of which must be set correctly) to do only one task. Instead I'd rather see us say that if the ExchangeMode is agressive, then the GroupId property will not be used reguardless of its setting. 31. (sect 7.2.6) I don't like having the "special value 0" on the AuthenticationMethod poperty. Since there can be N saProposals on an IKENegotiationAction I think we can list the IKEproposals with the IKEauthentication methods we want to use explicitly rather than having a setting for "just make a proposal for each applicable credential I have". And even if we did keep the "special value 0" thing, it seems like we would need to distinguis beteen authentication methods if we had an RSA cert credential. We would not completely know if we should use rsaEncrypt or revisedRsaEncrypt autenhtication methods. 32. (sect 7.8) yet another please explain this to me... Why would we want to associate SAProposals with the poperties available in the System class? 33. (note: I'm skipping review of the IKEServices stuff). 34. What happens to my configuration if one of my IPaddresses is changed (ie by dhcp or ppp or a human...) 35. Could we parallize the names SAConditionInRule and PolicyActionInSaRule? -- Ricky Charlet From owner-ipsec-policy@mail.vpnc.org Fri Dec 14 01:31:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12064 for ; Fri, 14 Dec 2001 01:31:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBE5L5v12345 for ipsec-policy-bks; Thu, 13 Dec 2001 21:21:05 -0800 (PST) Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE5L1212339 for ; Thu, 13 Dec 2001 21:21:02 -0800 (PST) Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA36590 for ; Thu, 13 Dec 2001 23:18:05 -0600 Received: from lrafalow (sig-9-15-11-137.mts.ibm.com [9.15.11.137]) by southrelay01.raleigh.ibm.com (8.11.1m3/NCO v5.01) with SMTP id fBE5JMq132854 for ; Fri, 14 Dec 2001 00:19:37 -0500 Message-ID: <000c01c1845e$f9921fe0$e2cb830c@lrafalow> Reply-To: "Lee Rafalow" From: "Lee Rafalow" To: References: <20011211155445.484.qmail@squatch.ir.bbn.com> Subject: TED poll (Re: Draft Minutes from IPSP WG Mtg at 52st IETF) Date: Thu, 13 Dec 2001 22:19:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > WG chairs asked for a show of hands: > 1) Does IPSP need to address gateway discovery: Many hands for, > few objections > 2) Should the WG pursue TED as is? a few hands > Should the WG pursue something beyond TED, which could be SPP? > somewhat more hands I was, I think, the only "few objections" to pursuing gateway discovery. The reason I objected is that if we're going to have a protocol that publishes policy to anyone who asks and that only works for a subset of the network, we can do much, much better with an existing protocol: LDAP. Define a schema (based on the ICPM + topology). The installation can then use the existing authorization mechanisms to restrict accesses as appropriate and anyone with authorization can then find the appropriate gateway(s) and the needed policy options to be able to initiate an SA. Two cents from a minority of one. Cheers. Lee M. Rafalow Voice: 1-919-254-4455, Fax: 1-919-254-6243 IBM Internet Technology Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709 USA Alternate email: rafalow@us.ibm.com Personal email: lrafalow@mindspring.com From owner-ipsec-policy@mail.vpnc.org Fri Dec 14 14:24:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05661 for ; Fri, 14 Dec 2001 14:24:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBEHuEO17888 for ipsec-policy-bks; Fri, 14 Dec 2001 09:56:14 -0800 (PST) Received: from redcreek4.redcreek.com (fw.redcreek.com [209.218.199.28] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBEHuD217883 for ; Fri, 14 Dec 2001 09:56:13 -0800 (PST) Received: by redcreek4.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Dec 2001 09:54:45 -0800 Received: from redcreek.com (RICK98LAP [209.125.38.51]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YMSJDGWJ; Fri, 14 Dec 2001 09:56:51 -0800 Message-ID: <3C1A3BFD.2090900@redcreek.com> Date: Fri, 14 Dec 2001 09:50:53 -0800 From: Ricky Charlet Reply-To: Ricky Charlet Organization: SonicWall User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 CC: ipsec-policy@vpnc.org Subject: Re: comments on ICPM References: <3C168C29.7010405@redcreek.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit (note my email address has changed to rcharlet@sonicwall.com) Howdy, Of the 30 or so listed items in my post, I think there are only 2 'big rock' issues. And I'd like to add one new issue... 1. I propose a substantial modification of attaching an IKE action to an IPsec action directly for egress unprotected packet in stead of using a secondary IKE rule lookup after the IPsec rule lookup. This has implications for moving contexts also. 2. credentialFilters and IDPayloadFilters are deeply underspecified in my opinion. I intend to produce some suggested additional text as a strawman so people can see what I mean. 3. (new) I'd like to see the IPsecBypass, IPsecReject, and IkeReject actions moved in the model to be peers with saStaticAction & saNegotiationAction under SAAction. Where they are now, they inherit a 'lifetime' property which makes no sence. Secondarily, I'd hope to seem them consolidated to bypass and reject instead of ipSecBypass, IPSecReject and IkeReject. Most of the other things are requests for clarifications. They could be solved either with additional descripive text or me being less dence. Since I've given up hope for becoming less dence, I would like to see additional descriptive text added in those areas. Ricky Charlet rcharlet@sonicwall.com Ricky Charlet wrote: > > Howdy, > Apologies for my poor timeing. I should have done this a month ago. > > Eric, Lee, Jamie... I'd actually like to get together while we are at > IETF so I can make sure I undersand some of these issues. I'm open > any time there is no IPsec related meeting. > > > 1. (editing trivia) there seems to be no section 4.5. The doc skips > from 4.4 to 4.6. > > 2. Thanks for the SANegotiationAction!!!!! > > 3. (in section 4.) in the case where we have an egress unprotected > packet which has been sucessfully matched to an ipsec rule and there > is no current SADB entry, we are instructed to used the "corresponding > IKE rule". But I cannot determine how to find an associated IKE rule. > Is it associated at the policyGroup level? What I would strongly > prefer, is to have an associate IKE action along side of the > IPsecAction both contained simultaniously in the IKENegotiationAction. > > 4. (in section 4.2.1) we are inheriting a PolicyDecisionStrategy > property from PCIM. This seems bad to me in the case of IPsec. The > policyDecisionStrategy allows administrators to configure if they want > to do all matching rules or do only the highest priority matching > rule. IPsec specifically demands that we do only the highest priority > matching rule. And I'd strongly like to see a priority property > re-introduced to PolicyRule and PolicyGroup. Why on earth was it > depricated based on input from ICPM? I'm currently very unclear about > how to administrativly order policies. I do see that ICPM has added a > priority property to the aggrigation classes RuleForIkeNegotiation and > RuleForIpsecNegotiation, but these aggrigations can contain N rules > and I don't see how to prioritize within them. What am I missing here?... > > > 5. (in section 4.2.2) There are no examples of using the "Do until > failure" execution strategy. And I can not imagine how to use it > myself. What happens if there is a failure? Is that good in this case? > What happens if there is no failure and we reach the end of our > actions? Would we start over and do them again? > > 5. (in sect. 4.3.1) I think it is problematic to store individual > context names in alphabetical order... could we do administrativly > configured order instead? > > 7. (also in sect 4.3.1) I do not beleive that we need to make identity > selection a function of (local-endpoint, type, and name). It seems to > me that identity selection only needs to be a function of (type and > name). > > 8. (sect s 4.8.1 and 4.9.1) Again, I'm unclear on why there are > priorities on the aggrigation classes but no priorities in the SARule > or IPsedPolicyGroup class. Some explanitory text may help here. > > > 9. (sect 4.9.3 and 4.10.2) should be a cardinality of 1..n ? > > 10. (sect 5.2) why must an IPHeaderFilter match traffic symetrically? > > 11. (sect 5.3 and 5.5) what is the difference between a > CredentialFilterEntry and a PeerIdPayloadFilterEntry? Would we use a > CredentialFilterEntry when we specificall want to farm out the > "good/bad" decision to a credentialManagement service? > > 12. (sect. 5.3.1) MatchFieldName seems underspecified. There is no > 'stuff' under the 'value' deffinition. > > 13. (sect. 5.3.2) MatchFieldValue seems underspecified. If we are > matching against DNs or GNs, we need a way to match the subparts of > these subjectNames and subjectAltNames and to wildcard match parts of > them also. > > 14. (sect 5.3.3) what about PSK? (or dare I ask... xauth) > > 15. (sect 5.4) who care?. Why are we doing Security Options filters? > Thanks for making it a MAY. > > 16. (sect 5.5) We deffinatly need to strike the phrase "when acting as > a responder" Both initiators and responders need to authenticate their > respective peers and both need a way to associate identities with > peers. Also the next sentence (beginning "Moreover, this filter can be > ...) seems unnecessary to me. That behaviour is specified elsewhere... > I move to stike it. > > 17. (sect 5.5.2) we need a way to match the subparts of a subjectName > and subjectAltName (DN and GN) and a way to wildcard match the subparts. > > 18. (sect 6.) I'd like vendors to have the freedom to add new actions > as siblings of SAAction. Specifically, I have in mind stuff like > Firewall, QOS, NAT, drop, bypass. Could we introduce a note in the > text to this effect? > > 19. (sect 6.1.1) the description of DoActionLogging seems vague to me. > I'm not sure what is meant by the phrase "when the action is > performed". Is this when a packet traverses this action, or is it when > the action is instantiated? > > 20. (sect 6.2) The description of SAStaticAction mentions that it is a > base class for IKE actions that do not require any negotiation. I > don't think there is any such thing. > > 21. (sect 6.6) In the notes area of PreconfiguredSAAction there is an > abbreviation "resp." used which I am guessing was meant to refer to > "Responder". But the use of the IKE term "Responder" would make no > sence in a description area of a static IPsec action. Can you clear > this up for me. > > 22. (sect 6.11.1) UsePFS seems to refer to PFS with respect to keys. > Where is a property to control PFS with respect to IDs? > > 23. (sect 6.14.2) could we use simple assending interger values to > describe ExchangeMode instead of powers of 2? > > 24. (sect. 6.14.3) UseIKEIdentyType. The phrase "This information is > to be used in conjunction with the IKE identities..." is too vague for > me. I need to know how to find exactly which IKE identity is to be > used in association with this IKEAction. > > 25. (sect 6.15) peer gateway. I'm fuzzy about how this class interacts > with (or does not interact with) the CredentailFilterEntry and > PeerIdaPayloadFilterEntry classes. I think we have an IPsec and IKE > rule in hand by the time we get down to IPsecTunnelAction. Now the > IKErule and the IPsecAction:PeerGateway both seem to offer ways to > identify the peer. What are the distinctions between when these > classes are applicable? > > 26. (sect 6.15.3) PeerIdentity seems underspecified. I think we would > need an ID payload type and in the case of DN or GN, ways to match and > wildcard match the subfields of the subjectName or subjectAltName. > > 27. (sect. 6.16.3) is a sequence nukmber on peer gateways still needed > now that the ExecutionStrategy property has been introduce to the SARule? > > 28. (sect 6.18) Again, something I'm not understanding here. Do we > need to keep a table of "systems" for all of our peers? And why do we > care about associating our IKE peers with the information availabl in > the "System" class? > > 29. (sect 7.2.4) the VALUE deffinition of PRFAlgorithm says "currently > none defined". While this is true, I'd rather say "see IKE" (or see > DOI, I didn't look up which was approprate for this). > > 30. (sect 7.2.5) setting groupID to the value "notNeeded" is poor > configuration design. It puts two knobs in the hands of an > adminstrator (both of which must be set correctly) to do only one > task. Instead I'd rather see us say that if the ExchangeMode is > agressive, then the GroupId property will not be used reguardless of > its setting. > > 31. (sect 7.2.6) I don't like having the "special value 0" on the > AuthenticationMethod poperty. Since there can be N saProposals on an > IKENegotiationAction I think we can list the IKEproposals with the > IKEauthentication methods we want to use explicitly rather than having > a setting for "just make a proposal for each applicable credential I > have". And even if we did keep the "special value 0" thing, it seems > like we would need to distinguis beteen authentication methods if we > had an RSA cert credential. We would not completely know if we should > use rsaEncrypt or revisedRsaEncrypt autenhtication methods. > > 32. (sect 7.8) yet another please explain this to me... Why would we > want to associate SAProposals with the poperties available in the > System class? > > 33. (note: I'm skipping review of the IKEServices stuff). > > 34. What happens to my configuration if one of my IPaddresses is > changed (ie by dhcp or ppp or a human...) > > 35. Could we parallize the names SAConditionInRule and > PolicyActionInSaRule? > > > -- > Ricky Charlet From owner-ipsec-policy@mail.vpnc.org Mon Dec 17 23:32:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26811 for ; Mon, 17 Dec 2001 23:32:16 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBI3Pev14469 for ipsec-policy-bks; Mon, 17 Dec 2001 19:25:40 -0800 (PST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBI3Pc214465 for ; Mon, 17 Dec 2001 19:25:39 -0800 (PST) Received: from marajade.sandelman.ottawa.on.ca ([2001:410:402:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id fBI3PYD04735 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 17 Dec 2001 22:25:37 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id fBI3PRI20468 for ; Mon, 17 Dec 2001 22:25:29 -0500 (EST) Message-Id: <200112180325.fBI3PRI20468@marajade.sandelman.ottawa.on.ca> To: ipsec-policy@vpnc.org Subject: Re: TED poll (Re: Draft Minutes from IPSP WG Mtg at 52st IETF) In-reply-to: Your message of "Thu, 13 Dec 2001 22:19:32 MST." <000c01c1845e$f9921fe0$e2cb830c@lrafalow> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 17 Dec 2001 22:25:26 -0500 From: Michael Richardson Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Lee" == Lee Rafalow writes: Lee> I was, I think, the only "few objections" to pursuing gateway Lee> discovery. Lee> The reason I objected is that if we're going to have a protocol Lee> that publishes policy to anyone who asks and that only works for a Lee> subset of the Keeping policy information confidential is a goal (not always achieveable), although I see that it has slipped out of the requirements document. I'll add it back. Lee> network, we can do much, much better with an existing protocol: LDAP. Lee> Define a schema (based on the ICPM + topology). The installation Lee> can then And what key would you use to look up the policy in this "global LDAP database"? if you wish, you may think of tunnel endpoint discovery as potentially discoverying an address of an LDAP server along with index into its database. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPB63JIqHRg3pndX9AQFsHAP/TBNgvYunZXdjilK8Xm8Z9EaJVVr2iHxm hAB/fXDf9xW+mj8SDYjsRs4hVw7/dDqY4V/5yzJqKuSnLhvK15Z3fjKpcze+BMY2 IZam4L83O+IhX8YakBtZ3whp8kz68JiLLUzQbnoRVjJzFFsIprCuwBg5UcvPd724 nT23n/yLhuQ= =3hps -----END PGP SIGNATURE----- From owner-ipsec-policy@mail.vpnc.org Wed Dec 19 09:34:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28480 for ; Wed, 19 Dec 2001 09:34:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBJDkB818269 for ipsec-policy-bks; Wed, 19 Dec 2001 05:46:11 -0800 (PST) Received: from outside (e23.nc.us.ibm.com [32.97.136.229]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJDk9218259 for ; Wed, 19 Dec 2001 05:46:09 -0800 (PST) Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208]) by outside (8.9.3/8.9.3) with ESMTP id HAA16926; Wed, 19 Dec 2001 07:42:35 -0600 Received: from lrafalow (dyn9-27-28-55.raleigh.ibm.com [9.27.28.55]) by southrelay01.raleigh.ibm.com (8.11.1m3/NCO v5.01) with SMTP id fBJDj7S257084; Wed, 19 Dec 2001 08:45:26 -0500 Message-ID: <004a01c18893$49f15f90$371c1b09@lrafalow> Reply-To: "Lee Rafalow" From: "Lee Rafalow" To: , "Michael Richardson" References: <200112180325.fBI3PRI20468@marajade.sandelman.ottawa.on.ca> Subject: Re: TED poll (Re: Draft Minutes from IPSP WG Mtg at 52st IETF) Date: Wed, 19 Dec 2001 08:44:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Off the top of my head, I'd say that the schema and dit structure would be optimized for a fully-qualified hostname search and that gateway topology would be represented by DN references. The available policies would also be DN references and can be protected by access controls. IMHO, this would be significantly better than TED in that it is not topology limited and has access controls, but I've given almost no thought to scaling and maintenance issues (although they seem tractable on first blush). ----- Original Message ----- From: "Michael Richardson" To: Sent: Monday, December 17, 2001 10:25 PM Subject: Re: TED poll (Re: Draft Minutes from IPSP WG Mtg at 52st IETF) > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Lee" == Lee Rafalow writes: > Lee> I was, I think, the only "few objections" to pursuing gateway > Lee> discovery. > Lee> The reason I objected is that if we're going to have a protocol > Lee> that publishes policy to anyone who asks and that only works for a > Lee> subset of the > > Keeping policy information confidential is a goal (not always achieveable), > although I see that it has slipped out of the requirements document. I'll add > it back. > > Lee> network, we can do much, much better with an existing protocol: LDAP. > Lee> Define a schema (based on the ICPM + topology). The installation > Lee> can then > > And what key would you use to look up the policy in this "global > LDAP database"? > > if you wish, you may think of tunnel endpoint discovery as potentially > discoverying an address of an LDAP server along with index into its database. > > ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ > > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3ia > Charset: latin1 > Comment: Finger me for keys > > iQCVAwUBPB63JIqHRg3pndX9AQFsHAP/TBNgvYunZXdjilK8Xm8Z9EaJVVr2iHxm > hAB/fXDf9xW+mj8SDYjsRs4hVw7/dDqY4V/5yzJqKuSnLhvK15Z3fjKpcze+BMY2 > IZam4L83O+IhX8YakBtZ3whp8kz68JiLLUzQbnoRVjJzFFsIprCuwBg5UcvPd724 > nT23n/yLhuQ= > =3hps > -----END PGP SIGNATURE----- > From owner-ipsec-policy@mail.vpnc.org Wed Dec 19 16:37:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07957 for ; Wed, 19 Dec 2001 16:37:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBJKh7d16649 for ipsec-policy-bks; Wed, 19 Dec 2001 12:43:07 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJKh6216641 for ; Wed, 19 Dec 2001 12:43:06 -0800 (PST) Received: from megisto.com (ppp-196-42-28-41.coqui.net [196.42.28.41]) by megisto-sql1.megisto.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Y8B5TG1M; Wed, 19 Dec 2001 15:38:26 -0500 Message-ID: <3C20FBAF.B9016176@megisto.com> Date: Wed, 19 Dec 2001 15:42:23 -0500 From: "Luis A. Sanchez" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lee Rafalow CC: ipsec-policy@vpnc.org, Michael Richardson Subject: Re: TED poll (Re: Draft Minutes from IPSP WG Mtg at 52st IETF) References: <200112180325.fBI3PRI20468@marajade.sandelman.ottawa.on.ca> <004a01c18893$49f15f90$371c1b09@lrafalow> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lee, It would be extremely difficult to configure, maintain, secure, and just to make work in general an LDAP or series of LDAP directories with all the IP addresses of all the IPsec Security Gateways that could be protecting some set of hosts at any given time. First of all, one needs to answer a series of political questions beyond the scope of our work here. For instance, which LDAP directories, do we trust them, who do we trust, who maintain them... authoritative?, etc... the list goes on and on. I would say that we should consider an independent and dynamic protocol that can propagate IPsec SG information (IP addresses, policies, etc.) in a secure fashion (authenticated, integrity checked, encrypted when needed, etc.) among hosts that need such information to establish an end2end IPsec SA. Luis Lee Rafalow wrote: > Off the top of my head, I'd say that the schema and dit structure would be > optimized for a fully-qualified hostname search and that gateway topology > would be represented by DN references. The available policies would also be > DN references and can be protected by access controls. IMHO, this would be > significantly better than TED in that it is not topology limited and has > access controls, but I've given almost no thought to scaling and maintenance > issues (although they seem tractable on first blush). > > ----- Original Message ----- > From: "Michael Richardson" > To: > Sent: Monday, December 17, 2001 10:25 PM > Subject: Re: TED poll (Re: Draft Minutes from IPSP WG Mtg at 52st IETF) > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > > >>>>> "Lee" == Lee Rafalow writes: > > Lee> I was, I think, the only "few objections" to pursuing gateway > > Lee> discovery. > > Lee> The reason I objected is that if we're going to have a protocol > > Lee> that publishes policy to anyone who asks and that only works for > a > > Lee> subset of the > > > > Keeping policy information confidential is a goal (not always > achieveable), > > although I see that it has slipped out of the requirements document. I'll > add > > it back. > > > > Lee> network, we can do much, much better with an existing protocol: > LDAP. > > Lee> Define a schema (based on the ICPM + topology). The > installation > > Lee> can then > > > > And what key would you use to look up the policy in this "global > > LDAP database"? > > > > if you wish, you may think of tunnel endpoint discovery as potentially > > discoverying an address of an LDAP server along with index into its > database. > > > > ] ON HUMILITY: to err is human. To moo, bovine. | > firewalls [ > > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > > ] panic("Just another NetBSD/notebook using, kernel hacking, security > guy"); [ > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: 2.6.3ia > > Charset: latin1 > > Comment: Finger me for keys > > > > iQCVAwUBPB63JIqHRg3pndX9AQFsHAP/TBNgvYunZXdjilK8Xm8Z9EaJVVr2iHxm > > hAB/fXDf9xW+mj8SDYjsRs4hVw7/dDqY4V/5yzJqKuSnLhvK15Z3fjKpcze+BMY2 > > IZam4L83O+IhX8YakBtZ3whp8kz68JiLLUzQbnoRVjJzFFsIprCuwBg5UcvPd724 > > nT23n/yLhuQ= > > =3hps > > -----END PGP SIGNATURE----- > > From owner-ipsec-policy@mail.vpnc.org Wed Dec 19 16:46:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08192 for ; Wed, 19 Dec 2001 16:46:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBJKu6B17911 for ipsec-policy-bks; Wed, 19 Dec 2001 12:56:06 -0800 (PST) Received: from os.directory.dfn.de (os.directory.dfn.de [134.2.217.70]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJKu4217903 for ; Wed, 19 Dec 2001 12:56:04 -0800 (PST) Received: from medea.directory.dfn.de (medea.directory.dfn.de [134.2.217.44]) by os.directory.dfn.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id fBJKu5M00619 for ; Wed, 19 Dec 2001 21:56:05 +0100 Subject: LDAP schema for the 'IPsec Configuration Policy Model' From: Christian Vollrath To: IETF IP Security PolicyWorking Group Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-y0ozlAe6u6GzwFZrEdU+" X-Mailer: Evolution/1.0 (Preview Release) Date: 19 Dec 2001 21:56:23 +0100 Message-Id: <1008795383.26695.2.camel@medea.directory.dfn.de> Mime-Version: 1.0 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-y0ozlAe6u6GzwFZrEdU+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi I am a student at the University of Tuebingen in Germany and currently working on my thesis about the management of ipsec policy informations in an LDAP based directory. Therefore I studied the papers from the DMTF and IETF about the CIM models and their LDAP schemas. Since there is no schema for the 'IPsec Configuration Policy Model' yet I started to define some respective LDAP object classes.=20 If there are others working on the same subject, I would like to get in touch with them to start a discussion and to avoid unneccessary doubling of effort. Greetings Christian Vollrath _____________________________________________________________________ o =20 Christian Vollrath / \ Mail: christian.vollrath@daasi.de =20 DAASI International GmbH o o Web: http://www.daasi.de =20 Wilhelmstrasse 106 / \ Phone: +49 7071 2970335 =20 D-72074 Tuebingen o o Fax: +49 7071 295912 =20 _____________________________________________________________________ --=-y0ozlAe6u6GzwFZrEdU+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8IP73QceOi9p9ssURAnmsAJ9WWHuFNuj9NJpH0tvMT1/r6sl+cwCfZrJe bxaWbSysPfGwWC0uWUAAd/8= =O+5E -----END PGP SIGNATURE----- --=-y0ozlAe6u6GzwFZrEdU+-- From owner-ipsec-policy@mail.vpnc.org Wed Dec 19 17:22:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09086 for ; Wed, 19 Dec 2001 17:22:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBJLWpL20349 for ipsec-policy-bks; Wed, 19 Dec 2001 13:32:51 -0800 (PST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJLWm220345 for ; Wed, 19 Dec 2001 13:32:48 -0800 (PST) Received: from marajade.sandelman.ottawa.on.ca ([2001:410:402:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id fBJLWgD08393 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 19 Dec 2001 16:32:45 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id fBJLWYn17772; Wed, 19 Dec 2001 16:32:38 -0500 (EST) Message-Id: <200112192132.fBJLWYn17772@marajade.sandelman.ottawa.on.ca> To: "Lee Rafalow" cc: ipsec-policy@vpnc.org Subject: Re: TED poll (Re: Draft Minutes from IPSP WG Mtg at 52st IETF) In-reply-to: Your message of "Wed, 19 Dec 2001 08:44:13 EST." <004a01c18893$49f15f90$371c1b09@lrafalow> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 19 Dec 2001 16:32:32 -0500 From: Michael Richardson Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Lee" == Lee Rafalow writes: Lee> Off the top of my head, I'd say that the schema and dit structure Lee> would be optimized for a fully-qualified hostname search and that Lee> gateway topology would be represented by DN references. The And, who would ask this question? Further, how does a forward search (FQDN->IP) tell you anything about about the world? People can put any A record they want into DNS or into LDAP. Lee> available policies would also be DN references and can be protected Lee> by access controls. IMHO, this would be significantly better than Lee> TED in that it is not topology limited and has access controls, but Lee> I've given almost no thought to scaling and maintenance issues Lee> (although they seem tractable on first blush). Oh, so you mean that LDAP directory replication is finally stable? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPCEHboqHRg3pndX9AQGifgP+Levfpaz0JQ2oTvj9JvYBXJf451o4lVoK QbaXQH/aMj4SaMXjrcDb57IyMiuRokzqfH6tBlYmYtuX2Vb7bfUhJM3NBkOAbZdS qdZYzgnq9DPlfyPI+1bDZWXNqEmVWkLlE5MEj4z1VyYcNaTUg1Nxe6WxACvTXB4/ P5ZO59kCQfM= =UBrs -----END PGP SIGNATURE----- From owner-ipsec-policy@mail.vpnc.org Wed Dec 19 17:27:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09288 for ; Wed, 19 Dec 2001 17:27:26 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBJLZwv20411 for ipsec-policy-bks; Wed, 19 Dec 2001 13:35:58 -0800 (PST) Received: from spsystems.net (spsystems.net [209.47.149.227]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJLZu220406 for ; Wed, 19 Dec 2001 13:35:56 -0800 (PST) Received: (from henry@localhost) by spsystems.net (8.9.3/8.9.3) id QAA19204; Wed, 19 Dec 2001 16:35:50 -0500 (EST) Date: Wed, 19 Dec 2001 16:35:49 -0500 (EST) From: Henry Spencer To: "Luis A. Sanchez" cc: ipsec-policy@vpnc.org Subject: Re: TED poll (Re: Draft Minutes from IPSP WG Mtg at 52st IETF) In-Reply-To: <3C20FBAF.B9016176@megisto.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 19 Dec 2001, Luis A. Sanchez wrote: > It would be extremely difficult to configure, maintain, secure, and just to > make work in general an LDAP or series of LDAP directories with all the IP > addresses of all the IPsec Security Gateways that could be protecting some set > of hosts at any given time... Of course, if you want a database that covers all those gateways, there *already is one*. It's called DNS. Why re-invent the wheel, especially when the re-invented one is often square? Henry Spencer henry@spsystems.net From owner-ipsec-policy@mail.vpnc.org Thu Dec 20 04:23:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04436 for ; Thu, 20 Dec 2001 04:23:36 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBK8aQ226807 for ipsec-policy-bks; Thu, 20 Dec 2001 00:36:26 -0800 (PST) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBK8aP226798 for ; Thu, 20 Dec 2001 00:36:25 -0800 (PST) Received: from EVYNCKE-W2K.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA16389; Thu, 20 Dec 2001 09:35:27 +0100 (MET) Message-Id: <4.3.2.7.2.20011220092550.044c68c0@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Dec 2001 09:26:20 +0100 To: Henry Spencer From: Eric Vyncke Subject: Re: TED poll (Re: Draft Minutes from IPSP WG Mtg at 52st IETF) Cc: "Luis A. Sanchez" , ipsec-policy@vpnc.org In-Reply-To: References: <3C20FBAF.B9016176@megisto.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 16:35 19/12/2001 -0500, Henry Spencer wrote: >On Wed, 19 Dec 2001, Luis A. Sanchez wrote: > > It would be extremely difficult to configure, maintain, secure, > and just to > > make work in general an LDAP or series of LDAP directories with all the IP > > addresses of all the IPsec Security Gateways that could be protecting > some set > > of hosts at any given time... > >Of course, if you want a database that covers all those gateways, there >*already is one*. It's called DNS. Why re-invent the wheel, especially >when the re-invented one is often square? So, we are back to square one: using the KX of DNSsec ;-) Personally, I do not disagree -eric > Henry Spencer > henry@spsystems.net From owner-ipsec-policy@mail.vpnc.org Thu Dec 20 04:28:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04457 for ; Thu, 20 Dec 2001 04:28:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBK8a2B26732 for ipsec-policy-bks; Thu, 20 Dec 2001 00:36:02 -0800 (PST) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBK8a0226724 for ; Thu, 20 Dec 2001 00:36:00 -0800 (PST) Received: from EVYNCKE-W2K.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA16470; Thu, 20 Dec 2001 09:35:31 +0100 (MET) Message-Id: <4.3.2.7.2.20011220092630.044c15c8@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Dec 2001 09:33:35 +0100 To: "Lee Rafalow" From: Eric Vyncke Subject: Re: TED poll (Re: Draft Minutes from IPSP WG Mtg at 52st IETF) Cc: In-Reply-To: <000c01c1845e$f9921fe0$e2cb830c@lrafalow> References: <20011211155445.484.qmail@squatch.ir.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 22:19 13/12/2001 -0700, Lee Rafalow wrote: >) >I was, I think, the only "few objections" to pursuing gateway discovery. >The reason I objected is that if we're going to have a protocol that >publishes policy to anyone who asks and that only works for a subset of the >network, we can do much, much better with an existing protocol: LDAP. >Define a schema (based on the ICPM + topology). The installation can then >use the existing authorization mechanisms to restrict accesses as >appropriate and anyone with authorization can then find the appropriate >gateway(s) and the needed policy options to be able to initiate an SA. > >Two cents from a minority of one. Cheers. It is always nice to be part of the minority ;-) Based on my experience of deploying IPSec, there is a big issue with IPSec deployment compared to QoS deployment: if one single IPSec device has a policy which is not compatible with the rest of the devices, then your VPN (or IPSec protected network) will completely break (including the lost of control plane). This is thus completely different than the QoS story. If one QoS device has a policy which is not compatible with the rest of the devices, then your QoS enabled network will still run (including the control plane) but perhaps with a sub-optimal configuration. Where I'm getting to is the fact that any kind of centralized management for IPSec is somehow broken because there is no guarantee that all IPSec devices can receive their new policy at a convenient time. => some devices will have a policy incompatible with the rest of the devices... Even further, LDAP uses a poll & pull model which will delay the policy synchronization. So, we should at least try to get a push protocol (PDP to PEP flow) like COPS-PR (perhaps using a LDAP based PDP). Hence, the genuine interest of TED (which could of course be improved). Regards -eric From owner-ipsec-policy@mail.vpnc.org Fri Dec 21 11:07:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25646 for ; Fri, 21 Dec 2001 11:07:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLF1Eb01853 for ipsec-policy-bks; Fri, 21 Dec 2001 07:01:14 -0800 (PST) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBLF1C201849 for ; Fri, 21 Dec 2001 07:01:13 -0800 (PST) Received: from EVYNCKE-W2K.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA15128; Fri, 21 Dec 2001 16:00:54 +0100 (MET) Message-Id: <4.3.2.7.2.20011221144555.061c0a88@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Dec 2001 16:00:25 +0100 To: Ricky Charlet From: Eric Vyncke Subject: Re: comments on ICPM Cc: ipsec-policy@vpnc.org In-Reply-To: <3C168C29.7010405@redcreek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ricky, Please find below a couple of answers (written by Lee -- our PCIM guru -- and myself) Regards and Merry Xmas -eric At 14:43 11/12/2001 -0800, Ricky Charlet wrote: > Howdy, > > Apologies for my poor timeing. I should have done this a month ago. > >Eric, Lee, Jamie... I'd actually like to get together while we are at IETF >so I can make sure I undersand some of these issues. I'm open any time >there is no IPsec related meeting. > > >1. (editing trivia) there seems to be no section 4.5. The doc skips from >4.4 to 4.6. ok >2. Thanks for the SANegotiationAction!!!!! You are welcome >3. (in section 4.) in the case where we have an egress unprotected packet >which has been sucessfully matched to an ipsec rule and there is no >current SADB entry, we are instructed to used the "corresponding IKE >rule". But I cannot determine how to find an associated IKE rule. Is it >associated at the policyGroup level? What I would strongly prefer, is to >have an associate IKE action along side of the IPsecAction both contained >simultaniously in the IKENegotiationAction. [Eric] Actually, you use the plain text egress packet first against the IPSecRules (= SPD) to get one IKE peer. Then if you have no SA, you can look into the IKERules for a IPHeaderFilter object matching the to be generated IKE packet (usually a match on HdrDstAddress). Another way is to use the PeerIDPayloadFilterEntry (typically for an aggressive mode responder). Adding a new association between IPSecAction and IKENegotiationAction was not deemed as useful at the time of writing. One of our goal was to separate the IPSecRules (SPD) from the IKE negotiation one (notable to be as independent as possible from IKEv1). >4. (in section 4.2.1) we are inheriting a PolicyDecisionStrategy property >from PCIM. This seems bad to me in the case of IPsec. The >policyDecisionStrategy allows administrators to configure if they want to >do all matching rules or do only the highest priority matching rule. IPsec >specifically demands that we do only the highest priority matching rule. >And I'd strongly like to see a priority property re-introduced to >PolicyRule and PolicyGroup. Why on earth was it depricated based on input >from ICPM? I'm currently very unclear about how to administrativly order >policies. I do see that ICPM has added a priority property to the >aggrigation classes RuleForIkeNegotiation and RuleForIpsecNegotiation, but >these aggrigations can contain N rules and I don't see how to prioritize >within them. What am I missing here?... [Lee] From section 4.2.1: "if the property PolicyDecisionStrategy exists, it must be set to "FirstMatching"" As you observed, the priority property is on the aggregation so that priorities can be set in the specific context of its policy group. When PCIM defined it as a context independent property, it was an intractable problem to determine the priority for a policyrule when it can be used in a number of groups. Each policysetcomponent aggregation (e.g., RuleForIPsecNegotiation) has a priority value. Perhaps the confusion is cleared up by observing that there is an instance of the aggregation class for each aggregated rule. So, for example, in the context of a given IPsecPolicyGroup each rule has either a RuleForIPsecNegotiation instance or a RuleForIKENegotiation instance and that instance has a priority in it that applies only to that context (policy group). In a different policy group, the same rule can have a different priority because it has a different aggregation instance. IHTH. >5. (in section 4.2.2) There are no examples of using the "Do until >failure" execution strategy. And I can not imagine how to use it myself. >What happens if there is a failure? Is that good in this case? What >happens if there is no failure and we reach the end of our actions? Would >we start over and do them again? [Eric & Lee] Indeed, we had no example of 'Do Until Failure' applicable to IPSec. We just left it in order to simplify the inheritance from PCIM. BTW, if all your aggregated actions are success, then you do not have any failure, then the net effect is a failure ;-) >5. (in sect. 4.3.1) I think it is problematic to store individual context >names in alphabetical order... could we do administrativly configured >order instead? [Lee] The alphabetization is an arbitrary algorithm so that string compares can be used to determine if compound contexts are the same. When, for example, an identity is used in multiple contexts, that list is not alphabetized; it's only ordered when a given context name is a composition of values (e.g., "pki&&x.com&&y.com" defines an identity context). This usage is generally unnecessary since one can name a context without the composition operator (e.g., "xy pki vpn"). >7. (also in sect 4.3.1) I do not beleive that we need to make identity >selection a function of (local-endpoint, type, and name). It seems to me >that identity selection only needs to be a function of (type and name). [Lee] Identities can be interface specific. When an identity is shared by more than one interface, one can associate a collection of IPPotocolEndpoint instances to the identity. >8. (sect s 4.8.1 and 4.9.1) Again, I'm unclear on why there are >priorities on the aggrigation classes but no priorities in the SARule or >IPsedPolicyGroup class. Some explanitory text may help here. > [Lee] See #4 above. >9. (sect 4.9.3 and 4.10.2) should be a cardinality of 1..n ? [Lee & Eric] 4.9.3: Since an IPsecPolicyGroup MAY be a structured set of groups, there's no requirement that each group have both IKE and IPsec rules in it. 4.10.2: Conditions do not have an existence dependency on being used in a rule. They're not terribly useful until they're in a rule, but they can exist independently. >10. (sect 5.2) why must an IPHeaderFilter match traffic symetrically? [Eric] If your selectors for inbound & outbound are identical, then you should used 'mirrored' for simplicity (but you can define mirrored IPHeaderFilters if desired). NB: note the SHOULD in the text. Else (asymmetrical selectors), obviously you should not use 'mirrored'. >11. (sect 5.3 and 5.5) what is the difference between a >CredentialFilterEntry and a PeerIdPayloadFilterEntry? Would we use a >CredentialFilterEntry when we specificall want to farm out the "good/bad" >decision to a credentialManagement service? [Eric] PeerIDPayloadFilterEntry: is a filter about the IKE identity used during phase 1 (FQDN, DN, IP address, ...). CredentialFilterEntry is typically used when you expect this IKERule to be applied only for some credential services (like for this IKERUle, use this CA only). >12. (sect. 5.3.1) MatchFieldName seems underspecified. There is no 'stuff' >under the 'value' deffinition. > >13. (sect. 5.3.2) MatchFieldValue seems underspecified. If we are matching >against DNs or GNs, we need a way to match the subparts of these >subjectNames and subjectAltNames and to wildcard match parts of them also. [Eric] It is indeed somehow underspecified. The goal was to be able to filter based on subjectAltName using wildcard. We should add (or have added) more examples and specifications. >14. (sect 5.3.3) what about PSK? (or dare I ask... xauth) [Eric] Xauth is out of the specification of ICPM. If PSK means PreShared Key for IKE authentication, the secret is actually in the SharedSecret class from CIMUSER (cfr 6.6 for IPSec static session keys). This should be (should have been) more specified. >15. (sect 5.4) who care?. Why are we doing Security Options filters? >Thanks for making it a MAY. [Eric] Our objective was to stick as close as possible to RFC 2401. >16. (sect 5.5) We deffinatly need to strike the phrase "when acting as a >responder" Both initiators and responders need to authenticate their >respective peers and both need a way to associate identities with peers. >Also the next sentence (beginning "Moreover, this filter can be ...) seems >unnecessary to me. That behaviour is specified elsewhere... I move to stike it. [Eric] This filter is used to reject IKE phase one when the remote is using a wrong/unacceptable ID. And indeed, this filter could be applied in both responder and initiator modes. >17. (sect 5.5.2) we need a way to match the subparts of a subjectName and >subjectAltName (DN and GN) and a way to wildcard match the subparts. [Eric] The text should have been more explicit on how to match a DN (as we give only example for FQDN and IP addresses). >18. (sect 6.) I'd like vendors to have the freedom to add new actions as >siblings of SAAction. Specifically, I have in mind stuff like Firewall, >QOS, NAT, drop, bypass. Could we introduce a note in the text to this effect? [Lee] SAAction is a subclass of PolicyAction. One can create new subclasses of PolicyAction if one chooses to do so but it's not in the scope of this document. See PCIM and PCIMe. But be aware that there are classes for drop and bypass already (see SAStaticAction subclasses) and there are standards activities for QOS policy. [Eric] In London meeting, I have orally made this comment. >19. (sect 6.1.1) the description of DoActionLogging seems vague to me. I'm >not sure what is meant by the phrase "when the action is performed". Is >this when a packet traverses this action, or is it when the action is >instantiated? [Lee] The DoActionLogging boolean tells whether the action of negotiating based on that action is performed. The DoPacketLogging boolean tells whether the resulting SA is to do packet logging. >20. (sect 6.2) The description of SAStaticAction mentions that it is a >base class for IKE actions that do not require any negotiation. I don't >think there is any such thing. [Lee] An IKERejectAction is a subclass of SAStaticAction. >21. (sect 6.6) In the notes area of PreconfiguredSAAction there is an >abbreviation "resp." used which I am guessing was meant to refer to >"Responder". But the use of the IKE term "Responder" would make no sence >in a description area of a static IPsec action. Can you clear this up for me. [Eric] Sorry for the confusion, probably a wrong English acronym has been used, I actually meant 'respectively'. >22. (sect 6.11.1) UsePFS seems to refer to PFS with respect to keys. Where >is a property to control PFS with respect to IDs? [Eric] Ricky, I do not understand what you mean by PFS with respect to ID ? >23. (sect 6.14.2) could we use simple assending interger values to >describe ExchangeMode instead of powers of 2? [Eric] It has been decided a long time ago, but, it was to have the same representation as on the wire (which is quite debatable of course) >24. (sect. 6.14.3) UseIKEIdentyType. The phrase "This information is to be >used in conjunction with the IKE identities..." is too vague for me. I >need to know how to find exactly which IKE identity is to be used in >association with this IKEAction. [Lee] See 8.6 IKEIdentity class and property descriptions. >25. (sect 6.15) peer gateway. I'm fuzzy about how this class interacts >with (or does not interact with) the CredentailFilterEntry and >PeerIdaPayloadFilterEntry classes. I think we have an IPsec and IKE rule >in hand by the time we get down to IPsecTunnelAction. Now the IKErule and >the IPsecAction:PeerGateway both seem to offer ways to identify the peer. >What are the distinctions between when these classes are applicable? [Eric] An egress plain text packet will trigger only one IPSecRule, one SAAction of the IPSecRule will possibly request a IKE negotiation with one PeerGateway. Once a possible PeerGateway is known, the IKERules are checked to select the relevant IKENegotiationAction. >26. (sect 6.15.3) PeerIdentity seems underspecified. I think we would need >an ID payload type and in the case of DN or GN, ways to match and wildcard >match the subfields of the subjectName or subjectAltName. [Lee & Eric] See PeerIdentityType. We should have added some more descriptive text. >27. (sect. 6.16.3) is a sequence nukmber on peer gateways still needed now >that the ExecutionStrategy property has been introduce to the SARule? [Lee] Yes, the ExecutionStrategy and sequence numbers specify the order in which actions are attempted. The gateway selection is within a given action. One might argue for this being an implementation decision rather than a policy decision, but it doesn't have anything to do with ExecutionStrategy and action ordering. >28. (sect 6.18) Again, something I'm not understanding here. Do we need to >keep a table of "systems" for all of our peers? And why do we care about >associating our IKE peers with the information availabl in the "System" class? [Lee] The HostedPeerGatewayInformation association simply anchors the "table" of peer gateways, nothing more. The system instance is the system that hosts the local IKEService. >29. (sect 7.2.4) the VALUE deffinition of PRFAlgorithm says "currently >none defined". While this is true, I'd rather say "see IKE" (or see DOI, >I didn't look up which was approprate for this). [Eric] Good point >30. (sect 7.2.5) setting groupID to the value "notNeeded" is poor >configuration design. It puts two knobs in the hands of an adminstrator >(both of which must be set correctly) to do only one task. Instead I'd >rather see us say that if the ExchangeMode is agressive, then the GroupId >property will not be used reguardless of its setting. [Eric] Good point as well. >31. (sect 7.2.6) I don't like having the "special value 0" on the >AuthenticationMethod poperty. Since there can be N saProposals on an >IKENegotiationAction I think we can list the IKEproposals with the >IKEauthentication methods we want to use explicitly rather than having a >setting for "just make a proposal for each applicable credential I have". >And even if we did keep the "special value 0" thing, it seems like we >would need to distinguis beteen authentication methods if we had an RSA >cert credential. We would not completely know if we should use rsaEncrypt >or revisedRsaEncrypt autenhtication methods. > >32. (sect 7.8) yet another please explain this to me... Why would we want >to associate SAProposals with the poperties available in the System class? > >33. (note: I'm skipping review of the IKEServices stuff). [Eric] Shame on you ! ;-) >34. What happens to my configuration if one of my IPaddresses is changed >(ie by dhcp or ppp or a human...) [Lee] It changes too; at least to the extent that configuration is anchored on an address. [Eric] And this is strict compliance to RFC 2401. >35. Could we parallize the names SAConditionInRule and PolicyActionInSaRule? [Lee] If you mean change the name of SAConditionInRule to SAConditionInSARule, I suppose so...if it's really important to you. [Eric] ;-) Thanks for your comments -eric & others