Re: [secdir] SecDir Review for draft-ietf-trill-oam-mib-06

["Deepak Kumar (dekumar)" <[e-mail]>]

Hi Yoav,

Please review new draft text and provide comments.

8. Security Considerations

This MIB relates to a system that will provide network connectivity and packet forwarding services. As such, improper manipulation of the objects represented by this MIB may result in denial of service to a large number of end-users.

There are number of management objects defined in this MIB module with a MAX-ACCESS clause of read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have negative effect on sensitivity/vulnerability:

The following table and objects in the TRILL-OAM-MIB can be manipulated to to interfere with the operation of RBridges by causing cpu spike:

o trillOamMepTransmitLbmReplyIp allows reply of Loopback message to be transmitted to Ip address in the TLV and thus allowing replies to be sent to any system or single single system to cause Denial of Service.

o trillOamMepTransmitPtmReplyIp allows reply of Path Trace message to be transmitted to Ip address in the TLV and thus allowing replies to be sent to any system or single single system to cause Denial of Service.

o trillOamMepTxPtmMessages allows generation of Ptm Messages and can be used to generate lots of cpu driven traffic.

o trillOamMepTransmitMtvmReplyIp allows reply of Mtv message to be transmitted to Ip address in the TLV and thus allowing replies to be sent to any system or single single system to cause Denial of Service.

o trillOamMepTxMtvmMessages allows generation of Mtv Messages and can be used to generate lots of cpu driven traffic.

Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control GET and/or NOTIFY access to these objects and possibly to encrypt the values of these objects when sending them over the network via SNMP. For example, Path trace message expose unicast topology of network and Multi-destination Tree verification message expose multicast tree topology of network and this information should not be available to all users of the network.

