Subject: RE: [NGO] MIB Access using Netconf RPCs

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 5 Dec 2006 21:24:07 +0200

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Tuesday, December 05, 2006 6:24 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [NGO] MIB Access using Netconf RPCs
> 
> Juergen Schoenwaelder wrote:
> >....
> > [Perhaps this thread should move somewhere else (e.g. ISMS) since it
> >  is really not netconf specific; but it is also unclear whether this
> >  falls into the ISMS charter, probably not.]
> > 
> 
> No.
> IMO, this list should be wide open to any ideas and threads 
> related to NETCONF.  This is related, although only the SNMP 
> experts know what you're talking about.
> 
> 
> > /js
> > 
> 
> Andy

I agree. 

Dan

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

---

From: "David Harrington" <[email-masked]>
Date: Wed, 6 Dec 2006 01:17:49 -0500

Hi,

How about a compromise? I think there are parts of this discussion
that belong here and parts that belong in ISMS.

USM provides a machanism to indirectly discover contextEngineIDs, but
the SSH transport model being developed in ISMS does not have this. At
this point, the SSH Transport Model relies on USM to discover
contextEngineIDs. So figuring out how to make this security-model
independent is an ISMS problem. The SNMP experts can go discuss
RFC341x details to their heart's content without monopolizing this
list. And maybe we can get somebody to write an actual proposal for
consideration in ISMS.

Once we figure this out in ISMS, we certainly should discuss how that
solution applies to Netconf. 

Until then we can discuss how Netconf will need to somehow provide the
appropriate parameters for access control related to accessing MIB
data, including such things as who (securityName/Model/Level), which
(contextEngineID/contextName) subset of MIB data, and the policy to
enforce for controlling access.

dbh

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Tuesday, December 05, 2006 2:24 PM
> To: Andy Bierman; [email-masked]
> Cc: [email-masked]
> Subject: RE: [NGO] MIB Access using Netconf RPCs
> 
> 
> 
>  
>  
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Dec 2006 08:18:45 +0100

> enforce for controlling access.

But this sounds easy. Like in ISMS, I assume the transport provides
the securityName/Model/Level. Surely true for SSH. The contextName
must be provided by the RPC call interface as a parameter or something
like a context name must exist in the NETCONF datamodel in general
(e.g.  an XML attribute close to the top or an element by itself or as
part of a namespace). The contextEngineID is either a "local" one or
there is a magic discovery mechanism.

Bottom line: We only have two problems to solve: The discovery of the
contextEngineID and we have a requirement to keep a context equivalent
in NETCONF's data model naming system.

Back to engineID discovery. I currently see three options:

a) Introduce a "localEngineID" constant and let applications register
   using this constant. Somehow weakens the concept of a scoped PDU,
   but should otherwise be consistent with our standards.

b) Change the RFC 3412 processing such that an unknownPduHandler report
   indicates the "local" engineID as the contextEngineID instead of
   echoing back the received contextEngineID. This way, it will be
   possible to ask for some random contextEngineID and to learn the
   one to use after receiving the report. This requires a small change
   to the RFC 3412 processing rules.

c) A mixture of a) and b): We define a "localEngineID" constant and
   request that all implementations register applications providing
   access to the SNMP-FRAMEWORK-MIB::snmpEngineID MIB object of the
   local engine under this "localEngineID". An application which needs
   to discover the contextEngineID would then send a scoped PDU using
   "localEngineID" to fetch the snmpEngineID.0 instance, pick up the
   engineID and subsequently nicely scoped PDUs can be exchanged.

If someones sees other alternatives, please say so.

Otherwise, we should just pick one and move along. I am willing to
turn this into an ID but I would like to know the direction first.
Personally, I somehow like c) since having a "localEngineID" which
only provides access to data related to the local engine itself. One
could consider to make other local engine specific information also
accessible in this special context (basically all objects currently in
the SNMP-FRAMEWORK-MIB) so that a single get can be used to pickup all
interesting parameters, e.g. the supported max-message-size.

