Subject: [NGO] MIB Access using Netconf RPCs

From: "David Harrington" <[email-masked]>
Date: Sun, 3 Dec 2006 19:43:10 -0500

Hi,

There are some addressing and security and operational issues related
to using netconf to access MIB data. There is also previous work of
which people should be aware.

RRC3411 defines certain points in the abstraction of an SNMP entity
where certain input information is required. These are the highly
unpopular "application service interfaces", usually called ASIs. 

It is helpful to consider where a netconf request for MIB data will
enter the SNMPv3 architectural model to understand what parameters
Netconf will likely need to provide to an SNMP implementation to be
compatible with SNMPv3 access control. The ASIs spell this out fairly
well.

-- addressing issues --

Data exists within a naming scope; in SNMPv3 this is called a context,
which is contained within a contextEngine. In SNMPv1/v2c this is
called a community. I will use the term context to refer to bot SNMPv3
contexts and SNMPv1 communities.

Contexts have been used in numerous ways by vendors, so to access MIB
data, netconf will need to either support communities and contexts as
defined by SNMP, or provide a mapping that somehow can be resolved to
fit with various vendor usages.

Contexts/comunities have been used to refer to 
1) hardware, such as a board within a chassis,
2) subsets of data in other systems, such as "public@device2"  (I used
to work on the Spectrum NMS and our customers had at least nine
different proprietary ways to do proxy in SNMPv1 that we tried to
model in a standard way)
3) and other approaches.
I won't try to list all the ways communities and contexts have been
used.

To be compatible with SNMPv3, netconf will need to at least provide a
contextName, on the assumption netconf will only try to access local
data of the engine to which it sends its messages.

SNMPv3 standardizes a proxy mechansism using the contextEngine and
contextname, so the SNMP engine will forward the message to another
entity for processing. 

Verbs are registered with the SNMP dispatcher based on the
contextEngineID, which permits the selction of a specific
contextEngine for processing, and allows multiple contextEngineIDs to
do local processing. This permits the same verb to be processed by
different contextEngineIDs, as in the case of having separate SNMPv1
and SNMPv3 processing engines within the same system, each of which
can process a GET request.

In SNMPv3, a request will NOT be forwarded to an "snmp application"
9the PDU processing functinality) without a contextEngineID. 

USM has a mechanism to discover contextEngineIDs. ISMS so far does
not. I do not know how Netconf will know which contextEngineID to
provide to specify the local system or a proxied system. Maybe netconf
can bypass that dispatcher functinality, but it may run into problems
on systems that support features that require contextEngineID.

-- security mappings --

So far in the IETF, we have not done a good job of balancing the
security characteristics of our different management interfaces.
SNMPv3 defines user-based access control to MIB data.  Netconf should
respect the MIB access control defined by the system administrator.

SNMP access control requires a securityName, a securityModel, and a
securityLevel.

securityName should be provided by the transport/application
(SSH/BEEP/SOAP) that provides the authenticaton of the principal (the
entity for whom operations are requested). Just as "just run it over
IPSec was not acceptable, it really is not acceptable to say "just run
it over SSH/BEEP/SOAP. We need to specify how the cryptographic
binding is provided - how does SSH/BEEP/SOAP provide the information
about who was authenticated.

securityModel may be fairly straightforward. In ISMS, we have
developed a transport security model that basically says "the
transport model provides this info".

SecurityLevel should identify which security services were provided by
the underlying transport/application - authentication and encryption,
comparable to SNMPv3's authPriv, authNoPriv, and noAuthNoPriv. In
ISMS, we simply made the SSH transport model always use authPriv, and
advise the operator to ensure that authentication and encryption are
always used for sending SNMP messages over the SSH transport model.
Netconf could do something similar.

To support SNMPv3 access control, netconf should utilize the
isAccessAllowed() ASI, with the specified set of parameters. Netconf
should either use a comparable ASI (and the semantics of some ASI
parameters may need to be modified slightly), or define a new
backwards-compatible way to define access control. Note that most if
not all of the isAccessAllowed() ASI parameters were defined to be
somewhat generic to support different access control approaches, so
hopefully any Netconf RPCs will be able to provide appropriate
parameters without too much trouble.

-- operational considerations --

SNMP has some definite rules about how operations work. Some of the
most notable are lexicographical ordering, and "as if simultaneous"
processing of SET requests. 

If Netconf RPCs call SNMP functions in the SNMP agent, the RPCs will
need to be prepared to deal with the results that depend on these SNMP
behaviors.

