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

Ivaylo Petrov <ivaylo@ackl.io> Thu, 13 October 2022 19:55 UTC

Return-Path: <ivaylo@ackl.io>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6EEC157B33 for <secdir@ietfa.amsl.com>; Thu, 13 Oct 2022 12:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaAJd0i4s58O for <secdir@ietfa.amsl.com>; Thu, 13 Oct 2022 12:55:28 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F0BC15259F for <secdir@ietf.org>; Thu, 13 Oct 2022 12:55:27 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id i65so2309959ioa.0 for <secdir@ietf.org>; Thu, 13 Oct 2022 12:55:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=O1+oGeNsogQ8xX5mmU8s3xkpYveInlmpIEYF9HXbCOc=; b=QkmwcCzUriDVFIsZrZ8dvKFcoROCmqF5ncVLVMNldC+3mFL44Tkk8tIGO+JUAz/pan b1kyvO9N1qq9H+jdmi359X/yCXyJpwj+MQSsHLbu9lgSwsOxbaMvM1LVl/HQDsQVodqz JQ/yBmtCKtRI5MFCRCsmDYhnuHQ40x/TaqFkv6cC/yUfYrH5koxBVr3raXYdxNaPcXrO PqVRGowh8XUYg1jCvvZlRPPRX9ac56a9Kpebn4VhVA1NiiqZPCdWsNwTo6s/XD+t8zxC VbCAHyWkE88N8MeYfj7dpv8an8C0yFxy2Xm/Oz8SGUyPnkWEN7F178JON0kJGO/FJt6j XbLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=O1+oGeNsogQ8xX5mmU8s3xkpYveInlmpIEYF9HXbCOc=; b=lkzsZuo/kV/tLr7KYDeB5SnL97mZ1MHT1mUPQqvK33nnIpboz5llVqEedLzk2Luqr2 vJzYcP4Z4Na2JMrgwz7rC+cSo8DHKS6QQqiN7piR0Rnu04dwgua5OYROHNXZJiD1E4Rz lDnw1Zg0RcczZ154sblcuXHzsBZb1+WGilURMPzaouBATP5J+kdrWb1fXUjpMpxoskDN DcPR3MPv+8HGP1YML4TNy62vbh4IkyEY64jEs2BBvfZ1oles+FUULbIZcr+wIPpI4ULC yyyOsJG4446QsWfeumqf3RPaQsDtPNb4dzbvAMCfEAu/Qu/JK3V1tYaT8sCA2t1/7Te1 Xifg==
X-Gm-Message-State: ACrzQf2YlhnolVnu+3u8ClOYOenlf0epEXnIrafe5HbDXoXR6MjlsMGU DJnYSS4rOcxw0ChE6vI50+iN8qIjbUTR7rALXL3H1LOCsl9onw==
X-Google-Smtp-Source: AMsMyM4VmvTjfBX6jfoepAIRjlHS+DF4Qs3SzGNMbf08+BsXPTb9Uq9hWan4B4isY20zl4gfgQEgQeggPJDQaBbFqYs=
X-Received: by 2002:a02:9483:0:b0:363:6f7d:f817 with SMTP id x3-20020a029483000000b003636f7df817mr933785jah.274.1665690926742; Thu, 13 Oct 2022 12:55:26 -0700 (PDT)
MIME-Version: 1.0
References: <CAJFkdRy4rG3Xody0FSU_KXtN4+oi1yexQj54p=7CHP8VihnPNQ@mail.gmail.com> <PH7PR14MB5368E485C91AD3A5892F9734BB259@PH7PR14MB5368.namprd14.prod.outlook.com>
In-Reply-To: <PH7PR14MB5368E485C91AD3A5892F9734BB259@PH7PR14MB5368.namprd14.prod.outlook.com>
From: Ivaylo Petrov <ivaylo@ackl.io>
Date: Thu, 13 Oct 2022 21:55:00 +0200
Message-ID: <CAJFkdRzHhq30QGrmw3qd5R3Ugz2iUfTEdiKZwyAYf59D05e0iQ@mail.gmail.com>
To: Don Fedyk <dfedyk@labn.net>
Cc: "draft-ietf-ipsecme-mib-iptfs.all@ietf.org" <draft-ietf-ipsecme-mib-iptfs.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/3Fb0XljB2kznWFgQ-sTPkXjJDZk>
Subject: Re: [secdir] Secdir last call review of draft-ietf-ipsecme-mib-iptfs-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Oct 2022 19:55:30 -0000

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 <dfedyk@labn.net> 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 <ivaylo@ackl.io>
> Sent: Wednesday, October 12, 2022 4:34 PM
> To: draft-ietf-ipsecme-mib-iptfs.all@ietf.org; secdir@ietf.org; The IESG <iesg@ietf.org>
> 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