Subject: [ipcdn] ipcdn MTA MIB: update of description clauses when secure SNMPv3 is not used

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 25 Feb 2004 12:33:07 -0700

Folks,

Some operators are using SNMPv2c for MTA device management (and will
continue to do so for some period of time). We've been discussing the
impact that the unsecure SNMPv2 mgmt has on the MTA MIB with the
PacketCable OSS vendor team. I would like to share some of our thoughts
and our suggestions to make sure that we are doing the right thing and
to that those proposed changes are sound and can later be reflected in
the IETF ID mtamib draft 04.

Note that the IETF ID mtamib draft 03 does have a fairly detailed
security consideration section and recommends the use of secure SNMPv3.
Yet, the MIB module and its objects definitions assume v3 only and we've
found that the implementers feel that there should be clear guidance
when v2c mgmt is used. Some MIB objects don't mean anything when v2 is
used (these objects are related to the key mgmt for the security
relationship with the SNMP entity or prov server
(pktcMtaDevProvSolicitedKeyTimeout and alike), or to key/hash values for
the config file that are passed in secure v3 mode when the MTA
enrollment mechanism is used (pktcMtaDevProvConfigKey), etc. 

At this point, our suggestions are as follows:
 - maintain the compliance statements as-is, all MTAs will support
SNMPv3 and when v3 is used, all the objects as defined in draft 03 make
sense (at least, we think they do);
 - define in our PacketCable MIB framework the mib views, access right
for v2 mgmt,
 - for the specific objects that do not mean anything in v2, enhance the
DESCRIPTION clause to state what the device must do if v2 mgmt is used,
that is, specify the MTA's behavior when receiving SNMPv2 SET & GET
operations on those v3-specific objects.
 - Suggestions:
   add something like this in the impacted objects:
   for pktcMtaDevProvConfigKey:
             This object should not be used in non secure SNMPv3 modes.
             In non secure SNMPv3 modes, the MTA MUST return an 
             'inconsistentValue' in response to SNMP SET operations, 
             and the MTA MUST return a 'genErr' error in response to 
             SNMP GET operations."
   for pktcMtaDevProvConfigHash:
             When the MTA SNMP Enrollment mechanism is not in use, the
             hash value is provided in the configuration file itself 
             and it is also calculated by the MTA. This object value
             MUST represent the hash value calculated by the MTA.
             When the MTA SNMP Enrollment mechanism is not in use, the
             MTA must reject all SNMP SET operations on this object and
             return an 'inconsistentValue' error.
   These are just 2 examples but they basically say:
     - if unsecure v2 is used, SNMP SET on the object =>
'inconsistentValue', SNMP GET => 'genErr'
   This seems to be consistent with RFC 3416 (one could argue that
'noAccess' could be returned as well).

Question:
Is this the proper way to do this to provide some info in the MIB module
as our MTA implementers have been asking for? We plan on adding some
more details on the VACM model (MIB views, access rights and object
trees that cannot be accessed without the proper security policies.

Thanks in advance for any input on this,
Jean-Francois 

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

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 25 Feb 2004 12:34:48 -0700

RESEND with Randy's email add corrected - sorry, removed the old one for
good from my add book.

> -----Original Message-----
> From: Jean-Francois Mule 
> Sent: Wednesday, February 25, 2004 12:33 PM
> To: [email-masked]; [email-masked]'; [email-masked]'
> Cc: 'Eugene Nechamkin'; Satish Kumar at Texas Instruments; 
> PacketCable Provisioning and OSS Majordomo List
> Subject: ipcdn MTA MIB: update of description clauses when 
> secure SNMPv3 is not used
> 
> 
> Folks,
> 
> Some operators are using SNMPv2c for MTA device management 
> (and will continue to do so for some period of time). We've 
> been discussing the impact that the unsecure SNMPv2 mgmt has 
> on the MTA MIB with the PacketCable OSS vendor team. I would 
> like to share some of our thoughts and our suggestions to 
> make sure that we are doing the right thing and to that those 
> proposed changes are sound and can later be reflected in the 
> IETF ID mtamib draft 04.
> 
> Note that the IETF ID mtamib draft 03 does have a fairly 
> detailed security consideration section and recommends the 
> use of secure SNMPv3. Yet, the MIB module and its objects 
> definitions assume v3 only and we've found that the 
> implementers feel that there should be clear guidance when 
> v2c mgmt is used. Some MIB objects don't mean anything when 
> v2 is used (these objects are related to the key mgmt for the 
> security relationship with the SNMP entity or prov server 
> (pktcMtaDevProvSolicitedKeyTimeout and alike), or to key/hash 
> values for the config file that are passed in secure v3 mode 
> when the MTA enrollment mechanism is used 
> (pktcMtaDevProvConfigKey), etc. 
> 
>  - maintain the compliance statements as-is, all MTAs will 
> support SNMPv3 and when v3 is used, all the objects as 
> defined in draft 03 make sense (at least, we think they do);
>  - define in our PacketCable MIB framework the mib views, 
> access right for v2 mgmt,
>  - for the specific objects that do not mean anything in v2, 
> enhance the DESCRIPTION clause to state what the device must 
> do if v2 mgmt is used, that is, specify the MTA's behavior 
> when receiving SNMPv2 SET & GET operations on those 
> v3-specific objects.
>  - Suggestions:
>    This seems to be consistent with RFC 3416 (one could argue 
> that 'noAccess' could be returned as well).
> 
> Question:
> Is this the proper way to do this to provide some info in the 
> MIB module as our MTA implementers have been asking for? We 
> plan on adding some more details on the VACM model (MIB 
> views, access rights and object trees that cannot be accessed 
> without the proper security policies.
>