SNMP version prior to SNMPv3 did not include adequate security. Even if the network itself is secure(for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.

Implementation should provide the security features described by SNMPv3 framework (see [RFC3410]), and implementations claiming compliance to the SNMPv3 standard MUST include full support for authentication and privacy via the User-based Security Model (USM)[RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353].

Further, deployment of SNMP version prior to SNMPv3 is NOT RECOMMENDED. Instead, deployment of SNMPv3 with cryptographic security enabled is RECOMMENDED. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give only those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them access to the objects.

Thanks,
Deepak

From: Alia Atlas <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, August 18, 2015 at 8:29 AM
To: dekumar <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Tissa Senevirathne <[e-mail]<mailto:[e-mail]>>, The IESG <[e-mail]<mailto:[e-mail]>>, Yoav Nir <[e-mail]<mailto:[e-mail]>>, secdir <[e-mail]<mailto:[e-mail]>>
Subject: Re: SecDir Review for draft-ietf-trill-oam-mib-06

Are you updating the draft or does Kathleen have to put a Discuss in?

Thanks,
Alia

On Thu, Aug 13, 2015 at 3:42 PM, Alia Atlas <[e-mail]<mailto:[e-mail]>> wrote:
thanks - the IESG generally begins reading drafts for the telechat about now - a week in advance.

Regards,
Alia

On Thu, Aug 13, 2015 at 1:52 PM, Deepak Kumar (dekumar) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Alia,

I will be able to take care of all comments  over weekend.

Thanks,
Deepak

From: Alia Atlas <[e-mail]<mailto:[e-mail]>>
Date: Thursday, August 13, 2015 at 10:44 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: dekumar <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Tissa Senevirathne <[e-mail]<mailto:[e-mail]>>, The IESG <[e-mail]<mailto:[e-mail]>>, Yoav Nir <[e-mail]<mailto:[e-mail]>>, secdir <[e-mail]<mailto:[e-mail]>>
Subject: Re: SecDir Review for draft-ietf-trill-oam-mib-06

Hi Deepak,

Are you planning on publishing an updated draft today?
I'd like to move the draft ahead to IESG Evaluation.

Thanks,
Alia

On Mon, Aug 10, 2015 at 2:19 PM, Donald Eastlake <[e-mail]<mailto:[e-mail]>> wrote:
HI Deepak,

On Sun, Aug 9, 2015 at 10:07 PM, Deepak Kumar (dekumar)
<[e-mail]<mailto:[e-mail]>> wrote:
> Hi Yoav,
>
> Thanks for review and comments. Please advise if we need to fix the nits
> and comments and upload new version as I am not sure about procedure of
> fixing comments during last call.
>
> Tissa has moved out of Cisco and working in another Company, I don¹t have
> privy of his new contact so I will contact him to get new contact and
> update the document also.

I've added Tissa to the cc list above. I believe that for now he wants
to be listed with "Consultant" as his affiliation and with email
address <[e-mail]<mailto:[e-mail]>>.

The IETF LC ends the 13th, in a few days. I suggest that you update
the contact info for Tissa, spell out OAM, and update the
MODULE-IDENTITY, since those don't seem like they would be
controversial. For any changes to the Security Considerations text, I
suggest you post proposed text in this thread before editing it in.

Thanks,
Donald (Shepherd)
=============================
 Donald E. Eastlake 3rd   [phone]<tel:%2B1-508-333-2270> (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]<mailto:[e-mail]>

> Thanks,
> Deepak
>
> On 8/8/15, 2:18 PM, "Yoav Nir" <[e-mail]<mailto:[e-mail]>> wrote:
>
>>Hi.
>>
>>I have reviewed this document as part of the security directorate's
>>ongoing effort to review all IETF documents being processed by the IESG.
>>These comments were written primarily for the benefit of the security
>>area directors.  Document editors and WG chairs should treat these
>>comments just like any other last call comments.
>>
>>TL;DR: The document is ready with nits.
>>
>>The document contains a MIB for operations, administration, and
>>maintenance (OAM) of TRILL. As is common for such documents, 34 of its 45
>>pages is section 7 ("Definition of the TRILL OAM MIB module²). Being an
>>expert on neither TRILL nor MIBs I have mostly skipped that section.
>>
>>Usually with MIB documents, the security considerations for the protocol
>>(several TRILL RFCs in this case) are in the protocol documents, while
>>the security considerations for SNMP are in the SNMP document (RFC 3410).
>>The MIB document only points data that is sensitive (in terms of privacy
>>or information leakage), and data which is dangerous in the sense that
>>falsified or modified data could lead to damage.
>>
>>In this document the Security Considerations section does a good job of
>>explaining that modified data can lead to changes in routing and
>>potentially to denial of service. The second paragraph is a little
>>hand-wavy for my taste:
>>
>>   There are number of management objects defined in this MIB module
>>   with a MAX-ACCESS clause of read-create. Such objects may be
>>   considered sensitive or vulnerable in some network environments.
>>
>>What network environment? Why in some but not in others? The third
>>paragraph is similar:
>>
>>   Some of the readable objects in this MIB module (objects with a MAC-
>>   ACCESS other than not-accessible) may be considered sensitive or
>>   vulnerable in some network environments.
>>
>>The section concludes with text that looks very familiar from other MIB
>>documents, basically saying that you should use SNMPv3 because it has
>>protections whereas earlier versions don¹t. It is also important to have
>>proper access control rules. One nit is that the section says that the
>>cryptographic mechanisms in SNMPv3 provide ³privacy². As of late we tend
>>to use that word for the protection of information about humans, not so
>>much about link status.
>>
>>A few general nits:
>> - In most documents that I see, the content of sections 1-4 is in a
>>single section.
>> - OAM is not expanded before first use.
>> - The MODULE-IDENTITY has ³TBD² for ORGANIZATION and authors¹ names in
>>CONTACT-INFO. looking at a few recent MIB documents, the working group is
>>usually given as ORGANIZATION and its mailing list is given as contact
>>info.
>>
>>Yoav
>>
>