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

From: Yoav Nir <[email-masked]>
Date: Sun, 9 Aug 2015 00:18:02 +0300

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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 10 Aug 2015 07:36:44 +0300

Generally you wait to the end of IETF last call and then fix whatever nits you're going to fix. It's up to you, your shepherd (Donald), and your AD.

Contact info should be fixed because all authors need to confirm to the RFC editor that they are ok with the edits. But that is at least two months away.

Regards,

Yoav

Sent from my Windows Phone 

-----Original Message-----
From: "Deepak Kumar (dekumar)" <[email-masked]>
Sent: ‎8/‎10/‎2015 5:07
To: "Yoav Nir" <[email-masked]>; "secdir" <[email-masked]>; "The IESG" <[email-masked]>; "[email-masked]" <[email-masked]>
Subject: Re: SecDir Review for draft-ietf-trill-oam-mib-06

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.

Thanks,
Deepak

On 8/8/15, 2:18 PM, "Yoav Nir" <[email-masked]> 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.
>
>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:
>
>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:
> - 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
>

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Mon, 10 Aug 2015 02:07:17 +0000

Hi Yoav,

Thanks,
Deepak

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 10 Aug 2015 14:19:38 -0400

HI Deepak,

> 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 <[email-masked]>.

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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Alia Atlas <[email-masked]>
Date: Thu, 13 Aug 2015 13:44:12 -0400

Hi Deepak,

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

Thanks,
Alia

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Thu, 13 Aug 2015 17:52:23 +0000

Hi Alia,

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

Thanks,
Deepak

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

Hi Deepak,

Thanks,
Alia

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

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 <[email-masked]<mailto:[email-masked]>>.

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

> Thanks,
> Deepak
>
> On 8/8/15, 2:18 PM, "Yoav Nir" <[email-masked]<mailto:[email-masked]>> wrote:
>
>>Hi.
>>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 13 Aug 2015 15:42:31 -0400

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) <[email-masked]>
wrote:

> From: Alia Atlas <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: dekumar <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, Tissa Senevirathne <
> [email-masked]>, The IESG <[email-masked]>, Yoav Nir <
> [email-masked]>, secdir <[email-masked]>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 14 Aug 2015 15:03:59 -0400

Thanks for the review Yoav!

I'll wait to see the new text or an updated draft before reviewing,
assuming this comes in over the weekend.  I was about to read it.

Thanks,
Kathleen

On Thu, Aug 13, 2015 at 3:42 PM, Alia Atlas <[email-masked]> wrote:
> thanks - the IESG generally begins reading drafts for the telechat about now
> - a week in advance.
>
> Regards,
> Alia
>
>> Cc: dekumar <[email-masked]>,
>> "[email-masked]"
>> <[email-masked]>, Tissa Senevirathne
>> <[email-masked]>, The IESG <[email-masked]>, Yoav Nir
>> <[email-masked]>, secdir <[email-masked]>

-- 

Best regards,
Kathleen

---

From: Alia Atlas <[email-masked]>
Date: Tue, 18 Aug 2015 11:29:07 -0400

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 <[email-masked]> wrote:

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

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Tue, 18 Aug 2015 17:18:26 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 18, 2015 at 8:29 AM
To: dekumar <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Tissa Senevirathne <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, Yoav Nir <[email-masked]<mailto:[email-masked]>>, secdir <[email-masked]<mailto:[email-masked]>>
Subject: Re: SecDir Review for draft-ietf-trill-oam-mib-06

Thanks,
Alia

On Thu, Aug 13, 2015 at 3:42 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> 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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

Thanks,
Deepak

Hi Deepak,

Thanks,
Alia

Thanks,
Donald (Shepherd)

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 18 Aug 2015 14:42:57 -0400

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)
<[email-masked]> wrote:
> 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 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
>
> To: dekumar <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>,
>> On Thu, Aug 13, 2015 at 1:52 PM, Deepak Kumar (dekumar)

-- 

Best regards,
Kathleen

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Tue, 18 Aug 2015 19:03:53 +0000

Hi Kathleen,

I will update the draft tonight or by EOB tomorrow.

Thanks,
Deepak

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

>> o trillOamMepTxPtmMessages allows generation of Ptm Messages and can be
>>used
>>>>> > and comments and upload new version as I am not sure about
>>>>>procedure
>>>>> > of
>>>>> > Tissa has moved out of Cisco and working in another Company, I
>>>>>don¹t
>>>>> > have
>>>>> >>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
>>>>> >>In this document the Security Considerations section does a good
>>>>>job
>>>>> >> of
>>>>> >>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.
>>>>> >> - The MODULE-IDENTITY has ³TBD² for ORGANIZATION and authors¹
>>>>>names
>>>>> >> in
>>>>> >>CONTACT-INFO. looking at a few recent MIB documents, the working
>>>>>group
>>>>> >> is

---

From: Yoav Nir <[email-masked]>
Date: Tue, 18 Aug 2015 23:03:29 +0300

Thanks, Deepak. This looks good.

Yoav

> On Aug 18, 2015, at 8:18 PM, Deepak Kumar (dekumar) <[email-masked]> wrote:
> 
> Hi Yoav,
> 
> From: Alia Atlas <[email-masked] <mailto:[email-masked]>>
> To: dekumar <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Tissa Senevirathne <[email-masked] <mailto:[email-masked]>>, The IESG <[email-masked] <mailto:[email-masked]>>, Yoav Nir <[email-masked] <mailto:[email-masked]>>, secdir <[email-masked] <mailto:[email-masked]>>
> On Thu, Aug 13, 2015 at 3:42 PM, Alia Atlas <[email-masked] <mailto:[email-masked]>> wrote:
>> On Thu, Aug 13, 2015 at 1:52 PM, Deepak Kumar (dekumar) <[email-masked] <mailto:[email-masked]>> wrote:
>>> Hi Alia,
>>> 
>>> From: Alia Atlas <[email-masked] <mailto:[email-masked]>>
>>> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>>> Cc: dekumar <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Tissa Senevirathne <[email-masked] <mailto:[email-masked]>>, The IESG <[email-masked] <mailto:[email-masked]>>, Yoav Nir <[email-masked] <mailto:[email-masked]>>, secdir <[email-masked] <mailto:[email-masked]>>
>>> On Mon, Aug 10, 2015 at 2:19 PM, Donald Eastlake <[email-masked] <mailto:[email-masked]>> wrote:
>>>> HI Deepak,
>>>> 
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>> > Hi Yoav,
>>>> >
>>>> address <[email-masked] <mailto:[email-masked]>>.
>>>> 
>>>>  Donald E. Eastlake 3rd   +1-508-333-2270 <tel:%2B1-508-333-2270> (cell)
>>>>  [email-masked] <mailto:[email-masked]>
>>>> 
>>>> > Thanks,
>>>> > Deepak
>>>> >
>>>> > On 8/8/15, 2:18 PM, "Yoav Nir" <[email-masked] <mailto:[email-masked]>> wrote:
>>>> >
>>>> >>Hi.
>>>> >>