RE: ipcdn MTA MIB: update of description clauses when secure SNMPv3 is not used

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 protected]; '[email protected]'; '[email protected]'
> 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. 
> 
> 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 
>