Re: [IETFMIBS] RFC 3584 usage of snmpTargetAddrTable

["tom.petch" <cfinss at dial.pipex.com>]

----- 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