Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-snmp-engineid-discovery-00.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Jan 2008 12:46:44 +0100

On Mon, Dec 31, 2007 at 03:44:23PM +0100, Romascanu, Dan (Dan) wrote:
> Here are my comments, speaking as a contributor. 
> 
> 1. section 2 - I find confusing saying that 'the contextEngineID is a
> binary value constructed according to the rules defined as part of the
> SnmpEngineID textual convention of the SNMP-FRAMEWORK-MIB [RFC3411]' In
> 3411 SnmpEngineID has a SYNTAX of OCTET STRING and within it only
> specific bits define the value of snmpEngineID/contextEngineID.
> Clarification and more details would be useful here I think.

I have replaced "binary value" with "octet string value" to be more
precise. I do not know which other clarifications or details you
request to be listed. Please elaborate.
 
> 2. section 3.2 - point 4) in the discovery procedure is not always
> executed, but only when the retrieval operation described at 3) is not
> successful. It would be useful to mention this, and maybe merge 4) into
> 3), as discovery is discontinued in both cases, I think. 

Step 2) also returns if an snmpEngineID has been detected. The steps
2) and 3) are both similar in structure (do a probe, return if
success, otherwise continue) and the final step returns a failure
indications. If we ever have to add additional probing steps, this
regular structure might be handy.

> 3. section 4 - s/four ctets/four octets/

fixed

> 4. same - add editor note that RFCXXXX is this document

done

> 5. because of the IANA consideration section I think it is appropriate
> to mention that the document updates RFC3412

I think it updates RFC3411 not RFC 3412. I have added an updates to
RFC3411.

> 6. section 5 - It looks appropriate to capitalize RECOMMENDED in 'In
> particular, it is recommended to protect the discovery exchange.'
> Similarly NOT RECOMMENDED in the following paragraph. 

done

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 1 Jan 2008 13:19:25 +0100

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, January 01, 2008 1:47 PM
> To: Romascanu, Dan (Dan)
> Cc: Scott O. Bradner; [email-masked]
> Subject: Re: [OPSAWG] WGLC 
> fordraft-ietf-opsawg-snmp-engineid-discovery-00.txt
> 
> > SnmpEngineID textual convention of the SNMP-FRAMEWORK-MIB 
> [RFC3411]' 
> > In
> I have replaced "binary value" with "octet string value" to 
> be more precise. I do not know which other clarifications or 
> details you request to be listed. Please elaborate.

If you say "octet string value" it looks clear enough to me now. 

> > successful. It would be useful to mention this, and maybe merge 4) 
> > into 3), as discovery is discontinued in both cases, I think.
> 
> 2) and 3) are both similar in structure (do a probe, return 
> if success, otherwise continue) and the final step returns a 
> failure indications. If we ever have to add additional 
> probing steps, this regular structure might be handy.
> 
> I think it updates RFC3411 not RFC 3412. I have added an 
> updates to RFC3411.

Of course. 

Dan

---

From: "David Harrington" <[email-masked]>
Date: Mon, 7 Jan 2008 20:57:23 -0500

Hi,

I have reviewed this draft and have a few comments.

1) In RFC3411, we moved away from the manager/agent terminology. The
text in the abstract and the text in the first paragraph in the
Introduction differ in their use of manager/agent terminology. I think
the text in the Introduction is closer to what the SNMPv3 WG wanted to
see.

2) In the abstract, I am not sure identity is the right word; I think
identifier is the right word.

3) I think the draft has now expired and is no longer available. Can
we get its expiration extended since it is in LC?

4) s/co-exists/co-exist/

5) s/discovery mechanisms, which may exist/discovery mechanisms that
may exist/

6) s/The contextName is a string/The contextName is an OCTET STRING/.
It is important to make this distinction, because RFC3411 and RFC3412
do not define this further. A contextName may have a structured value,
just as a contextEngineID has a structured value. That is an
implementation-dependent decision.

7) /contextEngineID is a binary value constructed/contextEngineID is
an OCTET STRING constructed/. 

8) would "tranport addresses" be better than "transport endpoints"?
For example, it really is the address of an endpoint that changes
dynamically, not the endpoint itself.

9) I don't know what a "main local context" is. 

I am a bit uncomfortable allowing users to getNext their way through a
"main local context" as part of the engineID discovery process. VACM
is not designed to control access based on the
contextEngineID/contextName combination, only contextName (see
RFC3415, section 2.5 and the isAccessAllowed ASI). I think it would be
more secure to use a special contextName with localEngineID, such as
"discovery", so operators can control what information is accessible
during localEngineID discovery.

