Subject: FW: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Sat, 5 Apr 2003 14:23:04 -0700

This is relevant to both IPSP and IPSec.

Hilarie

  ---Forwarded Message Follows---
To: IPsec WG <[email-masked]>
cc: "Wijnen, Bert (Bert)" <[email-masked]>
Subject: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt

IPsec folks,

I've been commissioned to do the MIB doctor review for
<draft-ietf-ipsec-doi-tc-mib-07.txt> but before I spend a lot of
time discussing the details I'd like to ask a very basic (and I
think very important) question.

If I correctly understand what I have read, the main content of this
draft is a set of enumerated INTEGER TCs that represent the values
of fields in IPsec-related protocol messages.  However, in many of
these TCs (all, in fact, except for IsakmpCertificateEncoding) the
DESCRIPTION clause (or the underlying reference document) has a
statement to the effect that certain ranges of values are "reserved
for private use amongst cooperating systems."  Such values do not
presently appear as named numbers in the enumeration list, and my
understanding is that they will never appear in the enumeration list
since they are not subject to assignment by the IANA.

The WG needs to be aware that (according to RFC 2578 Section 7.1.1)
the only values allowed for objects defined with these enumerated
INTEGER TCs are the named numbers that are actually present in the
enumeration list.  Thus, managed objects defined with these TCs
cannot represent values in the ranges that are reserved for private
use amongst cooperating systems.  If it is intended that objects
defined using these TCs be able to represent arbitrary values of the
corresponding parameters, including the "private use" values, then a
SYNTAX value other than enumerated INTEGER will be required -- for
instance, Unsigned32 with a subrange, as is used in the definition
of IkePrf.  Of course, in that case there would be no need to have
the IANA maintain these TCs:  they could be defined once, in a
WG-maintained document, with the value list in a conventional
assigned number registry.

I ask the WG to carefully consider whether an IANA-maintained MIB
module is really desirable in view of the above-described limitation
of enumerated INTEGER TCs.  It would be good to get an answer before
we spend a lot of time discussing detailed review comments.

Regards,

Mike Heard

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Tue, 8 Apr 2003 16:14:20 -0600

---Forwarded Message Follows---
Date: Tue, 8 Apr 2003 13:07:18 -0700 (PDT)
From: "C. M. Heard" <[email-masked]>
X-Sender: [email-masked]
To: IPsec WG <[email-masked]>
cc: "Wijnen, Bert (Bert)" <[email-masked]>
Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

John Shriver wrote:
> C. M. Heard wrote:
> John Shriver wrote:
> > > Let me be sure that I understand your intent.  Because RFC 2578
> > > Section 7.1.1 says that the only legal values of an enumeration
> > > are those in a list, and there may be numbers in the list from
> > > the user-reserved space that may not be in the list, we should
> > > abandon any effort to provide an enumeration for any of these
> > > number spaces in any MIB for IPsec?
> > > 
> > > Instead, they should all be range-limited INTEGERS[?]
[ ... ]
> > > This strikes me as a disservice to the real customers, which are
> > > the users of any IPsec MIBs.  (RFC 2578 is not a customer.)  The
> > > entire purpose of this MIB was to eliminate those manual lookups.
> > 
> > In retrospect, it might have been better if the SMI had adopted the
> > ASN.1 rule that enumerations only specified distinguished values,
> > and that the underlying type was allowed to have all INTEGER values
> > (well, all in the range -2147483648..2147483647, since the SMI
> > restricts INTEGER to that range).  But that wasn't what was decided,
> > and the current rule is the one we have to live with.
[ ... ]
> We discussed the "standards fudge" issue of the non-enumerated values
> back [when this project was started], and people on the IPsec list
> weren't offended by the problem.  A common-sense standards bending
> didn't bother them.

The problem with bending the rules in this way is that it is
confounds expectations that people have (based on what is in
the standard) regarding what enumerated INTEGERs mean.  I put
this question to the other MIB Doctors and got these answers:

On Mon, 7 Apr 2003, Randy Presuhn wrote:
% What bothers me about this proposal is not so much the notion of
% extending enumerations without adjusting the documentation, but
% rather the semantic ambigiuities that will result due to the lack
% of coordination of the enumeration assignments.  For this kind of
% un-coordinated private use, OBJECT IDENTIFIERs are really the way
% to go.  Otherwise, one has no way of knowing whether agent A's 42
% means the same thing as agent (or manager) B's.

