Subject: [IETFMIBS] RFC 3584 usage of snmpTargetAddrTable

From: "Eduardo Cardona" <[email-masked]>
Date: Mon, 14 Jul 2008 10:37:29 -0600

All, 
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.

If that appreciation is correct, the 'intended' syntax of
snmpTargetAddrParams should be as follows (although it seems to violates
the rules of RFC 2578 for syntax refinement) - folding the changes and
implications for RFC 3413 and RFC 3584 are different and maybe an
overkill for the scope of the issue itself.

Clarifications, comments or pointers to a later RFC that handles this
issue would be appreciated.

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 }
_______________________________________________
IETFMIBS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietfmibs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Jul 2008 20:32:53 +0200

> address/mask pair for SNMP Snmpv1/v2c coexistence with SNMPv3 framework.

Why do you think so?

>     ::= { 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietfmibs

---

From: "Eduardo Cardona" <[email-masked]>
Date: Mon, 14 Jul 2008 13:32:06 -0600

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

Then, the SnmpTargetAddrParams point back again to a Security Name in
snmpTargetParamsTable (?).
 
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.

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. 

Let me know it that clarifies the question

Thanks

Eduardo

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Monday, July 14, 2008 12:33 PM
To: Eduardo Cardona
Cc: [email-masked]
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?

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

---

From: "tom.petch" <[email-masked]>
Date: Wed, 16 Jul 2008 16:33:55 +0200

----- Original Message -----
From: "Eduardo Cardona" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 14, 2008 9:32 PM
Subject: Re: [IETFMIBS] RFC 3584 usage of snmpTargetAddrTable

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

> snmpTargetParamsTable (?).

True but not relevant for an incoming request or its response.

> as the agent responds using the MP model from the request message.

I agree

> snmpTargetParamsTable entry.

True, but for command and response, the snmpTargetParamsTable is ignored as per
RFC3584.

Tom Petch

---

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 17 Jul 2008 18:11:07 -0600

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:[email-masked]] 
Sent: Wednesday, July 16, 2008 8:34 AM
To: Eduardo Cardona; [email-masked]
Cc: [email-masked]
Subject: Re: [IETFMIBS] RFC 3584 usage of snmpTargetAddrTable

----- Original Message -----
From: "Eduardo Cardona" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 14, 2008 9:32 PM
Subject: Re: [IETFMIBS] RFC 3584 usage of snmpTargetAddrTable

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

I agree

> 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