Dave, Bert and the other SNMPv3 experts around, what do you think?

/js

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

---

From: Joe Fernandez <[email-masked]>
Date: Thu, 07 Dec 2006 23:05:11 +1100

Hi,

I'm not sure whether the consensus was that further discussion on this 
topic should be on another list - if so, my apologies for asking these 
questions here.

I want to ask a couple of questions to understand the proposals.

Does your b) involve making a minor change to the text in section 4.2.2.1 
in RFC 3412 to say the actual contextEngineID should be sent back in place 
of the received unrecognized contextEngineID?

Does your c) involve using a v3 Get with a security level of noAuthNoPriv 
to discover the contextEngineID?

Thanks.

At 08:18 AM 06-12-06 +0100, Juergen Schoenwaelder wrote:
[...]

>Dave, Bert and the other SNMPv3 experts around, what do you think?

Joe Fernandez
Kardinia Software
[email-masked]
www.kardinia.com

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Dec 2006 13:30:58 +0100

> topic should be on another list - if so, my apologies for asking these 

I think we just continue here for the moment...
 
> of the received unrecognized contextEngineID?

Yes.

> to discover the contextEngineID?

It requires a v3 Get. I would be silent about the security level since
there is no need to require noAuthNoPriv. In the ISMS case, you will
always get authPriv if you use SSH (or TLS/DTLS) so it should be fine
to do a v3 Get with authPriv to obtain the contextEngineID. In fact, I
think it does not matter since when you hit the command responder, the
authentication / privacy processing if needed has already done and
VACM would apply the usual access control rules.

I assume that SNMPv3/USM implementation will likely continue to assume
that securityEngineID can be used as a contextEngineID - so they won't
need to change. The discovery would likely only be used by SNMPv3/TSM
or other interfaces like NETCONF to discover the contextEngineID. 

In other words, I expect that SNMPv3 implementations do something
close to the following:

if (usm) {
  do_security_engineid_discovery();
  if (contextEngineID == nil) {
     contextEngineID = securityEngineID;	/* common guess */
  }
}

if (contextEngineID == nil) {
  do_context_engineid_discovery();
}

For historic version of SNMP, this does not at all matter since all
this is implicit.

Hope this clarifies the idea.

/js

---

From: Joe Fernandez <[email-masked]>
Date: Fri, 08 Dec 2006 22:22:11 +1100

Hi,

>   do_context_engineid_discovery();

Thanks for taking the time to explain in detail.

Is it correct to call the USM related action a "common guess" ? If an 
algorithm is based on a guess that is not confirmed, it seems to me that is 
a bug that needs to be fixed. But I'm not so sure that the USM related 
action can be called a "common guess".

snmpEngineID is defined in RFC 3411.

Later RFC 3411 says the contextEngineID is equal to the snmpEngineID of its 
associated SNMP engine.

Then in RFC 3412 securityEngineID appears in the ASIs and text says it 
should be set to the snmpEngineID.

AFAIK, it is only in the proxy case where contextEngineID can be different 
from the snmpEngineID of the engine to which the protocol message first 
goes. In this case the different contextEngineID has to be supplied by some 
external means. When it is not supplied, the algorithm uses the default 
value for contextEngineID, which is the snmpEngineID of the entity, as 
discovered using securityEngineID discovery. There's a difference to me 
between going with the default - unless overridden - and going with a guess.

If there is no bug in the algorithm, your option a) may be better - 
applications register for say, contextEngineID = 42, meaning this engine.

Joe Fernandez
Kardinia Software
[email-masked]
www.kardinia.com

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Dec 2006 14:20:37 +0100

> should be set to the snmpEngineID.

OK. So I will stop talking about a guess and remove the comment from
the pseudo code above.
 
> between going with the default - unless overridden - and going with a guess.

This was also my believe. But then others and the text in RFC 3412
which is not that crystal clear led to some confusion.

> applications register for say, contextEngineID = 42, meaning this engine.