On Mon, 7 Apr 2003, Andy Bierman wrote:
% I agree with Randy.  If they are leaving enum values unspecified
% so vendors can assign their own value, then this is a misuse of
% enumerated INTEGER.  If enums are really the appropriate data type,
% and they know now that they want specific values defined, then
% all enum values should be listed and documented.

What the Randy's and Andy's comments are saying is that enumerated
INTEGERs are the wrong data type for this application not because of
an obscure technical violation of RFC 2578 but because this usage
violates the semantics that are expected of enumerated INTEGERs.  I
tend to agree with that, and that's why I have suggested subranged
Unsigned32 would be a more appropriate choice.

> I don't have time to dig the archives...

I looked in the ipsec archives back to 1998 and was not able to find
any discussion of this specific issue (it is entirely possible that
I missed something, in which case a pointer would be helpful). 

Thanks,

Mike Heard

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Wed, 16 Apr 2003 15:50:22 -0600

Has this got any impact on the policy config doc?  We need a response
on this issue.

Hilarie

  ---Forwarded Message Follows---
From: "C. M. Heard" <[email-masked]>
To: IPsec WG <[email-masked]>
cc: "Wijnen, Bert (Bert)" <[email-masked]>
Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt

[ authors of draft-ietf-ipsp-ipsec-conf-mib-06.txt bcc'd;  ]
[ please direct all discussion to [email-masked]  ]

Summary of the discussion so far:  I have pointed out to the WG that
all of the enumerated INTEGER TCs in the IPSEC-ISAKMP-IKE-DOI-TC MIB
module in <draft-ietf-ipsec-doi-tc-mib-07.txt> (except for
IsakmpCertificateEncoding) are intended to represent data items that
have a certain range of values reserved for "private use amongst
cooperating systems."  Since values in these ranges are not subject
to standardization, there will be no enumerations for them.
However,  SMIv2 rules require (and MIB users/authors expect) that
objects defined with an enumerated INTEGER syntax will assume only
those values that are named in the enumeration list.  I have
therefore advised the WG (in my role as MIB reviewer) that the
SYNTAX value of all of the enumerated INTEGER TCs in the
IPSEC-ISAKMP-IKE-DOI-TC MIB module be changed to the appropriate
Unsigned32 subrange with the usages of the various ranges spelled
out in the DESCRIPTION clause (as is done now) and a pointer to the
IANA registry included.  This approach, which is the also used in
the SnmpSecurityModel TC from the SNMP-FRAMEWORK-MIB in RFC 3411,
has the added advantage of not imposing any extra workload on the
IANA to supplement or reorganize the existing IPsec and ISAKMP
registries.  The disadvantage of this approach is that applications
such as MIB browsers that don't have any built-in knowledge of the
underlying MIB objects can only display the integer value and not
the enumeration label, which makes the MIB modules harder to use.

This discussion has been dormant for about a week, and I do need to
proceed with finalization of my MIB review comments for the ADs.  So
unless I hear some very convincing arguments to the contrary before
Tuesday, 22 April 2003, my review comments will advise that all the
enumerated INTEGER TCs in the IPSEC-ISAKMP-IKE-DOI-TC have the
SYNTAX value changed to the appropriate Unsigned32 subrange, and
that the MIB module be maintained by the WG, not by IANA.

I am aware of the following Internet Drafts that contain MIB modules
which use one or more of the TCs defined in IPSEC-ISAKMP-IKE-DOI-TC:

draft-ietf-ipsec-ike-monitor-mib-04.txt
draft-ietf-ipsec-isakmp-di-mon-mib-05.txt
draft-ietf-ipsec-monitor-mib-06.txt
draft-ietf-ipsp-ipsec-conf-mib-06.txt

Of these, it appears that only the last one would be affected by
the changes I intend to recommend.  It would be necessary to
change the object definition

ipspSaPreActActionType OBJECT-TYPE
    SYNTAX      IpsecDoiEncapsulationMode
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "This object specifies the encapsulation mode to use for the
         preconfigured SA: tunnel or transport mode."
    DEFVAL { tunnel }
    ::= { ipspSaPreconfiguredActionEntry 9 }

to

ipspSaPreActActionType OBJECT-TYPE
    SYNTAX      IpsecDoiEncapsulationMode
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "This object specifies the encapsulation mode to use for the
         preconfigured SA: tunnel or transport mode."
    DEFVAL { 1 } -- tunnel
    ::= { ipspSaPreconfiguredActionEntry 9 }

Regards,

Mike Heard