Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends
"C. M. Heard" <heard@pobox.com> Sat, 14 June 2003 00:03 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29186 for <ipsec-archive@lists.ietf.org>; Fri, 13 Jun 2003 20:03:12 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22098 Fri, 13 Jun 2003 18:13:10 -0400 (EDT)
X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs
Date: Fri, 13 Jun 2003 15:19:12 -0700
From: "C. M. Heard" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: ipsec@lists.tislabs.com
cc: Bert Wijnen <bwijnen@lucent.com>
Subject: Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends
In-Reply-To: <3EEA10F7.1070402@sockeye.com>
Message-ID: <Pine.LNX.4.10.10306131211140.13801-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
[ Discussion moved to IPsec list at Barbare Fraser's request. ] On Fri, 13 Jun 2003, John Shriver wrote: JS> Wes Hardaker wrote: JS> > John> So, IPSP folks (you are on the CC: list, right?), do you JS> > John> still want this MIB without the enumerations? If so, JS> > John> I'll make Mike's changes, and ship it out again. JS> > JS> > I'd do it just because it still provides a standard convention JS> > for the datatypes and a standard place where the documentation JS> > about them can be listed. However, I agree it's less useful JS> > with the enums removed. JS> > JS> JS> Well, I will go ahead and do those changes. I've even been working JS> on MIBs in my paying job recently. Sounds good. JS> >>>draft-ietf-ipsec-ike-monitor-mib-04.txt, JS> >>>draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and JS> >>>draft-ietf-ipsec-monitor-mib-06.txt? JS> >> JS> > JS> > John> I think we can let them die, unless someone someone is JS> > John> wanting them. JS> > JS> > I think they'd be useful, but I haven't read them recently. The JS> > concepts in them are definitely needed and I've spoken to various JS> > people lately about them and they agree that they'd be useful to put JS> > into their products. However, that doesn't mean they will. JS> > JS> JS> If we were to keep them alive, they would need to migrate to IKEv2, JS> which is no small project. I don't see any point in MIB-ing IKEv1. JS> JS> There would need to be authors who were committed to implementing it. On the other hand, there is an author committed to finishing off the IPsec Flow Monitor MIB module: >>>>> On Fri, 13 Jun 2003 rks@cisco.com wrote: RKS> We are still pursuing the IPsec Flow Monitor for standard track. RKS> Could you please list the TopN good points of the drafts listed RKS> above which may be incoprorated into the Flow Monitor MIB? RKS> RKS> I know you dissected at length the Flow Monitor MIB in 2001. RKS> While I have read that (and addressed many of those criticisms RKS> in the latest draft), I am hoping you could identify what features RKS> of the MIBs listed above we could borrow into the Flow Monitor MIB. Currently there is a flow monitor TC MIB that duplicates a lot of the functionality of John's DOI TC MIB, which would be hard to accept, but the flow mon mib author has indicated that he's willing to switch: >>>>> On Mon, 9 Jun 2003 rks@cisco.com wrote: RKS> All that is of course irrelevant in addressing your comment about RKS> duplication. I am quite willing to base the Flow Monitor MIB on the RKS> textual conventions defined in draft-ietf-ipsec-doi-tc-mib-07.txt RKS> provided it accomodates the textual convention defining the Control RKS> Protocol: the IPsec Flow MIB can support different keying protocols RKS> based on ISAKMP (termed 'control protocol') and uses a distinct TC RKS> to type this value. Actually, there are two TCs in the flow monitor TC MIB that are not accounted for. One is ControlProtocol, mentioned above, and the other is Spi. After looking over the Flow Monitor MIB in more detail, I see that ControlProtocol (formerly named KeyType) does not represent an actual field in a PDU whose value is defined in an IANA registry -- which is the case for everything currently defined in the DOI TC MIB -- but instead just serves to identify keying and control protocols in the flow monitor MIB. In my opinion a TC local to the IPsec Flow monitor MIB (preferably with a less generic a name like IPsecFlowMonControlProto) would suffice for that purpose. If it is really supposed to reflect the content of an IANA registry, then there is already such a TC in the DOI TC MIB; it is called IpsecDoiTransformIdent, and it represents values recorded the "IPSEC ISAKMP Transform Identifiers" entry in the IANA registry http://www.iana.org//assignments/isakmp-registry Now, the Spi TC (as I understand it) is supposed to represent possible SPI values for AH (RFC 2402), ESP (RFC 2406), and IPComp (RFC 3173). The IANA registry http://www.iana.org//assignments/spi-numbers captures the special values for AH and ESP. For IPComp the special values are different: they are "IPCOMP Transform identifiers" and are recorded in http://www.iana.org//assignments/isakmp-registry (and represented in MIBs by DOI TC IpsecDoiIpcompTransform). However, the SYNTAX of Spi is Unsigned32 (256..4294967295) which excludes all the special values. So, again, this TC is unaffected by the contents of IANA registries it seems to me that it would be more appropriate to use a TC that is local to the IPsec Flow Monitor MIB rather than putting it in the DOI TC MIB. In other words, I don't think that the DOI TC MIB should have to change to accomodate these two TCs because (unlike all the stuff currently in the DOI TC MIB) these things aren't linked 1-for-1 with something in one of the IPsec-related IANA registries. RKS, can you live with these two TCs being defined locally in the IPsec Flow Monitor MIB? >>>>> On Mon, 9 Jun 2003, C. M. Heard wrote (off-list): CMH> John -- [ ... ] CMH> If the decision is made to abandon the following three drafts: CMH> CMH> draft-ietf-ipsec-ike-monitor-mib-04.txt, CMH> draft-ietf-ipsec-isakmp-di-mon-mib-05.txt CMH> draft-ietf-ipsec-monitor-mib-06.txt CMH> CMH> then you should consider removing the TCs that are not used by CMH> either the IPSP MIB or the IPsec Flow MIB. Those would be: CMH> CMH> IpsecDoiSituation CMH> IpsecDoiTransformIdent CMH> IpsecDoiAhTransform CMH> IsakmpDOI CMH> IsakmpCertificateEncoding CMH> IsakmpExchangeType CMH> IsakmpNotifyMessageType CMH> IkeGroupType CMH> IkePrf CMH> IkeNotifyMessageType Because of some stuff I've found in the client MIBs I am going to back-pedal a little bit on this advice. Specifically, in the IPSP MIB I see: ipspAhTransformTable OBJECT-TYPE SYNTAX SEQUENCE OF IpspAhTransformEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists all the AH transforms which can be used to build IPsec proposals." [ ... ] ipspAhTranAlgorithm OBJECT-TYPE SYNTAX IpsecDoiAuthAlgorithm MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the AH algorithm for this transform." Based on the followind DESCRIPTION clause, it seems to me that the SYNTAX value of ipspAhTranAlgorithm should probably be IpsecDoiAhTransform: IpsecDoiAhTransform ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The values of the IPsec DOI AH Transform Identifier which identify a particular algorithm to be used to provide integrity protection for AH. It is used in the Tranform-ID field of a ISAKMP Transform Payload for the IPsec DOI, when the Protocol-Id of the associated Proposal Payload is 2 (AH). (I also notices that the IPSP object ipspEspTranIntegrityAlgorithmId has a SYNTAX value of IpsecDoiAuthAlgorithm, but that seems to be correct.) So before anything actually gets removed, I would like to suggest that the authors of the IPSP MIB and IPsec flow monitoring MIB check their stuff very carefully for errors like this. Finally, I noticed something in the DOI TC MIB that appears to be erroneous, and which I did not flag in the previous MIB doctor review: IpsecDoiEspTransform ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The values of the IPsec DOI ESP Transform Identifier which identify a particular algorithm to be used to provide secrecy protection for ESP. It is used in the Tranform-ID field of a ISAKMP Transform Payload for the IPsec DOI, when the Protocol-Id of the associated Proposal Payload is 2 (AH), 3 (ESP), and 4 (IPCOMP). ^^^^^^ bug??? Since this and IpsecDoiAhTransform have different values, they can't both apply then the Protocol-Id of the associated Proposal Payload is 2 (AH). Thanks, Mike Heard
- draft-ietf-ipsec-doi-tc-mib-07.txt and friends Barbara Fraser
- Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends The Purple Streak, Hilarie Orman
- Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends John Shriver
- Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends Wes Hardaker
- Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends John Shriver
- Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends C. M. Heard