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

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

Hi Kathleen,

I will update the draft tonight or by EOB tomorrow.

Thanks,
Deepak

On 8/18/15, 11:42 AM, "Kathleen Moriarty"
<[e-mail]> wrote:

>Deepak,
>
>The improvements help a lot to better explain the security
>considerations.  Let me know when this has been updated in the draft.
>
>Thanks,
>Kathleen
>
>On Tue, Aug 18, 2015 at 1:18 PM, Deepak Kumar (dekumar)
><[e-mail]> wrote:
>> 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]>
>> Date: Tuesday, August 18, 2015 at 8:29 AM
>> To: dekumar <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>,
>> "[e-mail]"
>> <[e-mail]>, Tissa Senevirathne
>> <[e-mail]>, The IESG <[e-mail]>, Yoav Nir
>> <[e-mail]>, secdir <[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]> 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]> wrote:
>>>>
>>>> Hi Alia,
>>>>
>>>> I will be able to take care of all comments  over weekend.
>>>>
>>>> Thanks,
>>>> Deepak
>>>>
>>>> From: Alia Atlas <[e-mail]>
>>>> Date: Thursday, August 13, 2015 at 10:44 AM
>>>> To: "[e-mail]" <[e-mail]>
>>>> Cc: dekumar <[e-mail]>,
>>>> "[e-mail]"
>>>> <[e-mail]>, Tissa Senevirathne
>>>> <[e-mail]>, The IESG <[e-mail]>, Yoav Nir
>>>> <[e-mail]>, secdir <[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]>
>>>> wrote:
>>>>>
>>>>> HI Deepak,
>>>>>
>>>>> On Sun, Aug 9, 2015 at 10:07 PM, Deepak Kumar (dekumar)
>>>>> <[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]>.
>>>>>
>>>>> 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] (cell)
>>>>>  155 Beaver Street, Milford, MA 01757 USA
>>>>>  [e-mail]
>>>>>
>>>>> > Thanks,
>>>>> > Deepak
>>>>> >
>>>>> > On 8/8/15, 2:18 PM, "Yoav Nir" <[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
>>>>> >>
>>>>> >
>>>>>
>>>>
>>>
>>
>
>
>
>-- 
>
>Best regards,
>Kathleen