Would it add meaning to the name to use "discoveryEngineID" rather
than "localEngineID"? snmpEngineID is already the local engineID.

10) Section 3.1 mentions the SNMPv3 specs allowing to register
multiple contexts. A context is defined by a contextEngineID and a
contextName, so the current wording is incorrect.

The registerContextEngineID ASI defined in RFC3412 registers
combinations of contextEngineIDs and PDUTypes, with no contextName.

The registration mechanism allows the registration of multiple
engineIDs and multiple PDUtypes.

11) In section 3, you mention the format 3), but don't provide a
reference. The wording of the sentence seems ambiguous. Are you "using
the enterprise ID 0 for the localEngineID", or are you allocating
format#6 for enterprise 0? I think this sentence would be better
broken into multiple sentences.

12) s/SNMP command responder implementing/An SNMP command responder
implementing/

13) s/is simply done/is done/

14) I question whether the elements of procedure should discuss
checking whether the application provides a value, and whether a
security model does discovery. 

If these things SHOULD be done, then I think they should be descrbed
as specific changes to the current elements of procedure. How, and at
what point in the SNMPv3 elements of procedure, does one check whether
the application provided a contextEngineID? Is this step MPM and
security model-indepedent? Within the processing of which ASI should
this be done? Is the checking process only applicable when a manager
is preparing to send outgoing messages? What about outgoing
notifications? How about checking whether a previously received
notification revealed this information?
 
Recording contextEngineIDs is made implementation-dependent in SNMPv3,
because it is considered an internal process - it nmight be defined by
a user as a parameter in a command line application, or from a
pre-configured database, or by polling for snmpEnbgineID using SNMPv1
discovery, and so on. 

You are defining a new "protocol" for discovering contextEngineIDs. I
think you should have a clear separation of the hints for
implementation-dependent determination of whether the contextEngineID
is already known, from the required behaviors for interoperability of
the new "protocol". 

I don't see any problems caused by running this discovery even if the
contextEngineID is already known, assuming the results would be the
same. So is it really necessary to describe these steps to verify that
the contextEngineID is not known? 

15) It is legal to register multiple contextEngineIDs (in addition to
localEngineID). Can localEngineID discovery discover multiple
snmpEngineIDs?

16) s/exemplary/an example/ (exemplary has multiple meanings)

17) s/ctets/octets/

18) IANA does sort of have a registry for EngineID formats; it is
however very incomplete, with no mention of the existing formats. IANA
should actually manage values 1 through 127, not just 6-127. It's just
that SNMPv3 already defined formats 1-5.  

Since this document is requesting making the registry real, I suggest
this document should also specify what RFC2434 action is required to
add entries to the registry.

19) I think the Security Considerations should also mention that
snmpEngineID is represented in a MIB module, and if a device
configuration permits SNMPv1/v2c access to the snmpEngineID variable
of a target system, that will also reveal a suitable contextEngineID
value for subsequent SNMPv3 usage. 

Of course, if this is considered acceptable by the administrator,
non-secure reading of snmpEngineIDs using any version of SNMP is
another way to do discovery of contextEngineIDs.

20) If a special contextName is not used for discovery, then the
Security Considerations section should discuss the inability of an
administrator to differentiate the access controls applied for a
discovery operation compared to normal operations for the "main local
context" when using VACM. I think it might be appropriate for an
administrator to NOT point to the main local context, and if we don't
standardize a discovery localEngineID/contextName, we may end up with
different contextNames associated with the localEngineID. 

I think we should also provide a recommended VACM configuration for
what should be made accessible during an initial discovery operation.

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

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Monday, December 31, 2007 9:44 AM
> To: Scott O. Bradner; [email-masked]
> Subject: RE: [OPSAWG] WGLC for 
> draft-ietf-opsawg-snmp-engineid-discovery-00.txt
> 
> [RFC3411]' In
> > From: Scott O. Bradner [mailto:[email-masked]] 
> > Sent: Wednesday, December 19, 2007 6:01 PM
> > To: [email-masked]
> > Subject: [OPSAWG] WGLC for 
> > draft-ietf-opsawg-snmp-engineid-discovery-00.txt
> > 
> > 
> > This starts a working group last call for "Simple Network 
> > Management Protocol (SNMP) Context EngineID Discovery"
> > <draft-ietf-opsawg-snmp-engineid-discovery-00.txt> for 
> > publication as a Proposed Standard RFC
> > 
> > please review and comment on the list before Jan 7th
> > 
> > 
> > Thanks 
> > 
> > Scott & Ted
> > 
> >

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 7 Jan 2008 22:58:56 -0800

Hi -

