From owner-ipsec-policy@mail.vpnc.org Wed Mar 3 10:43: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 KAA06033 for ; Wed, 3 Mar 2004 10:43:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23F6G03069014; Wed, 3 Mar 2004 07:06:16 -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 i23F6GeM069013; Wed, 3 Mar 2004 07:06:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from wes.hardakers.net (adsl-66-127-127-227.dsl.scrm01.pacbell.net [66.127.127.227]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23F6FdJ069006 for ; Wed, 3 Mar 2004 07:06:15 -0800 (PST) (envelope-from hardaker@tislabs.com) Received: by wes.hardakers.net (Postfix, from userid 274) id EF6D311D573; Wed, 3 Mar 2004 07:06:08 -0800 (PST) To: ipsec-policy@vpnc.org Subject: Steve: review status? From: Wes Hardaker Organization: Sparta Date: Wed, 03 Mar 2004 07:06:08 -0800 Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.5 (celeriac, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve, I just wanted to make sure that the MIBs are really on your plate. The ID tracker shows them unassigned. -- Wes Hardaker Sparta From owner-ipsec-policy@mail.vpnc.org Fri Mar 12 13:52:21 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 NAA10421 for ; Fri, 12 Mar 2004 13:52:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CIKGgE056302; Fri, 12 Mar 2004 10:20:16 -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 i2CIKGlA056301; Fri, 12 Mar 2004 10:20:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CIKFhV056295 for ; Fri, 12 Mar 2004 10:20:15 -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.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2CIJs220973 for ; Fri, 12 Mar 2004 12:19:59 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699SK8X>; Fri, 12 Mar 2004 19:19:51 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C9D65C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Man.M.Li@nokia.com, bwijnen@lucent.com Cc: smb@research.att.com, ho@alum.mit.edu, lsanchez@xapiens.com, avri@apocalypse.org, ipsec-policy@vpnc.org Subject: RE: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - p art 1 Date: Fri, 12 Mar 2004 19:19:42 +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: Sorry that it took so (much too) long for my follow up. Comments inline. A separate email will contain additional new comments. Thanks, Bert > -----Original Message----- > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > Sent: vrijdag 21 november 2003 23:25 > To: bwijnen@lucent.com > Cc: smb@research.att.com; ho@alum.mit.edu; lsanchez@xapiens.com; > avri@apocalypse.org; ipsec-policy@vpnc.org > Subject: RE: MIB/PIB doctor review for > draft-ietf-ipsp-ipsecpib-09.txt - > part 1 > > > Hi Bert, > > Thanks for your comments on the IPsec PIB draft v9. > Modifications have been made to address your comments 1-7 and > they are described below. Please also take a look at my reply > to your comment #8, since any change will create a > discrepancy with RFC 3585, I suggest to leave it as is unless > you do not agree. > > Please let me know if any of the modifications described are > still not satisfactory. I look forward to hearing more > comments from you on the rest of the draft. At which point, > we'll submit a new version. Thanks. > OK, so I now have continued to review revision 9. I expect to see a rev 10 after all changes have been made. > Best regards > Man > > > -----Original Message----- > > From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: November 19, 2003 12:08 PM > > To: Li Man.M (NRC/Boston); 'ho@alum.mit.edu'; 'avri@apocalypse.org'; > > 'lsanchez@xapiens.com' > > Cc: Steve Bellovin (E-mail); Wijnen, Bert (Bert) > > Subject: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - > > part 1 > > > > > > Based on the revision 9 that I received privately: > > > > 1. I see: > > ipSecRuleIfName OBJECT-TYPE > > SYNTAX SnmpAdminString > > STATUS current > > DESCRIPTION > > "The interface capability set to which this IPsec rule applies. > > The interface capability name specified by this attribute MUST > > exist in the frwkCapabilitySetTable [9] prior to association with > > an instance of this class." > > ::= { ipSecRuleEntry 2 } > > > > So I wonder: > > - would an attribute name of ipSecRuleIfCapSetName not be > > better than > > ipSecRuleIfName ??? When I see the latter I think of > ifName in the > > IF-MIB, when I see the former I am more inclined to think about > > the capaibilty in the frwkCapabilitySetTable. The latter > > would also > > be more inline with what we see in other PIB docs (RFC3317 for > > example) > > OK. Name changed to ipSecRuleIfCapSetName. > > > - what kind of error must be returned when the entry in the > > frwkCapabilitySetTable does not yet exist? > > Added description in the table that the ipSecRule table entry > will not be installed if that happens. > > > - is it clear what values the OID pointers in the > > frwkCapabilitySetTable > > can/should take when they are associated with an entry in > > this ipSec table? > > Added "The frwkCapabilitySetCapability attribute of that > entry shall in turn point to an entry in the ipSecIfCaps > table." to make it clear. > > > > > 2. I see > > ipSecRuleRoles OBJECT-TYPE > > SYNTAX RoleCombination > > STATUS current > > DESCRIPTION > > "Specifies the role combination of the interface to which this > > IPsec rule should apply. There must exist an instance in the > > frwkRoleComboTable [9] specifying this role combination, together > > with the interface capability set specified by ipSecRuleIfName, > > prior to association with an instance of this class." > > ::= { ipSecRuleEntry 3 } > > > > - what error must be returned when the entry in > frwkRoleComboTable > > does not yet exist? > > Added description in the table that the ipSecRule table entry > will not be installed if that happens. > > > 3. I see > > ipSecRuleAutoStart OBJECT-TYPE > > SYNTAX TruthValue > > STATUS current > > DESCRIPTION > > "Indicates if this rule should be automatically executed." > > ::= { ipSecRuleEntry 11 } > > > > The name "AutoStart" seems to tell me it needs to be > activated when > > the class is instantiated. Is that the same as "automatically > > executed"? What if the value gets changed to false? > > Changed to "Indicates if this rule shall be activated when it > is instantiated, i.e., start negotiate or statically set > security associations. If the value is changed to false > later, there is no impact on the security associations that > have already started." > > > > > 4. May I assume that if either ipSecStaticActionLifetimeSeconds > > or ipSecStaticActionLifetimeKilobytes indicates end of life time > > that that indeed marks the end of life? It is not clear what > > happens in that case. You may want to clarify. > > Added the following in ALL lifetime attributes "When both the > LifetimeSeconds and LifetimeKilobytes are used, the first > lifetime to expire takes precedence." > > > > > 5. I see: > > ipSecAssociationVendorId OBJECT-TYPE > > SYNTAX OCTET STRING > > STATUS current > > DESCRIPTION > > "Specifies the IKE Vendor ID. .... > > > > and wonder: what is an IKE Vendor ID? How is it formatted? > > Where is that explained? Is a reference usefull? I think so. > > Added a reference to RFC 2408. There are a couple more > VendorId in the draft, will add references to them as well > OK, I see that it is a HASH. That explains it. The reference helps. Might be good to also state that this is the hash value as defined in RFC2408 sect 3.16 > > > > 6. WHen I see: > > ipSecAssociationDhGroup OBJECT-TYPE > > SYNTAX Unsigned16TC > > STATUS current > > DESCRIPTION > > "Specifies the key exchange group to use for phase 2 when the > > > > I wonder... is that justa random value? Or does each value mean > > something, and if so, where is that defined? > > Added "reference to RFC 2409 for valid Dh group values" to > both ipSecAssociationDhGroup and ipSecIkeProposalIkeDhGroup. > > > > > 7. ipSecAssociationGranularity > > when reading the DESCRIPTION clause, I wonder if a BITS syntax is > > not better here > > OK. Changed to BITS. > > > > > 8. ipSecAhTransformMaxLifetimeSeconds > > I find it strange that zero means a max lifetime of 8 hours here, > > where as in an earlier xxxMaxLifeTimeSeconds object/attribute it > > meand infinite ?? Is that logical? Does that make sense? > > All the lifetime attributes and their default values are > aligned with RFC 3585. All the maxLifeTimeSeconds seem to use > 0 to indicate 8 hours. All other lifetime or minLifetime uses > 0 to indicate infinite. We could make changes so that, for > example, 0 indicates infinite in all the cases. But that will > create discrepancy between this draft and RFC 3585. > If this PIB is to be modelling RFC3585, then pls do follow that document, It just seemed weird to me. Adding the references, and may be a few lines of explanantion will help people understand why the weirdness is in the PIB. Bert From owner-ipsec-policy@mail.vpnc.org Tue Mar 16 10:24:22 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 KAA06112 for ; Tue, 16 Mar 2004 10:24:20 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GEnVdL035744; Tue, 16 Mar 2004 06:49: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 i2GEnVVe035743; Tue, 16 Mar 2004 06:49:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GEnThu035736 for ; Tue, 16 Mar 2004 06:49: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.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2GEnMf27799 for ; Tue, 16 Mar 2004 08:49:23 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <16994S9V>; Tue, 16 Mar 2004 15:49:20 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503DB05EF@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Man.M.Li@nokia.com, bwijnen@lucent.com Cc: smb@research.att.com, ho@alum.mit.edu, lsanchez@xapiens.com, avri@apocalypse.org, ipsec-policy@vpnc.org Subject: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - part 2 Date: Tue, 16 Mar 2004 15:49:18 +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: Steve, you may want to pay specific attention to items 34-37. Addtional things I found when revieing revision 9 Comments 1-8 were in part 1 email of the review 9. Doing s smilint syntax check, I get the following: C:\smi\pibs\ietf>smilint -l 6 -s -m -inamelength-32 ./IPSEC-POLICY-PIB /IPSEC-POLICY-PIB:83: [5] {type-without-format} warning: type `Unsigned16TC' has no format specification simple to fix by adding a DISPLAY-HINT /IPSEC-POLICY-PIB:19: [5] {import-unused} warning: identifier `zeroDotZero' imported from module `SNMPv2-SMI's never used simple to fix by removing zeroDotZero from the imports 10. I see a lot of acronyms in the document without expansion (when used for the first time. These maybe well know to security folk, but not to new readers. RFC-Editor wants them to be exanded first time they are used. Pls note that when PIB module is extracted, previous text is gone, and so it is probably wise to always expand in PIB DESCRIPTION clauses. 11. All RFCs that contain PIB or MIB modules from which you IMPORT must be normatively referenced. The RFC-Editor recently also wanted such references to have citations. The notatation we agreed on is IMPORTS Unsigned32, Unsigned64, MODULE-IDENTITY, OBJECT-TYPE, TEXTUAL-CONVENTION, MODULE-COMPLIANCE, OBJECT-GROUP, pib FROM COPS-PR-SPPI -- [RFC3159] TruthValue FROM SNMPv2-TC -- [RFC2579] and so on. But.. your references seem to be just numbered. I Do not find OBJECT-GROUP, pib FROM COPS-PR-SPPI -- [14] very acceptable. This is because when the PIB module gest extracted, then a "citation" of [14] does not help much. A Citation of [RFC3159] would still be clear for the reader (or so I think). 12. I see various ENUMERATIONS (e.g. INTEGERS) that probably would be better represented as a TC. For example: SYNTAX INTEGER { in(1), out(2), bi-directional(3) } and also SYNTAX INTEGER { copy(1), set(2), clear(3) } there are others. Those are just 2 examples. 13.I wonder if this is wise: Unsigned16TC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An unsigned 16 bit integer." SYNTAX Unsigned32 (0..65535) In some places its use seems OK. In many places, it is used to indicate an "order" as in: ipSecRuleOrder OBJECT-TYPE SYNTAX Unsigned16TC STATUS current DESCRIPTION "Specifies the precedence order of the rule within all the rules associated with {IfName, Roles}. A smaller value indicates a higher precedence order. " ::= { ipSecRuleEntry 9 } I wonder if it would not be better to define a TC aka: IpSecOrderTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An unsigned 16 bit integer that defines the order of a Rule or Set. A smaller value indicates a higher precedence order." SYNTAX Unsigned32 (0..65535) And then use that TC for all "order" objects. In the case of ipSecAssociationDhGroup OBJECT-TYPE SYNTAX Unsigned16TC I also wonder if a IpSecDhGroupTC would not be a wise thing. 14.I see citations in DESCRIPTION clauses, as in: ipSecRuleIfName OBJECT-TYPE SYNTAX SnmpAdminString STATUS current DESCRIPTION "The interface capability set to which this IPsec rule applies. The interface capability name specified by this attribute MUST exist in the frwkCapabilitySetTable [9] prior to association with an instance of this class." ::= { ipSecRuleEntry 2 } The [9] of course means nothing anymore when the PIB module gets extracted. If you used a notation ala [RFCxxxx] then it would still mean something in an extracted module. 15.In the ipSecXxxTable DESCRIPTION clauses you use text aka: "This table ...." In all other PIB modules that the IETF has published sofar, we did not talk about a table but either of a PRC (Policy Rule Class) or just class. See the DIFFSERV-PIB and the FRAMEWORK-PIB for example. I think that changing this so as to be consistent is a GOOD THING. 16.In the DESCRIPTION clause of: ipSecActionSetDoPacketLogging OBJECT-TYPE SYNTAX TruthValue STATUS current DESCRIPTION "Specifies whether to log when the resulting security association is used to process a packet. For ipSecStaticActions, a log message is to be generated when the IPsecBypass, IpsecDiscard or IKEReject actions are executed." ::= { ipSecActionSetEntry 5 } I wonder if "IPsecBypass, IpsecDiscard or IKEReject" are meant to mean the same thing as the enumerations in: ipSecStaticActionAction OBJECT-TYPE SYNTAX INTEGER { byPass(1), discard(2), ikeRejection(3), preConfiguredTransport(4), preConfiguredTunnel(5) } STATUS current If so, then you may want to sync up the labels. 17.I see: ipSecAssociationUseKeyExchangeGroup OBJECT-TYPE SYNTAX TruthValue STATUS current DESCRIPTION "Specifies whether or not to use the same GroupId for phase 2 as was used in phase 1. If UsePFS is false, then this attribute is ignored. A value of true indicates that the phase 2 GroupId should be the same as phase 1. A value of false indicates that the group number specified by the ipSecSecurityAssociationDhGroup attribute SHALL be used for phase 2. " ::= { ipSecAssociationEntry 7 } And wonder if ipSecSecurityAssociationDhGroup is mean to point to: ipSecAssociationDhGroup OBJECT-TYPE SYNTAX Unsigned16TC STATUS current DESCRIPTION "Specifies the key exchange group to use for phase 2 when the property ipSecSecurityAssociationUsePfs is true and the property ipSecSecurityAssociationUseKeyExchangeGroup is false." ::= { ipSecAssociationEntry 8 } If so, then better sync up the descriptors. If not, then where is ipSecSecurityAssociationDhGroup defined? By the way, in the last object, there are also a few descriptors that start with ipSecSecurityAssociation.... and that I cannot find. Again, probably s/Security// ?? 18.I see: ipSecAhTransformReplayPreventionWindowSize OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "Specifies, in bits, the length of the sliding window used by the replay prevention detection mechanism. The value of this property is ignored if UseReplayPrevention is false. It is assumed that the window size will be power of 2." ::= { ipSecAhTransformEntry 5 } Might be good to add a UNITS clause? But I also wonder what "window size will be power of 2" means? 19.ipSecEspTransformCipherKeyLength, ipSecEspTransformReplayPreventionWindowSize and may be others can also use a UNITS clause 20.In Table/Class ipSecCompTransformTable I see ipSecCompTransformAlgorithm and also ipSecCompTransformPrivateAlgorithm. Canthey both be specified for the same instance? If so, what happens? If not, can you make that clear? If yes, you may want to explain also what happens. 21.ipSecIkeRuleTable is probably talking about IKEv1 ?? Should that be made clear? What sort of change do we expect for IKEv2? WOuld it make sense to define this "optional" class in a separate document? In any event, you do not put in the DESCRIPTION clause that this table/class is optional. That is expressed (and even in machine readable form) in the MODULE-COMPLIACNE. 22.I am really wondering and worried about some of the UNIQUENESS clauses that require many columns/attributes to define uniqueness. But ipSecIkeAssociationEntry really seems excessive to me. It states that ALL attributes need to be checked for unqiueness !!??? Is that really intended? You may want to check all tables/classes in fact. 23.ipSecIkeAssociationVendorId is an OCTET STRING and the descripiton clause talks about a vlaue of NULL. That is not clear! Better is to talk about a zero length OCTET STRING. That is clear! 24.I see: ipSecIkeProposalPrfAlgorithm OBJECT-TYPE SYNTAX Unsigned16TC STATUS current DESCRIPTION "Specifies the Psuedo-Random Function (PRF) to propose for the IKE association." ::= { ipSecIkeProposalEntry 7 } So where do I find what any value means? And would it not be better to have a separate TC fo such algorithm values? And pls add REFERENCE clause to point to it. 24.Similar question for ipSecIkeProposalIkeDhGroup And pls add REFERENCE clause to point to it. 25.IN ipSecIkePeerEndpointIdentityValue you are using IP addresses as example. But you must use the ange of addresses that has been allocated for examples as per ID-NITs http://www.ietf.org/ID-nits.html which states: Addresses used in examples should prefer use of fully qualified domain names to literal IP addresses, and prefer use of example fqdn's such as foo.example.com to real-world fqdn's. See RFC 2606 for example domain names that can be used. There is also a range of IP addresses set aside for this purpose. These are 192.0.2.0/24 (see RFC 3330). Private addressess that would be used in the real world should be avoided in examples. 26.Object ipSecCredentialFieldsValue is defined as an OCTET STRING. However, reading the DESCRIPTION clause, it feels as if this is a string that will be used/read by human beings. In that case, it must be a UTF-8 string. Possibly a SnmpAdminString or some other TC that defines UTF-8 text. 27.When I read the ipSecSelectorTable and related tables, then I really wonder if you guys have really evaluated the possible re-use of the frwkIpFilterTable in the FRAMEWORK-PIB !!?? I thought that that framework filter table was meant to be re-used by many (if not all) filter/selector uses. 28.I have trouble understanding the ipSecIpsoFilterSetTable I bet it is cause by the very short DESCRIPTION clauses that do not mean much to me (and so probably do not mean much to other non-expert readers). 29.When I see ipSecRuleTimePeriodTimePeriod defined as an OCTET STRING then I wonder. It claims to be RFC2445 format (as RFC3060 also prescribes). There they talk about a string. I think it is US-ASCII, possibly represented as UTF-8 ?? I need to go and check to be sure. In any event, if you say OCTET STRING and specify that THISANDPRIOR has special meaning, then it needs to be clear what encoding needs to be used for that text. A SIZE specification may also make sense (or so I think). This is a generic Policy construct, which probably even warrants a TC. 30.I do not understand ipSecRuleTimePeriodMonthOfYearMask OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "An octet string that specifies which months the policy is valid for. The octet string is structured as follows: - a 4-octet length field, indicating the length of the entire octet string; this field is always set to 0x00000006 for this property; - a 2-octet field consisting of 12 bits identifying the 12 months of the year, beginning with January and ending with December, followed by 4 bits that are always set to '0'. For each month, the value '1' indicates that the policy is valid for that month, and the value '0' indicates that it is not valid. If this property is omitted, then the policy rule is treated as valid for all twelve months." ::= { ipSecRuleTimePeriodEntry 3 } My questions/thinking: - if indeed the length is ALWAYS 6, with only 2 octets of information, then why not define it as: OCTET STRING (SIZE(2)) - But since you need to represent BITS, I wonder why you do not use the BITS construct aka: ipSecRuleTimePeriodMonthOfYearMask OBJECT-TYPE SYNTAX BITS { january(0), february(1), march(2), ... december(11) } In fact I would make it a TC. It is a generic construct for Policy information. As you probably know, BITS does translate to an octet string of the proper size on the wire. 31.Similar questions for ipSecRuleTimePeriodDayOfMonthMask. ipSecRuleTimePeriodDayOfWeekMask I have similar questions 32.For ipSecRuleTimePeriodTimeOfDayMask I ahve similar questions as in point 29 above 33.ipSecRuleTimePeriodLocalOrUtcTime I can live with it. It does not always result in a 16bit unint as per RFC3060 sect 6.5.6, but can easily be converted to that. Agin, it would be good if defined as a TC. 34.The reason I suggest to define TCs for points 29-33, is that the same TCs can/should be used by the MIB defintion. Since the MIB wants to (and can) go stds track, there probably should be a separate POLICY-TC-MIB module that defines those TCs. 35.In fact, the whole TimePeriod... stuff seems so generic to any policy, that I would think it would also be in a separate module so that it can be re-used much easier. In fact the RFC3060 (and possibly RFC3460) should be separate modules that can be re-used by technology specific specifications and/or modules. I thought that that was the whole concept/idea of doing a PCIM and PCIMe. They would be CORE definitions upon which technology specific definitions (like IPsec and QoS) could/would build. Have we completely lost this idea/concept? 36.If I see it correctly, then every table has its own OBJECT-GROUP with a description clause of "Objects from the xxxTable." Is that the most logical grouping? I doubt it very much. Has any thought gone into this? 37.I will leave it to your security ADs to tell you about the security considerations section. But it seems to me that it is inadequate. 38.RFC-Editor considerations is incorrect. There are many more normative references. In any event, [9] has been published as RFC3318, as you indicate yoruself in ref section. ANdf ref [12] has been published as RFC3385, as you can see on your WG charter page. 39.IANA Considerations section - the 1st para is fine, except I would add a ptr to the iana web page that has the registry. Makes it easier for everyone - the 2nd para need to be formulated in the same way as 1st para. So that it is also readable after IAN has done the assignment. Pls also add ptr to the cirrect iana web page. Since this will result in a new revision, I propose to also add the proper IPR statements as per the new RFCs 3667/8/9 Bert From owner-ipsec-policy@mail.vpnc.org Tue Mar 16 10:54:18 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 KAA07473 for ; Tue, 16 Mar 2004 10:54:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GFO8Sr037742; Tue, 16 Mar 2004 07:24:08 -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 i2GFO8Ji037741; Tue, 16 Mar 2004 07:24:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GFO7BQ037732 for ; Tue, 16 Mar 2004 07:24:07 -0800 (PST) (envelope-from bwijnen@lucent.com) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2GFNxc27416 for ; Tue, 16 Mar 2004 09:24:00 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <169944FK>; Tue, 16 Mar 2004 16:23:58 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503DB0600@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Man.M.Li@nokia.com'" , "'bwijnen@lucent.com'" Cc: "'smb@research.att.com'" , "'ho@alum.mit.edu'" , "'lsanchez@xapiens.com'" , "'avri@apocalypse.org'" , "'ipsec-policy@vpnc.org'" Subject: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - gener al comment/question Date: Tue, 16 Mar 2004 16:23:56 +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: What I am missing in the prose section before the actual PIB definition is a desciption of how these PIB Classes match or fit to the PCIM (RFC3060), PCIMe (RFC3460), and IPsec IM (RFC3585). Maybe that is just me... but I thought that it should be easier to see the mapping (if it does exist). I would also expect a similar modularity (abstraction level) as in those 3 Information Model RFCs. Maybe that is just me ?? Thanks, Bert From owner-ipsec-policy@mail.vpnc.org Fri Mar 26 09:50:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22388 for ; Fri, 26 Mar 2004 09:50:38 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QEDwL6014992; Fri, 26 Mar 2004 06:13:58 -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 i2QEDw19014991; Fri, 26 Mar 2004 06:13:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QEDucd014984 for ; Fri, 26 Mar 2004 06:13:56 -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.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2QEDm219200 for ; Fri, 26 Mar 2004 08:13:50 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <16997V7P>; Fri, 26 Mar 2004 14:58:37 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503ED0855@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Man.M.Li@nokia.com'" Cc: "'smb@research.att.com'" , "'ho@alum.mit.edu'" , "'lsanchez@xapiens.com'" , "'avri@apocalypse.org'" , "'ipsec-policy@vpnc.org'" Subject: RE: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - p art 2 Date: Fri, 26 Mar 2004 14:58:34 +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 have to be very careful here (cause it took me many months before I finished my review; for which I again appologize). But once I have done the review, these things are kind of "fresh" in my mind/memory. If it takes a long time before you get to respond or send a new revision... things get swapped out, sometimes into a sort of off-site store... Thanks, Bert > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: dinsdag 16 maart 2004 15:49 > To: Man.M.Li@nokia.com; bwijnen@lucent.com > Cc: smb@research.att.com; ho@alum.mit.edu; lsanchez@xapiens.com; > avri@apocalypse.org; ipsec-policy@vpnc.org > Subject: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - > part 2 > > > Steve, you may want to pay specific attention to items 34-37. > > Addtional things I found when revieing revision 9 > > Comments 1-8 were in part 1 email of the review > > 9. Doing s smilint syntax check, I get the following: > > C:\smi\pibs\ietf>smilint -l 6 -s -m -inamelength-32 > ./IPSEC-POLICY-PIB > /IPSEC-POLICY-PIB:83: [5] {type-without-format} warning: type > `Unsigned16TC' has no format specification > simple to fix by adding a DISPLAY-HINT > > /IPSEC-POLICY-PIB:19: [5] {import-unused} warning: identifier > `zeroDotZero' imported from module `SNMPv2-SMI's never used > > simple to fix by removing zeroDotZero from the imports > > 10. I see a lot of acronyms in the document without expansion > (when used > for the first time. These maybe well know to security > folk, but not > to new readers. RFC-Editor wants them to be exanded first > time they > are used. Pls note that when PIB module is extracted, > previous text is > gone, and so it is probably wise to always expand in PIB > DESCRIPTION > clauses. > > 11. All RFCs that contain PIB or MIB modules from which you > IMPORT must > be normatively referenced. The RFC-Editor recently also > wanted such > references to have citations. The notatation we agreed on is > > IMPORTS > Unsigned32, Unsigned64, MODULE-IDENTITY, > OBJECT-TYPE, TEXTUAL-CONVENTION, MODULE-COMPLIANCE, > OBJECT-GROUP, pib > FROM COPS-PR-SPPI -- [RFC3159] > TruthValue > FROM SNMPv2-TC -- [RFC2579] > > and so on. But.. your references seem to be just numbered. > I Do not find > > OBJECT-GROUP, pib > FROM COPS-PR-SPPI -- [14] > > very acceptable. This is because when the PIB module gest > extracted, > then a "citation" of [14] does not help much. A Citation > of [RFC3159] > would still be clear for the reader (or so I think). > > 12. I see various ENUMERATIONS (e.g. INTEGERS) that probably would be > better represented as a TC. > For example: > > SYNTAX INTEGER { > in(1), > out(2), > bi-directional(3) > } > > and also > SYNTAX INTEGER { > copy(1), > set(2), > clear(3) > } > there are others. Those are just 2 examples. > > 13.I wonder if this is wise: > > Unsigned16TC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "An unsigned 16 bit integer." > SYNTAX Unsigned32 (0..65535) > > In some places its use seems OK. In many places, it is used > to indicate an "order" as in: > > ipSecRuleOrder OBJECT-TYPE > SYNTAX Unsigned16TC > STATUS current > DESCRIPTION > "Specifies the precedence order of the rule within > all the rules > associated with {IfName, Roles}. A smaller value indicates a > higher precedence order. " > ::= { ipSecRuleEntry 9 } > > I wonder if it would not be better to define a TC aka: > > IpSecOrderTC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION "An unsigned 16 bit integer that > defines the order > of a Rule or Set. A smaller value indicates a > higher precedence order." > SYNTAX Unsigned32 (0..65535) > > And then use that TC for all "order" objects. > > In the case of > ipSecAssociationDhGroup OBJECT-TYPE > SYNTAX Unsigned16TC > > I also wonder if a IpSecDhGroupTC would not be a wise thing. > > > 14.I see citations in DESCRIPTION clauses, as in: > > ipSecRuleIfName OBJECT-TYPE > SYNTAX SnmpAdminString > STATUS current > DESCRIPTION > "The interface capability set to which this IPsec rule applies. > The interface capability name specified by this attribute MUST > exist in the frwkCapabilitySetTable [9] prior to > association with > an instance of this class." > ::= { ipSecRuleEntry 2 } > > The [9] of course means nothing anymore when the PIB module gets > extracted. If you used a notation ala [RFCxxxx] then it would still > mean something in an extracted module. > > 15.In the ipSecXxxTable DESCRIPTION clauses you use text aka: > "This table ...." > In all other PIB modules that the IETF has published sofar, we did > not talk about a table but either of a PRC (Policy Rule Class) or > just class. See the DIFFSERV-PIB and the FRAMEWORK-PIB for example. > I think that changing this so as to be consistent is a GOOD THING. > > 16.In the DESCRIPTION clause of: > ipSecActionSetDoPacketLogging OBJECT-TYPE > SYNTAX TruthValue > STATUS current > DESCRIPTION > "Specifies whether to log when the resulting security > association > is used to process a packet. For ipSecStaticActions, a > log message > is to be generated when the IPsecBypass, IpsecDiscard > or IKEReject > actions are executed." > ::= { ipSecActionSetEntry 5 } > > I wonder if "IPsecBypass, IpsecDiscard or IKEReject" are meant to > mean the same thing as the enumerations in: > > ipSecStaticActionAction OBJECT-TYPE > SYNTAX INTEGER { > byPass(1), > discard(2), > ikeRejection(3), > preConfiguredTransport(4), > preConfiguredTunnel(5) > } > STATUS current > > If so, then you may want to sync up the labels. > > 17.I see: > ipSecAssociationUseKeyExchangeGroup OBJECT-TYPE > SYNTAX TruthValue > STATUS current > DESCRIPTION > "Specifies whether or not to use the same GroupId for > phase 2 as > was used in phase 1. If UsePFS is false, then this > attribute is > ignored. > > A value of true indicates that the phase 2 GroupId > should be the > same as phase 1. A value of false indicates that the > group number > specified by the ipSecSecurityAssociationDhGroup > attribute SHALL > be used for phase 2. " > ::= { ipSecAssociationEntry 7 } > > And wonder if ipSecSecurityAssociationDhGroup is mean to point to: > > ipSecAssociationDhGroup OBJECT-TYPE > SYNTAX Unsigned16TC > STATUS current > DESCRIPTION > "Specifies the key exchange group to use for phase 2 when the > property ipSecSecurityAssociationUsePfs is true and > the property > ipSecSecurityAssociationUseKeyExchangeGroup is false." > ::= { ipSecAssociationEntry 8 } > > If so, then better sync up the descriptors. > If not, then where is ipSecSecurityAssociationDhGroup defined? > By the way, in the last object, there are also a few descriptors > that start with ipSecSecurityAssociation.... and that I > cannot find. > Again, probably s/Security// ?? > > 18.I see: > ipSecAhTransformReplayPreventionWindowSize OBJECT-TYPE > SYNTAX Unsigned32 > STATUS current > DESCRIPTION > "Specifies, in bits, the length of the sliding window > used by the > replay prevention detection mechanism. The value of > this property > is ignored if UseReplayPrevention is false. It is > assumed that the > window size will be power of 2." > ::= { ipSecAhTransformEntry 5 } > Might be good to add a UNITS clause? > But I also wonder what "window size will be power of 2" means? > > 19.ipSecEspTransformCipherKeyLength, > ipSecEspTransformReplayPreventionWindowSize > and may be others can also use a UNITS clause > > 20.In Table/Class ipSecCompTransformTable I see > ipSecCompTransformAlgorithm > and also ipSecCompTransformPrivateAlgorithm. Canthey both > be specified > for the same instance? If so, what happens? If not, can you make > that clear? If yes, you may want to explain also what happens. > > 21.ipSecIkeRuleTable is probably talking about IKEv1 ?? > Should that be made clear? > What sort of change do we expect for IKEv2? > WOuld it make sense to define this "optional" class in a separate > document? > In any event, you do not put in the DESCRIPTION clause > that this table/class > is optional. That is expressed (and even in machine > readable form) in the > MODULE-COMPLIACNE. > > 22.I am really wondering and worried about some of the > UNIQUENESS clauses > that require many columns/attributes to define uniqueness. > But ipSecIkeAssociationEntry really seems excessive to me. > It states > that ALL attributes need to be checked for unqiueness !!??? > Is that really intended? > You may want to check all tables/classes in fact. > > 23.ipSecIkeAssociationVendorId is an OCTET STRING and the > descripiton clause > talks about a vlaue of NULL. That is not clear! Better is > to talk about > a zero length OCTET STRING. That is clear! > > 24.I see: > ipSecIkeProposalPrfAlgorithm OBJECT-TYPE > SYNTAX Unsigned16TC > STATUS current > DESCRIPTION > "Specifies the Psuedo-Random Function (PRF) to propose > for the IKE > association." > ::= { ipSecIkeProposalEntry 7 } > So where do I find what any value means? > And would it not be better to have a separate TC fo such algorithm > values? And pls add REFERENCE clause to point to it. > > 24.Similar question for ipSecIkeProposalIkeDhGroup > And pls add REFERENCE clause to point to it. > > 25.IN ipSecIkePeerEndpointIdentityValue you are using IP addresses as > example. But you must use the ange of addresses that has been > allocated for examples as per ID-NITs > http://www.ietf.org/ID-nits.html > which states: > > Addresses used in examples should prefer use of fully > qualified > domain names to literal IP addresses, and prefer use > of example > fqdn's such as foo.example.com to real-world fqdn's. > See RFC 2606 > for example domain names that can be used. There is > also a range > of IP addresses set aside for this purpose. These are > 192.0.2.0/24 > (see RFC 3330). Private addressess that would be used > in the real > world should be avoided in examples. > > 26.Object ipSecCredentialFieldsValue is defined as an OCTET STRING. > However, reading the DESCRIPTION clause, it feels as if this is > a string that will be used/read by human beings. In that case, it > must be a UTF-8 string. Possibly a SnmpAdminString or some other > TC that defines UTF-8 text. > > 27.When I read the ipSecSelectorTable and related tables, > then I really > wonder if you guys have really evaluated the possible re-use of the > frwkIpFilterTable in the FRAMEWORK-PIB !!?? > I thought that that framework filter table was meant to be re-used > by many (if not all) filter/selector uses. > > 28.I have trouble understanding the ipSecIpsoFilterSetTable > I bet it is cause by the very short DESCRIPTION clauses that do not > mean much to me (and so probably do not mean much to other > non-expert > readers). > > 29.When I see ipSecRuleTimePeriodTimePeriod defined as an OCTET STRING > then I wonder. It claims to be RFC2445 format (as RFC3060 also > prescribes). There they talk about a string. > I think it is US-ASCII, possibly represented as UTF-8 ?? > I need to go and check to be sure. In any event, if you > say OCTET STRING > and specify that THISANDPRIOR has special meaning, then it > needs to be > clear what encoding needs to be used for that text. > A SIZE specification may also make sense (or so I think). > This is a generic Policy construct, which probably even > warrants a TC. > > 30.I do not understand > ipSecRuleTimePeriodMonthOfYearMask OBJECT-TYPE > SYNTAX OCTET STRING > STATUS current > DESCRIPTION > "An octet string that specifies which months the policy is valid > for. The octet string is structured as follows: > > - a 4-octet length field, indicating the length of the entire > octet string; this field is always set to 0x00000006 for this > property; > > - a 2-octet field consisting of 12 bits identifying > the 12 months > of the year, beginning with January and ending with December, > followed by 4 bits that are always set to '0'. For > each month, > the value '1' indicates that the policy is valid for > that month, > and the value '0' indicates that it is not valid. > > If this property is omitted, then the policy rule is treated as > valid for all twelve months." > ::= { ipSecRuleTimePeriodEntry 3 } > > My questions/thinking: > - if indeed the length is ALWAYS 6, with only 2 octets of > information, > then why not define it as: OCTET STRING (SIZE(2)) > - But since you need to represent BITS, I wonder why you do not > use the BITS construct aka: > ipSecRuleTimePeriodMonthOfYearMask OBJECT-TYPE > SYNTAX BITS { > january(0), > february(1), > march(2), > ... > december(11) > } > In fact I would make it a TC. It is a generic construct for Policy > information. As you probably know, BITS does translate to an > octet string of the proper size on the wire. > > 31.Similar questions for ipSecRuleTimePeriodDayOfMonthMask. > ipSecRuleTimePeriodDayOfWeekMask I have similar questions > > 32.For ipSecRuleTimePeriodTimeOfDayMask I ahve similar questions as > in point 29 above > > 33.ipSecRuleTimePeriodLocalOrUtcTime > I can live with it. It does not always result in a 16bit unint > as per RFC3060 sect 6.5.6, but can easily be converted to that. > Agin, it would be good if defined as a TC. > > 34.The reason I suggest to define TCs for points 29-33, is that the > same TCs can/should be used by the MIB defintion. Since the MIB > wants to (and can) go stds track, there probably should be a > separate POLICY-TC-MIB module that defines those TCs. > > 35.In fact, the whole TimePeriod... stuff seems so generic to any > policy, that I would think it would also be in a separate module > so that it can be re-used much easier. > In fact the RFC3060 (and possibly RFC3460) should be separate > modules that can be re-used by technology specific specifications > and/or modules. I thought that that was the whole concept/idea of > doing a PCIM and PCIMe. They would be CORE definitions upon which > technology specific definitions (like IPsec and QoS) could/would > build. Have we completely lost this idea/concept? > > 36.If I see it correctly, then every table has its own OBJECT-GROUP > with a description clause of "Objects from the xxxTable." > Is that the most logical grouping? I doubt it very much. > Has any thought gone into this? > > 37.I will leave it to your security ADs to tell you about the security > considerations section. But it seems to me that it is inadequate. > > 38.RFC-Editor considerations is incorrect. There are many more > normative references. In any event, [9] has been published as > RFC3318, as you indicate yoruself in ref section. ANdf ref [12] > has been published as RFC3385, as you can see on your WG > charter page. > > 39.IANA Considerations section > - the 1st para is fine, except I would add a ptr to the > iana web page > that has the registry. Makes it easier for everyone > - the 2nd para need to be formulated in the same way as 1st para. > So that it is also readable after IAN has done the assignment. > Pls also add ptr to the cirrect iana web page. > > Since this will result in a new revision, I propose to also add the > proper IPR statements as per the new RFCs 3667/8/9 > > Bert > From owner-ipsec-policy@mail.vpnc.org Fri Mar 26 10:06:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23554 for ; Fri, 26 Mar 2004 10:06:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QEYlBS016060; Fri, 26 Mar 2004 06:34:47 -0800 (PST) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QEYlOl016059; Fri, 26 Mar 2004 06:34:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QEYg6J016053 for ; Fri, 26 Mar 2004 06:34:46 -0800 (PST) (envelope-from Man.M.Li@nokia.com) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2QEYSD06578; Fri, 26 Mar 2004 16:34:28 +0200 (EET) X-Scanned: Fri, 26 Mar 2004 16:32:46 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i2QEWkwo008219; Fri, 26 Mar 2004 16:32:46 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00q6J2Ho; Fri, 26 Mar 2004 16:32:45 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 i2QEWhs18577; Fri, 26 Mar 2004 16:32:43 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 26 Mar 2004 08:32:41 -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: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - part 2 Date: Fri, 26 Mar 2004 09:32:41 -0500 Message-ID: Thread-Topic: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - part 2 Thread-Index: AcQTPhxbEnDN4b3BSbifjQo5mkFCsAAAJUwA From: To: Cc: , , , , X-OriginalArrivalTime: 26 Mar 2004 14:32:41.0826 (UTC) FILETIME=[32235420:01C4133F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2QEYl6J016054 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Bert, Thanks for your comments and no need to worry since I am working on the draft. Will submit a new version when I finish. Best regards Man Li -----Original Message----- From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Friday, March 26, 2004 8:59 AM To: Li Man.M (Nokia-NRC/Boston) Cc: 'smb@research.att.com'; 'ho@alum.mit.edu'; 'lsanchez@xapiens.com'; 'avri@apocalypse.org'; 'ipsec-policy@vpnc.org' Subject: RE: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - part 2 I have to be very careful here (cause it took me many months before I finished my review; for which I again appologize). But once I have done the review, these things are kind of "fresh" in my mind/memory. If it takes a long time before you get to respond or send a new revision... things get swapped out, sometimes into a sort of off-site store... Thanks, Bert > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: dinsdag 16 maart 2004 15:49 > To: Man.M.Li@nokia.com; bwijnen@lucent.com > Cc: smb@research.att.com; ho@alum.mit.edu; lsanchez@xapiens.com; > avri@apocalypse.org; ipsec-policy@vpnc.org > Subject: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - > part 2 > > > Steve, you may want to pay specific attention to items 34-37. > > Addtional things I found when revieing revision 9 > > Comments 1-8 were in part 1 email of the review > > 9. Doing s smilint syntax check, I get the following: > > C:\smi\pibs\ietf>smilint -l 6 -s -m -inamelength-32 > ./IPSEC-POLICY-PIB > /IPSEC-POLICY-PIB:83: [5] {type-without-format} warning: type > `Unsigned16TC' has no format specification > simple to fix by adding a DISPLAY-HINT > > /IPSEC-POLICY-PIB:19: [5] {import-unused} warning: identifier > `zeroDotZero' imported from module `SNMPv2-SMI's never used > > simple to fix by removing zeroDotZero from the imports > > 10. I see a lot of acronyms in the document without expansion > (when used > for the first time. These maybe well know to security > folk, but not > to new readers. RFC-Editor wants them to be exanded first > time they > are used. Pls note that when PIB module is extracted, > previous text is > gone, and so it is probably wise to always expand in PIB > DESCRIPTION > clauses. > > 11. All RFCs that contain PIB or MIB modules from which you > IMPORT must > be normatively referenced. The RFC-Editor recently also > wanted such > references to have citations. The notatation we agreed on is > > IMPORTS > Unsigned32, Unsigned64, MODULE-IDENTITY, > OBJECT-TYPE, TEXTUAL-CONVENTION, MODULE-COMPLIANCE, > OBJECT-GROUP, pib > FROM COPS-PR-SPPI -- [RFC3159] > TruthValue > FROM SNMPv2-TC -- [RFC2579] > > and so on. But.. your references seem to be just numbered. > I Do not find > > OBJECT-GROUP, pib > FROM COPS-PR-SPPI -- [14] > > very acceptable. This is because when the PIB module gest > extracted, > then a "citation" of [14] does not help much. A Citation > of [RFC3159] > would still be clear for the reader (or so I think). > > 12. I see various ENUMERATIONS (e.g. INTEGERS) that probably would be > better represented as a TC. > For example: > > SYNTAX INTEGER { > in(1), > out(2), > bi-directional(3) > } > > and also > SYNTAX INTEGER { > copy(1), > set(2), > clear(3) > } > there are others. Those are just 2 examples. > > 13.I wonder if this is wise: > > Unsigned16TC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "An unsigned 16 bit integer." > SYNTAX Unsigned32 (0..65535) > > In some places its use seems OK. In many places, it is used > to indicate an "order" as in: > > ipSecRuleOrder OBJECT-TYPE > SYNTAX Unsigned16TC > STATUS current > DESCRIPTION > "Specifies the precedence order of the rule within > all the rules > associated with {IfName, Roles}. A smaller value indicates a > higher precedence order. " > ::= { ipSecRuleEntry 9 } > > I wonder if it would not be better to define a TC aka: > > IpSecOrderTC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION "An unsigned 16 bit integer that > defines the order > of a Rule or Set. A smaller value indicates a > higher precedence order." > SYNTAX Unsigned32 (0..65535) > > And then use that TC for all "order" objects. > > In the case of > ipSecAssociationDhGroup OBJECT-TYPE > SYNTAX Unsigned16TC > > I also wonder if a IpSecDhGroupTC would not be a wise thing. > > > 14.I see citations in DESCRIPTION clauses, as in: > > ipSecRuleIfName OBJECT-TYPE > SYNTAX SnmpAdminString > STATUS current > DESCRIPTION > "The interface capability set to which this IPsec rule applies. > The interface capability name specified by this attribute MUST > exist in the frwkCapabilitySetTable [9] prior to > association with > an instance of this class." > ::= { ipSecRuleEntry 2 } > > The [9] of course means nothing anymore when the PIB module gets > extracted. If you used a notation ala [RFCxxxx] then it would still > mean something in an extracted module. > > 15.In the ipSecXxxTable DESCRIPTION clauses you use text aka: > "This table ...." > In all other PIB modules that the IETF has published sofar, we did > not talk about a table but either of a PRC (Policy Rule Class) or > just class. See the DIFFSERV-PIB and the FRAMEWORK-PIB for example. > I think that changing this so as to be consistent is a GOOD THING. > > 16.In the DESCRIPTION clause of: > ipSecActionSetDoPacketLogging OBJECT-TYPE > SYNTAX TruthValue > STATUS current > DESCRIPTION > "Specifies whether to log when the resulting security > association > is used to process a packet. For ipSecStaticActions, a > log message > is to be generated when the IPsecBypass, IpsecDiscard > or IKEReject > actions are executed." > ::= { ipSecActionSetEntry 5 } > > I wonder if "IPsecBypass, IpsecDiscard or IKEReject" are meant to > mean the same thing as the enumerations in: > > ipSecStaticActionAction OBJECT-TYPE > SYNTAX INTEGER { > byPass(1), > discard(2), > ikeRejection(3), > preConfiguredTransport(4), > preConfiguredTunnel(5) > } > STATUS current > > If so, then you may want to sync up the labels. > > 17.I see: > ipSecAssociationUseKeyExchangeGroup OBJECT-TYPE > SYNTAX TruthValue > STATUS current > DESCRIPTION > "Specifies whether or not to use the same GroupId for > phase 2 as > was used in phase 1. If UsePFS is false, then this > attribute is > ignored. > > A value of true indicates that the phase 2 GroupId > should be the > same as phase 1. A value of false indicates that the > group number > specified by the ipSecSecurityAssociationDhGroup > attribute SHALL > be used for phase 2. " > ::= { ipSecAssociationEntry 7 } > > And wonder if ipSecSecurityAssociationDhGroup is mean to point to: > > ipSecAssociationDhGroup OBJECT-TYPE > SYNTAX Unsigned16TC > STATUS current > DESCRIPTION > "Specifies the key exchange group to use for phase 2 when the > property ipSecSecurityAssociationUsePfs is true and > the property > ipSecSecurityAssociationUseKeyExchangeGroup is false." > ::= { ipSecAssociationEntry 8 } > > If so, then better sync up the descriptors. > If not, then where is ipSecSecurityAssociationDhGroup defined? > By the way, in the last object, there are also a few descriptors > that start with ipSecSecurityAssociation.... and that I > cannot find. > Again, probably s/Security// ?? > > 18.I see: > ipSecAhTransformReplayPreventionWindowSize OBJECT-TYPE > SYNTAX Unsigned32 > STATUS current > DESCRIPTION > "Specifies, in bits, the length of the sliding window > used by the > replay prevention detection mechanism. The value of > this property > is ignored if UseReplayPrevention is false. It is > assumed that the > window size will be power of 2." > ::= { ipSecAhTransformEntry 5 } > Might be good to add a UNITS clause? > But I also wonder what "window size will be power of 2" means? > > 19.ipSecEspTransformCipherKeyLength, > ipSecEspTransformReplayPreventionWindowSize > and may be others can also use a UNITS clause > > 20.In Table/Class ipSecCompTransformTable I see > ipSecCompTransformAlgorithm > and also ipSecCompTransformPrivateAlgorithm. Canthey both > be specified > for the same instance? If so, what happens? If not, can you make > that clear? If yes, you may want to explain also what happens. > > 21.ipSecIkeRuleTable is probably talking about IKEv1 ?? > Should that be made clear? > What sort of change do we expect for IKEv2? > WOuld it make sense to define this "optional" class in a separate > document? > In any event, you do not put in the DESCRIPTION clause > that this table/class > is optional. That is expressed (and even in machine > readable form) in the > MODULE-COMPLIACNE. > > 22.I am really wondering and worried about some of the > UNIQUENESS clauses > that require many columns/attributes to define uniqueness. > But ipSecIkeAssociationEntry really seems excessive to me. > It states > that ALL attributes need to be checked for unqiueness !!??? > Is that really intended? > You may want to check all tables/classes in fact. > > 23.ipSecIkeAssociationVendorId is an OCTET STRING and the > descripiton clause > talks about a vlaue of NULL. That is not clear! Better is > to talk about > a zero length OCTET STRING. That is clear! > > 24.I see: > ipSecIkeProposalPrfAlgorithm OBJECT-TYPE > SYNTAX Unsigned16TC > STATUS current > DESCRIPTION > "Specifies the Psuedo-Random Function (PRF) to propose > for the IKE > association." > ::= { ipSecIkeProposalEntry 7 } > So where do I find what any value means? > And would it not be better to have a separate TC fo such algorithm > values? And pls add REFERENCE clause to point to it. > > 24.Similar question for ipSecIkeProposalIkeDhGroup > And pls add REFERENCE clause to point to it. > > 25.IN ipSecIkePeerEndpointIdentityValue you are using IP addresses as > example. But you must use the ange of addresses that has been > allocated for examples as per ID-NITs > http://www.ietf.org/ID-nits.html > which states: > > Addresses used in examples should prefer use of fully > qualified > domain names to literal IP addresses, and prefer use > of example > fqdn's such as foo.example.com to real-world fqdn's. > See RFC 2606 > for example domain names that can be used. There is > also a range > of IP addresses set aside for this purpose. These are > 192.0.2.0/24 > (see RFC 3330). Private addressess that would be used > in the real > world should be avoided in examples. > > 26.Object ipSecCredentialFieldsValue is defined as an OCTET STRING. > However, reading the DESCRIPTION clause, it feels as if this is > a string that will be used/read by human beings. In that case, it > must be a UTF-8 string. Possibly a SnmpAdminString or some other > TC that defines UTF-8 text. > > 27.When I read the ipSecSelectorTable and related tables, > then I really > wonder if you guys have really evaluated the possible re-use of the > frwkIpFilterTable in the FRAMEWORK-PIB !!?? > I thought that that framework filter table was meant to be re-used > by many (if not all) filter/selector uses. > > 28.I have trouble understanding the ipSecIpsoFilterSetTable > I bet it is cause by the very short DESCRIPTION clauses that do not > mean much to me (and so probably do not mean much to other > non-expert > readers). > > 29.When I see ipSecRuleTimePeriodTimePeriod defined as an OCTET STRING > then I wonder. It claims to be RFC2445 format (as RFC3060 also > prescribes). There they talk about a string. > I think it is US-ASCII, possibly represented as UTF-8 ?? > I need to go and check to be sure. In any event, if you > say OCTET STRING > and specify that THISANDPRIOR has special meaning, then it > needs to be > clear what encoding needs to be used for that text. > A SIZE specification may also make sense (or so I think). > This is a generic Policy construct, which probably even > warrants a TC. > > 30.I do not understand > ipSecRuleTimePeriodMonthOfYearMask OBJECT-TYPE > SYNTAX OCTET STRING > STATUS current > DESCRIPTION > "An octet string that specifies which months the policy is valid > for. The octet string is structured as follows: > > - a 4-octet length field, indicating the length of the entire > octet string; this field is always set to 0x00000006 for this > property; > > - a 2-octet field consisting of 12 bits identifying > the 12 months > of the year, beginning with January and ending with December, > followed by 4 bits that are always set to '0'. For > each month, > the value '1' indicates that the policy is valid for > that month, > and the value '0' indicates that it is not valid. > > If this property is omitted, then the policy rule is treated as > valid for all twelve months." > ::= { ipSecRuleTimePeriodEntry 3 } > > My questions/thinking: > - if indeed the length is ALWAYS 6, with only 2 octets of > information, > then why not define it as: OCTET STRING (SIZE(2)) > - But since you need to represent BITS, I wonder why you do not > use the BITS construct aka: > ipSecRuleTimePeriodMonthOfYearMask OBJECT-TYPE > SYNTAX BITS { > january(0), > february(1), > march(2), > ... > december(11) > } > In fact I would make it a TC. It is a generic construct for Policy > information. As you probably know, BITS does translate to an > octet string of the proper size on the wire. > > 31.Similar questions for ipSecRuleTimePeriodDayOfMonthMask. > ipSecRuleTimePeriodDayOfWeekMask I have similar questions > > 32.For ipSecRuleTimePeriodTimeOfDayMask I ahve similar questions as > in point 29 above > > 33.ipSecRuleTimePeriodLocalOrUtcTime > I can live with it. It does not always result in a 16bit unint > as per RFC3060 sect 6.5.6, but can easily be converted to that. > Agin, it would be good if defined as a TC. > > 34.The reason I suggest to define TCs for points 29-33, is that the > same TCs can/should be used by the MIB defintion. Since the MIB > wants to (and can) go stds track, there probably should be a > separate POLICY-TC-MIB module that defines those TCs. > > 35.In fact, the whole TimePeriod... stuff seems so generic to any > policy, that I would think it would also be in a separate module > so that it can be re-used much easier. > In fact the RFC3060 (and possibly RFC3460) should be separate > modules that can be re-used by technology specific specifications > and/or modules. I thought that that was the whole concept/idea of > doing a PCIM and PCIMe. They would be CORE definitions upon which > technology specific definitions (like IPsec and QoS) could/would > build. Have we completely lost this idea/concept? > > 36.If I see it correctly, then every table has its own OBJECT-GROUP > with a description clause of "Objects from the xxxTable." > Is that the most logical grouping? I doubt it very much. > Has any thought gone into this? > > 37.I will leave it to your security ADs to tell you about the security > considerations section. But it seems to me that it is inadequate. > > 38.RFC-Editor considerations is incorrect. There are many more > normative references. In any event, [9] has been published as > RFC3318, as you indicate yoruself in ref section. ANdf ref [12] > has been published as RFC3385, as you can see on your WG > charter page. > > 39.IANA Considerations section > - the 1st para is fine, except I would add a ptr to the > iana web page > that has the registry. Makes it easier for everyone > - the 2nd para need to be formulated in the same way as 1st para. > So that it is also readable after IAN has done the assignment. > Pls also add ptr to the cirrect iana web page. > > Since this will result in a new revision, I propose to also add the > proper IPR statements as per the new RFCs 3667/8/9 > > Bert > From owner-ipsec-policy@mail.vpnc.org Tue Mar 30 13:19:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03790 for ; Tue, 30 Mar 2004 13:19:27 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UHkXiV031085; Tue, 30 Mar 2004 09:46:33 -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 i2UHkXOl031084; Tue, 30 Mar 2004 09:46:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UHkVPW031075 for ; Tue, 30 Mar 2004 09:46:31 -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-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2UHkSu11217; Tue, 30 Mar 2004 20:46:28 +0300 (EET DST) X-Scanned: Tue, 30 Mar 2004 20:45:25 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2UHjPZc022536; Tue, 30 Mar 2004 20:45:25 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00Qf18rW; Tue, 30 Mar 2004 20:45:24 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2UHjIF11894; Tue, 30 Mar 2004 20:45:18 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 30 Mar 2004 11:45:10 -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: TimePeriod (Was RE: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - part 2) Date: Tue, 30 Mar 2004 12:45:07 -0500 Message-ID: Thread-Topic: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - part 2 Thread-Index: AcQLZn2IR67aMuhfRzi2n6nccWN0OwKVml9g From: To: Cc: , , , , X-OriginalArrivalTime: 30 Mar 2004 17:45:10.0035 (UTC) FILETIME=[BF0F2E30:01C4167E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2UHkWPW031079 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Regarding this comment from Bert: "35.In fact, the whole TimePeriod... stuff seems so generic to any policy, that I would think it would also be in a separate module so that it can be re-used much easier. In fact the RFC3060 (and possibly RFC3460) should be separate modules that can be re-used by technology specific specifications and/or modules. I thought that that was the whole concept/idea of doing a PCIM and PCIMe. They would be CORE definitions upon which technology specific definitions (like IPsec and QoS) could/would build. Have we completely lost this idea/concept? " I agree with Bert that the TimePeriod is generic. If we separate this to another PIB module, is the ipsp group (or anywhere in IETF) willing to accommodate another PIB draft? If not, I'll leave it inside IPsec PIB since in most cases IPsec policy specification needs to be associated with time periods. Best regards Man