Re: [secdir] Secdir last call review of draft-ietf-ipsecme-mib-iptfs-05

[Don Fedyk <[e-mail]>]

Hi Ivaylo

These paragraphs were added as part of Ipsecme WG last call and implicitly refer to the prior paragraph that states:

      Access to IP inner
      and outer traffic flow security statistics can provide information
      that IP traffic flow security obscures such as the true activity
      of the flows using IP traffic flow security. 

If we turn these paragraphs into a bullet list introduced like this:

To prevent unauthorized access to SNMP including access to IP-TFS 
sensitive objects: 

 * Implementations SHOULD provide the security features described by the
   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 versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  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 access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

  
Does that satisfy your nit?

Thanks
Don 

-----Original Message-----
From: Ivaylo Petrov <[e-mail]> 
Sent: Wednesday, October 12, 2022 4:34 PM
To: [e-mail]; [e-mail]; The IESG <[e-mail]>
Subject: Secdir last call review of draft-ietf-ipsecme-mib-iptfs-05

Reviewer: Ivaylo Petrov
Review result: Has Nits

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.

When seeing SHOULD, RECOMMEND or MAY in the security considerations, I would always like to see some information about what are possible issues if I don't follow the recommendations or what do I gain by implementing them. My reading of the security considerations section left me wanting more such details specifically in the following
paragrams:

   Implementations SHOULD provide the security features described by the
   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 versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  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 access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

Regards,
Ivaylo