On 12/1/16, 3:20 AM, "Juergen Schoenwaelder"
<[email protected]> wrote:
>On Wed, Nov 30, 2016 at 09:37:21PM +0000, Acee Lindem (acee) wrote:
>
>> In the days of MIBs, we used to omit key strings from the data that
>>would be returned. This was ostensibly done for security purposes.
>
>This is not correct. In SMIv2, INDEX objects are not accessible
>because the values of these objects are embedded in the instance
>identifier. In other words, making INDEX objects not-accessible was a
>performance optimization, forcing SNMP managers to extract the INDEX
>object values out of the instance identifiers. Making INDEX objects
>not accessible does _not_ hide any information.
This is a different issue. What I am referring to is never returning the
keys in a read request (get, get-next, get-many, etc). For example,
(excerpted from RFC 4750):
ospfIfAuthKey OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..256))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The cleartext password used as an OSPF
authentication key when simplePassword security
is enabled. This object does not access any OSPF
cryptogaphic (e.g., MD5) authentication key under
any circumstance.
If the key length is shorter than 8 octets, the
agent will left adjust and zero fill to 8 octets.
Unauthenticated interfaces need no authentication
key, and simple password authentication cannot use
a key of more than 8 octets.
Note that the use of simplePassword authentication
is NOT recommended when there is concern regarding
attack upon the OSPF system. SimplePassword
authentication is only sufficient to protect against
accidental misconfigurations because it re-uses
cleartext passwords [RFC1704].
When read, ospfIfAuthKey always returns an octet
string of length zero."
REFERENCE
"OSPF Version 2, Section 9 The Interface Data
Structure"
DEFVAL { '0000000000000000'H } -- 0.0.0.0.0.0.0.0
::= { ospfIfEntry 16 }
Thanks,
Acee
>
>/js
>
>--
>Juergen Schoenwaelder Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
