Re: [6lowapp] [6lowpan] SNMP optimizations

["Rene Struik" <[e-mail]>]

Hi Juergen:

I submitted a 6lowapp draft on security considerations precisely because
one needs a description of the problem space and make sure it is not
"forgotten". 

I do understand that people may wish and use some functionality that is
already out there, but question is whether it supports the desired
security functionality over the lifecycle of the system. 

Could you recommend an overview paper on SNMP that would make it easy to
see what the supposed security features are suitable to sensor-type
applications and how these are delivered (mechanisms, communication
overhead, etc.). This should make it easier to provide a more
quantitative assessment.

Best regards, Rene

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Juergen Schoenwaelder
Sent: Wednesday, November 18, 2009 6:58 PM
To: Ulrich Herberg
Cc: [e-mail]; 6lowpan; [e-mail]
Subject: Re: [6lowpan] SNMP optimizations

On Wed, Nov 18, 2009 at 10:10:23PM +0100, Ulrich Herberg wrote:

[... we should restrict this to one mailing list...]

> However, it is unclear whether the code footprint of SNMP
> implementations can fit into the memory of small devices. From
> discussions with several persons from the MANET WG, I conclude that
> for MANET the same problem exists. (and I think for ROLL, too?)
> 
> I have several questions that came to my mind about this topic:
> 
> - First of all, to which WG does this issue belong to? Or is it -- as
> I suppose -- a common problem for the three working groups addressed
> in this mail?

I don't know.

> - Is this really an issue? Are there implementations of SNMP (maybe
> not open-source) that can be run on very small devices such as
> considered in 6lowpan/ROLL/MANET? Is there any experimental (or
> theoretical) analysis whether SNMP (or any other standardized
> management protocol) can run on these devices?

The question is under specified. What is a "very small device" and how
much can a "very small device" devote to SNMP? And what is SNMP? The
SNMPv3 specs are pretty modular. One of the more important questions
is how you deal with security - the security code has the potential to
be bigger than the rest of the SNMP engine. And it boils down to the
question of how many MIB objects you support and to what extend you
hardwire things. Remember that SNMP is a child of the late 80s and
early versions were sometimes embedded into devices that could not
afford TCP. Of course, the 80s version of SNMP did not care much about
security...

> - If SNMP cannot be used for small devices, how can we manage and
> monitor these devices then? (e.g. using proxies, different message
> formats such as proposed in 6lowapp, etc.). Do we need a different
> lightweight protocol for management?

Again, the big question is how to deal with the security aspect. SNMP
originally was lightweight because there was no security. It took the
IETF many years to find a workable security solution and even today
people are working on utilizing transport layer security protocols
within SNMP (see ISMS working group).

>  - Can we provide SNMP not only on a single device, but for a whole
> network? That might need an aggregator device that runs full SNMP and
> collects the data from the low power devices. This would imply to
> monitor statistics of a whole network (e.g. number of links, average
> throughput, average path-length, etc.)

Sure, there are ways of doing this. For read-only objects, this is
relatively easy - it can get a bit messy if you have read-write
objects. Whether this direction is worthwhile to explore depends on
how you solve the security issues and whether a dependency on a
"gateway" is desirable in the first place.

>  - What kind of objects should be provided in a MIB running on a
> MANET/6lowpan/ROLL device? This might be specific to the routing
> protocol, but there can be commonalities.

In general, the IETF tends to break MIB modules down along protocol
functions. Following this approach, a ROLL MIB module would report
data about the ROLL routing protocol. A 6LoWPAN MIB would report data
about the 6LoWPAN layer, that is for example the list of supported
6LoWPAN protocol features and counters for 6LoWPAN processing failures
(e.g. reassembly failures) that help to trouble shoot 6LoWPAN issues.
I would hope that some IPv6 MIB objects apply as well and then there
should ideally be an IEEE 802.15.4 MIB module for this particular
radio technology. I do not think there is much overlap if things get
structured well. This, however, might be difficult to achieve if work
is spread over several WGs.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>
_______________________________________________
6lowpan mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowpan

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.