Subject: Re: [nmrg] Question on BER encoding
From: Aiko Pras <[email-masked]>
To: Frank Strauß <[email-masked]>
Cc: [email-masked]
Date: Fri, 23 Jan 2004 16:13:17 +0100
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

Frank Strauß wrote:
> If the first octet would not be present the remaining bits would start with
> the most significant bit set to 1 denoting a negative value (I guess
> -6777216 :-)).

That's it :-)

Thanks a lot

Aiko

Date: Fri, 23 Jan 2004 16:04:03 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Frank Strau? <[email-masked]>
Cc: Aiko Pras <[email-masked]>, [email-masked]
Subject: Re: [nmrg] Question on BER encoding
Reply-To: [email-masked]
Mail-Followup-To: Frank Strau? <[email-masked]>, Aiko Pras <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, Jan 23, 2004 at 03:22:17PM +0100, Frank Strau? wrote:
 
> If the first octet would not be present the remaining bits would start with
> the most significant bit set to 1 denoting a negative value (I guess
> -6777216 :-)).

Yes, the sign is the key. Integer32 values always fit into 4 bytes but
Unsigned32 or Counter32 or Gauge32 may need 5 bytes. Aiko, I guess it
is time to re-read the old books. ;-)

BTW, the OULU SNMP tests which caused many implementations to crash were
doing much more interesting things. It is really fun to look at them.

/js
 
-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Fri, 23 Jan 2004 15:22:17 +0100
From: =?ISO-8859-1?Q?Frank_Strau=DF?= <[email-masked]>
To: Aiko Pras <[email-masked]>
cc: [email-masked]
Subject: Re: [nmrg] Question on BER encoding
Sender: [email-masked]

Aiko Pras wrote:

> Frank Strauß wrote:
>> I found a quite extensive explanation in Stallings, "SNMP.. and RMON.."
>> book. In general, it is due to the encoding of signed and unsigned values
>> as ASN.1 INTEGERS, which are always signed. Thus you need to extend the
>> length for the upper half of an unsigned value range to encode it as a
>> (signed) INTEGER value.
> 
> This still does not explain why, for example, decimal 10.000.000 (10
> million) is coded as 00 98 96 80. The first octet (00) is, in my opinion,
> not necessary. Still this is what I find in my traces.

If the first octet would not be present the remaining bits would start with
the most significant bit set to 1 denoting a negative value (I guess
-6777216 :-)).

Date: Fri, 23 Jan 2004 15:13:12 +0100
From: Aiko Pras <[email-masked]>
To: =?ISO-8859-1?Q?Frank_Strau=DF?= <[email-masked]>
CC: [email-masked]
Subject: Re: [nmrg] Question on BER encoding
Sender: [email-masked]

Frank Strauß wrote:
> I found a quite extensive explanation in Stallings, "SNMP.. and RMON.."
> book. In general, it is due to the encoding of signed and unsigned values
> as ASN.1 INTEGERS, which are always signed. Thus you need to extend the
> length for the upper half of an unsigned value range to encode it as a
> (signed) INTEGER value.

This still does not explain why, for example, decimal 10.000.000 (10 
million) is coded as 00 98 96 80. The first octet (00) is, in my 
opinion, not necessary. Still this is what I find in my traces.

Bye

Aiko

Date: Fri, 23 Jan 2004 14:24:20 +0100
From: =?ISO-8859-1?Q?Frank_Strau=DF?= <[email-masked]>
To: Aiko Pras <[email-masked]>
cc: [email-masked]
Subject: Re: [nmrg] Question on BER encoding
Sender: [email-masked]

Aiko Pras wrote:

> Your theory is correct wrt the coding of ASN.1's LENGTH field. My
> question, however, relates to the ASN.1 DATA field. As far as I know, the
> first bit of an octet does not have a special meaning there.
> 
> If I look at my traces, I see that the ASN.1 DATA fields have ordinary
> hex encodings. To my surprise, however, I see that the hex encoding of
> large numbers get a octet with a zero value in front. I therefore get 5
> octest for large values, whereas 4 would be sufficient. I don't
> understand the "zero octet" in the beginning.

Oh, I mixed up the encoding of INTEGERs and the sub-ids within OIDs.
Sorry for the confusion!

I found a quite extensive explanation in Stallings, "SNMP.. and RMON.."
book. In general, it is due to the encoding of signed and unsigned values
as ASN.1 INTEGERS, which are always signed. Thus you need to extend the
length for the upper half of an unsigned value range to encode it as a
(signed) INTEGER value.

Date: Fri, 23 Jan 2004 13:45:07 +0100
From: Aiko Pras <[email-masked]>
To: =?ISO-8859-1?Q?Frank_Strau=DF?= <[email-masked]>
CC: [email-masked]
Subject: Re: [nmrg] Question on BER encoding
Sender: [email-masked]

Hi Frank

