Subject: Re: <draft-ietf-disman-remops-mib-06.txt>

From: Alan Luchuk <[email-masked]>
Date: Thu, 12 Aug 1999 09:27:52 -0400 (EDT)

Hello all,

I've deleted most of the text to reduce in-box stuffing...

>> Page 7
>> ------
>>
>> Section 3.1.4, second paragraph, the last sentence reads:
>>
>I believe interpretation "b" is correct.  Do we need to clarify the text?

Thanks for refreshing my memory!

Not sure if it's _necessary_ but it seems likely that if someone
that's been following the discussion isn't sure, then someone 
reading the MIB (presumably before implementing it) for the first 
time might be unsure.

I'll defer to the best judgement of the WG.

>> Page 13
>> -------
>>
>> The HostAddress textual convention is specified like this:
>>
>>
>>    HostAddress ::= TEXTUAL-CONVENTION
>>       STATUS  current
>>       DESCRIPTION
>>           "The textual convention for specifying a host
>>           address.  The type of address can be determined
>>           by examining the value of the preceding
>>           HostAddressType object:
>>
>>              HostAddressType   OCTETs    ADDRESS TYPE
>>                 none(0)         0        not specified
>>                 dnsName(1)      1-255    DNS name
>>                 ipv4(2)         4        ipv4
>>                 ipv6(3)         16       ipv6"
>>       SYNTAX OCTET STRING (SIZE (0..255))
>>
>
>I don't see anything in the TC definition that would require a
>management system to use the hex form for either display or data
>entry.  Am I mising something here?

OK.  You got me.  I guess the definition doesn't absolutely
_require_ the management system use the hex form, but I guess
I assumed that implementors would conform to what's documented
in the DESCRIPTION.

>> Something similar should be done for ipv6 addresses.
>>
>> Personally, I would prefer that the agent take ipv4 and ipv6
>> addresses specified in human-friendly (e.g., 192.147.142.150)
>> form and do the conversion.   This would require changing the
>> size restrictions specified in the description clause.
>
>I strongly disagree.  Construction of user-interface-specific
>data representations is far outside the scope of what agents
>should be doing.

This point makes good sense to me.  But (certainly in the 
development environment, at least) alot of work is done with
ad-hoc get/set utilities.  Forcing humans to conform to
what is convenient for a machine makes the ad-hoc gets/sets 
much harder.

I guess I'd be curious about what real-world, production-type,
network managers tend to use most  (GUI-based tools or ad-hoc
query tools) and what their opinions are.  It would be helpful
to choose these kinds of things such that real-world network
managers' jobs are easiest.

I can align with whatever the WG believes is the right thing to 
do.  I just wanted to ask the question in case the issue had not 
been considered.

>> Page 16
>> -------
>>
>> The pingCtlOwnerIndex object is specified as:
>>
>>    pingCtlOwnerIndex OBJECT-TYPE
>>       SYNTAX      SnmpAdminString (SIZE(0..32))
>>       MAX-ACCESS  not-accessible
>>       STATUS      current
>>       DESCRIPTION
>>          "Description text deleted by Alan."
>>       ::= { pingCtlEntry 1 }
>>
>> The minimum size for this object is 0 octets.   Was this intended?
>> Will this minimum size of 0 octets affect the use of View-Based
>> Access Control?   (As in, could security be compromised because
>> someone specifies a pingCtlOwnerIndex of 0 octets in length?)
>
>It's the security administrator's problem to ensure that the access
>control policies for entries whose owner index get encoded as a single
>0 subidentifier are formulated properly.  I don't see it introducing
>any problems for VACM.
>
>> The pingCtlTestName (page 17),  traceRouteCtlOwnerIndex (page 35),
>> traceRouteCtlTestName (page 36), lookupCtlOwnerIndex (page 58),
>> and lookupCtlOperationName (page 59) are similarly defined with
>> size restrictions of (0..32) octets.
>>
>>
>> Would changing the minimum size to 1 would resolve any possible
>> security holes resulting from zero-length table indices?
>
>I don't see what the security hole is, unless someone formulates policies
>which wildcard the length subidentifier and try to work with substrings
>of the owner index.  As detailed at the WG meeting in (Minneapolis?)
>there are lots of nasty corner cases for formulating access control
>policies in this way.  Since the "0" case is special anyway, the security
>administrator would need to take care to formulate a distinct access
>control policy for "0" (the length subidentifier NOT wildcarded).
>
>I think there is no problem here.

Works for me.  Truthfully, I'm not super-knowledgable about VACM, so 
I wasn't sure _if_ there were any possible security holes.  Again, I 
just wanted to raise the issue in case this minor issue in the MIB
might have profound implications for security.

Regards,
--Alan
 
 -----------------------------------------------------------------------------
 Alan Luchuk       SNMP Research, Inc.                 Voice:  +1 423 573 1434
 Software Engineer 3001 Kimberlin Heights Road         FAX:    +1 423 573 9197
 [email-masked]   Knoxville, TN  37920-9716  U.S.A.   http://www.int.snmp.com/
 -----------------------------------------------------------------------------