From owner-ipsec-policy@mail.vpnc.org Tue Nov 2 10:22:15 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 KAA00050 for ; Tue, 2 Nov 2004 10:22:14 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2EhbZ2048202; Tue, 2 Nov 2004 06:43:37 -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 iA2EhbAB048201; Tue, 2 Nov 2004 06:43:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from hoemail1.lucent.com (hoemail1.lucent.com [192.11.226.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2EhbfP048194 for ; Tue, 2 Nov 2004 06:43:37 -0800 (PST) (envelope-from bwijnen@lucent.com) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iA2EhbtK006456 for ; Tue, 2 Nov 2004 08:43:38 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <4M32Q2X3>; Tue, 2 Nov 2004 15:43:36 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79EA6@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Man.M.Li@nokia.com'" , ipsec-policy@vpnc.org Subject: RE: Deleting ipSecPolicyTimePeriod related classes from IPsec PIB Date: Tue, 2 Nov 2004 15:43:35 +0100 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: Thanks for pinging/reminding me. It seems that I last reviewed revision 9 ad that I should take a look at rev 10. Will put it on my todo list. Not sure I can get to it before the end of IETF61. Actaully I doubt I will be able to do so before Nov 15 or so. Pls ping me again around that time if I have not answered. Bert > -----Original Message----- > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > Sent: Wednesday, October 27, 2004 19:33 > To: bwijnen@lucent.com; ipsec-policy@vpnc.org > Subject: Deleting ipSecPolicyTimePeriod related classes from IPsec PIB > > > Hi Bert, > > In March, we received your comments on IPsec PIB and made > modifications accordingly. The only remaining issue is about > the ipSecPolicyTimePeriod classes. You and I discussed two > solutions and both seemed to have some drawback: > > Solution #1. Put the ipSecPolicyTImePeriod classes into a > separate module within the IPsec PIB document. The drawback > is that since the title of the draft is IPsec PIB, it should > not contain a separate module that is not IPsec related. > People will probably not look into this draft to find time > related PIB classes > > Solution #2. Put the ipSecPolicyTime Period classes into a > separate module in a separate IETF draft. The drawback is > that it seems to me that IETF does not want to entertain > another PIB draft. > > At the end of our April e-mail discussions, you were going to > check if the TimePeriod classes are the only ones that should > be separate from the IPsec PIB. I am now proposing another > simpler solution as follows. > > If, after checking the document, you also think that the > TimePeriod classes are the only ones that are not IPsec > specific, what about we delete the ipSecPolicyTimePeriod > classes from the IPsec PIB so that we can move on? > > If on the other hand, you think that there are other stuff > that are not IPsec specific, please let use know. Thanks. > > Best regards > Man Li > > From owner-ipsec-policy@mail.vpnc.org Sun Nov 7 11:56: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 LAA04319 for ; Sun, 7 Nov 2004 11:56:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7GHVIb025814; Sun, 7 Nov 2004 08:17:31 -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 iA7GHVkT025809; Sun, 7 Nov 2004 08:17:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7GHU7P025772 for ; Sun, 7 Nov 2004 08:17:30 -0800 (PST) (envelope-from bwijnen@lucent.com) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iA7GHOxi019009 for ; Sun, 7 Nov 2004 10:17:25 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <4M32TS5Q>; Sun, 7 Nov 2004 17:17:22 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15505A98559@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ipsec-policy@vpnc.org Subject: FW: note: the IPSP MIB -01 documents were posted Date: Sun, 7 Nov 2004 17:17:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In addition to the below (which I had forgotten to copy to WG list) I also saw: !! Missing citation for Normative reference: P062 L040: [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An !! Missing citation for Normative reference: P062 L046: [RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, !! Missing citation for Normative reference: P062 L052: [RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network !! Missing citation for Normative reference: P062 L057: [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model !! Missing citation for Normative reference: P062 L062: [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based C:\smi\pibs\ietf>smilint -l 6 -m -s -inamelength-32 ./IPSEC-SPD-MIB ./IPSEC-SPD-MIB:72: [2] {} Object identifier element `xxx' name only allowed as first element ./IPSEC-SPD-MIB:115: [5] {type-without-format} warning: type `SpdIPPacketLogging ' has no format specification Bert -----Original Message----- From: Wijnen, Bert (Bert) Sent: Monday, October 25, 2004 09:15 To: 'Wes Hardaker'; Wijnen, Bert (Bert) Subject: RE: note: the IPSP MIB -01 documents were posted SMICng tells me: W: f(spd.mi2), (67,21) The first revision should match the last update for MODULE-IDENTITY spdMIB Yopu may want to check some otehr dates/timestanmps as well E: f(spd.mi2), (215,4) Item "spdEndGroupDirection" has invalid value for MAX-ACCESS E: f(spd.mi2), (879,4) Item "spdTrueFilter" must not have items registered below it W: f(spd.mi2), (2086,20) Item "spdPacketPart" should have SIZE specified W: f(spd.mi2), (115,4) Textual convention "SpdIPPacketLogging" defined but not used *** 2 errors and 3 warnings in parsing Sect 4.1.2 is using net 10 addresses as examples. Pls see RFC3330 for IP addresses to be used in examples. I.e. they should be in 192.0.2.0/24 I see IPSec at some places. I kniow that at least one of the SEC ADs wants it to be IPsec!! Sect 4.1.2 I see spdEndGroupRowStatus = 5) -- createAndGo Mmm... I though that createAndGo is 4!! spdIncomingPolicyGroupName is read-write but I see not explanantion w.r.t. the persistence behaviour spdEndGroupStorageType Description clause MUST (according to RFC2579) explain which columns must be writable for permanent rows! same for other StorageType objects spdEndGroupIdentType DESCRIPTION clause says: Values of unknown, ipv4z, ipv6z and dns are not legal values for this object." I would like to see that represented in the MODULE-COMPLIANCE. It even seem you only allow ipv4 and ipv6 given the size constraint in the InetAddress itself. The above is just a very very quick scan at the beginning of the document. I'll see if I can find a MIB doctor for detailed review. Bert > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > Sent: Friday, October 22, 2004 21:37 > To: Bert Wijnen > Subject: note: the IPSP MIB -01 documents were posted > > > > subject says it all > -- > Wes Hardaker > Sparta > From owner-ipsec-policy@mail.vpnc.org Sun Nov 7 11:57:57 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 LAA04478 for ; Sun, 7 Nov 2004 11:57:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7GHYZK025844; Sun, 7 Nov 2004 08:17:34 -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 iA7GHYaD025843; Sun, 7 Nov 2004 08:17:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7GHYm5025787 for ; Sun, 7 Nov 2004 08:17:34 -0800 (PST) (envelope-from bwijnen@lucent.com) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iA7GHRp7019060 for ; Sun, 7 Nov 2004 10:17:30 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <4M32TS5X>; Sun, 7 Nov 2004 17:17:22 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15505A9855A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Man.M.Li@nokia.com'" , "'ipsec-policy@vpnc.org'" Subject: RE: Deleting ipSecPolicyTimePeriod related classes from IPsec PIB Date: Sun, 7 Nov 2004 17:17:22 +0100 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: I started to look at thos document again. But this is a very looong document, so I see no way to finsih my review before end of IETF61 week. W.r.t. the TimePeriod, I see your TC and I also see pmSchedTimePeriod in the pm-mib (an approved document now in RFC-Editor queue): draft-ietf-snmpconf-pm-14.txt They are using a PmUTF8string (their own TC). They also have a size limited (0..31) while you use unlimited length (even though your DISPLAY-HINT seems to limit it to 255. Similar concern for yout TimeOfDayTC. And then I need to check how much similarities or differences there are with the other time/schedule related TCs. I wonder, would you not be able to just use some of the tables of the PM-MIB? Has anyone every looked at that? Bert > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: Tuesday, November 02, 2004 09:44 > To: 'Man.M.Li@nokia.com'; ipsec-policy@vpnc.org > Subject: RE: Deleting ipSecPolicyTimePeriod related classes from IPsec > PIB > > > Thanks for pinging/reminding me. > > It seems that I last reviewed revision 9 ad that I should take > a look at rev 10. Will put it on my todo list. > Not sure I can get to it before the end of IETF61. > Actaully I doubt I will be able to do so before Nov 15 or so. > Pls ping me again around that time if I have not answered. > > Bert > > > -----Original Message----- > > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > > Sent: Wednesday, October 27, 2004 19:33 > > To: bwijnen@lucent.com; ipsec-policy@vpnc.org > > Subject: Deleting ipSecPolicyTimePeriod related classes > from IPsec PIB > > > > > > Hi Bert, > > > > In March, we received your comments on IPsec PIB and made > > modifications accordingly. The only remaining issue is about > > the ipSecPolicyTimePeriod classes. You and I discussed two > > solutions and both seemed to have some drawback: > > > > Solution #1. Put the ipSecPolicyTImePeriod classes into a > > separate module within the IPsec PIB document. The drawback > > is that since the title of the draft is IPsec PIB, it should > > not contain a separate module that is not IPsec related. > > People will probably not look into this draft to find time > > related PIB classes > > > > Solution #2. Put the ipSecPolicyTime Period classes into a > > separate module in a separate IETF draft. The drawback is > > that it seems to me that IETF does not want to entertain > > another PIB draft. > > > > At the end of our April e-mail discussions, you were going to > > check if the TimePeriod classes are the only ones that should > > be separate from the IPsec PIB. I am now proposing another > > simpler solution as follows. > > > > If, after checking the document, you also think that the > > TimePeriod classes are the only ones that are not IPsec > > specific, what about we delete the ipSecPolicyTimePeriod > > classes from the IPsec PIB so that we can move on? > > > > If on the other hand, you think that there are other stuff > > that are not IPsec specific, please let use know. Thanks. > > > > Best regards > > Man Li > > > > > From owner-ipsec-policy@mail.vpnc.org Sun Nov 7 12:45:48 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 LAA04318 for ; Sun, 7 Nov 2004 11:56:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7GHb8h025866; Sun, 7 Nov 2004 08:17:37 -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 iA7GHb7S025865; Sun, 7 Nov 2004 08:17:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7GHWaM025776 for ; Sun, 7 Nov 2004 08:17:32 -0800 (PST) (envelope-from bwijnen@lucent.com) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iA7GHRp6019060 for ; Sun, 7 Nov 2004 10:17:28 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <4M32TS5V>; Sun, 7 Nov 2004 17:17:22 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15505A98558@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: baerm@tislabs.com, rcharlet@alumni.calpoly.edu, hardaker@tislabs.com, ipsp-mib@revelstone.com, cliffwang2000@yahoo.com Cc: ipsec-policy@vpnc.org Subject: IPSEC-IPSEC-ACTION-MIB Date: Sun, 7 Nov 2004 17:17:21 +0100 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: [pls forward to ipsp WG I happened to be looking at (since I was checking IPsec PIB) IPSEC-IPSECACTION-MIB. (IPSEC-IKEACTION-MIB may have similar concerns, did not check so much, but pls do check yourself). And I see: ipsaPeerIdAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The property PeerAddress specifies the IP address of the peer. The format is specified by the ipsaPeerIdAddressType. Values of unknown, ipv4z, ipv6z and dns are not legal values for this object." Such "not legal" things MUST be specified in the MODULE-COMPLIANCE with OBJECT ipsaPeerIdAddressType SYNTAX InetAddressType { ipv4(x), ipv6(y) } DESCRIPTION "No need to support values unknown, ipv4z, ipv6z and dns because they are legal values for this object." Pls fill out the x and y At the same time you can then restrict the SIZE for the InetAddress (if you want to (also in the MODULE-COMPLIANCE) For StorageType objects (like ipsaSaPreActStorageType), you MUST specify which of the columns MUST be writable for permanent rows. See the STorageType TC in RFC2579 that explains/prescribes this MODULE assignments like ::= { spdActions 1 } are not good. (see MIB review guidelines about that. It will be difficult to keep track as to which ones have been assigned and which ones have not. We have been burnt in the past. Why not just allocate under mib-2 ? Tool smilint tells me: C:\smi\pibs\ietf>smilint -l 6 -m -s -inamelength-32 ./IPSEC-IPSECACTION-MIB ./IPSEC-IPSECACTION-MIB:97: [5] {type-without-format} warning: type `IpsecDoiEnc apsulationMode' has no format specification ./IPSEC-IPSECACTION-MIB:117: [5] {type-without-format} warning: type `IpsecDoiIp compTransform' has no format specification ./IPSEC-IPSECACTION-MIB:147: [5] {type-without-format} warning: type `IpsecDoiAu thAlgorithm' has no format specification ./IPSEC-IPSECACTION-MIB:185: [5] {type-without-format} warning: type `IpsecDoiEs pTransform' has no format specification ./IPSEC-IPSECACTION-MIB:228: [5] {type-without-format} warning: type `IpsecDoiId entType' has no format specification These are only warnings, but you may want to check it anyway,. I believe it is caused by a missing DISPLAY-HINT Various of your objects would be improved if you added a UNITS clause. This sentence (on page 39) seems copied from another MIB document Therefore, when configuring data in the IPSEC-SPD-MIB, you SHOULD use SNMP version 3. The rest of this discussion assumes the use of SNMPv3. This is a real strength, because it allows administrators That is OK, but I guess you want to at least use the name of your MIB module, no? I see no IANA COnsiderations section. This is mandatory these days (quite a while already). I think that the prose to explain this MIB module (i.e. sect 3 and 4 is pretty meager. You may want to expand somewhat on that, This is not a final review by a long shot. Just some quick remarks after a very quick and cursory browse. You may also want to check *** matchref -- match citations and references. Input file: draft-ietf-ipsp-ipsecaction-mib-01.txt !! Missing citation for Normative reference: P041 L043: [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An !! Missing citation for Normative reference: P041 L049: [RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, !! Missing citation for Normative reference: P041 L055: [RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network !! Missing citation for Normative reference: P041 L060: [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model !! Missing citation for Normative reference: P042 L006: [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based ~ Bert From owner-ipsec-policy@mail.vpnc.org Mon Nov 8 17:38:48 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 RAA11388 for ; Mon, 8 Nov 2004 17:38:48 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8M22EK025541; Mon, 8 Nov 2004 14:02:02 -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 iA8M227f025540; Mon, 8 Nov 2004 14:02:02 -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.9) with ESMTP id iA8M1u7x025486 for ; Mon, 8 Nov 2004 14:01:57 -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 iA8M1vv25890; Tue, 9 Nov 2004 00:01:57 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 23:58:36 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iA8LwabN028680; Mon, 8 Nov 2004 23:58:36 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00DQaJD4; Mon, 08 Nov 2004 23:58:34 EET 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 iA8LwXS14965; Mon, 8 Nov 2004 23:58:33 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 15:58:08 -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: RE: Deleting ipSecPolicyTimePeriod related classes from IPsec PIB Date: Mon, 8 Nov 2004 16:58:08 -0500 Message-ID: Thread-Topic: Deleting ipSecPolicyTimePeriod related classes from IPsec PIB Thread-Index: AcTE548cIVXymitIRy6IXGL3a7kkJgA9buBQ From: To: , X-OriginalArrivalTime: 08 Nov 2004 21:58:08.0947 (UTC) FILETIME=[08839830:01C4C5DE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA8M1v7x025514 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Bert, You have a good point about TimePeriod in PM-MIB. By now, you have convinced me that the time period classes should not be in IPsec PIB. Hence if there is no objection from you and the group, I would suggest to delete them from IPsec PIB. IPsec PIB will be just like Diffserv PIB in the sense that it focuses on config a specific policy and it contains neither time period information nor any reference to time period. Please let us know if you think otherwise. We also look forward to hearing your further comments on the draft. Thanks Best regards Man > -----Original Message----- > From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Sunday, November 07, 2004 11:17 AM > To: Li Man.M (Nokia-NRC/Boston); 'ipsec-policy@vpnc.org' > Subject: RE: Deleting ipSecPolicyTimePeriod related classes from IPsec > PIB > > > I started to look at thos document again. > But this is a very looong document, so I see no way to finsih > my review before end of IETF61 week. > > W.r.t. the TimePeriod, I see your TC and I also see > pmSchedTimePeriod in the pm-mib (an approved document > now in RFC-Editor queue): draft-ietf-snmpconf-pm-14.txt > They are using a PmUTF8string (their own TC). > They also have a size limited (0..31) while you use > unlimited length (even though your DISPLAY-HINT seems to > limit it to 255. > > Similar concern for yout TimeOfDayTC. > > And then I need to check how much similarities or differences > there are with the other time/schedule related TCs. > > I wonder, would you not be able to just use some of the > tables of the PM-MIB? > Has anyone every looked at that? > > Bert > > > -----Original Message----- > > From: Wijnen, Bert (Bert) > > Sent: Tuesday, November 02, 2004 09:44 > > To: 'Man.M.Li@nokia.com'; ipsec-policy@vpnc.org > > Subject: RE: Deleting ipSecPolicyTimePeriod related classes > from IPsec > > PIB > > > > > > Thanks for pinging/reminding me. > > > > It seems that I last reviewed revision 9 ad that I should take > > a look at rev 10. Will put it on my todo list. > > Not sure I can get to it before the end of IETF61. > > Actaully I doubt I will be able to do so before Nov 15 or so. > > Pls ping me again around that time if I have not answered. > > > > Bert > > > > > -----Original Message----- > > > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > > > Sent: Wednesday, October 27, 2004 19:33 > > > To: bwijnen@lucent.com; ipsec-policy@vpnc.org > > > Subject: Deleting ipSecPolicyTimePeriod related classes > > from IPsec PIB > > > > > > > > > Hi Bert, > > > > > > In March, we received your comments on IPsec PIB and made > > > modifications accordingly. The only remaining issue is about > > > the ipSecPolicyTimePeriod classes. You and I discussed two > > > solutions and both seemed to have some drawback: > > > > > > Solution #1. Put the ipSecPolicyTImePeriod classes into a > > > separate module within the IPsec PIB document. The drawback > > > is that since the title of the draft is IPsec PIB, it should > > > not contain a separate module that is not IPsec related. > > > People will probably not look into this draft to find time > > > related PIB classes > > > > > > Solution #2. Put the ipSecPolicyTime Period classes into a > > > separate module in a separate IETF draft. The drawback is > > > that it seems to me that IETF does not want to entertain > > > another PIB draft. > > > > > > At the end of our April e-mail discussions, you were going to > > > check if the TimePeriod classes are the only ones that should > > > be separate from the IPsec PIB. I am now proposing another > > > simpler solution as follows. > > > > > > If, after checking the document, you also think that the > > > TimePeriod classes are the only ones that are not IPsec > > > specific, what about we delete the ipSecPolicyTimePeriod > > > classes from the IPsec PIB so that we can move on? > > > > > > If on the other hand, you think that there are other stuff > > > that are not IPsec specific, please let use know. Thanks. > > > > > > Best regards > > > Man Li > > > > > > > > > From owner-ipsec-policy@mail.vpnc.org Thu Nov 11 17:32:48 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 RAA06940 for ; Thu, 11 Nov 2004 17:32:47 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABLs3pj027136; Thu, 11 Nov 2004 13:54:03 -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 iABLs3Pc027135; Thu, 11 Nov 2004 13:54:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [205.150.200.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABLrOka026913 for ; Thu, 11 Nov 2004 13:53:33 -0800 (PST) (envelope-from mcr@sandelman.ottawa.on.ca) Received: from road.marajade.sandelman.ca ([130.129.133.170]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id iABLrAu20331 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Thu, 11 Nov 2004 16:53:11 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by road.marajade.sandelman.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id iABLr943002153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Nov 2004 16:53:09 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id iABLr6sx002147; Thu, 11 Nov 2004 16:53:07 -0500 To: Yacine.El_Mghazli@alcatel.fr cc: ipsec-policy@vpnc.org, Michael Baer , hardaker@tislabs.com, rs-snmp@revelstone.com, cliffwang2000@yahoo.com, Julien Bournelle , Yoshihiro Ohba Subject: Re: IPSP MIBs usage review needed In-Reply-To: Message from Yacine.El_Mghazli@alcatel.fr of "Tue, 28 Sep 2004 17:41:54 +0200." <41598642.2080405@alcatel.fr> References: <40B1B345.6000208@alcatel.fr> <40F2BB06.7050807@alcatel.fr> <41598642.2080405@alcatel.fr> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 11 Nov 2004 16:53:06 -0500 Message-ID: <2146.1100209986@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- I had a long talk with Wes Hardaker about the IPSP MIB. My understanding was that it simply can not progress, because the requirement that it use the DTMF object model conflicts with MIB doctor review that suggests that the MIB should be far simpler. Someone will need to make a decision so that this MIB can progress. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQZPfQYqHRg3pndX9AQEZzgP9ElEi7jo0CEIv0dNgxBlcHKYzIDLHtUDA qWdFxT4wMENggC66xXa/+BBhXNq80qmWHL0YVpJUhFk68B+r/EcOuiGoP5kFuhay IE8c+taNVCpkl4/jPZqMEr1e+E+2QRM8cWqDYavUi8KzeMRSGMS2vgh/ccb2mDmQ KzuiE+rHeLc= =xLQi -----END PGP SIGNATURE----- From owner-ipsec-policy@mail.vpnc.org Fri Nov 12 02:39:44 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 CAA07168 for ; Fri, 12 Nov 2004 02:39:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAC77ARX066847; Thu, 11 Nov 2004 23:07:10 -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 iAC77A1W066846; Thu, 11 Nov 2004 23:07:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from mail.rfburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAC76r3h066560 for ; Thu, 11 Nov 2004 23:06:53 -0800 (PST) (envelope-from ho@alum.mit.edu) Received: from tobermory.localdomain ([66.119.143.202]) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id iAC72asv014914; Fri, 12 Nov 2004 00:02:36 -0700 Received: from tobermory.localdomain (localhost [127.0.0.1]) by tobermory.localdomain (8.12.10/8.11.6) with ESMTP id iAC74Nal006253; Fri, 12 Nov 2004 00:04:23 -0700 Received: (from ho@localhost) by tobermory.localdomain (8.12.10/8.12.10/Submit) id iAC74Mq8006249; Fri, 12 Nov 2004 00:04:22 -0700 Date: Fri, 12 Nov 2004 00:04:22 -0700 Message-Id: <200411120704.iAC74Mq8006249@tobermory.localdomain> From: "The Purple Streak, Hilarie Orman" To: mcr@sandelman.ottawa.on.ca Cc: Yacine.El_Mghazli@alcatel.fr, yohba@tari.toshiba.com, Julien.Bournelle@int-evry.fr, cliffwang2000@yahoo.com, rs-snmp@revelstone.com, hardaker@tislabs.com, baerm@sparta.com, ipsec-policy@vpnc.org In-reply-to: Yourmessage <2146.1100209986@marajade.sandelman.ottawa.on.ca> X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu Subject: Re: IPSP MIBs usage review needed Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We dealt with this for the PIB, and for most issues, reference to the DMTF OM was sufficient explanation to satisfy the reviewers. Hilarie From owner-ipsec-policy@mail.vpnc.org Fri Nov 12 10:11: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 KAA10237 for ; Fri, 12 Nov 2004 10:11:02 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACEcNr6026817; Fri, 12 Nov 2004 06:38:23 -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 iACEcMP7026816; Fri, 12 Nov 2004 06:38:23 -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 ([130.129.134.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACEcMb1026810 for ; Fri, 12 Nov 2004 06:38:22 -0800 (PST) (envelope-from hardaker@tislabs.com) Received: by wes.hardakers.net (Postfix, from userid 274) id 350DF11D9A9; Fri, 12 Nov 2004 06:38:44 -0800 (PST) To: Yacine.El_Mghazli@alcatel.fr Cc: ipsec-policy@vpnc.org, Michael Baer , rs-snmp@revelstone.com, cliffwang2000@yahoo.com, Julien Bournelle , Yoshihiro Ohba Subject: Re: IPSP MIBs usage review needed References: <40B1B345.6000208@alcatel.fr> <40F2BB06.7050807@alcatel.fr> <41598642.2080405@alcatel.fr> From: Wes Hardaker Organization: Sparta Date: Fri, 12 Nov 2004 06:38:44 -0800 In-Reply-To: <41598642.2080405@alcatel.fr> (Yacine's message of "Tue, 28 Sep 2004 17:41:54 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, 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 Tue, 28 Sep 2004 17:41:54 +0200, Yacine.El_Mghazli@alcatel.fr said: Yacine> our document in the PANA WG proposes to re-use the IPSP MIBs Yacine> in the PANA framework for authorization features. we need Yacine> people from this group to review the usage example in our I-D Yacine> (section 6, page 16): Yacine> Yacine> http://www.ietf.org/internet-drafts/draft-ietf-pana-snmp-01.txt Hi, and sorry for the delay. I told the PANA working group that I (or one of the authors) will read the PANA MIB and review it for you to check its usage of the IPSP MIBs. -- Wes Hardaker Sparta From owner-ipsec-policy@mail.vpnc.org Sat Nov 13 23:46:35 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 XAA25111 for ; Sat, 13 Nov 2004 23:46:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAE49oTx011762; Sat, 13 Nov 2004 20:09:50 -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 iAE49ohE011761; Sat, 13 Nov 2004 20:09:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from hoemail1.lucent.com (hoemail1.lucent.com [192.11.226.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAE49oo7011755 for ; Sat, 13 Nov 2004 20:09:50 -0800 (PST) (envelope-from bwijnen@lucent.com) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iAE49slU003752 for ; Sat, 13 Nov 2004 22:09:55 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <4M32YSCK>; Sun, 14 Nov 2004 05:09:53 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15505A98F55@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Man.M.Li@nokia.com, bwijnen@lucent.com, ipsec-policy@vpnc.org Subject: RE: Deleting ipSecPolicyTimePeriod related classes from IPsec PIB Date: Sun, 14 Nov 2004 05:09:50 +0100 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: Inline > -----Original Message----- > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > Sent: Monday, November 08, 2004 16:58 > To: bwijnen@lucent.com; ipsec-policy@vpnc.org > Subject: RE: Deleting ipSecPolicyTimePeriod related classes from IPsec > PIB > > > Hi Bert, > > You have a good point about TimePeriod in PM-MIB. By now, you > have convinced me that the time period classes should not be > in IPsec PIB. Hence if there is no objection from you and the > group, I would suggest to delete them from IPsec PIB. IPsec > PIB will be just like Diffserv PIB in the sense that it > focuses on config a specific policy and it contains neither > time period information nor any reference to time period. > ANd so, I guess people who need such classes then use them from the MIB, right? > Please let us know if you think otherwise. We also look > forward to hearing your further comments on the draft. Thanks > I know I am (too) slow on this. But it is a 75 page PIB definition. Not a quick read. I am on the road this coming week. Will try to give this doc some attention in week of 22 nov. By the way, the issue on what is generic and what is technology specific is something you can find out if you study the Policy WG documents. I will have to do same if I am to give you my advise and my opinions. Bert > Best regards > Man > > > -----Original Message----- > > From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Sunday, November 07, 2004 11:17 AM > > To: Li Man.M (Nokia-NRC/Boston); 'ipsec-policy@vpnc.org' > > Subject: RE: Deleting ipSecPolicyTimePeriod related classes > from IPsec > > PIB > > > > > > I started to look at thos document again. > > But this is a very looong document, so I see no way to finsih > > my review before end of IETF61 week. > > > > W.r.t. the TimePeriod, I see your TC and I also see > > pmSchedTimePeriod in the pm-mib (an approved document > > now in RFC-Editor queue): draft-ietf-snmpconf-pm-14.txt > > They are using a PmUTF8string (their own TC). > > They also have a size limited (0..31) while you use > > unlimited length (even though your DISPLAY-HINT seems to > > limit it to 255. > > > > Similar concern for yout TimeOfDayTC. > > > > And then I need to check how much similarities or differences > > there are with the other time/schedule related TCs. > > > > I wonder, would you not be able to just use some of the > > tables of the PM-MIB? > > Has anyone every looked at that? > > > > Bert > > > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) > > > Sent: Tuesday, November 02, 2004 09:44 > > > To: 'Man.M.Li@nokia.com'; ipsec-policy@vpnc.org > > > Subject: RE: Deleting ipSecPolicyTimePeriod related classes > > from IPsec > > > PIB > > > > > > > > > Thanks for pinging/reminding me. > > > > > > It seems that I last reviewed revision 9 ad that I should take > > > a look at rev 10. Will put it on my todo list. > > > Not sure I can get to it before the end of IETF61. > > > Actaully I doubt I will be able to do so before Nov 15 or so. > > > Pls ping me again around that time if I have not answered. > > > > > > Bert > > > > > > > -----Original Message----- > > > > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > > > > Sent: Wednesday, October 27, 2004 19:33 > > > > To: bwijnen@lucent.com; ipsec-policy@vpnc.org > > > > Subject: Deleting ipSecPolicyTimePeriod related classes > > > from IPsec PIB > > > > > > > > > > > > Hi Bert, > > > > > > > > In March, we received your comments on IPsec PIB and made > > > > modifications accordingly. The only remaining issue is about > > > > the ipSecPolicyTimePeriod classes. You and I discussed two > > > > solutions and both seemed to have some drawback: > > > > > > > > Solution #1. Put the ipSecPolicyTImePeriod classes into a > > > > separate module within the IPsec PIB document. The drawback > > > > is that since the title of the draft is IPsec PIB, it should > > > > not contain a separate module that is not IPsec related. > > > > People will probably not look into this draft to find time > > > > related PIB classes > > > > > > > > Solution #2. Put the ipSecPolicyTime Period classes into a > > > > separate module in a separate IETF draft. The drawback is > > > > that it seems to me that IETF does not want to entertain > > > > another PIB draft. > > > > > > > > At the end of our April e-mail discussions, you were going to > > > > check if the TimePeriod classes are the only ones that should > > > > be separate from the IPsec PIB. I am now proposing another > > > > simpler solution as follows. > > > > > > > > If, after checking the document, you also think that the > > > > TimePeriod classes are the only ones that are not IPsec > > > > specific, what about we delete the ipSecPolicyTimePeriod > > > > classes from the IPsec PIB so that we can move on? > > > > > > > > If on the other hand, you think that there are other stuff > > > > that are not IPsec specific, please let use know. Thanks. > > > > > > > > Best regards > > > > Man Li > > > > > > > > > > > > > > From owner-ipsec-policy@mail.vpnc.org Mon Nov 15 15:08:43 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 PAA26900 for ; Mon, 15 Nov 2004 15:08:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFJW4U5084029; Mon, 15 Nov 2004 11:32:04 -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 iAFJW4Yq084028; Mon, 15 Nov 2004 11:32:04 -0800 (PST) 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.9) with ESMTP id iAFJW2ki084022 for ; Mon, 15 Nov 2004 11:32:03 -0800 (PST) (envelope-from Man.M.Li@nokia.com) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAFJW3F23188; Mon, 15 Nov 2004 21:32:04 +0200 (EET) X-Scanned: Mon, 15 Nov 2004 21:29:24 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iAFJTOLI027170; Mon, 15 Nov 2004 21:29:24 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00tG3gd5; Mon, 15 Nov 2004 21:29:23 EET 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 iAFJTLa18949; Mon, 15 Nov 2004 21:29:21 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 15 Nov 2004 13:29:20 -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: RE: Deleting ipSecPolicyTimePeriod related classes from IPsec PIB Date: Mon, 15 Nov 2004 14:29:16 -0500 Message-ID: Thread-Topic: Deleting ipSecPolicyTimePeriod related classes from IPsec PIB Thread-Index: AcTJ/+6rdM4hqgSNSCmEV4bxLvGmmABSDUrQ From: To: , X-OriginalArrivalTime: 15 Nov 2004 19:29:20.0640 (UTC) FILETIME=[67B85000:01C4CB49] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAFJW3ki084023 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Please see inline. > > -----Original Message----- > > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > > Sent: Monday, November 08, 2004 16:58 > > To: bwijnen@lucent.com; ipsec-policy@vpnc.org > > Subject: RE: Deleting ipSecPolicyTimePeriod related classes > from IPsec > > PIB > > > > > > Hi Bert, > > > > You have a good point about TimePeriod in PM-MIB. By now, you > > have convinced me that the time period classes should not be > > in IPsec PIB. Hence if there is no objection from you and the > > group, I would suggest to delete them from IPsec PIB. IPsec > > PIB will be just like Diffserv PIB in the sense that it > > focuses on config a specific policy and it contains neither > > time period information nor any reference to time period. > > > ANd so, I guess people who need such classes then use them > from the MIB, right? Ideally, if there is a separate time period PIB module document or if the time period is inside the framework PIB, a simple reference to them will do. Since neither is possible now, people have to look for other approaches available in their specific environment. > > > Please let us know if you think otherwise. We also look > > forward to hearing your further comments on the draft. Thanks > > > > I know I am (too) slow on this. > But it is a 75 page PIB definition. Not a quick read. > I am on the road this coming week. > Will try to give this doc some attention in week of 22 nov. > > By the way, the issue on what is generic and what is technology > specific is something you can find out if you study the Policy WG > documents. I will have to do same if I am to give you my advise > and my opinions. I looked through RFC 3060, 3460 and 3703 and it seems to me that time period is the only thing in the IPsec PIB that is in 3060 and hence is generic. All other stuff in the IPsec PIB is in RFC 3585 (IPsec config information model) and is hence specific to IPsec. It is possible that my interpretation is not totally correct and if that is the case, please let me know. > > Bert > > > Best regards > > Man > > > > > -----Original Message----- > > > From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > Sent: Sunday, November 07, 2004 11:17 AM > > > To: Li Man.M (Nokia-NRC/Boston); 'ipsec-policy@vpnc.org' > > > Subject: RE: Deleting ipSecPolicyTimePeriod related classes > > from IPsec > > > PIB > > > > > > > > > I started to look at thos document again. > > > But this is a very looong document, so I see no way to finsih > > > my review before end of IETF61 week. > > > > > > W.r.t. the TimePeriod, I see your TC and I also see > > > pmSchedTimePeriod in the pm-mib (an approved document > > > now in RFC-Editor queue): draft-ietf-snmpconf-pm-14.txt > > > They are using a PmUTF8string (their own TC). > > > They also have a size limited (0..31) while you use > > > unlimited length (even though your DISPLAY-HINT seems to > > > limit it to 255. > > > > > > Similar concern for yout TimeOfDayTC. > > > > > > And then I need to check how much similarities or differences > > > there are with the other time/schedule related TCs. > > > > > > I wonder, would you not be able to just use some of the > > > tables of the PM-MIB? > > > Has anyone every looked at that? > > > > > > Bert > > > > > > > -----Original Message----- > > > > From: Wijnen, Bert (Bert) > > > > Sent: Tuesday, November 02, 2004 09:44 > > > > To: 'Man.M.Li@nokia.com'; ipsec-policy@vpnc.org > > > > Subject: RE: Deleting ipSecPolicyTimePeriod related classes > > > from IPsec > > > > PIB > > > > > > > > > > > > Thanks for pinging/reminding me. > > > > > > > > It seems that I last reviewed revision 9 ad that I should take > > > > a look at rev 10. Will put it on my todo list. > > > > Not sure I can get to it before the end of IETF61. > > > > Actaully I doubt I will be able to do so before Nov 15 or so. > > > > Pls ping me again around that time if I have not answered. > > > > > > > > Bert > > > > > > > > > -----Original Message----- > > > > > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > > > > > Sent: Wednesday, October 27, 2004 19:33 > > > > > To: bwijnen@lucent.com; ipsec-policy@vpnc.org > > > > > Subject: Deleting ipSecPolicyTimePeriod related classes > > > > from IPsec PIB > > > > > > > > > > > > > > > Hi Bert, > > > > > > > > > > In March, we received your comments on IPsec PIB and made > > > > > modifications accordingly. The only remaining issue is about > > > > > the ipSecPolicyTimePeriod classes. You and I discussed two > > > > > solutions and both seemed to have some drawback: > > > > > > > > > > Solution #1. Put the ipSecPolicyTImePeriod classes into a > > > > > separate module within the IPsec PIB document. The drawback > > > > > is that since the title of the draft is IPsec PIB, it should > > > > > not contain a separate module that is not IPsec related. > > > > > People will probably not look into this draft to find time > > > > > related PIB classes > > > > > > > > > > Solution #2. Put the ipSecPolicyTime Period classes into a > > > > > separate module in a separate IETF draft. The drawback is > > > > > that it seems to me that IETF does not want to entertain > > > > > another PIB draft. > > > > > > > > > > At the end of our April e-mail discussions, you were going to > > > > > check if the TimePeriod classes are the only ones that should > > > > > be separate from the IPsec PIB. I am now proposing another > > > > > simpler solution as follows. > > > > > > > > > > If, after checking the document, you also think that the > > > > > TimePeriod classes are the only ones that are not IPsec > > > > > specific, what about we delete the ipSecPolicyTimePeriod > > > > > classes from the IPsec PIB so that we can move on? > > > > > > > > > > If on the other hand, you think that there are other stuff > > > > > that are not IPsec specific, please let use know. Thanks. > > > > > > > > > > Best regards > > > > > Man Li > > > > > > > > > > > > > > > > > > > > From owner-ipsec-policy@mail.vpnc.org Thu Nov 18 14:45:23 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 OAA25849 for ; Thu, 18 Nov 2004 14:45:22 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIJ54kt084125; Thu, 18 Nov 2004 11:05:04 -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 iAIJ54j0084123; Thu, 18 Nov 2004 11:05:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from hosting.revelstone.com (sls-ce10p21.dca2.superb.net [66.36.242.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIJ4WdM083930 for ; Thu, 18 Nov 2004 11:04:36 -0800 (PST) (envelope-from ipsp-mib@revelstone.com) Received: from localhost ([127.0.0.1] helo=dev.localdomain) by hosting.revelstone.com with smtp (Exim 4.43) id 1CUrZy-0005Uv-HP; Thu, 18 Nov 2004 14:04:26 -0500 Date: Thu, 18 Nov 2004 14:04:26 -0500 From: Robert Story To: Wes Hardaker Cc: Yacine.El_Mghazli@alcatel.fr, ipsec-policy@vpnc.org, Michael Baer , cliffwang2000@yahoo.com, Julien Bournelle , Yoshihiro Ohba Subject: Re: IPSP MIBs usage review needed Message-ID: <20041118140426.0db17289@dev.localdomain> In-Reply-To: References: <40B1B345.6000208@alcatel.fr> <40F2BB06.7050807@alcatel.fr> <41598642.2080405@alcatel.fr> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - vpnc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - revelstone.com Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Fri, 12 Nov 2004 06:38:44 -0800 Wes wrote: WH> >>>>> On Tue, 28 Sep 2004 17:41:54 +0200, Yacine.El_Mghazli@alcatel.fr WH> >said: WH> Yacine> our document in the PANA WG proposes to re-use the IPSP MIBs WH> Yacine> in the PANA framework for authorization features. we need WH> Yacine> people from this group to review the usage example in our I-D WH> Yacine> (section 6, page 16): WH> Yacine> WH> Yacine> http://www.ietf.org/internet-drafts/draft-ietf-pana-snmp-01.txt WH> WH> Hi, and sorry for the delay. I told the PANA working group that I (or WH> one of the authors) will read the PANA MIB and review it for you to WH> check its usage of the IPSP MIBs. Here are my comments on the usage example. I'll try to get to the rest of it tomorrow. Let me know if you have questions or need further clarification. 1) You seem to use the notation "xxxTable.N" to indicate the Nth entry in a table. Unfortunately, this looks like an OID and could be confusing. I recommend using some other notation, such as "xxxTable, row 1". This is especially confusing when you use the notation as an example value for an object that actually takes an OID (eg spdGroupContFilter). Section 6.1 ----------- 2) The spdRuleDefFilter in the spdRuleDefinitionTable rows should be set to spdTrueFilterInstance, since the filter in the spdGroupContents table has already matched. 3) I recommend using spdAcceptAction instead of spdStaticActions.2, for readability. Section 6.2 ----------- 4) you state that the previous configuration set is still valid, but you reuse the spdGroupContName "EP-SPD-IN" from spdGroupContentsTable row 1 defined in 6.1 with the same priority and a different filter. I recommend you use examples that could co-exist, which would mean a) defining row 1 of the spdGroupContentsTable in section 6.1 to use a lower priority (higher spdGroupContPriority, eg 1000). b) defining row 1 (hopefully renamed to row 3) in the spdGroupContentsTable in section 6.2 with a higher priority (I'm guessing the IKE rule should have the higher priority(lower spdGroupContPriority, eg 1)). 5) in spdGroupContentsTable.1 (hopefully renamed), I recommend using ipiaIkePhase1Filter instead of ipiaStaticFilters.1, for readability. 6) the spdRuleDefFilter in spdRuleDefinitionTable row 3 should be set to spdTrueFilterInstance, since the filter in the spdGroupContents table has already matched. The spdRuleDefAction should refer to ipiaIkeActionTable, not spdIkeActionTable. 7) You defined an ipiaIkeActionTable row, but not any associated ipiaIkeActionProposalsTable and ipiaIkeProposalTable rows. 8) pre-shared keys should be stored in the ipiaCredentialTable. The ipiaCredentialFilterTable is for matching incoming credentials from peers. 9) You define IKE actions, but no IPsec actions, so I assume IKE is just used for identity, and not to actually set up an IPsec tunnel for secure communications. 10) There is only one spdRuleDefinition (matching IKE Phase 1 traffic). Since an interface that has a group entry will drop any packet that doesn't match any rules, this means that all non IKE Phase 1 traffic would be dropped, even if the Phase 1 negotiation completes. Thus, Phase 2 negotiation isn't possible, unless further rules are added. This would also mean that SNMP traffic to/from the PAA would be dropped. A common setup section prior to 6.1 might be useful, to define what traffic is allowed for the interface (eg per section 2.1, PANA, ARP, IPv6 discover, DHCP, etc). 11) I also couldn't tell who initiates the IKE exchange. Is it always one side or the other? 12) You may also want to mention that the IPSP-SPD-MIB specifies that if an interface has no spdEndpointToGroup defined, the spdIncomingPolicyGroupName and spdOutgoingPolicyGroupName objects are used to apply policy. If these objects are not set, the default it accept all packets to the interface. It is generally accepted that "reject unless accepted" is more secure than "accept unless rejected", so the PAA may want to create a reject policy and set these objects ASAP. From owner-ipsec-policy@mail.vpnc.org Sun Nov 28 13:29:36 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 NAA04456 for ; Sun, 28 Nov 2004 13:29:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iASHod3B061035; Sun, 28 Nov 2004 09:50:39 -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 iASHodiw061033; Sun, 28 Nov 2004 09:50:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from hosting.revelstone.com (sls-ce10p21.dca2.superb.net [66.36.242.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iASHo1Vk060157 for ; Sun, 28 Nov 2004 09:50:05 -0800 (PST) (envelope-from ipsp-mib@revelstone.com) Received: from localhost ([127.0.0.1] helo=dev.localdomain) by hosting.revelstone.com with smtp (Exim 4.43) id 1CYTB1-0007m3-Kt; Sun, 28 Nov 2004 12:49:35 -0500 Date: Sun, 28 Nov 2004 12:49:35 -0500 From: Robert Story To: Yacine.El_Mghazli@alcatel.fr Cc: Wes Hardaker , ipsec-policy@vpnc.org, Michael Baer , cliffwang2000@yahoo.com, Julien Bournelle , Yoshihiro Ohba , Alper Yegin , pana@ietf.org Subject: Re: IPSP MIBs usage review needed Message-ID: <20041128124935.74ebf93b@dev.localdomain> In-Reply-To: <41A5A8CD.9020803@alcatel.fr> References: <40B1B345.6000208@alcatel.fr> <40F2BB06.7050807@alcatel.fr> <41598642.2080405@alcatel.fr> <20041118140426.0db17289@dev.localdomain> <41A5A8CD.9020803@alcatel.fr> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - vpnc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - revelstone.com Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Thu, 25 Nov 2004 10:41:33 +0100 Yacine.El_Mghazli@alcatel.fr wrote: YEF> > 7) You defined an ipiaIkeActionTable row, but not any associated YEF> > ipiaIkeActionProposalsTable and ipiaIkeProposalTable rows. YEF> YEF> this is a point we had troubles to figure out how it works. I've just recently finished updating some graphics for the recent MIB split. They may (or may not) help you get a grasp on the relationships between the tables: http://net-policy.sourceforge.net/tutorial/mib2/index.html YEF> our understanding is that ipiaIkeActionProposalsTable and YEF> ipiaIkeProposalTable gives the necessary information for the Phase 2 YEF> negotiation. could you please provide us with consistent values for YEF> those entries (instead of xxx) ? The spdRuleDefAction will point to a row in the ipiaIkeActionTable, which is indexed by a name (ipiaIkeActName). For that action, the same index (name) is used as the primary index into the ipiaIkeActionProposalsTable. The secondary index is a priority (ipiaIkeActPropPriority), which allows ordering of the proposals that will be sent to the peer (or accepted from the peer). The ipiaIkeActPropName points to a row in the ipiaIkeProposalTable, which contains the actual IKE parameters. There is a similar hierarchy for the IPsec proposals, which are used for Phase 2 negotiations, and result in a Phase 2 SA being created, upon successful negotiations. YEF> > 8) pre-shared keys should be stored in the ipiaCredentialTable. The YEF> > ipiaCredentialFilterTable is for matching incoming credentials from YEF> > peers. YEF> YEF> cannot find such a table in the IPIA MIB. are you really sure the PSK is YEF> not stored in the ipiaCredentialFilterTable ? The ipiaCredentialTable is in the IPSEC-IPSECACTION-MIB, and I am quite sure it is the right table. An IKE identity would refer to the ipsaCredentialTable for the credential to be used during negotiations. The ipiaCredentialFilterTable would be more useful for allowing/disallowing packets for more flexible credential types (like x.509 certificates; eg, disallowing certs from a certain issuer). YEF> > 9) You define IKE actions, but no IPsec actions, so I assume IKE is just YEF> > used for identity, and not to actually set up an IPsec tunnel for secure YEF> > communications. YEF> YEF> indeed we have to define IPSec actions. not sure if we need to provide a YEF> full IPSP configuration in this section. what are the entries which are YEF> lacking in the attached version ? Well, the IPsec parameters would be set up in the ipiaIpsecActionTable, ipiaIpsecProposalsTable and ipiaIpsecTransformsTable, along with the necessary related tables. You would then need a rule to trigger the row in the ipiaIpsecActionTable. You would probably want a single rule, with a compound action composed of an IKE sub-action and an IPsec sub-action. YEF> > 10) There is only one spdRuleDefinition (matching IKE Phase 1 YEF> > traffic). Since an interface that has a group entry will drop any packet YEF> > that doesn't match any rules, this means that all non IKE Phase 1 YEF> > traffic would be dropped [...] YEF> YEF> done. added a section "common setup" to make it explicit in the draft. YEF> the example focus on DHCP traffic. What you have will work, but I suggest using a more generic entry in the group contents table (e.g. "Accept allowed unprotected traffic"), with a compound filter and sub-filters for each allowed traffic type. This would allow the single compound filter to be applied to multiple interfaces, whereas your current setup in the group contents table would have to be replicated for every interface. So if there are N interfaces and M allowed traffic types, filtering in group contents would be (N * M) rows, versus (N + M) rows when using a compound filter. YEF> > 12) You may also want to mention that [...] If these objects are not YEF> > set, the default [is to] accept all packets to the interface. YEF> YEF> can we consider it's done through the definition of the common setup YEF> section (see your comment #10) ? Yes, that's fine. Just one other comment on the new section 6 IKE: 13) you define a peer identity filter, but it is not used anywhere. If relying on the shared secret if not sufficient and you want to use a filter on the identity, then the filter for spdGroupContentsTable, row 4 should be a compound filter, with sub-filters of spdIpHeaderFilterTable.1 and ipiaPeerIdentityFilterTable.1. Now, on to the PANA-EP-MIB. I'm assuming that the panaL2FilterTable is intended to be used as a means to trigger panaNewPacL2Notification messages, and not as a filter type for use with the IPsec policy MIBs. The use of the table does not appear to be defined in the draft. This is not a problem, or even a suggestion. Just food for thought. In general, the more flexible a filter, the better. This table is filtering on MAC addresses. For ethernet addresses, the MAC has a prefix that identifies the manufacturer of the interface. So, if you have a homogeneous network of devices with ethernet interfaces from one (or a few) vendors, filtering based on the vendor prefix might be useful. If the panaL2FitlerTable had an additional column, panaL2FileAddrPrefix, then this could easily be accomplished. The default value should be 0, so the table would require exact matches by default. Another flexibility idea for the panaL2FilterTable would be to explicity define the action to be taken on a match. The default would likely be to send the panaNewPacL2Notification, but if a particular MAC was determined to be an attacker, it would be useful to set the action to drop/ignore, so that resources would not be wasted attempting negotiations. I would also suggest a MIB level object for setting a threshold for sending the notifications. If you are getting 10 packets per second from somewhere, you don't really need to send a trap every time. A simple integer object defining the number of seconds that packets will be ignored before a new notification is sent. From owner-ipsec-policy@mail.vpnc.org Tue Nov 30 04:59:07 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 EAA28268 for ; Tue, 30 Nov 2004 04:59:04 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAU9Fjln098028; Tue, 30 Nov 2004 01:15:45 -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 iAU9Fj42098027; Tue, 30 Nov 2004 01:15:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from mid-2.inet.it (mid-2.inet.it [213.92.5.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAU9Fa3S097690 for ; Tue, 30 Nov 2004 01:15:43 -0800 (PST) (envelope-from harrie@lisanza.net) Received: from harrie.inet.it [::ffff:213.92.1.193] by mid-2.inet.it via I-SMTP-5.2.1-520 id ::ffff:213.92.1.193+EejUAe1R8s9y; Tue, 30 Nov 2004 10:15:11 +0100 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <15889186-42B0-11D9-A818-0003934A5A7E@lisanza.net> Content-Transfer-Encoding: 7bit Cc: Harrie Hazewinkel , Bert Wijnen From: Harrie Hazewinkel Subject: mib-doctor review of draft-ietf-ipsp-spd-mib Date: Tue, 30 Nov 2004 10:13:22 +0100 To: ipsec-policy@vpnc.org X-Mailer: Apple Mail (2.619) Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, On Berts request I have done a review of the draft-ietf-ipsp-spd-mib-01.txt. Hereby my comments. (I am subscribe to this list so I do not need an explicit CC). - General, it may be subjective, but I do not like the use of 'we' and 'us' in an RFC. Therefore, I suggest, for example change "we should do" into "one should do". - There are also parts of this MIB which use similar ideas as the packet filtering in the DIFF-SERV MIB. Maybe it is good to make a check wheter that can be used. I believe that at least some terms can be used from that MIB. For instance, incoming -> ingress. Actually, also the draft itself speaks sometimes of inbound and sometimes of incoming (in particular the FORMAL MIB part). - Beyond that I believe it would be a good thing first to clean up the usage of the language. Sometimes, many object descriptions can be made way more precise. - Some comments on the objects, need to be repeated for other simila objects also. These are not explicitly added. - What is the rational of defining a filter and a subfilter? Is the subfilter not just another filter. - I beleive it may help a reader/implementor a lot if the logical structure is explained at front of the MIB module. This descrription is currently brief by the size/complexity/ relations of the tables in the MIB module. (more detailed comments below) regards, Harrie > Abstract > > > This document defines a SMIv2 Management Information Base (MIB) > module for configuring the security policy database of a device > implementing the IPSec protocol. The policy-based packet filtering > and the corresponding execution of actions is of a more general > nature than for IPsec configuration only, such as for configuration > of a firewall. This MIB module is designed with future > extensibility > in mind. It is thus possible to externally add other packet filters > and actions to the policy-based packet filtering system defined in > this document. I am not sure of the usefulnes of 'future extensibility' here. I would also indicate that it is therefore possible to extends with enterprises specific managed objects. > 1. Introduction > [snip] > It is possible to add other packet transforming > actions to this MIB module if those actions needed to be performed > conditionally on filtered traffic. The last part of the sentence sounds odd. > Companion documents [RFCXXXX], [RFCYYYY] document actions which are > specific to IPsec and IKE. No IPsec or IKE specific actions are > defined within this document. Add note that RFCXXXX and RFCYYYY must be replaced by the RFC-editor. > 3. Relationship to the DMTF Policy Model > > > The Distributed Management Task Force (DMTF) has created an object > oriented model of IPsec policy information known as the IPsec Policy > Model White Paper [IPPMWP]. The contents of this document are also > reflected in the "IPsec Configuration Policy Model" (IPCP) > [RFC3585]. Is it not opposite? The "IPsec Configuration Policy Model" is also reflected in this document. > This MIB module is a task specific derivation of the IPCP for use > with SNMPv3. But how does the MIB relate to the previous documents? > o Policies, Groups, Conditions, and some levels of Action are > generically named. That is we dropped prefixes like "SA", or 'we dropped' -> 'this document drops' What is 'SA'? > "ipsec". This is because we feel that packet classification and > matching of conditions to actions is more general than IPsec and > could possibly be reused by other packet transforming actions > which need to conditionally act on packets matching filters. If this are general packet filters, why not using diff-serv packet filters. > o Filters are implemented in a more generic and scalable manner, > rather than enforcing the condition/filtering pairing and their > restrictions upon the user. The MIB module offers a compound > filter object to provide for greater flexibility when creating > complex filters. Implementations hints are fine, but is it really that this document implement things in a 'more generic and scalable manner'. I guess not, since the RFC does not specify implementation specific things and there contradicts. > 4. MIB Module Overview > > > The MIB module is modularized into several different parts: rules, > filters, and actions. Start new paragraph as you do for the other 'parts'. > The rules section connects endpoints and > groups of rules together. The rules section does not do anything. Maybe the objects defined in the section. It is not really clear what a 'rule' is. The rules section provides endpoint relationships and grouping of the 'rules'. > This is partially made up of the > ipspEndpointToGroupTable, ipspGroupContentsTable, and the > ipspRuleDefinitionTable. Why partially? In that case this MIB is incomplete. > Each row of the ipspRuleDefinitionTable > connects a filter(s) with an action(s). It is structured to allow > for reuse through the future creation of extension tables that > provide additional filters and/or actions. In fact, the companion > documents to this one do just that to define IPsec and IKE specific > actions to be used within this SPD configuration MIB. > > > The filter section of the MIB module is composed of all the > different 'of all the' -> ' of the' > types of filters in the Policy Model. It is partially made up of > the Again 'partially'... > trueFilter, ipspCompoundFilterTable, ipspIpHeaderFilterTable, > ipspIpOffsetFilterTable, ipspTimeFilterTable, and the > ipspIpsoHeaderFilterTable. > > > The action section of the MIB module contains different action types 'contains different' -> 'contains the different' > from the Policy Model. This document contains only the basic > actions > needed for firewall processing (accept, drop, log, ...) that an SPD > implementation will need. The companion documents define the IPsec > and IKE specific actions. > > > 4.1 Usage Tutorial > > > In order to make use of the tables contained in this document, a > general understanding of firewall processing must be first > understood. The processing of the security policy database involves > applying a set of firewall rules to an interface on a device. The > given set of rules to apply to any given interface is defined within > the ipspEndpointToGroupTable table. This table maps a given > interface to a group of rules. The interface itself with in this > table is specified using its assigned address. There is also one > group of rules per direction (inbound and outbound). This sounds more like introduction. > > > 4.1.1 Notational conventions > > > Notes about the following example operations: > > 1. All of the example operations in the following section make use > of default values for all columns not listed. The operations > and > close are the minimal SNMP Varbinds that must be sent. 'operations and close' do sound odd here. Maybe it is they are eplained later, but a read (me) is confused. > 2. The example operations are formatted such that a row (i.e. the > table's Entry object) is operated on by using the indexes to > that > row and the column values for the that row. It is left as an > exercise for the reader to turn these into real SNMP operations > using real OIDs and real varbinds in a SET PDU. Example: > > > > rowEntry(index1 = value1, > index2 = value2) > = (column1 = column_value1, > column2 = column_value2) I am not getting this example. Maybe it is better if you once explain how the excercise for the reader must be done. > IMPORTS > MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, > mib-2 FROM SNMPv2-SMI Add rfc as comment. (also other imports) > spdMIB MODULE-IDENTITY > DESCRIPTION > "This MIB module defines configuration objects for managing > IPsec Security Policy. Policy -> Policies > Copyright (C) The Internet Society (2003). This version of We are in the year 2004. > this MIB module is part of RFC XXXX, see the RFC itself for > full legal notices." > > > -- Revision History > > > REVISION "200401070000Z" -- 7 January 2004 > DESCRIPTION "Initial version, published as RFC xxxx." > -- RFC-editor assigns xxxx Hmm, you use here also RFC XXXX. That was also a reference. Change one of them. > > spdConfigObjects OBJECT IDENTIFIER > ::= { spdMIB 1 } > spdNotificationObjects OBJECT IDENTIFIER > ::= { spdMIB 2 } > spdConformanceObjects OBJECT IDENTIFIER > ::= { spdMIB 3 } > spdActions OBJECT IDENTIFIER > ::= { spdMIB 4 } In your introduction text I saw there are three parts. For instance, rules and actions, I see actions here, but no rules. > -- Note: the following subassignments have been used in other MIBs: > -- IPSEC-IPSECACTION-MIB: > -- ipsaMIB MODULE-IDENTITY ::= { spdActions 1 } > -- IPSEC-IKEACTION-MIB: > -- ipiaMIB MODULE-IDENTITY ::= { spdActions 2 } Why do you not import them? > SpdBooleanOperator ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The SpdBooleanOperator operator is used to specify > whether sub-components in a decision making process are > ANDed or ORed together to decide if the resulting > expression is true or false." > SYNTAX INTEGER { or(1), and(2) } How about XOR and NOT/negate? Or not possible to use? > SpdIPPacketLogging ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "SpdIPPacketLogging specifies whether or not an audit > message should be logged when a packet is passed through an > SA. It does not really indicate whether logging i must be done, but more precise how many bytes of the message must be logged. I guess, it would be better to express that. Beyond that what is an SA?? > A value of '-1' indicates no logging. A value of '0' > or greater indicates that logging should be done and how > many bytes of the beginning of the packet to place in the > log. Values greater than the size of the packet being > processed indicate that the entire packet should be sent. > > > Examples: > '-1' no logging > '0' log but do not include any of the packet in the log > '20' log and include the first 20 bytes of the packet > in the log." The examples roughly duplicate the text before and do not added much. > spdIncomingPolicyGroupName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE(0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object indicates the policy group containing the > global system policy that is to be applied on incoming > packets (I.E., arriving at a interface) when a given > endpoint does not contain a policy definition in the > spdEndpointToGroupTable. Its value can be used as an index > into the spdGroupContentsTable to retrieve a list of > policies. A zero length string indicates no system wide > policy exits and the default policy of 'accept' should be > executed for incoming packets until one is imposed by > either this object or by the endpoint processing a given > packet." > ::= { spdLocalConfigObjects 1 } > > spdOutgoingPolicyGroupName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE(0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object indicates the policy group containing the > global system policy that is to be applied on outgoing > packets (I.E., leaving an interface) when a given endpoint > does not contain a policy definition in the > spdEndpointToGroupTable. Its value can be used as an index > into the spdGroupContentsTable to retrieve a list of > policies. A zero length string indicates no system wide > policy exits and the default policy of 'accept' should be I beleive that the description is close to the InComing, but for outgoing packets, I do not believe you could use 'accept'. > executed for outgoing packets until one is imposed by > either > this object or by the endpoint processing a given packet." > ::= { spdLocalConfigObjects 2 } > > > > > spdEndpointToGroupTable OBJECT-TYPE > SYNTAX SEQUENCE OF SpdEndpointToGroupEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table is used to map policy (groupings) onto an > endpoint where traffic is to pass by. Any policy group > assigned to an endpoint is then used to control access > to the traffic passing by it. > > > If an endpoint has been configured with a policy group > and no contained rule matches the incoming packet, the > default action in this case shall be to drop the packet. > > > If no policy group has been assigned to an endpoint, > then the policy group specified by > spdSystemPolicyGroupName should be used for the > endpoint." > ::= { spdConfigObjects 2 } > > > spdEndpointToGroupEntry OBJECT-TYPE > SYNTAX SpdEndpointToGroupEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A mapping assigning a policy group to an endpoint." > INDEX { spdEndGroupIdentType, spdEndGroupAddress } Why is the spdEndGroupDirection not part of the index? It looks to me you make a distinction and thus need to be reflected in making configurations also. > ::= { spdEndpointToGroupTable 1 } > > spdEndGroupDirection OBJECT-TYPE > SYNTAX INTEGER { incoming(1), outgoing(2) } > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The direction of the packet crossing the interface. As > packets arrive or leave an interface, the appropriate > policy is applied according to the direction it is > traveling: into or out of the device." The text does like to me partial repeating itself. > ::= { spdEndpointToGroupEntry 1 } > > > spdEndGroupIdentType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The Internet Protocol version of the address associated > with a given endpoint. All addresses are represented as an > array of octets in network byte order. When combined with > the spdEndGroupAddress these objects can be used to > uniquely identify an endpoint that a set of policy groups > should be applied to. Devices supporting IPv4 MUST support > the ipv4 value, and devices supporting IPv6 MUST support > the ipv6 value. > > > Values of unknown, ipv4z, ipv6z and dns are not legal > values for this object." > ::= { spdEndpointToGroupEntry 2 } > > > spdEndGroupAddress OBJECT-TYPE > SYNTAX InetAddress (SIZE (4|16)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The address of a given endpoint, the format of which is > specified by the spdEndGroupIdentType object." > ::= { spdEndpointToGroupEntry 3 } > > > > spdEndGroupName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE(1..32)) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The policy group name to apply to this endpoint. The > value of the spdEndGroupName object should then be used > as an index into the spdGroupContentsTable to come up > with a list of rules that MUST be applied to this > endpoint." This text looks to me a duplicating. If the object has a value I would indeed think it must be used. But how can you make sure that these are used in the spdGroupContentsTable. While thinkin of it, why not using the index of this table in the spdGroupTable? Looks easier to me. > ::= { spdEndpointToGroupEntry 4 } > This object may not be set to active until one or more > active rows exist within the spdGroupContentsTable for > the group referenced by the spdEndGroupName object." > ::= { spdEndpointToGroupEntry 7 } What happens when you do set it active and those rows do not exist. > spdGroupContentsTable OBJECT-TYPE > SYNTAX SEQUENCE OF SpdGroupContentsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table contains a list of rules and/or subgroups > contained within a given policy group. Is this table used for two purposes? > The entries are > sorted by the spdGroupContPriority object and MUST be > executed in order according to this value, starting with > the lowest value. Once a group item has been processed, > the processor MUST stop processing this packet if an action > was executed as a result of the processing of a given > group. Iterating into the next policy group item by > finding the next largest spdGroupContPriority object shall > only be done if no actions were run when processing the > last item for a given packet." > ::= { spdConfigObjects 3 } > > > spdGroupContentsEntry OBJECT-TYPE > SYNTAX SpdGroupContentsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Defines a given sub-component within a policy group." The table does contain a list of rules anr/or subgroups, but the entries do consist of sub-components. On top of that a sub-component is not defined either. > INDEX { spdGroupContName, spdGroupContPriority } > ::= { spdGroupContentsTable 1 } > spdGroupContPriority OBJECT-TYPE > SYNTAX Integer32 (0..65535) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The priority (sequence number) of the sub-component in > this group." > ::= { spdGroupContentsEntry 2 } > > > spdGroupContFilter OBJECT-TYPE > SYNTAX VariablePointer Since below the pointer refers to entries in tables. Is a RowPointer not prefered then? > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "spdGroupContFilter points to a filter which is evaluated > to determine whether the sub-component within this group > should be exercised. What is considered a sub-component? > > If this column is set to a VariablePointer value which > references a non-existent row in an otherwise supported > table, the inconsistentName exception should be > returned. If the table or scalar pointed to by the > VariablePointer is not supported at all, then an > inconsistentValue exception should be returned." What should the value be if the variable pointed to is destroyed? > DEFVAL { spdTrueFilterInstance } Why do you not use a zeroDotZero? > ::= { spdGroupContentsEntry 3 } > > > spdGroupContComponentType OBJECT-TYPE > SYNTAX INTEGER { reserved(0), group(1), rule(2) } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Indicates whether the spdGroupContComponentName object > is the name of another group defined within the > spdGroupContentsTable or is the name of a rule defined > within the spdRuleDefinitionTable." What do the values mean here? I believe group and rule are ok, but reserved? > DEFVAL { rule } > ::= { spdGroupContentsEntry 4 } > > > spdGroupContComponentName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE(1..32)) I notice a lot of times that this indicates a group or rule name. Why not making a single TC providing the semantics for such a name. > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The name of the policy rule or subgroup contained within > this group, as indicated by the > spdGroupContComponentType object." > ::= { spdGroupContentsEntry 5 } > spdRuleDefDescription OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "A user definable string. 'definable' -> 'defined' > spdRuleDefFilter OBJECT-TYPE DEF-VAL?? It looks to me a simialr object as before. > ::= { spdRuleDefinitionEntry 3 } > > > spdRuleDefFilterNegated OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "spdRuleDefFilterNegated specifies whether the filter > referenced by the spdRuleDefFilter object should be > negated or not." > DEFVAL { false } What is the rational for the negation, is not better to added the negated rule instead of this mechanism? > ::= { spdRuleDefinitionEntry 4 } > > > spdRuleDefAction OBJECT-TYPE DEFVAL? > spdCompFiltDescription OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "A user definable string. You may use this field for > your administrative tracking purposes." > DEFVAL { ''H } Before this was defined as "". > > spdTrueFilter OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This scalar indicates a (automatic) true result for > a filter. I.e. this is a filter that is always > true, useful for adding as a default filter for a > default action or a set of actions." > ::= { spdStaticFilters 1 } What does this add in the boolean logic? > > > spdTrueFilterInstance OBJECT IDENTIFIER ::= { spdTrueFilter 0 } > > > -- > -- Policy IPHeader filter definition table > -- > > > spdIpHeaderFilterTable OBJECT-TYPE > SYNTAX SEQUENCE OF SpdIpHeaderFilterEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table contains a list of filter definitions to be > used within the spdRuleDefinitionTable or the > spdSubfilterTable table." > ::= { spdConfigObjects 8 } I believe this is similar as defined in the DIFF-SERV-MIB. Would it not be better to use those filters. For instance, also the IPCDN WG could use the same filters for traffic filtering. > spdTimeFiltTimeOfDayMaskStart OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Indicates the starting time of day for which this filter > evaluates to true. The date portions of the DateAndTime > TC are ignored for purposes of evaluating this mask and > only the time specific portions are used." > DEFVAL { '00000000000000002b0000'H } > ::= { spdTimeFilterEntry 7 } I beleive it would be better to make a new Time TC. You add more semantics to a value that you want. > spdTimeFiltTimeOfDayMaskEnd OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Indicates the ending time of day for which this filter > evaluates to true. The date portions of the DateAndTime > TC are ignored for purposes of evaluating this mask and > only the time specific portions are used. If this > starting and ending time values indicated by the > spdTimeFiltTimeOfDayMaskStart and > spdTimeFiltTimeOfDayMaskEnd objects are equal, the > filter is expected to be evaluated over the entire 24 > hour period." > DEFVAL { '00000000000000002b0000'H } > ::= { spdTimeFilterEntry 8 } I would earlier follow a schema as in RFC 2445 is used. Mostly a full day starts at, 00:00:00 and ends at 23:59:00 > spdIPInterfaceType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "Contains the interface type for the interface that the The value should represent an interface type, but you use an InetAddressType as syntax. Is this really correct. > packet which triggered the notification in question is > passing through." > ::= { spdNotificationVariables 2 } > > > spdIPInterfaceAddress OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "Contains the interface address for the interface that > the packet which triggered the notification in question > is passing through." As with the previous object. Does this have any relationship to the interface MIB. > ::= { spdNotificationVariables 3 } > > > spdIPSourceType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "Contains the source address type of the packet which > triggered the notification in question." 'in question' what does it add. > ::= { spdNotificationVariables 4 } > > > spdPacketDirection OBJECT-TYPE > SYNTAX INTEGER { inbound(1), outbound(2) } > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "Indicates if the packet whic triggered the action in > questions was inbound our outbound." > ::= { spdNotificationVariables 8 } From the previous source/destinations i get the feeling the direction is already fixed. Why this object? > > > spdPacketPart OBJECT-TYPE > SYNTAX OCTET STRING > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "Is the front part of the packet that triggered this > notification. The size is determined by the value of > 'SpdIPPacketLogging' or the size of the packet, > whichever is smaller." > ::= { spdNotificationVariables 9 } The value SpdIPPacketLogging is first of all an TEXTUAL-CONVENTION, secondly the SYNTAX is "Integer32 (-1..65535)" and thus may become 65535 and does not fit in the SNMP packet. How will that be handled? > -- > spdRuleFilterCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for SNMP entities that include > an IPsec MIB implementation with Endpoint, Rules, and > filters support." Maybe it is a good idea to provide also a ReadOnly Compliance statement. I can immagine setups/implementations that do not allow configuration via SNMP. (See for intstance, the DIFF-SERV-MIB. > MODULE -- This Module > MANDATORY-GROUPS { spdEndpointGroup, > spdGroupContentsGroup, > spdRuleDefinitionGroup, > spdIPHeaderFilterGroup, > spdStaticFilterGroup, > spdStaticActionGroup } > > > GROUP spdIpsecSystemPolicyNameGroup > DESCRIPTION > "This group is mandatory for IPsec Policy > implementations which support a system policy group > name." If mandatory, why not in the MANDATORY-GROUPS? (also others) > OBJECT spdEndGroupRowStatus > SYNTAX RowStatus { > active(1), createAndGo(4), destroy(6) > } > DESCRIPTION > "Support of the values notInService(2), notReady(3), > and createAndWait(5) is not required." > > > OBJECT spdEndGroupLastChanged > MIN-ACCESS not-accessible > DESCRIPTION > "This object not required for compliance." This may be not required for compliance, but it is defined in a MANDATORY-GROUP. I guess you want to change the grouping then. > > spdEndpointGroup OBJECT-GROUP > OBJECTS { > spdEndGroupName, spdEndGroupLastChanged, > spdEndGroupStorageType, spdEndGroupRowStatus > } > STATUS current > DESCRIPTION > "The IPsec Policy Endpoint Table Group." > ::= { spdGroups 1 } This counts also for the other descriptions, but it does not add any value. I would suggest a more description text of for instance why/what this group of objects are for. > > > spdActionNotificationGroup NOTIFICATION-GROUP > NOTIFICATIONS { > spdActionNotification, > spdPacketNotification > } > STATUS current > DESCRIPTION > "Notifications." This description adds nothing. It is equal as not having it. WHat kind fo notifications are these? > ::= { spdGroups 14 } > > > > END > > > > 6. Security Considerations > > > 6.1 Introduction > > > This document defines a MIB module used to configure IPsec policy > services. Since IPsec provides security services it is important > that the IPsec configuration data be at least as protected as the > IPsec provided security service. There are two main threats you > need > to thwart when configuring IPsec devices. > > > 1. Malicious Configuration: only the official administrators should > be allowed to configure a device. In other words, > administrators' identities should be authenticated and their > access rights checked before they are allowed to do device > configuration. The support for SET operations to the IPSP MIB > in > a non-secure environment, without proper protection, can have a > negative effect on the security of the network traffic affected > by the IPSP MIB. > > > 2. Disclosure of Configuration: Malicious parties should not be > able to read configuration data while the data is in network > transit. Any knowledge about a device's IPsec policy > configuration could help an unfriendly party compromise that > device and/or the network(s) it protects. It is thus important > to control even GET access to these objects and possibly to even > encrypt the values of these objects when sending them over the > network via SNMP. > > > SNMP versions prior to SNMPv3 did not include adequate security. > Even if the network itself is secure (for example by using IPsec), > even then, there is no control as to who on the secure network is > allowed to access and GET/SET (read/change/create/delete) the > objects > in this MIB module. > > > It is RECOMMENDED that implementers consider the security features > as > provided by the SNMPv3 framework (see [RFC3410], section 8), > including full support for the SNMPv3 cryptographic mechanisms (for > authentication and privacy). > > > Further, deployment of SNMP versions prior to SNMPv3 is NOT > RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to > enable cryptographic security. It is then a customer/operator > responsibility to ensure that the SNMP entity giving access to an > instance of this MIB module, is properly configured to give access > to > the objects only to those principals (users) that have legitimate > rights to indeed GET or SET (change/create/delete) them. > > > Therefore, when configuring data in the IPSEC-SPD-MIB, you SHOULD > use > SNMP version 3. The rest of this discussion assumes the use of > SNMPv3. This is a real strength, because it allows administrators > the ability to load new IPsec configuration on a device and keep the > conversation private and authenticated under the protection of > SNMPv3 > before any IPsec protections are available. Once initial > establishment of IPsec configuration on a device has been achieved, > it would be possible to set up IPsec SAs to then also provide > security and integrity services to the configuration conversation. > This may seem redundant at first, but will be shown to have a use > for > added privacy protection below. > > > 6.2 Protecting against in-authentic access > > > The current SNMPv3 User Security Model provides for key based user > authentication. Typically, keys are derived from passwords (but are > not required to be), and the keys are then used in HMAC algorithms > (currently MD5 and SHA-1 HMACs are defined) to authenticate all SNMP > data. Each SNMP device keeps a (configured) list of users and keys. > Under SNMPv3 user keys may be updated as often as an administrator > cares to have users enter new passwords. But Perfect Forward > Secrecy > for user keys is not yet provided by standards track documents, > although RFC2786 defines an experimental method of doing so. > > > 6.3 Protecting against involuntary disclosure > > > While sending IPsec configuration data to a PEP, there are a few > critical parameters which MUST NOT be observed by third parties. It would be wise to spell those objects out. > These include IKE Pre-Shared Keys and possibly the private key of a > public/private key pair for use in a PKI. Were either of those > parameters to be known to a third party, they could then impersonate > your device to other IKE peers. Aside from those critical > parameters, policy administrators have an interest in not divulging > any of their policy configuration. Any knowledge about a device's > configuration could help an unfriendly party compromise that device. > SNMPv3 offers privacy security services, but at the time this > document was written, the only standardized encryption algorithm > supported by SNMPv3 is the DES encryption algorithm. Support for > other (stronger) cryptographic algorithms is in the works and may be > done as you read this. Policy administrators SHOULD use a privacy > security service to configure their IPsec policy which is at least > as > strong as the desired IPsec policy. E.G., it is unwise to configure > IPsec parameters implementing 3DES algorithms while only protecting > that conversation with single DES. > > > 6.4 Bootstrapping your configuration > > Hopefully vendors will not ship new products with a default SNMPv3 > user/password pair, but it is possible. Most SNMPv3 distributions > should hopefully require an out-of-band initialization over a > trusted > medium, such as a local console connection. I understand the point, but what should a vendor do? > 8.1 Normative References > The normative refences for SNMP based RFC' can be cleaned up I believe in accordance with the new boiler plate. be aware that the MIB modules that are imported still must be references as RFC. > > [RFC3585] Jason, J., Rafalow, L. and E. Vyncke, "IPsec > Configuration > Policy Information Model", RFC 3585, August 2003. > > > 8.2 Informative References > > > [RFCXXXX] Baer, M., Charlet, R., Hardaker, W., Story, R. and C. > Wang, "IPsec Security Policy IPsec Action MIB", December > 2002. > > > [RFCYYYY] Baer, M., Charlet, R., Hardaker, W., Story, R. and C. > Wang, "IPsec Security Policy IKE Action MIB", December > 2002. Add note for RFC editor to replace RFCXXX/YYY. Also you use RFC XXXX for the dradft itself. > > [IPPMWP] Lortz, V. and L. Rafalow, "IPsec Policy Model White > Paper", November 2000. > > > > Authors' Addresses I would put the addresses more compact. No need for filling pages. From owner-ipsec-policy@mail.vpnc.org Tue Nov 30 11:10:00 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 LAA02174 for ; Tue, 30 Nov 2004 11:09:59 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUFcOBh094027; Tue, 30 Nov 2004 07:38:24 -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 iAUFcO2f094026; Tue, 30 Nov 2004 07:38:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUFcNmA093942 for ; Tue, 30 Nov 2004 07:38:23 -0800 (PST) (envelope-from yacine.el_mghazli@alcatel.fr) Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id iAUFbnrV012869; Tue, 30 Nov 2004 16:37:49 +0100 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2004113016374594:5582 ; Tue, 30 Nov 2004 16:37:45 +0100 Message-ID: <41AC93CA.5070106@alcatel.fr> Date: Tue, 30 Nov 2004 16:37:46 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: pana@ietf.org, ipsec-policy@vpnc.org Subject: Re: IPSP MIBs usage review needed References: <40B1B345.6000208@alcatel.fr> <40F2BB06.7050807@alcatel.fr> <41598642.2080405@alcatel.fr> <20041118140426.0db17289@dev.localdomain> <41A5A8CD.9020803@alcatel.fr> <20041128124935.74ebf93b@dev.localdomain> In-Reply-To: <20041128124935.74ebf93b@dev.localdomain> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/30/2004 16:37:46, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/30/2004 16:37:48, Serialize complete at 11/30/2004 16:37:48 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit without the attachements for the mailing lists: -------------------------------------------------------------------------------- > On Thu, 25 Nov 2004 10:41:33 +0100 Yacine.El_Mghazli@alcatel.fr wrote: > YEF> > 7) You defined an ipiaIkeActionTable row, but not any associated > YEF> > ipiaIkeActionProposalsTable and ipiaIkeProposalTable rows. > YEF> > YEF> this is a point we had troubles to figure out how it works. > > I've just recently finished updating some graphics for the recent MIB split. > They may (or may not) help you get a grasp on the relationships between the > tables: > > http://net-policy.sourceforge.net/tutorial/mib2/index.html [yacine]: yes it does clarify. thx. > YEF> our understanding is that ipiaIkeActionProposalsTable and > YEF> ipiaIkeProposalTable gives the necessary information for the Phase 2 > YEF> negotiation. could you please provide us with consistent values for > YEF> those entries (instead of xxx) ? > > The spdRuleDefAction will point to a row in the ipiaIkeActionTable, which is > indexed by a name (ipiaIkeActName). For that action, the same index (name) > is used as the primary index into the ipiaIkeActionProposalsTable. The > secondary index is a priority (ipiaIkeActPropPriority), which allows ordering > of the proposals that will be sent to the peer (or accepted from the peer). The > ipiaIkeActPropName points to a row in the ipiaIkeProposalTable, which contains > the actual IKE parameters. > > There is a similar hierarchy for the IPsec proposals, which are used for Phase > 2 negotiations, and result in a Phase 2 SA being created, upon successful > negotiations. [yacine]: agree. some of this text has been added to the example section to facilitate understanding. > YEF> > 8) pre-shared keys should be stored in the ipiaCredentialTable. The > YEF> > ipiaCredentialFilterTable is for matching incoming credentials from > YEF> > peers. > YEF> > YEF> cannot find such a table in the IPIA MIB. are you really sure the PSK is > YEF> not stored in the ipiaCredentialFilterTable ? > > The ipiaCredentialTable is in the IPSEC-IPSECACTION-MIB, and I am quite sure > it is the right table. An IKE identity would refer to the ipsaCredentialTable > for the credential to be used during negotiations. The > ipiaCredentialFilterTable would be more useful for allowing/disallowing packets > for more flexible credential types (like x.509 certificates; eg, disallowing > certs from a certain issuer). [yacine]: ok I updated the section accordingly. the right name of the table is ipsaCredentialTable. shared-secret is also a proposed option (2) for the the type field of the credentialFilterTable: this could bring some confusion. > YEF> > 9) You define IKE actions, but no IPsec actions, so I assume IKE is just > YEF> > used for identity, and not to actually set up an IPsec tunnel for secure > YEF> > communications. > YEF> > YEF> indeed we have to define IPSec actions. not sure if we need to provide a > YEF> full IPSP configuration in this section. what are the entries which are > YEF> lacking in the attached version ? > > Well, the IPsec parameters would be set up in the ipiaIpsecActionTable, > ipiaIpsecProposalsTable and ipiaIpsecTransformsTable, along with the necessary > related tables. You would then need a rule to trigger the row in the > ipiaIpsecActionTable. You would probably want a single rule, with a compound > action composed of an IKE sub-action and an IPsec sub-action. [yacine]: ok. added some text on this in the new version. > YEF> > 10) There is only one spdRuleDefinition (matching IKE Phase 1 > YEF> > traffic). Since an interface that has a group entry will drop any packet > YEF> > that doesn't match any rules, this means that all non IKE Phase 1 > YEF> > traffic would be dropped [...] > YEF> > YEF> done. added a section "common setup" to make it explicit in the draft. > YEF> the example focus on DHCP traffic. > > What you have will work, but I suggest using a more generic entry in the group > contents table (e.g. "Accept allowed unprotected traffic"), with a compound > filter and sub-filters for each allowed traffic type. This would allow the > single compound filter to be applied to multiple interfaces, whereas your > current setup in the group contents table would have to be replicated for every > interface. So if there are N interfaces and M allowed traffic types, filtering > in group contents would be (N * M) rows, versus (N + M) rows when using a > compound filter. [yacine]: what you suggests is nice. The -03b version takes this into account. > YEF> > 12) You may also want to mention that [...] If these objects are not > YEF> > set, the default [is to] accept all packets to the interface. > YEF> > YEF> can we consider it's done through the definition of the common setup > YEF> section (see your comment #10) ? > > Yes, that's fine. > > > Just one other comment on the new section 6 IKE: > > 13) you define a peer identity filter, but it is not used anywhere. If relying > on the shared secret if not sufficient and you want to use a filter on the > identity, then the filter for spdGroupContentsTable, row 4 should be a compound > filter, with sub-filters of spdIpHeaderFilterTable.1 and > ipiaPeerIdentityFilterTable.1. [yacine]: ok. -03b integrates the changes. > Now, on to the PANA-EP-MIB. [yacine]: firstly, thanks for your help. I am planning to do another thread with the PANA-EP-MIB specific issues ASAP, with other reviews we received recently. anyway let me answer a couple of your comments: > I'm assuming that the panaL2FilterTable is intended to be used as a means to > trigger panaNewPacL2Notification messages, and not as a filter type for use > with the IPsec policy MIBs. The use of the table does not appear to be defined > in the draft. [yacine]: indeed the PANA L2 filter is intended to filter the PaC traffic at the Link-Layer level. the additional PANA-EP-MIB module has been designed as simple as possible: by default a L2 EP implements a reject all traffic (except PANA, DHCP, etc.) and an entry in the panaL2FilterTable corresponds to an authorized L2 traffic. this should be independent from the IPSP MIBs which are re-used only for the IP scenarii. > This is not a problem, or even a suggestion. Just food for thought. In general, > the more flexible a filter, the better. This table is filtering on MAC > addresses. For ethernet addresses, the MAC has a prefix that identifies the > manufacturer of the interface. So, if you have a homogeneous network of devices > with ethernet interfaces from one (or a few) vendors, filtering based on the > vendor prefix might be useful. If the panaL2FitlerTable had an additional > column, panaL2FileAddrPrefix, then this could easily be accomplished. The > default value should be 0, so the table would require exact matches by default. [yacine]: this table is not intending to filter only MAC addresses, other L2 addressing are supported as well (PhysAddress). it has been designed as generic as possible. > Another flexibility idea for the panaL2FilterTable would be to explicity define > the action to be taken on a match. The default would likely be to send the > panaNewPacL2Notification, but if a particular MAC was determined to be an > attacker, it would be useful to set the action to drop/ignore, so that > resources would not be wasted attempting negotiations. [yacine]: your proposal sounds nice and consistent. there could be an elegant integration into the IPSP model. depends of the need of the working group. > I would also suggest a MIB level object for setting a threshold for sending the > notifications. If you are getting 10 packets per second from somewhere, you > don't really need to send a trap every time. A simple integer object defining > the number of seconds that packets will be ignored before a new notification is > sent. [yacine]: this issue has been raised already. I'll keep you informed. -------------------------------------------------------------------------------