Note that MIB modules are generally SNMP-version agnostic. If a
netconf RPC accesses MIB data through an SNMPv1 operations, some of
the rules change. In SNMPv1, PDU processing is all-or-nothing, while
SNMPv2 operations have per-varbind exceptions to make this easier for
an NMS.

-- previous work --

  @Article{KS04,
    author =       "T. Klie and F. Strau{\ss}",
    title =        "Integrating {SNMP} Agents with {XML}-based
Management
                   Systems",
    journal =      "IEEE Communications Magazine",
    volume =       "42",
    number =       "7",
    pages =        "76--83",
    month =        jul,
    year =         "2004",
  }

And see the minutes from the 12th meeting of the NMRG
http://www.ibr.cs.tu-bs.de/projects/nmrg/minutes/minutes-012.txt

(Thank you Juergen for pointing these out)

David Harrington
[email-masked] 
[email-masked]
[email-masked]

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 4 Dec 2006 15:48:19 +0100

> unpopular "application service interfaces", usually called ASIs. 

They are actually called "abstract service interfaces" in RFC 3411.
 
> can process a GET request.

I though different messages versions are handled by the message
processesing subsystem. My understand was that a conextEngineID which
is not identical with the local engineID only occurs proxy situations.
 
> USM has a mechanism to discover contextEngineIDs. 

I disagree. USM has a mechanism to discover the securityEngineID. Many
implementations than use the securityEngineID as a best guess for a
contextEngineID; but I do not think this is how it was designed.

> ISMS so far does not. I do not know how Netconf will know which
> contextEngineID to provide to specify the local system or a proxied
> system. Maybe netconf can bypass that dispatcher functinality, but
> it may run into problems on systems that support features that
> require contextEngineID.

I believe we should follow Dave Perkin's suggestion and define a
"this" contextEngineID constant which always means use the local
engineID as the contextEngineID. This would solve the problem for the
non-proxy case for both ISMS and NETCONF or any other interfaces. (And
the creative usage of securityEngineID as contextEngineIDs does not
work with proxies either - so introducing a "this" contextEngineID is
not worse than what we have.)

/js

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

---

From: "David Harrington" <[email-masked]>
Date: Mon, 4 Dec 2006 15:28:25 -0500

Hi 

> They are actually called "abstract service interfaces" in RFC 3411.
You are correct.
 
> is not identical with the local engineID only occurs proxy
situations.

Different message versions are handled by different messaging models;
different pdu types are handled by different "snmp applications", and
the dispatch of pdus to applications is handled by the dispatcher. The
list of pdutypes is dependent on the messaging models supported. 

I am of the impression that a given engine is free to register one
application for a v1GET pduType, and another for a v3GET pduType. I
know this was discussed, and am fairly certain that was consensus.
However, RFC3413 has text in section 3.2 that makes me question
whether this is possible.

"4.1.5.  Registering Responsibility for Handling SNMP PDUs

   Applications can register/unregister responsibility for a specific
   contextEngineID, for specific pduTypes, with the PDU Dispatcher
   according to the following primitives.  The list of particular
   pduTypes that an application can register for is determined by the
   Message Processing Model(s) supported by the SNMP entity that
   contains the PDU Dispatcher.

   statusInformation =            -- success or errorIndication
     registerContextEngineID(
     IN   contextEngineID         -- take responsibility for this one
     IN   pduType                 -- the pduType(s) to be registered
          )
"

I believe I may be wrong in one of my statements. I said the
registration mechanism allows multiple contextEngineIDs to do local
processing. I believe that may be incorrect. However, the text from
the various RFC341x RFCs surrounding registrations is pretty funky, so
I am not certain that is incorrect.

> contextEngineID; but I do not think this is how it was designed.

You are correct.

> non-proxy case for both ISMS and NETCONF or any other interfaces. 

I agree this might work, but we need to determine how to change the
existing elements of procedure to support this.

> (And

Agreed.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 4 Dec 2006 21:56:01 +0100

> I am not certain that is incorrect.

Lets simply agree that the text is open for some interpretation. ;-)

> > engineID as the contextEngineID. This would solve the problem for
> > the non-proxy case for both ISMS and NETCONF or any other
> > interfaces.
> 

Section 4.2.2.1. or RFC 3412 says:

   1) The combination of contextEngineID and pduType is used to
      determine which application has registered for this request or
      notification.

What about this:

a) We define a "localEngineID" contextEngineID value.

b) We suggest that the applications handling pduTypes that are "local"
   to the snmp engine register under this "localEngineID" value (in
   addition to the usual registration under the contextEngineID).

Once that has happened, things should just work without any further
modifications of the elements of procedure. Note that RFC 3412 already
allows multiple registrations for different engineIDs. Am I missing
something?

/js