Subject: RE: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-m ib-15.txt

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 2 Nov 2003 06:36:02 -0500

Hi

The following is the proposed resolution to Randy-59  Assuming no objection,
this item will be considered closed conditional on the proposed edit being
done.

In the description of alarmActiveContextName replace

          "The name of the SNMP MIB context from which the alarm came.
          For SNMPv1 alarms this is the community string from the Trap.
          Note that care needs to be taken when selecting community
          strings to ensure that these can be represented as a
          well-formed SnmpAdminString.

          If the alarm's source SNMP engine is known not to support
          multiple contexts, this object is a zero length string."

With

          "The name of the SNMP MIB context from which the alarm came.
          For SNMPv1 alarms this is the community string from the Trap.
          Note that care MUST be taken when selecting community
          strings to ensure that these can be represented as a
          well-formed SnmpAdminString. Community or Context names
          that are not well-formed SnmpAdminStrings will be mapped
          to zero length strings.

          If the alarm's source SNMP engine is known not to support
          multiple contexts, this object is a zero length string."

And add the following text to the security considerations section

"Although the use of community strings in SNMPv1 is not considered an
effective means of providing security, security administrators SHOULD
consider whether the fact that alarmActiveContextName can reveal community
string values would make this object sensitive in their environment."

Sharon

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2003 3:15 PM
To: Randy Presuhn; Disman (E-mail)
Subject: RE: [Disman] alarmActiveContextName in
draft-ietf-disman-alarm-mib-15.txt

OK to me as well. Dan

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: 22 October, 2003 3:12 AM
> To: Disman (E-mail)
> Subject: Re: [Disman] alarmActiveContextName in
> draft-ietf-disman-alarm-mib-15.txt
> 
> 
> Hi -
> 
> This looks fine to me.  I know that in the past there has
> been concern about
> MIB objects that provide access to community strings, 
> insecure as they are.
> Perhaps we should add words to the security considerations 
> section explaining
> the (perceived) sensitivity of this object, perhaps saying 
> something like
> "Although the use of community strings in SNMPv1 is not 
> considered an effective
> means of providing security, security administrators SHOULD 
> consider whether
> the fact that alarmActiveContextName can reveal community 
> string values would
> make this object sensitive in their environment."  (I'm sure 
> someone can find
> better words!)
> 
> Randy
> 
> > From: "Sharon Chisholm" <[email-masked]>
> > To: "Disman (E-mail)" <[email-masked]>
> > Sent: Saturday, October 18, 2003 3:15 PM
> > Subject: RE: [Disman] alarmActiveContextName in
> draft-ietf-disman-alarm-mib-15.txt
> >
> 
> > Hi
> >
> > The following is the proposed resolution to Randy-59
> Assuming no objection,
> > this item will be considered closed conditional on the
> proposed edit being
> > done.
> >
> > In the description of alarmActiveContextName replace
> >
> >           "The name of the SNMP MIB context from which the
> alarm came.
> >           For SNMPv1 alarms this is the community string
> from the Trap.
> >           Note that care needs to be taken when selecting community
> >           strings to ensure that these can be represented as a
> >           well-formed SnmpAdminString.
> >
> >           If the alarm's source SNMP engine is known not to support
> >           multiple contexts, this object is a zero length string."
> >
> > With
> >
> >           "The name of the SNMP MIB context from which the
> alarm came.
> >           For SNMPv1 alarms this is the community string
> from the Trap.
> >           Note that care MUST be taken when selecting community
> >           strings to ensure that these can be represented as a
> >           well-formed SnmpAdminString. Community or Context names
> >           that are not well-formed SnmpAdminStrings will be mapped
> >           to zero length strings.
> >
> >           If the alarm's source SNMP engine is known not to support
> >           multiple contexts, this object is a zero length string."
> >
> > -----Original Message-----
> > From: Randy Presuhn [mailto:[email-masked]]
> > Sent: Thursday, October 02, 2003 4:12 PM
> > To: Disman (E-mail)
> > Subject: Re: [Disman] alarmActiveContextName in 
> > draft-ietf-disman-alarm-mib-15.txt
> >
> >
> > Hi -
> >
> > As technical contributor...
> >
> > > From: "Romascanu, Dan (Dan)" <[email-masked]>
> > > To: "Randy Presuhn" <[email-masked]>;
> "Disman (E-mail)"
> > > <[email-masked]>
> > > Sent: Thursday, October 02, 2003 10:22 AM
> > > Subject: RE: [Disman] alarmActiveContextName in
> > draft-ietf-disman-alarm-mib-15.txt
> >
> >
> > ...
> > > > still doesn't tell us what a system is supposed to do when its 
> > > > handling a trap with a community string of, say, 0xff.
> > >
> > > I was meaning that a NULL string is being added in this
> case. Yeah,
> > > it's more than just a MUST.
> >
> > If that's what's intended, it should say so.
> > I'm not sure whether it's the best possible solution,
> > but this is a corner case that's probably not worth
> over-engineering.
> >
> > ...
> > > I am not familiar enough with AgentX or SMUX, but how do they deal 
> > > with notifications received from sub-agents that need to
> be forwarded?
> > > This should not be different? Also, was not SMUX a
> pre-SNMPv2 beast?
> >
> > Yeah, let's focus on AgentX; SMUX is a red herring here. For AgentX, 
> > the subagent supplies the context name as part of the notification.  
> > The master agent need never have
> heard of it
> > before, though if VACM is in use an entry with a zero-length 
> > vacmAccessContextPrefix and vacmAccessContextMatch equal to
> prefix(2) would
> > be needed to let these things get to the wire.
> >
> > The important thing is that the information is supplied by
> the subagent, and
> > the master agent doesn't know in advance how many different
> contexts it
> > might see in these notifications.
> >
> > Furthermore, RFC 2741 is (unfortunately) explicit in
> section 6.1.1 in saying
> > that
> >
> >    AgentX provides a mechanism for transmitting a context
> specification
> >    within relevant PDUs, but does not place any constraints on the
> >    content of that specification.
> > ...
> >    context.  The context is represented as an Octet String.
>  There are
> >    no constraints on its length or contents.
> >
> > I'm willing to treat non-SnmpAdminString contexts from
> subagents as a
> > pathological case. Lumping them in with the goofy community
> strings and
> > mapping them to a zero-length alarmActiveContextName.
> (which would be
> > indistinguishable from the default context) is probably as
> good a solution
> > as any.
> >
> > Sooo, back to the original problem:
> >
> > I think the first paragraph should state that community or
> context values
> > that violate the SYNTAX are to be mapped to a zero-length
> string. I think
> > the second paragraph should be MAY rather than MUST.
> >
> > Randy
> >
> >
> >
> >
> 
> 
> 
>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 2 Nov 2003 06:36:02 -0500

Hi

With

Sharon

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2003 3:15 PM
To: Randy Presuhn; Disman (E-mail)
Subject: RE: [Disman] alarmActiveContextName in

OK to me as well. Dan