[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IETFMIBS] RFC 3584 usage of snmpTargetAddrTable
Tom,
Thanks for the reply,
Understood, so from the protocol perspective you fill 'dummy' values in
the snmpTargetAddrParams MIB object - I guess there is no more options
than that as snmpTargetAddrParams is a required object to turn the entry
active.
That's how we specify that today, although not clean.
Eduardo
-----Original Message-----
From: tom.petch [mailto:cfinss at dial.pipex.com]
Sent: Wednesday, July 16, 2008 8:34 AM
To: Eduardo Cardona; j.schoenwaelder at jacobs-university.de
Cc: ietfmibs at ietf.org
Subject: Re: [IETFMIBS] RFC 3584 usage of snmpTargetAddrTable
----- Original Message -----
From: "Eduardo Cardona" <e.cardona at CableLabs.com>
To: <j.schoenwaelder at jacobs-university.de>
Cc: <ietfmibs at ietf.org>
Sent: Monday, July 14, 2008 9:32 PM
Subject: Re: [IETFMIBS] RFC 3584 usage of snmpTargetAddrTable
> Jurgen thanks for the reply
>
> It appears to me REF 3484 defines a Community Name mapped to a
> security name for MP access level and the transport tag points to the
> source access control (transport Addr/Mask ) (I believe not the
> original intention of the snmpTargetAddrTable).
>
Sort of. SNMPv3 security revolves around securityName and so there is a
mapping table between community name and securityName. The tag is a way
of joining an entry in the snmpCommunityTable to one or more entries in
the snmpTargetAddrTable which then allows access control on the source
address; the rest of the entry in the snmpTargetAddrTable is ignored as
RFC3584 implies. (And if they are ignored, then it is immaterial what
length the string is).
> Then, the SnmpTargetAddrParams point back again to a Security Name in
> snmpTargetParamsTable (?).
True but not relevant for an incoming request or its response.
>
> For me SnmpTargetAddrParams is clear when used in notifications and
> probably in Proxy systems.
>
> RFC 3584 does not explain the role of SnmpTargetAddrParams. My thought
> was that SnmpTargetAddrParams in SNMPv1, SNMPv2c responses is not used
> as the agent responds using the MP model from the request message.
>
I agree
> See RFC 3584
> 5.2.2. Generating An Outgoing Response
>
> There is no special processing required for generating an outgoing
> response. However, the community string used in an outgoing
response
> must be the same as the community string from the original request.
> The original community string MUST be present in the
> securityStateReference information of the original request.
>
> Moreover, different community names associated with different security
> names can point to the same transport tag, therefore the
> snmpCommunityTable security name will not match the securityName in
> the snmpTargetParamsTable entry.
>
True, but for command and response, the snmpTargetParamsTable is ignored
as per RFC3584.
Tom Petch
> Let me know it that clarifies the question
>
> Thanks
>
> Eduardo
>
> -----Original Message-----
> From: Juergen Schoenwaelder
> [mailto:j.schoenwaelder at jacobs-university.de]
> Sent: Monday, July 14, 2008 12:33 PM
> To: Eduardo Cardona
> Cc: ietfmibs at ietf.org
> Subject: Re: [IETFMIBS] RFC 3584 usage of snmpTargetAddrTable
>
> On Mon, Jul 14, 2008 at 10:37:29AM -0600, Eduardo Cardona wrote:
>
> > I think the syntax constrain of snmpTargetAddrParams does not cover
> > the usage of snmpTargetAddrTable in RFC 3584 where
> > snmpTargetAddrTable
>
> > does not represent a SNMP notification target but a SNMPv1/v2c
> > transport address/mask pair for SNMP Snmpv1/v2c coexistence with
> SNMPv3 framework.
>
> Why do you think so?
>
> > Existing definition RFC 3413,
> >
> > snmpTargetAddrParams OBJECT-TYPE
> > SYNTAX SnmpAdminString (SIZE(1..32))
> > MAX-ACCESS read-create
> > STATUS current
> > DESCRIPTION
> > "The value of this object identifies an entry in the
> > snmpTargetParamsTable. The identified entry
> > contains SNMP parameters to be used when generating
> > messages to be sent to this transport address."
> > ::= { snmpTargetAddrEntry 7 }
> >
> > 'intended' syntax
> > snmpTargetAddrParams OBJECT-TYPE
> > SYNTAX SnmpAdminString (SIZE(0|1..32))
> > MAX-ACCESS read-create
> > STATUS current
> > DESCRIPTION
> > "The value of this object identifies an entry in the
> > snmpTargetParamsTable. The identified entry
> > contains SNMP parameters to be used when generating
> > messages to be sent to this transport address.
> > The zero-length string is applicable to entries in this
> > table related to RFC 3584."
> > ::= { snmpTargetAddrEntry 7 }
>
> I fail to see how the added sentence provides clearity. An
> snmpTargetAddrEntry identifies a transport endpoint with associated
> parameters while an snmpTargetParamsEntry adds to it the SNMP message
> processing model to be used, the security model to be used, etc. You
> need all this for SNMPv1 or SNMPv2c. Perhaps what is missing is just
> an example how these tables work together but I doubt someone will
> revise RFC 3584 for that purpose.
>
> /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/>
> _______________________________________________
> IETFMIBS mailing list
> IETFMIBS at ietf.org
> https://www.ietf.org/mailman/listinfo/ietfmibs
>
_______________________________________________
IETFMIBS mailing list
IETFMIBS at ietf.org
https://www.ietf.org/mailman/listinfo/ietfmibs