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

[Don Fedyk <[e-mail]>]

Hi 

I have made this change and the changes from IANA Review. I also adjusted the mib name based on what I found for other drafts and a reference to informative also based on other drafts and the error I was getting from idnits.

Thanks
Don   

-----Original Message-----
From: Ivaylo Petrov <[e-mail]> 
Sent: Thursday, October 13, 2022 3:55 PM
To: Don Fedyk <[e-mail]>
Cc: [e-mail]; [e-mail]; The IESG <[e-mail]>
Subject: Re: Secdir last call review of draft-ietf-ipsecme-mib-iptfs-05

Hi Don,

Thank you for the quick response! Yes, that looks good to me.

Thanks,
Ivaylo

On Thu, Oct 13, 2022 at 2:13 PM Don Fedyk <[e-mail]> wrote:
>
> 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