From owner-ipsec-policy@mail.vpnc.org Thu Apr 1 10:17:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16394 for ; Thu, 1 Apr 2004 10:17:04 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31Eg9cb099081; Thu, 1 Apr 2004 06:42:09 -0800 (PST) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i31Eg9pA099080; Thu, 1 Apr 2004 06:42:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31Eg7dJ099074 for ; Thu, 1 Apr 2004 06:42:08 -0800 (PST) (envelope-from Man.M.Li@nokia.com) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31Eg8h27736 for ; Thu, 1 Apr 2004 17:42:08 +0300 (EET DST) X-Scanned: Thu, 1 Apr 2004 17:42:04 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i31Eg4Tg010666 for ; Thu, 1 Apr 2004 17:42:04 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00897lEM; Thu, 01 Apr 2004 17:42:03 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31Efvs18430 for ; Thu, 1 Apr 2004 17:41:57 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Apr 2004 08:38:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: A question about IkeAuthMethod TC in ikeaction-mib? Date: Thu, 1 Apr 2004 09:38:37 -0500 Message-ID: Thread-Topic: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - general comment/question Thread-Index: AcQLazy052vXvv4vSTOHkH/N8rtmnQIGQe7A From: To: X-OriginalArrivalTime: 01 Apr 2004 14:38:39.0740 (UTC) FILETIME=[05F32BC0:01C417F7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i31Eg8dJ099075 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I was looking to import some of the TEXTUAL-CONVENTION from the IPsec MIB to PIB. In the ikeaction-mib-00.txt, should the IkeAuthMethod TC also include Kerberos? Best regards Man From owner-ipsec-policy@mail.vpnc.org Thu Apr 1 12:18:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22506 for ; Thu, 1 Apr 2004 12:18:05 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31GllLE009380; Thu, 1 Apr 2004 08:47:47 -0800 (PST) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i31Gllso009379; Thu, 1 Apr 2004 08:47:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from smtp.um.es (xenon2.um.es [155.54.212.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31GlkNs009367 for ; Thu, 1 Apr 2004 08:47:47 -0800 (PST) (envelope-from fgarcia@dif.um.es) Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id BF4C7111C for ; Thu, 1 Apr 2004 18:47:43 +0200 (CEST) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id A5FA61113 for ; Thu, 1 Apr 2004 18:47:43 +0200 (CEST) Received: from dif.um.es (alborada.dif.um.es [155.54.210.32]) by aries.dif.um.es (Postfix) with ESMTP id 9E0C314431 for ; Thu, 1 Apr 2004 18:47:40 +0200 (MET DST) Message-ID: <406C481B.66335D53@dif.um.es> Date: Thu, 01 Apr 2004 18:49:31 +0200 From: "=?iso-8859-1?Q?F=E9lix?= J.=?iso-8859-1?Q?Garc=EDa?= Clemente" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-policy@vpnc.org Subject: ipSecIfCapsTable not many attributes Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello all, I am including a complete support for the Framework PIB and the IPSec PIB in my own COPS-PR implementation. I have noted that IPSec PIB includes the table ipSecIfCapsTable to specify capabilities that may be associated with an interface. This table has not many attributes, are you going to add new attributes or capability tables? I think this is necessary. For example, an interface may not support 'policy reload', i.e. to apply a policy forces to restart the interface, or even an attribute may specify the cryptography system supported (symmetric or asymmetric, or both). Regards, Félix From owner-ipsec-policy@mail.vpnc.org Thu Apr 1 12:22:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22692 for ; Thu, 1 Apr 2004 12:22:38 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31GoLWm009549; Thu, 1 Apr 2004 08:50:21 -0800 (PST) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i31GoL2l009548; Thu, 1 Apr 2004 08:50:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from wes.hardakers.net (adsl-66-127-127-227.dsl.scrm01.pacbell.net [66.127.127.227]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31GoLnv009541 for ; Thu, 1 Apr 2004 08:50:21 -0800 (PST) (envelope-from hardaker@tislabs.com) Received: by wes.hardakers.net (Postfix, from userid 274) id 3EDDF11D811; Thu, 1 Apr 2004 08:50:22 -0800 (PST) To: Cc: Subject: Re: A question about IkeAuthMethod TC in ikeaction-mib? References: From: Wes Hardaker Organization: Sparta Date: Thu, 01 Apr 2004 08:50:22 -0800 In-Reply-To: (Man M. Li's message of "Thu, 1 Apr 2004 09:38:37 -0500") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.5 (celeriac, linux) 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 Thu, 1 Apr 2004 09:38:37 -0500, said: Man> I was looking to import some of the TEXTUAL-CONVENTION from the Man> IPsec MIB to PIB. In the ikeaction-mib-00.txt, should the Man> IkeAuthMethod TC also include Kerberos? Has it been assigned a value by IANA? If so, then yes it should. -- Wes Hardaker Sparta From owner-ipsec-policy@mail.vpnc.org Mon Apr 5 17:37:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10384 for ; Mon, 5 Apr 2004 17:37:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35LHVOu008860; Mon, 5 Apr 2004 14:17:31 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35LHV61008859; Mon, 5 Apr 2004 14:17:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35LHTL1008853 for ; Mon, 5 Apr 2004 14:17:30 -0700 (PDT) (envelope-from Man.M.Li@nokia.com) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i35LHSh09597; Tue, 6 Apr 2004 00:17:28 +0300 (EET DST) X-Scanned: Tue, 6 Apr 2004 00:14:44 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i35LEiwv012889; Tue, 6 Apr 2004 00:14:44 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Hu5JtX; Tue, 06 Apr 2004 00:14:42 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i35LEbs17995; Tue, 6 Apr 2004 00:14:37 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Apr 2004 16:14:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - general comment/question Date: Mon, 5 Apr 2004 17:14:14 -0400 Message-ID: Thread-Topic: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - general comment/question Thread-Index: AcQLazy052vXvv4vSTOHkH/N8rtmnQP5gvJg From: To: Cc: , , , , X-OriginalArrivalTime: 05 Apr 2004 21:14:16.0220 (UTC) FILETIME=[F3A595C0:01C41B52] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i35LHUL1008854 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Added two paragraphs (3rd and 4th of Section 3) to explain the structure and mapping between this PIB and RFC3585. The mapping is easy to see - In many cases, even the attribute names are the same. Best regards Man > -----Original Message----- > From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: March 16, 2004 10:24 AM > To: Li Man.M (Nokia-NRC/Boston); 'bwijnen@lucent.com' > Cc: 'smb@research.att.com'; 'ho@alum.mit.edu'; 'lsanchez@xapiens.com'; > 'avri@apocalypse.org'; 'ipsec-policy@vpnc.org' > Subject: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - > general comment/question > > > > What I am missing in the prose section before the actual > PIB definition is a desciption of how these PIB Classes > match or fit to the PCIM (RFC3060), PCIMe (RFC3460), and > IPsec IM (RFC3585). Maybe that is just me... but I thought > that it should be easier to see the mapping (if it does > exist). I would also expect a similar modularity (abstraction > level) as in those 3 Information Model RFCs. Maybe that is just > me ?? > > Thanks, > Bert > From owner-ipsec-policy@mail.vpnc.org Mon Apr 5 17:37:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10403 for ; Mon, 5 Apr 2004 17:37:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35LCmOE008541; Mon, 5 Apr 2004 14:12:49 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35LCmYm008540; Mon, 5 Apr 2004 14:12:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35LCkNf008515 for ; Mon, 5 Apr 2004 14:12:47 -0700 (PDT) (envelope-from Man.M.Li@nokia.com) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i35LCiE25146; Tue, 6 Apr 2004 00:12:44 +0300 (EET DST) X-Scanned: Tue, 6 Apr 2004 00:11:24 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i35LBOTg005762; Tue, 6 Apr 2004 00:11:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 005PwFwD; Tue, 06 Apr 2004 00:11:21 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i35LBHs16207; Tue, 6 Apr 2004 00:11:17 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Apr 2004 16:10:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - part 1 Date: Mon, 5 Apr 2004 17:10:28 -0400 Message-ID: Thread-Topic: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - part 1 Thread-Index: AcQIXsmi1ydh61rYR8KCqQIfF8oWFgQgrxrg From: To: Cc: , , , , X-OriginalArrivalTime: 05 Apr 2004 21:10:30.0187 (UTC) FILETIME=[6CEBAFB0:01C41B52] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i35LCmNf008530 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Please see inline for further modifications made according to the suggestions. > -----Original Message----- > From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: March 12, 2004 01:20 PM > To: Li Man.M (Nokia-NRC/Boston); bwijnen@lucent.com > Cc: smb@research.att.com; ho@alum.mit.edu; lsanchez@xapiens.com; > avri@apocalypse.org; ipsec-policy@vpnc.org > Subject: RE: MIB/PIB doctor review for > draft-ietf-ipsp-ipsecpib-09.txt - > part 1 > > > > Sorry that it took so (much too) long for my follow up. > Comments inline. > > A separate email will contain additional new comments. > > Thanks, > Bert > > > -----Original Message----- > > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > > Sent: vrijdag 21 november 2003 23:25 > > To: bwijnen@lucent.com > > Cc: smb@research.att.com; ho@alum.mit.edu; lsanchez@xapiens.com; > > avri@apocalypse.org; ipsec-policy@vpnc.org > > Subject: RE: MIB/PIB doctor review for > > draft-ietf-ipsp-ipsecpib-09.txt - > > part 1 > > > > > > Hi Bert, > > > > Thanks for your comments on the IPsec PIB draft v9. > > Modifications have been made to address your comments 1-7 and > > they are described below. Please also take a look at my reply > > to your comment #8, since any change will create a > > discrepancy with RFC 3585, I suggest to leave it as is unless > > you do not agree. > > > > Please let me know if any of the modifications described are > > still not satisfactory. I look forward to hearing more > > comments from you on the rest of the draft. At which point, > > we'll submit a new version. Thanks. > > > OK, so I now have continued to review revision 9. > I expect to see a rev 10 after all changes have been made. > > > Best regards > > Man > > > > > -----Original Message----- > > > From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > Sent: November 19, 2003 12:08 PM > > > To: Li Man.M (NRC/Boston); 'ho@alum.mit.edu'; > 'avri@apocalypse.org'; > > > 'lsanchez@xapiens.com' > > > Cc: Steve Bellovin (E-mail); Wijnen, Bert (Bert) > > > Subject: MIB/PIB doctor review for > draft-ietf-ipsp-ipsecpib-09.txt - > > > part 1 > > > > > > > > > Based on the revision 9 that I received privately: > > > > > > 1. I see: > > > ipSecRuleIfName OBJECT-TYPE > > > SYNTAX SnmpAdminString > > > STATUS current > > > DESCRIPTION > > > "The interface capability set to which this IPsec rule applies. > > > The interface capability name specified by this attribute MUST > > > exist in the frwkCapabilitySetTable [9] prior to > association with > > > an instance of this class." > > > ::= { ipSecRuleEntry 2 } > > > > > > So I wonder: > > > - would an attribute name of ipSecRuleIfCapSetName not be > > > better than > > > ipSecRuleIfName ??? When I see the latter I think of > > ifName in the > > > IF-MIB, when I see the former I am more inclined to > think about > > > the capaibilty in the frwkCapabilitySetTable. The latter > > > would also > > > be more inline with what we see in other PIB docs (RFC3317 for > > > example) > > > > OK. Name changed to ipSecRuleIfCapSetName. > > > > > - what kind of error must be returned when the entry in the > > > frwkCapabilitySetTable does not yet exist? > > > > Added description in the table that the ipSecRule table entry > > will not be installed if that happens. > > > > > - is it clear what values the OID pointers in the > > > frwkCapabilitySetTable > > > can/should take when they are associated with an entry in > > > this ipSec table? > > > > Added "The frwkCapabilitySetCapability attribute of that > > entry shall in turn point to an entry in the ipSecIfCaps > > table." to make it clear. > > > > > > > > 2. I see > > > ipSecRuleRoles OBJECT-TYPE > > > SYNTAX RoleCombination > > > STATUS current > > > DESCRIPTION > > > "Specifies the role combination of the interface to which this > > > IPsec rule should apply. There must exist an instance in the > > > frwkRoleComboTable [9] specifying this role > combination, together > > > with the interface capability set specified by ipSecRuleIfName, > > > prior to association with an instance of this class." > > > ::= { ipSecRuleEntry 3 } > > > > > > - what error must be returned when the entry in > > frwkRoleComboTable > > > does not yet exist? > > > > Added description in the table that the ipSecRule table entry > > will not be installed if that happens. > > > > > 3. I see > > > ipSecRuleAutoStart OBJECT-TYPE > > > SYNTAX TruthValue > > > STATUS current > > > DESCRIPTION > > > "Indicates if this rule should be automatically executed." > > > ::= { ipSecRuleEntry 11 } > > > > > > The name "AutoStart" seems to tell me it needs to be > > activated when > > > the class is instantiated. Is that the same as "automatically > > > executed"? What if the value gets changed to false? > > > > Changed to "Indicates if this rule shall be activated when it > > is instantiated, i.e., start negotiate or statically set > > security associations. If the value is changed to false > > later, there is no impact on the security associations that > > have already started." > > > > > > > > 4. May I assume that if either ipSecStaticActionLifetimeSeconds > > > or ipSecStaticActionLifetimeKilobytes indicates end of > life time > > > that that indeed marks the end of life? It is not clear what > > > happens in that case. You may want to clarify. > > > > Added the following in ALL lifetime attributes "When both the > > LifetimeSeconds and LifetimeKilobytes are used, the first > > lifetime to expire takes precedence." > > > > > > > > 5. I see: > > > ipSecAssociationVendorId OBJECT-TYPE > > > SYNTAX OCTET STRING > > > STATUS current > > > DESCRIPTION > > > "Specifies the IKE Vendor ID. .... > > > > > > and wonder: what is an IKE Vendor ID? How is it formatted? > > > Where is that explained? Is a reference usefull? I think so. > > > > Added a reference to RFC 2408. There are a couple more > > VendorId in the draft, will add references to them as well > > > OK, I see that it is a HASH. That explains it. > The reference helps. Might be good to also state that this is the > hash value as defined in RFC2408 sect 3.16 OK also added "It is a hash value as defined in [RFC2408] Section 3.16." > > > > > > > 6. WHen I see: > > > ipSecAssociationDhGroup OBJECT-TYPE > > > SYNTAX Unsigned16TC > > > STATUS current > > > DESCRIPTION > > > "Specifies the key exchange group to use for phase 2 when the > > > > > > I wonder... is that justa random value? Or does each value mean > > > something, and if so, where is that defined? > > > > Added "reference to RFC 2409 for valid Dh group values" to > > both ipSecAssociationDhGroup and ipSecIkeProposalIkeDhGroup. > > > > > > > > 7. ipSecAssociationGranularity > > > when reading the DESCRIPTION clause, I wonder if a > BITS syntax is > > > not better here > > > > OK. Changed to BITS. > > > > > > > > 8. ipSecAhTransformMaxLifetimeSeconds > > > I find it strange that zero means a max lifetime of 8 > hours here, > > > where as in an earlier xxxMaxLifeTimeSeconds > object/attribute it > > > meand infinite ?? Is that logical? Does that make sense? > > > > All the lifetime attributes and their default values are > > aligned with RFC 3585. All the maxLifeTimeSeconds seem to use > > 0 to indicate 8 hours. All other lifetime or minLifetime uses > > 0 to indicate infinite. We could make changes so that, for > > example, 0 indicates infinite in all the cases. But that will > > create discrepancy between this draft and RFC 3585. > > > If this PIB is to be modelling RFC3585, then pls do follow > that document, > It just seemed weird to me. Adding the references, and may be > a few lines > of explanantion will help people understand why the weirdness > is in the > PIB. OK. Added references to RFC3585 for all life time related attributes. > > Bert > From owner-ipsec-policy@mail.vpnc.org Mon Apr 5 17:44:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10567 for ; Mon, 5 Apr 2004 17:44:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35LCs4s008576; Mon, 5 Apr 2004 14:12:54 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35LCs4s008575; Mon, 5 Apr 2004 14:12:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35LCq7U008563 for ; Mon, 5 Apr 2004 14:12:53 -0700 (PDT) (envelope-from Man.M.Li@nokia.com) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i35LCnx01410; Tue, 6 Apr 2004 00:12:50 +0300 (EET DST) X-Scanned: Tue, 6 Apr 2004 00:11:00 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i35LB0FG004611; Tue, 6 Apr 2004 00:11:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00AgXgPH; Tue, 06 Apr 2004 00:10:58 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i35LAps15930; Tue, 6 Apr 2004 00:10:52 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Apr 2004 16:10:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FW: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - part 2 Date: Mon, 5 Apr 2004 17:10:14 -0400 Message-ID: Thread-Topic: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - part 2 Thread-Index: AcQTPhxbEnDN4b3BSbifjQo5mkFCsAFpQd4Q From: To: Cc: , <'ho@alum.mit.edu>, , , X-OriginalArrivalTime: 05 Apr 2004 21:10:15.0688 (UTC) FILETIME=[64475080:01C41B52] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i35LCs7U008570 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Bert, Thanks for your comments. Suggestions on time period syntax are very helpful. Below is a description of modifications made according to each comment. Best regards Man > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: dinsdag 16 maart 2004 15:49 > To: Man.M.Li@nokia.com; bwijnen@lucent.com > Cc: smb@research.att.com; ho@alum.mit.edu; lsanchez@xapiens.com; > avri@apocalypse.org; ipsec-policy@vpnc.org > Subject: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - > part 2 > > > Steve, you may want to pay specific attention to items 34-37. > > Addtional things I found when revieing revision 9 > > Comments 1-8 were in part 1 email of the review > > 9. Doing s smilint syntax check, I get the following: > > C:\smi\pibs\ietf>smilint -l 6 -s -m -inamelength-32 > ./IPSEC-POLICY-PIB > /IPSEC-POLICY-PIB:83: [5] {type-without-format} warning: type > `Unsigned16TC' has no format specification > simple to fix by adding a DISPLAY-HINT > > /IPSEC-POLICY-PIB:19: [5] {import-unused} warning: identifier > `zeroDotZero' imported from module `SNMPv2-SMI's never used > > simple to fix by removing zeroDotZero from the imports OK. added display hint and removed zeroDotZero. > > 10. I see a lot of acronyms in the document without expansion > (when used > for the first time. These maybe well know to security > folk, but not > to new readers. RFC-Editor wants them to be exanded first > time they > are used. Pls note that when PIB module is extracted, > previous text is > gone, and so it is probably wise to always expand in PIB > DESCRIPTION > clauses. Expanded the acronyms when they first appear in text and in PIB. > > 11. All RFCs that contain PIB or MIB modules from which you > IMPORT must > be normatively referenced. The RFC-Editor recently also > wanted such > references to have citations. The notatation we agreed on is > > IMPORTS > Unsigned32, Unsigned64, MODULE-IDENTITY, > OBJECT-TYPE, TEXTUAL-CONVENTION, MODULE-COMPLIANCE, > OBJECT-GROUP, pib > FROM COPS-PR-SPPI -- [RFC3159] > TruthValue > FROM SNMPv2-TC -- [RFC2579] > > and so on. But.. your references seem to be just numbered. > I Do not find > > OBJECT-GROUP, pib > FROM COPS-PR-SPPI -- [14] > > very acceptable. This is because when the PIB module gest > extracted, > then a "citation" of [14] does not help much. A Citation > of [RFC3159] > would still be clear for the reader (or so I think). OK. Used [RFCxxx] INSIDE the mib module. > > 12. I see various ENUMERATIONS (e.g. INTEGERS) that probably would be > better represented as a TC. > For example: > > SYNTAX INTEGER { > in(1), > out(2), > bi-directional(3) > } > > and also > SYNTAX INTEGER { > copy(1), > set(2), > clear(3) > } > there are others. Those are just 2 examples. Defined many new TCs and also imported TCs from ipsec policy mibs. The few enumerations left are "un-typical" ones. > 13.I wonder if this is wise: > > Unsigned16TC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "An unsigned 16 bit integer." > SYNTAX Unsigned32 (0..65535) > > In some places its use seems OK. In many places, it is used > to indicate an "order" as in: > > ipSecRuleOrder OBJECT-TYPE > SYNTAX Unsigned16TC > STATUS current > DESCRIPTION > "Specifies the precedence order of the rule within > all the rules > associated with {IfName, Roles}. A smaller value indicates a > higher precedence order. " > ::= { ipSecRuleEntry 9 } > > I wonder if it would not be better to define a TC aka: > > IpSecOrderTC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION "An unsigned 16 bit integer that > defines the order > of a Rule or Set. A smaller value indicates a > higher precedence order." > SYNTAX Unsigned32 (0..65535) > > And then use that TC for all "order" objects. Created a IpSecOrderTC and used for all order objects. > > In the case of > ipSecAssociationDhGroup OBJECT-TYPE > SYNTAX Unsigned16TC > > I also wonder if a IpSecDhGroupTC would not be a wise thing. Imported IkeGroupDescription from the ipsec MIB for the purpose > > > 14.I see citations in DESCRIPTION clauses, as in: > > ipSecRuleIfName OBJECT-TYPE > SYNTAX SnmpAdminString > STATUS current > DESCRIPTION > "The interface capability set to which this IPsec rule applies. > The interface capability name specified by this attribute MUST > exist in the frwkCapabilitySetTable [9] prior to > association with > an instance of this class." > ::= { ipSecRuleEntry 2 } > > The [9] of course means nothing anymore when the PIB module gets > extracted. If you used a notation ala [RFCxxxx] then it would still > mean something in an extracted module. Changed to [RFC3318] > > 15.In the ipSecXxxTable DESCRIPTION clauses you use text aka: > "This table ...." > In all other PIB modules that the IETF has published sofar, we did > not talk about a table but either of a PRC (Policy Rule Class) or > just class. See the DIFFSERV-PIB and the FRAMEWORK-PIB for example. > I think that changing this so as to be consistent is a GOOD THING. replaced "table" with "class" in all cases. > > 16.In the DESCRIPTION clause of: > ipSecActionSetDoPacketLogging OBJECT-TYPE > SYNTAX TruthValue > STATUS current > DESCRIPTION > "Specifies whether to log when the resulting security > association > is used to process a packet. For ipSecStaticActions, a > log message > is to be generated when the IPsecBypass, IpsecDiscard > or IKEReject > actions are executed." > ::= { ipSecActionSetEntry 5 } > > I wonder if "IPsecBypass, IpsecDiscard or IKEReject" are meant to > mean the same thing as the enumerations in: > > ipSecStaticActionAction OBJECT-TYPE > SYNTAX INTEGER { > byPass(1), > discard(2), > ikeRejection(3), > preConfiguredTransport(4), > preConfiguredTunnel(5) > } > STATUS current > > If so, then you may want to sync up the labels. Added labels in the packet logging description as follows "Specifies whether to log when the resulting security association is used to process a packet. For ipSecStaticActions, a log message is to be generated when the IPsecBypass (ipSecStaticActionAction = 1), IpsecDiscard (ipSecStaticActionAction = 2) or IKEReject (ipSecStaticActionAction = 3) actions are executed. " > > 17.I see: > ipSecAssociationUseKeyExchangeGroup OBJECT-TYPE > SYNTAX TruthValue > STATUS current > DESCRIPTION > "Specifies whether or not to use the same GroupId for > phase 2 as > was used in phase 1. If UsePFS is false, then this > attribute is > ignored. > > A value of true indicates that the phase 2 GroupId > should be the > same as phase 1. A value of false indicates that the > group number > specified by the ipSecSecurityAssociationDhGroup > attribute SHALL > be used for phase 2. " > ::= { ipSecAssociationEntry 7 } > > And wonder if ipSecSecurityAssociationDhGroup is mean to point to: > > ipSecAssociationDhGroup OBJECT-TYPE > SYNTAX Unsigned16TC > STATUS current > DESCRIPTION > "Specifies the key exchange group to use for phase 2 when the > property ipSecSecurityAssociationUsePfs is true and > the property > ipSecSecurityAssociationUseKeyExchangeGroup is false." > ::= { ipSecAssociationEntry 8 } > > If so, then better sync up the descriptors. > If not, then where is ipSecSecurityAssociationDhGroup defined? > By the way, in the last object, there are also a few descriptors > that start with ipSecSecurityAssociation.... and that I > cannot find. > Again, probably s/Security// ?? You are right. Made changes accordingly. > > 18.I see: > ipSecAhTransformReplayPreventionWindowSize OBJECT-TYPE > SYNTAX Unsigned32 > STATUS current > DESCRIPTION > "Specifies, in bits, the length of the sliding window > used by the > replay prevention detection mechanism. The value of > this property > is ignored if UseReplayPrevention is false. It is > assumed that the > window size will be power of 2." > ::= { ipSecAhTransformEntry 5 } > Might be good to add a UNITS clause? > But I also wonder what "window size will be power of 2" means? Added a UNITS clause. Also changed the sentense to "It is assumed that the window size will take a value that is a power of 2." > > 19.ipSecEspTransformCipherKeyLength, > ipSecEspTransformReplayPreventionWindowSize > and may be others can also use a UNITS clause Added UNITS clause when appropriate. > > 20.In Table/Class ipSecCompTransformTable I see > ipSecCompTransformAlgorithm > and also ipSecCompTransformPrivateAlgorithm. Canthey both > be specified > for the same instance? If so, what happens? If not, can you make > that clear? If yes, you may want to explain also what happens. Deleted ipSecCompTransformPrivateAlgorithm since there is no value defined. > > 21.ipSecIkeRuleTable is probably talking about IKEv1 ?? > Should that be made clear? OK, used IKEv1 in the DESCRIPTION of IKE related classes > What sort of change do we expect for IKEv2? > WOuld it make sense to define this "optional" class in a separate > document? It seems to me that currently IETF does not want to see any more PIB drafts (and please let me know if I am wrong on this.) In any case, as explained in the document, specifying the use of IKEv2 is quite simple -- direct the pointer to an IKEv2 class instead of the IKEv1 defined in this document. > In any event, you do not put in the DESCRIPTION clause > that this table/class > is optional. That is expressed (and even in machine > readable form) in the > MODULE-COMPLIACNE. OK. removed optional from DESCRIPTION clauses. > > 22.I am really wondering and worried about some of the > UNIQUENESS clauses > that require many columns/attributes to define uniqueness. > But ipSecIkeAssociationEntry really seems excessive to me. > It states > that ALL attributes need to be checked for unqiueness !!??? > Is that really intended? > You may want to check all tables/classes in fact. I looked through all the classes, in some cases (e.g., ipSecRuleTable) only a few attributes are needed in the UNIQUENESS. Unfortunately, ipSecIkeAssociationEntry does need all the attributes. > > 23.ipSecIkeAssociationVendorId is an OCTET STRING and the > descripiton clause > talks about a vlaue of NULL. That is not clear! Better is > to talk about > a zero length OCTET STRING. That is clear! Changed NULL to zero length OCTET STRING. > > 24.I see: > ipSecIkeProposalPrfAlgorithm OBJECT-TYPE > SYNTAX Unsigned16TC > STATUS current > DESCRIPTION > "Specifies the Psuedo-Random Function (PRF) to propose > for the IKE > association." > ::= { ipSecIkeProposalEntry 7 } > So where do I find what any value means? > And would it not be better to have a separate TC fo such algorithm > values? And pls add REFERENCE clause to point to it. Changed the DESCRIPTION to "Specifies the Psuedo-Random Function (PRF) to propose for the IKE association. As indicated in [RFC2409], there are currently no negotiable pseudo-random functions defined in this document. Private use attribute values can be used for prf negotiation between consenting parties." > > 24.Similar question for ipSecIkeProposalIkeDhGroup > And pls add REFERENCE clause to point to it. Imported IkeGroupDescription TC from ipsec MIB for this usage. > > 25.IN ipSecIkePeerEndpointIdentityValue you are using IP addresses as > example. But you must use the ange of addresses that has been > allocated for examples as per ID-NITs > http://www.ietf.org/ID-nits.html > which states: > > Addresses used in examples should prefer use of fully > qualified > domain names to literal IP addresses, and prefer use > of example > fqdn's such as foo.example.com to real-world fqdn's. > See RFC 2606 > for example domain names that can be used. There is > also a range > of IP addresses set aside for this purpose. These are > 192.0.2.0/24 > (see RFC 3330). Private addressess that would be used > in the real > world should be avoided in examples. > OK. Used 192.0.2.0/24 in the example instead. > 26.Object ipSecCredentialFieldsValue is defined as an OCTET STRING. > However, reading the DESCRIPTION clause, it feels as if this is > a string that will be used/read by human beings. In that case, it > must be a UTF-8 string. Possibly a SnmpAdminString or some other > TC that defines UTF-8 text. Changed to SnmpAdminString instead of octet string. > > 27.When I read the ipSecSelectorTable and related tables, > then I really > wonder if you guys have really evaluated the possible re-use of the > frwkIpFilterTable in the FRAMEWORK-PIB !!?? > I thought that that framework filter table was meant to be re-used > by many (if not all) filter/selector uses. As discussed in the document, the selector group is meant to specify a scalable way of define a large number of selectors. As indicated in the document (Section 3), to use other filters, simply direct the pointer to that class in a different PIB (e.g framework PIB). > > 28.I have trouble understanding the ipSecIpsoFilterSetTable > I bet it is cause by the very short DESCRIPTION clauses that do not > mean much to me (and so probably do not mean much to other > non-expert > readers). Expand the DESCRIPTION as follows "Specifies IP Security Options (IPSO) filter sets. Each set contains an ordered list of IPSO filters. Please refer to [RFC1108] for details on IPSO." > > 29.When I see ipSecRuleTimePeriodTimePeriod defined as an OCTET STRING > then I wonder. It claims to be RFC2445 format (as RFC3060 also > prescribes). There they talk about a string. > I think it is US-ASCII, possibly represented as UTF-8 ?? > I need to go and check to be sure. In any event, if you > say OCTET STRING > and specify that THISANDPRIOR has special meaning, then it > needs to be > clear what encoding needs to be used for that text. > A SIZE specification may also make sense (or so I think). > This is a generic Policy construct, which probably even > warrants a TC. Defined a TC for this OCTET STRING encoded as UTF-8. > > 30.I do not understand > ipSecRuleTimePeriodMonthOfYearMask OBJECT-TYPE > SYNTAX OCTET STRING > STATUS current > DESCRIPTION > "An octet string that specifies which months the policy is valid > for. The octet string is structured as follows: > > - a 4-octet length field, indicating the length of the entire > octet string; this field is always set to 0x00000006 for this > property; > > - a 2-octet field consisting of 12 bits identifying > the 12 months > of the year, beginning with January and ending with December, > followed by 4 bits that are always set to '0'. For > each month, > the value '1' indicates that the policy is valid for > that month, > and the value '0' indicates that it is not valid. > > If this property is omitted, then the policy rule is treated as > valid for all twelve months." > ::= { ipSecRuleTimePeriodEntry 3 } > > My questions/thinking: > - if indeed the length is ALWAYS 6, with only 2 octets of > information, > then why not define it as: OCTET STRING (SIZE(2)) > - But since you need to represent BITS, I wonder why you do not > use the BITS construct aka: > ipSecRuleTimePeriodMonthOfYearMask OBJECT-TYPE > SYNTAX BITS { > january(0), > february(1), > march(2), > ... > december(11) > } > In fact I would make it a TC. It is a generic construct for Policy > information. As you probably know, BITS does translate to an > octet string of the proper size on the wire. Defined a TC as suggested. > > 31.Similar questions for ipSecRuleTimePeriodDayOfMonthMask. > ipSecRuleTimePeriodDayOfWeekMask I have similar questions Defined TCs for them. > > 32.For ipSecRuleTimePeriodTimeOfDayMask I ahve similar questions as > in point 29 above Defined a TC for this OCTET STRING encoded as UTF-8. > 33.ipSecRuleTimePeriodLocalOrUtcTime > I can live with it. It does not always result in a 16bit unint > as per RFC3060 sect 6.5.6, but can easily be converted to that. > Agin, it would be good if defined as a TC. Defined a TC > > 34.The reason I suggest to define TCs for points 29-33, is that the > same TCs can/should be used by the MIB defintion. Since the MIB > wants to (and can) go stds track, there probably should be a > separate POLICY-TC-MIB module that defines those TCs. OK. > > 35.In fact, the whole TimePeriod... stuff seems so generic to any > policy, that I would think it would also be in a separate module > so that it can be re-used much easier. > In fact the RFC3060 (and possibly RFC3460) should be separate > modules that can be re-used by technology specific specifications > and/or modules. I thought that that was the whole concept/idea of > doing a PCIM and PCIMe. They would be CORE definitions upon which > technology specific definitions (like IPsec and QoS) could/would > build. Have we completely lost this idea/concept? I sent out an e-mail to see if the working group or anywhere in IETF is interested in having a separate PIB draft. No response which I take as "No". > > 36.If I see it correctly, then every table has its own OBJECT-GROUP > with a description clause of "Objects from the xxxTable." > Is that the most logical grouping? I doubt it very much. > Has any thought gone into this? Modified. The PIB has four core groups and a few optional groups > > 37.I will leave it to your security ADs to tell you about the security > considerations section. But it seems to me that it is inadequate. OK > > 38.RFC-Editor considerations is incorrect. There are many more > normative references. In any event, [9] has been published as > RFC3318, as you indicate yoruself in ref section. ANdf ref [12] > has been published as RFC3385, as you can see on your WG > charter page. OK removed the sentence referring [9] and [12] > > 39.IANA Considerations section > - the 1st para is fine, except I would add a ptr to the > iana web page > that has the registry. Makes it easier for everyone > - the 2nd para need to be formulated in the same way as 1st para. > So that it is also readable after IAN has done the assignment. > Pls also add ptr to the cirrect iana web page. Copied with modification the IANA section from RFC3317. > Since this will result in a new revision, I propose to also add the > proper IPR statements as per the new RFCs 3667/8/9 Added IPR ack as Section 12. > > Bert > From owner-ipsec-policy@mail.vpnc.org Tue Apr 6 00:05:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14436 for ; Tue, 6 Apr 2004 00:05:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i363dcmZ034510; Mon, 5 Apr 2004 20:39:38 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i363dcgx034509; Mon, 5 Apr 2004 20:39:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from psg.com (mailnull@psg.com [147.28.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i363dcqc034503 for ; Mon, 5 Apr 2004 20:39:38 -0700 (PDT) (envelope-from avri@acm.org) Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BAhRB-000GyF-Eb; Tue, 06 Apr 2004 03:39:45 +0000 In-Reply-To: <406C481B.66335D53@dif.um.es> References: <406C481B.66335D53@dif.um.es> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0AC9DE7B-877C-11D8-9DCF-000393CC2112@acm.org> Cc: ipsec-policy@vpnc.org From: avri@acm.org Subject: Re: ipSecIfCapsTable not many attributes Date: Tue, 6 Apr 2004 12:39:43 +0900 To: =?ISO-8859-1?Q?"F=E9lix_J.Garc=EDa_Clemente"?= X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i363dcqc034504 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, First let me say how glad I am to hear about another implementation of the PIB. My first issue is that since the ID has been through WG last call and is currently in IESG review and MIB doctor review, I would not like to pull it back to add a major new capability for anything less then a show stopper at this point. Further on the specific issue: While capabilities are important, the Framework PIB has comprehensive capability mechanism, that should cover the requirements. thanks a. On 2 apr 2004, at 01.49, Félix J.García Clemente wrote: > > Hello all, > I am including a complete support for the Framework PIB and the IPSec > PIB in my own COPS-PR implementation. > I have noted that IPSec PIB includes the table ipSecIfCapsTable to > specify capabilities that may be associated with an interface. > This table has not many attributes, are you going to add new attributes > or capability tables? > > I think this is necessary. For example, an interface may not support > 'policy reload', i.e. to apply a policy forces to restart the > interface, > or even an attribute may specify the cryptography system supported > (symmetric or asymmetric, or both). > > Regards, > Félix > > > > From subs-reminder@vpnc.org Wed Apr 7 00:25:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06812 for ; Wed, 7 Apr 2004 00:25:28 -0400 (EDT) From: subs-reminder@vpnc.org Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i374PM6K070460 for ; Tue, 6 Apr 2004 21:25:22 -0700 (PDT) (envelope-from subs-reminder@vpnc.org) Received: (from root@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i374PMbC070459; Tue, 6 Apr 2004 21:25:22 -0700 (PDT) Date: Tue, 6 Apr 2004 21:25:22 -0700 (PDT) Message-Id: <200404070425.i374PMbC070459@above.proper.com> To: ipsp-archive@ietf.org Subject: [[945418401]] Subscription to ipsec-policy for ipsp-archive@lists.ietf.org Greetings. This message is a periodic reminder that ipsp-archive@lists.ietf.org is subscribed to the ipsec-policy mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ipsec-policy mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ipsec-policy-request@vpnc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "ipsp-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ipsec-policy@mail.vpnc.org Wed Apr 7 12:04:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05467 for ; Wed, 7 Apr 2004 12:04:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FX3Gq004168; Wed, 7 Apr 2004 08:33:03 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i37FX39x004167; Wed, 7 Apr 2004 08:33:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FX27Z004155 for ; Wed, 7 Apr 2004 08:33:02 -0700 (PDT) (envelope-from rbunch@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03774; Wed, 7 Apr 2004 11:33:02 -0400 (EDT) Message-Id: <200404071533.LAA03774@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ipsec-policy@vpnc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsp-ipsecpib-10.txt Date: Wed, 07 Apr 2004 11:33:02 -0400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Policy Working Group of the IETF. Title : IPSec Policy Information Base Author(s) : M. Li, et al. Filename : draft-ietf-ipsp-ipsecpib-10.txt Pages : 93 Date : 2004-4-6 This document describes a portion of the Policy Information Base (PIB) for a device implementing the IP Security Architecture. The provisioning classes defined here provide control of IPsec policy. These provisioning classes can be used with other non-IPsec provisioning classes (defined in other PIB modules) to provide for a comprehensive policy controlled mapping of service requirement to device capability and usage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsecpib-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsp-ipsecpib-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsp-ipsecpib-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-7110720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsp-ipsecpib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsp-ipsecpib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-7110720.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec-policy@mail.vpnc.org Thu Apr 8 13:17:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04211 for ; Thu, 8 Apr 2004 13:17:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38Gl9YO095616; Thu, 8 Apr 2004 09:47:09 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38Gl9TX095615; Thu, 8 Apr 2004 09:47:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38Gl86a095609 for ; Thu, 8 Apr 2004 09:47:08 -0700 (PDT) (envelope-from bwijnen@lucent.com) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38Gkjr23799 for ; Thu, 8 Apr 2004 11:46:51 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1690H29X>; Thu, 8 Apr 2004 18:01:20 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503FD6A34@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Man.M.Li@nokia.com, bwijnen@lucent.com Cc: smb@research.att.com, ho@alum.mit.edu, lsanchez@xapiens.com, avri@apocalypse.org, ipsec-policy@vpnc.org Subject: RE: TimePeriod (Was RE: MIB/PIB doctor review for draft-ietf-ipsp -ipsecpib-09.txt - part 2) Date: Thu, 8 Apr 2004 18:01:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Regarding this comment from Bert: > > "35.In fact, the whole TimePeriod... stuff seems so generic to any > policy, that I would think it would also be in a separate module > so that it can be re-used much easier. > In fact the RFC3060 (and possibly RFC3460) should be separate > modules that can be re-used by technology specific specifications > and/or modules. I thought that that was the whole concept/idea of > doing a PCIM and PCIMe. They would be CORE definitions upon which > technology specific definitions (like IPsec and QoS) could/would > build. Have we completely lost this idea/concept? " > > I agree with Bert that the TimePeriod is generic. If we > separate this to another PIB module, is the ipsp group (or > anywhere in IETF) willing to accommodate another PIB draft? > If not, I'll leave it inside IPsec PIB since in most cases > IPsec policy specification needs to be associated with time periods. > One possibility is to do the generic stuff as a separate PIB module in the same document! Bert > Best regards > Man > From owner-ipsec-policy@mail.vpnc.org Fri Apr 9 09:55:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27951 for ; Fri, 9 Apr 2004 09:55:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39DO9Np089668; Fri, 9 Apr 2004 06:24:09 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i39DO9tu089667; Fri, 9 Apr 2004 06:24:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from smtp8.clb.oleane.net (smtp8.clb.oleane.net [213.56.31.28]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39DO5QW089641 for ; Fri, 9 Apr 2004 06:24:08 -0700 (PDT) (envelope-from peter.lewis@upperside.fr) Received: from paviliondeux ([194.206.151.59]) by smtp8.clb.oleane.net with ESMTP id i39DNtWD000918 for ; Fri, 9 Apr 2004 15:24:00 +0200 Message-Id: <200404091324.i39DNtWD000918@smtp8.clb.oleane.net> From: "peter" To: Subject: SSL VPN Conference Date: Fri, 9 Apr 2004 15:24:01 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01C41E46.AF832CD0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQeNeuy8+SBp7WVTzC06ctJ4r5tig== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0087_01C41E46.AF832CD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit . How to provide SSL-based remote access to a broad range of Web and legacy applications? . What about application performance and requirements? . Are encrypted application tunneling issues solved? . What differences with IPsec VPNs? These questions, among others, will be tackled by the most recognised experts in this field during the SSL VPN Conference to be held in Paris from November 30th to the 3rd of December, 2004. A call for proposals is online at: http://www.upperside.fr/sslvpn04/sslvpn04intro.htm ------=_NextPart_000_0087_01C41E46.AF832CD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

• = How to = provide SSL-based remote access to a broad range of Web and   legacy = applications?
• What about application performance and requirements?
• Are encrypted = application tunneling issues solved?
• What differences with = IPsec VPNs?

These questions, among others, will be tackled by the most recognised = experts in this field during the SSL VPN = Conference to be held in Paris from November 30th to the 3rd of December, = 2004.

 

A call for proposals is online = at:

http://www.upperside.fr/sslvpn04/sslvpn04intro.htm

 

------=_NextPart_000_0087_01C41E46.AF832CD0-- From owner-ipsec-policy@mail.vpnc.org Thu Apr 15 13:37:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07911 for ; Thu, 15 Apr 2004 13:37:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FH93Oh079422; Thu, 15 Apr 2004 10:09:03 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3FH93QB079421; Thu, 15 Apr 2004 10:09:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from smtp.um.es (xenon2.um.es [155.54.212.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FH92WH079394 for ; Thu, 15 Apr 2004 10:09:03 -0700 (PDT) (envelope-from fgarcia@dif.um.es) Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id DAC2923D1 for ; Thu, 15 Apr 2004 19:08:57 +0200 (CEST) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id C497623C8 for ; Thu, 15 Apr 2004 19:08:57 +0200 (CEST) Received: from dif.um.es (alborada.dif.um.es [155.54.210.32]) by aries.dif.um.es (Postfix) with ESMTP id 1D54514435 for ; Thu, 15 Apr 2004 19:08:42 +0200 (MET DST) Message-ID: <407EC305.4C0F6695@dif.um.es> Date: Thu, 15 Apr 2004 19:14:45 +0200 From: "=?iso-8859-1?Q?F=E9lix?= J.=?iso-8859-1?Q?Garc=EDa?= Clemente" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-policy@vpnc.org Subject: IPSEC-PIB as mechanism for key distribution Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello all, IPSEC-PIB has several attributes to specify keys. The attribute ipSecXXTransformIntegrityKey specifies the integrity key to be used and the attribute ipSecEspTransformCipherKey specifies the cipher key to be used. And the attribute ipSecIkeAssociationPresharedKey contains the pre-shared key. It means that IPSEC-PIB is used to distribute keys, doesn't it?. I have noted that the keys don't have a specific class where can be defined (for example ipSecSharedSecret) and then they must be specified in other classes and it is not possible to reference them. Even the keys are transported by PIB in plaintext. Maybe an attribute similar to 'Algorithm' of the class CIM_SharedSecret may be useful to protect the keys. Maybe it can be interesting in a future draft. What do you think? Regards, Félix From owner-ipsec-policy@mail.vpnc.org Thu Apr 15 14:25:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10879 for ; Thu, 15 Apr 2004 14:25:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FI2QtR086919; Thu, 15 Apr 2004 11:02:26 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3FI2Q5b086918; Thu, 15 Apr 2004 11:02:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FI2OFt086893 for ; Thu, 15 Apr 2004 11:02:25 -0700 (PDT) (envelope-from Man.M.Li@nokia.com) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3FI2HH11675; Thu, 15 Apr 2004 21:02:17 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 21:01:39 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3FI1dDS001238; Thu, 15 Apr 2004 21:01:39 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00Ax6jVX; Thu, 15 Apr 2004 21:01:37 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3FI1bF17192; Thu, 15 Apr 2004 21:01:37 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 12:59:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPSEC-PIB as mechanism for key distribution Date: Thu, 15 Apr 2004 13:59:25 -0400 Message-ID: Thread-Topic: IPSEC-PIB as mechanism for key distribution Thread-Index: AcQjEbf6bj2zDJvXSYmtHuK1Rec1iQAAGdhA From: To: , X-OriginalArrivalTime: 15 Apr 2004 17:59:25.0676 (UTC) FILETIME=[63ABA2C0:01C42313] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3FI2QFt086897 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit You probably noticed that all the "key" attributes are optional. Hence, you don't have to use IPsec PIB to distribute keys. If you choose to distribute keys via IPsec PIB, you certainly need to secure the transport, i.e., COPS-PR protocol. These are discussed in the "security considerations" section. Best regards Man Li > -----Original Message----- > From: owner-ipsec-policy@mail.vpnc.org > [mailto:owner-ipsec-policy@mail.vpnc.org]On Behalf Of ext > Félix J.García > Clemente > Sent: Thursday, April 15, 2004 1:15 PM > To: ipsec-policy@vpnc.org > Subject: IPSEC-PIB as mechanism for key distribution > > > > > Hello all, > IPSEC-PIB has several attributes to specify keys. The attribute > ipSecXXTransformIntegrityKey specifies the integrity key to > be used and > the attribute ipSecEspTransformCipherKey specifies the cipher > key to be > used. And the attribute ipSecIkeAssociationPresharedKey contains the > pre-shared key. > It means that IPSEC-PIB is used to distribute keys, doesn't it?. > > I have noted that the keys don't have a specific class where can be > defined (for example ipSecSharedSecret) and then they must be > specified > in other classes and it is not possible to reference them. > Even the keys are transported by PIB in plaintext. Maybe an attribute > similar to 'Algorithm' of the class CIM_SharedSecret may be useful to > protect the keys. > Maybe it can be interesting in a future draft. What do you think? > > Regards, > Félix > > > > From owner-ipsec-policy@mail.vpnc.org Thu Apr 15 14:31:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11098 for ; Thu, 15 Apr 2004 14:31:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FI6l1g087509; Thu, 15 Apr 2004 11:06:47 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3FI6ljw087508; Thu, 15 Apr 2004 11:06:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FI6jHE087500 for ; Thu, 15 Apr 2004 11:06:46 -0700 (PDT) (envelope-from Man.M.Li@nokia.com) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3FI6mH16930; Thu, 15 Apr 2004 21:06:48 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 21:06:06 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3FI66NV008538; Thu, 15 Apr 2004 21:06:06 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00kfxp7Z; Thu, 15 Apr 2004 21:06:05 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3FI64F18890; Thu, 15 Apr 2004 21:06:04 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 13:06:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ipSecIfCapsTable not many attributes Date: Thu, 15 Apr 2004 14:06:00 -0400 Message-ID: Thread-Topic: ipSecIfCapsTable not many attributes Thread-Index: AcQbjQVhxCvqtWW/TFy24XTzfy3ziAHhmxPw From: To: , Cc: X-OriginalArrivalTime: 15 Apr 2004 18:06:01.0516 (UTC) FILETIME=[4F9C06C0:01C42314] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3FI6kHE087502 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I agree with Avri. The capability table inside IPsec PIB shall report things that are specific to IPsec PIB. In addition, the framework PIB frwkPrcSupportTable and frwkCompLimitsTable together can be used to indicate what kind of encryptions and algorithms are supported. Hence there seems to be no need to add on the ifSecIfCapsTable. Best regards Man Li > -----Original Message----- > From: owner-ipsec-policy@mail.vpnc.org > [mailto:owner-ipsec-policy@mail.vpnc.org]On Behalf Of ext avri@acm.org > Sent: Monday, April 05, 2004 11:40 PM > To: "Félix J.García Clemente" > Cc: ipsec-policy@vpnc.org > Subject: Re: ipSecIfCapsTable not many attributes > > > > > Hi, > > First let me say how glad I am to hear about another > implementation of > the PIB. > > My first issue is that since the ID has been through WG last call and > is currently in IESG review and MIB doctor review, I would > not like to > pull it back to add a major new capability for anything less then a > show stopper at this point. > > Further on the specific issue: > > While capabilities are important, the Framework PIB has comprehensive > capability mechanism, that should cover the requirements. > > thanks > > a. > > On 2 apr 2004, at 01.49, Félix J.García Clemente wrote: > > > > > Hello all, > > I am including a complete support for the Framework PIB and > the IPSec > > PIB in my own COPS-PR implementation. > > I have noted that IPSec PIB includes the table ipSecIfCapsTable to > > specify capabilities that may be associated with an interface. > > This table has not many attributes, are you going to add > new attributes > > or capability tables? > > > > I think this is necessary. For example, an interface may not support > > 'policy reload', i.e. to apply a policy forces to restart the > > interface, > > or even an attribute may specify the cryptography system supported > > (symmetric or asymmetric, or both). > > > > Regards, > > Félix > > > > > > > > > > > From owner-ipsec-policy@mail.vpnc.org Fri Apr 16 04:57:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24157 for ; Fri, 16 Apr 2004 04:57:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3G8X2wr098533; Fri, 16 Apr 2004 01:33:02 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3G8X2el098532; Fri, 16 Apr 2004 01:33:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from smtp.um.es (xenon2.um.es [155.54.212.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3G8X1mV098483 for ; Fri, 16 Apr 2004 01:33:02 -0700 (PDT) (envelope-from fgarcia@dif.um.es) Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 665733C6; Fri, 16 Apr 2004 10:32:56 +0200 (CEST) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id 4E35023F; Fri, 16 Apr 2004 10:32:56 +0200 (CEST) Received: from dif.um.es (alborada.dif.um.es [155.54.210.32]) by aries.dif.um.es (Postfix) with ESMTP id A171414435; Fri, 16 Apr 2004 10:32:39 +0200 (MET DST) Message-ID: <407F9B9C.A59B009@dif.um.es> Date: Fri, 16 Apr 2004 10:38:52 +0200 From: "=?iso-8859-1?Q?F=E9lix?= J.=?iso-8859-1?Q?Garc=EDa?= Clemente" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Man.M.Li@nokia.com Cc: ipsec-policy@vpnc.org Subject: Re: IPSEC-PIB as mechanism for key distribution References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, Man.M.Li@nokia.com wrote: > You probably noticed that all the "key" attributes are optional. Hence, you don't have to use IPsec PIB to distribute keys. Ok, but if IPsec PIB don't specify the keys, how can I know the keys to use? IPsec PIB cann't reference the keys. Do I must use a external mechanism to link the key with the PIB? > If you choose to distribute keys via IPsec PIB, you certainly need to secure the transport, i.e., COPS-PR protocol. These are discussed in the "security considerations" section. Ok, I need to secure the transport protocol (maybe IPsec or TLS) and then it means that I need distribute keys previously. In my opinion, I think the key distribution must be not permited in the IPsec PIB (neither as optional) and other mechanism has to be used to distribute keys (maybe other PIB or MIB). Regards, Félix > Best regards > Man Li > > > -----Original Message----- > > From: owner-ipsec-policy@mail.vpnc.org > > [mailto:owner-ipsec-policy@mail.vpnc.org]On Behalf Of ext > > Félix J.García > > Clemente > > Sent: Thursday, April 15, 2004 1:15 PM > > To: ipsec-policy@vpnc.org > > Subject: IPSEC-PIB as mechanism for key distribution > > > > > > > > > > Hello all, > > IPSEC-PIB has several attributes to specify keys. The attribute > > ipSecXXTransformIntegrityKey specifies the integrity key to > > be used and > > the attribute ipSecEspTransformCipherKey specifies the cipher > > key to be > > used. And the attribute ipSecIkeAssociationPresharedKey contains the > > pre-shared key. > > It means that IPSEC-PIB is used to distribute keys, doesn't it?. > > > > I have noted that the keys don't have a specific class where can be > > defined (for example ipSecSharedSecret) and then they must be > > specified > > in other classes and it is not possible to reference them. > > Even the keys are transported by PIB in plaintext. Maybe an attribute > > similar to 'Algorithm' of the class CIM_SharedSecret may be useful to > > protect the keys. > > Maybe it can be interesting in a future draft. What do you think? > > > > Regards, > > Félix > > > > > > > > From owner-ipsec-policy@mail.vpnc.org Fri Apr 16 05:15:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25069 for ; Fri, 16 Apr 2004 05:15:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3G8tvPX008716; Fri, 16 Apr 2004 01:55:57 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3G8tvxL008715; Fri, 16 Apr 2004 01:55:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from smtp.um.es (xenon2.um.es [155.54.212.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3G8tufK008667 for ; Fri, 16 Apr 2004 01:55:56 -0700 (PDT) (envelope-from fgarcia@dif.um.es) Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 6C7F7662; Fri, 16 Apr 2004 10:55:51 +0200 (CEST) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id 512102E5; Fri, 16 Apr 2004 10:55:51 +0200 (CEST) Received: from dif.um.es (alborada.dif.um.es [155.54.210.32]) by aries.dif.um.es (Postfix) with ESMTP id 3F40714435; Fri, 16 Apr 2004 10:55:35 +0200 (MET DST) Message-ID: <407FA0FF.CFBB4358@dif.um.es> Date: Fri, 16 Apr 2004 11:01:51 +0200 From: "=?iso-8859-1?Q?F=E9lix?= J.=?iso-8859-1?Q?Garc=EDa?= Clemente" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Man.M.Li@nokia.com, ipsec-policy@vpnc.org Subject: Re: ipSecIfCapsTable not many attributes References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello again, Man.M.Li@nokia.com wrote: > I agree with Avri. The capability table inside IPsec PIB shall report things that are specific to IPsec PIB. I agree with you. My worry is that currently the capability table inside IPsec PIB is very simple, I think that new attributes may report more information. > In addition, the framework PIB frwkPrcSupportTable and frwkCompLimitsTable together can be used to indicate what kind of encryptions and algorithms are supported. For example to indicate that only simmetric encryption is supported, in my opinion it seems more simple to add a new attribute in the capability table than to build several support and limits tables. Even I think this attribute may be more interesting as capability than as limit. Of course I can create my own capability tables extending the table ipSecIfCapsTable but it will be 'my' solution. Thanks for your explanation. Regards, Félix > Hence there seems to be no need to add on the ifSecIfCapsTable. > > Best regards > Man Li > > > -----Original Message----- > > From: owner-ipsec-policy@mail.vpnc.org > > [mailto:owner-ipsec-policy@mail.vpnc.org]On Behalf Of ext avri@acm.org > > Sent: Monday, April 05, 2004 11:40 PM > > To: "Félix J.García Clemente" > > Cc: ipsec-policy@vpnc.org > > Subject: Re: ipSecIfCapsTable not many attributes > > > > > > > > > > Hi, > > > > First let me say how glad I am to hear about another > > implementation of > > the PIB. > > > > My first issue is that since the ID has been through WG last call and > > is currently in IESG review and MIB doctor review, I would > > not like to > > pull it back to add a major new capability for anything less then a > > show stopper at this point. > > > > Further on the specific issue: > > > > While capabilities are important, the Framework PIB has comprehensive > > capability mechanism, that should cover the requirements. > > > > thanks > > > > a. > > > > On 2 apr 2004, at 01.49, Félix J.García Clemente wrote: > > > > > > > > Hello all, > > > I am including a complete support for the Framework PIB and > > the IPSec > > > PIB in my own COPS-PR implementation. > > > I have noted that IPSec PIB includes the table ipSecIfCapsTable to > > > specify capabilities that may be associated with an interface. > > > This table has not many attributes, are you going to add > > new attributes > > > or capability tables? > > > > > > I think this is necessary. For example, an interface may not support > > > 'policy reload', i.e. to apply a policy forces to restart the > > > interface, > > > or even an attribute may specify the cryptography system supported > > > (symmetric or asymmetric, or both). > > > > > > Regards, > > > Félix > > > > > > > > > > > > > > > > > > From owner-ipsec-policy@mail.vpnc.org Fri Apr 16 11:05:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14622 for ; Fri, 16 Apr 2004 11:05:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3GEgCL7069164; Fri, 16 Apr 2004 07:42:12 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3GEgC5a069163; Fri, 16 Apr 2004 07:42:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3GEg9CL069147 for ; Fri, 16 Apr 2004 07:42:10 -0700 (PDT) (envelope-from Man.M.Li@nokia.com) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3GEgBH17989; Fri, 16 Apr 2004 17:42:11 +0300 (EET DST) X-Scanned: Fri, 16 Apr 2004 17:40:21 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3GEeLaU011275; Fri, 16 Apr 2004 17:40:21 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00IXWEaz; Fri, 16 Apr 2004 17:40:20 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3GEeJF09878; Fri, 16 Apr 2004 17:40:20 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 16 Apr 2004 09:40:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPSEC-PIB as mechanism for key distribution Date: Fri, 16 Apr 2004 10:40:15 -0400 Message-ID: Thread-Topic: IPSEC-PIB as mechanism for key distribution Thread-Index: AcQjjt8Kw3SVROjUSl+UnE5gbrvELwAMXSdA From: To: Cc: X-OriginalArrivalTime: 16 Apr 2004 14:40:18.0545 (UTC) FILETIME=[BD09DE10:01C423C0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3GEgBCL069150 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > > > You probably noticed that all the "key" attributes are > optional. Hence, you don't have to use IPsec PIB to distribute keys. > > Ok, but if IPsec PIB don't specify the keys, how can I know > the keys to use? > IPsec PIB cann't reference the keys. Do I must use a external > mechanism to link the key with the PIB? Yes. > > > If you choose to distribute keys via IPsec PIB, you > certainly need to secure the transport, i.e., COPS-PR > protocol. These are discussed in the "security > considerations" section. > > Ok, I need to secure the transport protocol (maybe IPsec or > TLS) and then it means that I need distribute keys previously. > In my opinion, I think the key distribution must be not > permited in the IPsec PIB (neither as optional) and other > mechanism has to be used to distribute keys (maybe other PIB or MIB). Many other people have different opinions than yours and that's why we have the optional feature. > > Regards, > Félix > > > Best regards > > Man Li > > > > > -----Original Message----- > > > From: owner-ipsec-policy@mail.vpnc.org > > > [mailto:owner-ipsec-policy@mail.vpnc.org]On Behalf Of ext > > > Félix J.García > > > Clemente > > > Sent: Thursday, April 15, 2004 1:15 PM > > > To: ipsec-policy@vpnc.org > > > Subject: IPSEC-PIB as mechanism for key distribution > > > > > > > > > > > > > > > Hello all, > > > IPSEC-PIB has several attributes to specify keys. The attribute > > > ipSecXXTransformIntegrityKey specifies the integrity key to > > > be used and > > > the attribute ipSecEspTransformCipherKey specifies the cipher > > > key to be > > > used. And the attribute ipSecIkeAssociationPresharedKey > contains the > > > pre-shared key. > > > It means that IPSEC-PIB is used to distribute keys, doesn't it?. > > > > > > I have noted that the keys don't have a specific class > where can be > > > defined (for example ipSecSharedSecret) and then they must be > > > specified > > > in other classes and it is not possible to reference them. > > > Even the keys are transported by PIB in plaintext. Maybe > an attribute > > > similar to 'Algorithm' of the class CIM_SharedSecret may > be useful to > > > protect the keys. > > > Maybe it can be interesting in a future draft. What do you think? > > > > > > Regards, > > > Félix > > > > > > > > > > > > > > >