This conclusion now escapes me. I believe the algorithm above is still
viable - all that changes is to remove the comment. My point was that
I like the fact that we have payload in a scoped PDU and a default
"local" contextEngineID just means a scoped PDU is not really fully
scoped anymore, which sounds like moving backwards architecturally.

Do you see something wrong with the following?

  do_context_engineid_discovery()
  {
     contextEngineID = LOCAL_CONTEXT;
     contextEngineID = get(snmpEngineID.0)
  }

  /* ... */

  if (usm) {
      do_security_engineid_discovery();
      if (contextEngineID == nil) {
         contextEngineID = securityEngineID;
      }
  }

This reduces the usage of the special "local" context to the retrieval
of exactly one MIB object which is part of the engine itself. The
downside is that there is overhead for an application that only
retrieves say a single object in it's whole lifetime. But then
session-based security will make this application rather expensive
anyway, so for ISMS this might not be such a big issue.

One way out could be to leave it open how many objects agents register
under the "local" contextEngineID but this is just kind of pushing the
decision out to implementors.

/js

---

From: Joe Fernandez <[email-masked]>
Date: Sat, 09 Dec 2006 14:21:21 +1100

[...]

>This conclusion now escapes me.

Sorry, I'll try to explain my reasoning better. I think we are overloading 
the phrase "the algorithm" in this discussion and humans don't cope with 
overloading as well as compilers do.

I was referring to the algorithm that a USM based system employs to get to 
contextEngineID, a subset of your algorithm pseudo code. Your option c) 
allows for independent discovery of contextEngineID. The motivation is for 
Netconf and ISMS  implementations to be able to provide context 
identification. I was thinking that *if* the USM scenario procedures have a 
bug, then the development of this independent discovery would also allow 
USM based systems to do it right and would benefit them as well. But I am 
not convinced that the procedure in the USM scenario is wrong and you are 
not either. So option c) does not seem to provide any benefit to USM 
scenarios.

So the requirement is a "narrower" one to get at context engine 
identification in a non-USM scenario. You are arguing for c) over a) in the 
interests of architectural purity. In arguments about architectural purity 
vs quick fixes I am usually on the architectural purity side but in this 
case I don't get it. You see Gets in local context as unscoped and 
therefore ugly and want to reduce them to one or a small number (but we 
cannot eliminate them completely.) I'm failing to see the ugliness because 
I see the Gets as still scoped to local engine in option a).

>I believe the algorithm above is still

Isn't it scoped to the local engine?

>Do you see something wrong with the following?

"wrong" is probably too strong a word. I still don't get the benefit of the 
extra complexity that the extra level of indirection introduces.

Joe Fernandez
Kardinia Software
[email-masked]
www.kardinia.com

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 10 Dec 2006 23:06:27 +0100

> not either. So option c) does not seem to provide any benefit to USM 

The pseudo code was on purpose written such that nothing changes to
the way things seem to work today with USM.
 
> identification in a non-USM scenario. You are arguing for c) over a)
> in the interests of architectural purity. In arguments about
> architectural purity vs quick fixes I am usually on the
> architectural purity side but in this case I don't get it. You see
> Gets in local context as unscoped and therefore ugly and want to
> reduce them to one or a small number (but we cannot eliminate them
> completely.) I'm failing to see the ugliness because I see the Gets
> as still scoped to local engine in option a).

With SNMPv3, SNMP messages contain a ScopedPDU and this ScopedPDU
contains everything to name an object uniquely within an
administrative domain. The tuple (contextEngineID, contextName, OID)
serves as a unique identifier for a piece of information in your
managed network.

I like to preserve this so that it does not matter how I retrieved a
piece of data - whether I used SNMPv3/USM, SNMPv3/TSM, or NETCONF, or
even SYSLOG structured data. Once I have the (contextEngineID,
contextName, OID) tuple, I know to which data I can safely related
that information.

With approach a), I loose this nice feature of SNMPv3 since I now need
to have additional information which transport addresses and access
methods happen to map to the same engine. This becomes even worse if
there are transports that use dynamic transport endpoints.