Your theory is correct wrt the coding of ASN.1's LENGTH field. My 
question, however, relates to the ASN.1 DATA field. As far as I know, 
the first bit of an octet does not have a special meaning there.

If I look at my traces, I see that the ASN.1 DATA fields have ordinary 
hex encodings. To my surprise, however, I see that the hex encoding of 
large numbers get a octet with a zero value in front. I therefore get 5 
octest for large values, whereas 4 would be sufficient. I don't 
understand the "zero octet" in the beginning.

Bye

Aiko

Frank Strauß wrote:

> Aiko Pras wrote:
> 
> 
>>I'm still looking at bandwidth consumption of SNMP. I have now a question
>>wrt BER encoding.
>>
>>Assume I want to BER encode a 32 bit INTEGER value. The ASN.1 encoding
>>will start with a 1 octet TAG field, a 1 octet LENGTH field, and then x
>>octets for the value. x depends on the precise value: a zero value can be
>>coded in 1 octet and MAXINT needs more octets.
> 
> 
> In theory, there is no MAXINT in ASN.1. But of course, SMI type range are
> limited.
> 
> 
>>My question is now: how many?
>>I expect that, for a 32 bit INTEGER, x never exceeds 4 octets. If I look
>>at my traces, however, I often find x=5.
> 
> 
> I did not look up the exact details and terminology, but in general it is
> something like this:
> 
> The most significant bit of each octet denotes whether the next octet
> belongs to the value: If it's zero this octet is the last one. I.e., with
> one octet (which requires that the most significant bit is 0), you can
> represent values from 0 to 2^7==127 with the remaining 7 bits. With two
> octets (which means that the most significant bit of the first octet is 1
> and of the second octet is 0), you can represent values up to 2^15, etc.
> This also means that the "upper half" of the "traditional" 32 bit value
> range needs 5 BER octets and the "lower half" needs just 4 octets (or even
> less). Note also, that each single value can be represented with different
> numbers of octets (with a variable number of most significant octets
> containing just zeros, except the "continuation bit").
> 
> The series of vulnerabilites of many SNMP implementations that have been
> revealed in 2002 by a finnish academic group have been based partly on the
> fact that some implementations handled some of the "valid but obscure"
> value encodings (e.g., integers in even more than 5 octets) badly.

Date: Fri, 23 Jan 2004 11:28:20 +0100
From: =?ISO-8859-1?Q?Frank_Strau=DF?= <[email-masked]>
To: Aiko Pras <[email-masked]>, [email-masked]
Subject: Re: [nmrg] Question on BER encoding
Sender: [email-masked]

Aiko Pras wrote:

> I'm still looking at bandwidth consumption of SNMP. I have now a question
> wrt BER encoding.
> 
> Assume I want to BER encode a 32 bit INTEGER value. The ASN.1 encoding
> will start with a 1 octet TAG field, a 1 octet LENGTH field, and then x
> octets for the value. x depends on the precise value: a zero value can be
> coded in 1 octet and MAXINT needs more octets.

In theory, there is no MAXINT in ASN.1. But of course, SMI type range are
limited.

> My question is now: how many?
> I expect that, for a 32 bit INTEGER, x never exceeds 4 octets. If I look
> at my traces, however, I often find x=5.

I did not look up the exact details and terminology, but in general it is
something like this:

The most significant bit of each octet denotes whether the next octet
belongs to the value: If it's zero this octet is the last one. I.e., with
one octet (which requires that the most significant bit is 0), you can
represent values from 0 to 2^7==127 with the remaining 7 bits. With two
octets (which means that the most significant bit of the first octet is 1
and of the second octet is 0), you can represent values up to 2^15, etc.
This also means that the "upper half" of the "traditional" 32 bit value
range needs 5 BER octets and the "lower half" needs just 4 octets (or even
less). Note also, that each single value can be represented with different
numbers of octets (with a variable number of most significant octets
containing just zeros, except the "continuation bit").

The series of vulnerabilites of many SNMP implementations that have been
revealed in 2002 by a finnish academic group have been based partly on the
fact that some implementations handled some of the "valid but obscure"
value encodings (e.g., integers in even more than 5 octets) badly.

Date: Fri, 23 Jan 2004 11:01:19 +0100
From: Aiko Pras <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: Aiko Pras <[email-masked]>
Subject: [nmrg] Question on BER encoding
Sender: [email-masked]

Hi

I'm still looking at bandwidth consumption of SNMP. I have now a 
question wrt BER encoding.

Assume I want to BER encode a 32 bit INTEGER value. The ASN.1 encoding 
will start with a 1 octet TAG field, a 1 octet LENGTH field, and then x 
octets for the value. x depends on the precise value: a zero value can 
be coded in 1 octet and MAXINT needs more octets. My question is now: 
how many?
I expect that, for a 32 bit INTEGER, x never exceeds 4 octets. If I look 
at my traces, however, I often find x=5.

Aiko

