[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends



[ 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