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

[Kathleen Moriarty <[e-mail]>]

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