Since I believe there are good reasons to keep the ScopedPDU
meaningful (and since I do not want to be guilty to damage this
concept), I proposed to restrict the usage of a wildcard "local"
engineID to just one purpose - discovery of the proper
contextEngineID.

Does this make sense?

/js

---

From: Joe Fernandez <[email-masked]>
Date: Mon, 11 Dec 2006 22:54:49 +1100

Hi,
Thanks for another patient detailed explanation. In fact, given that my 
mail client says you sent it just before midnight on Sunday your time, 
thanks for giving up your Sunday evening to answer my mail. (BTW, according 
to rumour there is life outside IETF mailing lists ...but it is only a rumour.)

>the way things seem to work today with USM.

Yes, I didn't originally understand why you did this  - if there was a bug 
I would rather fix it than maintain "backward compatibility bug mode". 
Anyway, the two of us seem to believe that the USM scenario gets it right, 
so this point is now not relevant.

>serves as a unique identifier for a piece of information in your

Well, yes, but there is an SNMP engine in the picture and your 
identification includes the SNMP engineID.  The raw data may be a different 
data structure but the SNMP MIB presents the data as part of the SNMP 
architecture.

>engineID to just one purpose - discovery of the proper

Yes but I think this is a case of us taking two different MIB views. (I 
think) you want to completely decouple the data from the transport 
(laudable) and you want to take the view that the MIB information is 
defined by a 3-tuple independent of SNMP engine. I'm taking the view that 
the identification associates the MIB information with an engine anyway so 
using the local engine ID concept does not in fact introduce extra coupling 
and the extra overhead of separate engineID retrieval is not justified.

Let me put it another way:

I tend to think of your 3 solutions by label: (If I explain what the labels 
mean to me, I hope it is OK to use them.)

- The Dave Perkins/42 solution: I think you said David Perkins came up with 
the idea of a "this" engine local contextEngineID constant and I tossed in 
42 as a suggestion for the constant because some other standards body used it
- the PlayBingo - the NMS sends  a random contextEngineID NNNN and the 
agent answers "No-o-o, the right answer is MMMM"
- the One-Object Agent: There is an agent that registers for the local 
contextEngineID and it is used only for Gets of snmpEngineID.

Play Bingo looks ugly to me.

I don't like having an agent (application) whose sole raison d'etre is to 
return the value of one object.

Anyway you originally asked for people to put in their views. The other 62 
people on this list have presumably been waiting politely for us to to 
finish this exchange before doing so. So perhaps I should give them the 
chance to comment on the options a), b), c) as defined in your earlier 
posting in this thread.

Thanks

Joe Fernandez
Kardinia Software
[email-masked]
www.kardinia.com

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Dec 2006 17:51:51 +0100

On Mon, Dec 11, 2006 at 10:54:49PM +1100, Joe Fernandez wrote:

> defined by a 3-tuple independent of SNMP engine.

I believe this is the view taken by RFC 3411 and yes I believe the RFC
3411 view is laudable. Section 3.3. of RFC 3411 is all about the
naming of management information and it says among other things:

   [...] Thus, in order to identify an
   individual item of management information within the management
   domain, its contextName and contextEngineID must be identified in
   addition to its object type and its instance.

In fact, I am not trying to introduce something laudable; I more
trying to not be the one who was breaking something laudable. ;-)

> contextEngineID and it is used only for Gets of snmpEngineID.

The last one is a misnomer - we are not talking about a "one-object
agent". As RFC 3411 says: 

   [...] The same item of management information can exist
   in multiple contexts.

So you register this one object (the snmpEngineID) in the default
"local" context in addition to the normal context instead of
registering every object twice. (If your implementation becomes
simpler by registering all objects, be my guest. I would just not
require this and managers to depend on this - this is the essence of
our difference.)
 
> chance to comment on the options a), b), c) as defined in your earlier 

Yes, it would be nice and very helpful if others can share their
wisdom with us.

The discussion so far helped me to better understand the issue and
this alone was useful, whatever a final solution will look like. I
should probably start to but things into an ID so we don't loose the
details in one of these many email archives.

/js