Wireshark · Ethereal-dev: Re: [ethereal-dev] packet-snmp.c patch to handle zero length context names

[Guy Harris <gharris@xxxxxxxxxxxx>]

On Thu, Jun 29, 2000 at 03:29:49PM +0200, Jochen Friedrich wrote:
> There are several examples on where an OCTET STRING is used for any kind
> of binary data.

Yes, I know - but many of the places where we extract an OCTET STRING,
we *already* don't treat it as a character string; the only places where
it's appropriate to treat it as a character string would be places
where the spec says that the particular OCTET STRING in question is to
be interpreted as a character string.

The places where we *do* seem to interpret an OCTET STRING
unconditionally as a character string are:

	the community field in SNMP V1 and V2 PDUs;

	the msgSecurityParameters field in SNMPv3 packets using the
	SNMP V1 or SNMP V2C security model (RFC 2261 says a security
	model of 1 is "reserved for SNMPv1" and 2 is "reserved for
	SNMPv2c"; are those models documented anywhere, or are they
	still reserved?);

	the msgUserName field in the msgSecurityParameters field in
	SNMPv3 packets using the USM security model;

	the contextName field in SNMPv3 packets;

	the description and password fields in SMUX packets.

RFC 1157 says that "Each SNMP community is named by a string of octets,
that is called the community name for said community" - octets, not
characters.

RFC 2574 says of msgUserName

   7)  The userName is encoded as an OCTET STRING into the msgUserName 
       field of the securityParameters.

and of the userName

   userName
     A string representing the name of the user.

For what it's worth, it doesn't say "human-readable", as it does for
"securityName":

   securityName
     A human-readable string representing the user in a format that is
     Security Model independent.

RFC 2572 doesn't seem to indicate whether contextName is a printable
ASCII string or not.

"description" in SMUX packets is of type DisplayString, which RFC 1214
says "is restricted to the NVT ASCII character set as defined in pages
10-11 of RFC 854 'TELNET Protocol Specification'"; this is *mostly*
printable ASCII, although it also supports some control characters.

I have the impression the community field *tends* to be human-readable.

I suspect that the msgSecurityParameters field in SNMPv3 packets using
the SNMP V1 or SNMP V2C security model are *not* necessarily
human-readable.

I suspect the the msgUserName field in the msgSecurityParameters field in
SNMPv3 packets using the USM security model is *probably*
human-readable.

I don't know whether contextName is likely to be human-readable or not,
nor whether the password field in SMUX packets is likely to be
human-readable or not; I infer that the description field is intended to
be human-readable.

I see at least three choices for each of those fields:

	1) unconditionally display it as a sequence of hex octet
	   values;

	2) display it as a text string if it contains only printable
	   characters, and otherwise display it as a sequence of hex
	   octet values;

	3) hand it to "format_text()" so that non-printable characters
	   are displayed as C-style escape sequences.

I'd say

	1) should be used if the field is not ever expected to be
	   human-readable;

	2) should be used if they may be human-readable but there's a
	   reasonable chance that they won't be;

	3) should be used if they're expected to be human-readable.