> From: "David Harrington" <[email-masked]>
> To: <[email-masked]>
> Cc: "'Seely, Ted A [CTO]'" <[email-masked]>
> Sent: Monday, January 07, 2008 5:57 PM
> Subject: RE: [OPSAWG] WGLC for draft-ietf-opsawg-snmp-engineid-discovery-00.txt

...
> than "localEngineID"? snmpEngineID is already the local engineID.
...

In RFC 3415 section A.1 (2) we already recommend a default context "".
I would hope that that is what is meant by the phrase "main local context",
and that we would not need to mandate any other contexts to support
discovery.

Randy

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 8 Jan 2008 13:41:06 +0100

W.r.t.
> -----Oorspronkelijk bericht-----
> Van: David Harrington [mailto:[email-masked]]
> Verzonden: dinsdag 8 januari 2008 2:57
> Aan: [email-masked]
> CC: 'Seely, Ted A [CTO]'
> Onderwerp: RE: [OPSAWG] WGLC for

.. snip ..

> implementation-dependent decision.

Mmm... I do see that we have defined contextName as an OCTET STRING in the
SNMPv3 Message format. Seems OK.
But once we use a contectName within any MIB module, then it is based on TC
SnmpAdminString. So it MUST be human readable I think. So I am not sure I
would
like us to use "OCTET STRING" instead of "string".

Bert

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 8 Jan 2008 13:41:34 +0100

I agree

Bert Wijnen 

> Van: Randy Presuhn [mailto:[email-masked]]
> Verzonden: dinsdag 8 januari 2008 7:59
> Aan: [email-masked]
> Onderwerp: Re: [OPSAWG] WGLC for

---

From: "David Harrington" <[email-masked]>
Date: Tue, 8 Jan 2008 11:54:01 -0500

Hi,

Let me tell you that I started out my comment on "main local context"
as a recommendation that "default context" be used.

I also wanted to comment that I would prefer that localEgineID
discovery only support GET of snmpEngineID, to help contrain what
information was made available using localEngineID. Unfortunately, the
registration mechanism doesn't allow such a fine-grained approach. 

In researching this further, I realize that my proposed "discovery"
context made no difference. localEngineID gets registered for any read
operation for ANY contextName.

So I agree that we can simply use "default context" for "main local
context".

VACM does not allow contraints based on contextEngineID, so VACM
offers no better control than already exists for messages where the
contextEngineID is known. Forcing a requester to know the
contextEngineID provides only trivial authentication, but it is more
authentication than not requiring this knowledge.

My concern is for the administrator who wants to enable automated
engineID discovery, but doesn't want to make everything available to a
potential attacker doing an engineID discovery. Operators need to be
aware of just what becomes more accessible by allowing this "wildcard"
value for contextEngineID.

Support for localEngineID can be added by a vendor with no knowledge
of the administrator of the system. Vendors can hardcode a
registration entry (or hardwire processing) for the mapping of
localEngeinID and GET*, and I believe operators should be allowed to
disable that if desired.

I would like to see more analysis in the security considerations about
the tradeoffs between automated engineID discovery and making the MIB
accessible using a wildcard EngineID. This should probably include
discussion of initial configuration from Appendix A of RFC3415.

Maybe there is effectively no real difference in the security
vulnerabilities, but I would like to see the analysis of potential
vulnerabilities discussed a bit more, and if there are differences,
then how to protect against them should be discussed.

dbh

> From: Randy Presuhn [mailto:[email-masked]] 
> Sent: Tuesday, January 08, 2008 1:59 AM
> To: [email-masked]
> Subject: Re: [OPSAWG] WGLC for

---

From: "David Harrington" <[email-masked]>
Date: Tue, 8 Jan 2008 12:19:41 -0500

inline.

> From: Bert Wijnen - IETF [mailto:[email-masked]] 

> like us to use "OCTET STRING" instead of "string".

string is not an SNMP datatype or textual convention. I think saying
it is a string, which happens to be a common C datatype, not an SNMP
datatype, could cause problems, especially if somebody defined an
OCTET STRING value that contained an embedded '0'.

If the text was modified to read "The contextName is an OCTET STRING
formatted according to the SnmpAdminString textual convention", and
provided suitable references to its SnmpAdminString usage in RFC341x
MIB modules, I would not object. I recommend reference to
vacmContextTable in RFC3415.

dbh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Jan 2008 15:31:01 +0100

> I have reviewed this draft and have a few comments.

Thanks for your detailed review. I will respond inline how I like
to address the comments.
 
> the text in the Introduction is closer to what the SNMPv3 WG wanted to