Date: Thu, 15 Jan 2004 15:37:45 +0100
From: =?ISO-8859-1?Q?Frank_Strau=DF?= <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: [nmrg] 15th NMRG meeting last week
Sender: [email-masked]

Juergen Schoenwaelder wrote:

> I think we had a nice meeting last week. I have now put all the slides
> on the meeting web page for those who could not attend. 
> 
> Frank Strauss recorded the meetings in video and audio. These recordings 
> are basically an experiment to see whether this is doable these days with 
> an acceptable amount of work. Please contact Frank if you want to look 
> at the material (and if you look at it, please give us feedback whether 
> you think this is useful).

The recordings are available for download at
http://www.ibr.cs.tu-bs.de/projects/nmrg/recordings/. If you would
like to try steaming, let me know, I've started playing with the
Darwin streaming server and we could give it a try.

For any reason the video recording did not work for the second part
(Juergen Quittek's MIDCOM presentation), but however the audio is there.
For any(!) of the recordings you definitely need the PDF slides as well,
since the projections on the wall cannot be read in the video.

I used standard MPEG-4 encoding to achieve a quite good compression,
but unfortunately there are not many decoder implementations. Apple
QuickTime (also freely available for MS Windows) works fine. A recent
mplayer compiled with the appropriate libraries should work as well.

Date: Thu, 15 Jan 2004 13:53:18 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] 15th NMRG meeting last week
Sender: [email-masked]

I think we had a nice meeting last week. I have now put all the slides
on the meeting web page for those who could not attend. 

Frank Strauss recorded the meetings in video and audio. These recordings 
are basically an experiment to see whether this is doable these days with 
an acceptable amount of work. Please contact Frank if you want to look 
at the material (and if you look at it, please give us feedback whether 
you think this is useful).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Mon, 12 Jan 2004 09:25:35 +0100
From: =?ISO-8859-1?Q?Frank_Strau=DF?= <[email-masked]>
To: Emmanuel Nataf <[email-masked]>, [email-masked]
Subject: Re: [nmrg] sming soft
Sender: [email-masked]

Frank Strauß wrote:

> [...] Hence, we are currently at
> draft-irtf-nmrg-sming-07 and draft-irtg-nmrg-sming-snmp-05. But the good
> news is that the content did not really change. The documents are now in
> last call [...]

Bert just noticed me that this is not true. I misunderstood the process for
non-IETF-WG I-Ds to be published as Experimental RFCs. The SMIng I-Ds are
going to be put on the IESG agenda for any final IESG comments. There will
be no IETF wide last call for documents like these. Thanks to Bert.

Date: Thu, 08 Jan 2004 14:16:50 +0100
From: =?ISO-8859-1?Q?Frank_Strau=DF?= <[email-masked]>
To: Emmanuel Nataf <[email-masked]>, [email-masked]
Subject: Re: [nmrg] sming soft
Sender: [email-masked]

Emmanuel Nataf wrote:

> A new release of a java SMIng compiler and a SMIng-based proxy agent
> (with JMX and SNMP) is available at :
> 
> http://sourceforge.net/projects/sming/
> 
> The distribution is compliant with the draft-irtf-nmrg-sming-06 document
> available at http://www/ibr.cs.tu-bs.de/projects/sming

Great News! BTW, during the process to get the specs published as
experimental RFCs, the RFC Editor proposed to integrate the "Modules
document" as an appendix to the core document. Hence, we are currently at
draft-irtf-nmrg-sming-07 and draft-irtg-nmrg-sming-snmp-05. But the good
news is that the content did not really change. The documents are now in
last call since 2003-12-24, so we might hope to get it published soon.

Greetings from the ongoing NMRG meeting,

 -frank

To: [email-masked]
From: Luca Deri <[email-masked]>
Date: Thu, 8 Jan 2004 10:57:28 +0100
Subject: [nmrg] Packet Capture Paper
Sender: [email-masked]

Loris Degioanni, Mario Baldi, Fulvio Risso and Gianluca Varenni, 
Profiling and Optimization of Software-Based Network-Analysis 
Applications, Proceedings of the 15th IEEE Symposium on Computer 
Architecture and High Performance Computing (SBAC-PAD 2003), Sao Paulo, 
Brasil, November 2003

http://winpcap.polito.it/docs/default.htm
- -------
Luca Deri <[email-masked]>
http://luca.ntop.org

Date: Wed, 07 Jan 2004 16:33:00 +0100
From: Emmanuel Nataf <[email-masked]>
To: [email-masked]
Subject: [nmrg] sming soft
Sender: [email-masked]

A new release of a java SMIng compiler and a SMIng-based proxy agent 
(with JMX and SNMP) is available at :

http://sourceforge.net/projects/sming/

The distribution is compliant with the draft-irtf-nmrg-sming-06 document 
available at http://www/ibr.cs.tu-bs.de/projects/sming

E. Nataf