Changed the first paragraph to the following:

   The Simple Network Management Protocol (SNMP) version three (SNMPv3)
   requires that an application knows the identifier (snmpEngineID) of
   the remote SNMP protocol engine in order to retrieve or manipulate
   objects maintained on the remote SNMP entity.

> identifier is the right word.

Replaced identity with identifier in all places where it was used.

> we get its expiration extended since it is in LC?

I leave this to the chair. You can still find it on the tools.ietf.org
pages...

fixed

fixed

> implementation-dependent decision.

As others have already pointed out, the contextName is in fact an
SnmpAdminString in all our MIB modules and hence a character string.
I suggest to use the following text:

   [...] The contextName is a character string (following the
   SnmpAdminString textual convention of the SNMP-FRAMEWORK-MIB
   [RFC3411]) while the contextEngineID is an octet string constructed
   according to the rules defined as part of the SnmpEngineID textual
   convention of the SNMP-FRAMEWORK-MIB [RFC3411].

> an OCTET STRING constructed/. 

see above

> dynamically, not the endpoint itself.

changed from endpoints to addresses

> than "localEngineID"? snmpEngineID is already the local engineID.

I replaced "main local context" with "default context" since this is
the appropriate term. I strongly prefer to not introduce a special
context for discovery, agreeing with Randy and Bert. We don't do this
for USM either. I also don't see the value to be able to control what
is accessible during localEngineID discovery since SNMPv3 access
control by design is based on the (authenticated) securityName and not
on contextName or transport addresses. I believe we should not change
this model.

> engineIDs and multiple PDUtypes.

Good catch. I reworded the first paragraph in 3.1 as follows:

   An SNMP command responder implementing this specification MUST
   register their pduTypes using the localEngineID snmpEngineID value
   (defined below) using the registerContextEngineID() Abstract
   Service Interface (ASI) defined in RFC 3412 [RFC3412].  This
   registration is done in addition to the normal registration under
   the SNMP engine's snmpEngineID.  This is consistent with the SNMPv3
   specifications since they explicitly allow to register multiple
   engineIDs and multiple pduTypes [RFC3412].

> broken into multiple sentences.

I find the text pretty clear if you look at the description of the
SnmpEngineID textual convention. I have added a reference to RFC3411
to make it clear where the relevant definition of SnmpEngineID can
be found. It now reads:

   The SnmpEngineID textual convention [RFC3411] defines that an
   snmpEngineID value MUST be between 5 and 32 octets long.  This
   specification proposes to use the variable length format 3) and to
   allocate the reserved, unused format value 6, using the enterprise ID
   0 for the localEngineID.  An ASN.1 definition for localEngineID would
   look like this:

               localEngineID OCTET STRING ::= '8000000006'H

If you think this is still ambiguous, pleaase make a concrete proposal
how to change the wording.

fixed

fixed

> the contextEngineID is not known? 

I have changed the wording a bit so that we talk about known
contextEngineIDs and leave it open where the contextEngineID comes
from. Otherwise, I find the procedure useful to have. Are you having
an issue with the statement that discovery SHOULD only be done when it
is needed? This I guess needs further discussion as I do not
understand the edits...

> localEngineID). Can localEngineID discovery discover multiple

Sure, you can register multiple contextEngineIDs (e.g. in proxy
situations). However, an SNMP engine has a single unique snmpEngineID
(this is why SNMP-FRAMEWORK-MIB::snmpEngineID is a scalar).

fixed

fixed

> add entries to the registry.

Changed to the following:

   IANA has to create a registry to assign new format values out of the
   originally assigned and reserved number space 1-127.  For new
   assignments, a specification is required as per [RFC2434].
 
> another way to do discovery of contextEngineIDs.

I have added the following text:

   If a device configuration permits non-secure SNMPv1/v2c access to a
   target system, then reading the snmpEngineID variable of the SNMP-
   FRAMEWORK-MIB will also reveal a suitable contextEngineID value for
   subsequent SNMPv3 usage.  However, implementations should not rely on
   non-secure SNMPv1/v2c access and therefore MUST implement this
   specification to enable secure contextEngineID discovery.

> what should be made accessible during an initial discovery operation.

I have added the following new text to explain the situation:

   The isAccessAllowed() abstract service primitive of the SNMP access
   control subsystem does not take the contextEngineID into account when
   checking access rights [RFC3411].  As a consequence, it is not
   possible to define a special view for context engineID discovery.  A
   request with a localEngineID is thus treated like a request with the
   correct snmpEngineID by the access control subsystem.  This is inline
   with the SNMPv3 design where the authenticated identity is the
   securityName (together with the securityModel and securityLevel
   information) and transport addresses or knowledge of contextEngineID
   values do not impact to the access control decision.

/js