Re: [secdir] [bmwg] Secdir telechat review of draft-ietf-bmwg-b2b-frame-03

"MORTON, ALFRED C (AL)" <acm@research.att.com> Tue, 15 December 2020 19:22 UTC

Return-Path: <acm@research.att.com>
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 B78453A16DF; Tue, 15 Dec 2020 11:22:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dK9gtResM9yu; Tue, 15 Dec 2020 11:22:34 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD7113A16DD; Tue, 15 Dec 2020 11:22:33 -0800 (PST)
Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0BFJFBVJ010024; Tue, 15 Dec 2020 14:22:33 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0048589.ppops.net-00191d01. with ESMTP id 35dcccbr8q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Dec 2020 14:22:33 -0500
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 0BFJMVuV112079; Tue, 15 Dec 2020 13:22:32 -0600
Received: from zlp30493.vci.att.com (zlp30493.vci.att.com [135.46.181.176]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 0BFJMQiO111886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Dec 2020 13:22:26 -0600
Received: from zlp30493.vci.att.com (zlp30493.vci.att.com [127.0.0.1]) by zlp30493.vci.att.com (Service) with ESMTP id C3AA1400A0A4; Tue, 15 Dec 2020 19:22:26 +0000 (GMT)
Received: from clph811.sldc.sbc.com (unknown [135.41.107.12]) by zlp30493.vci.att.com (Service) with ESMTP id 9E0CB40006A0; Tue, 15 Dec 2020 19:22:26 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 0BFJMQ7B099405; Tue, 15 Dec 2020 13:22:26 -0600
Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 0BFJMKMC098857; Tue, 15 Dec 2020 13:22:20 -0600
Received: from exchange.research.att.com (njmtcas1.research.att.com [135.207.255.86]) by mail-azure.research.att.com (Postfix) with ESMTP id CAF3810A18E3; Tue, 15 Dec 2020 14:22:19 -0500 (EST)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas1.research.att.com ([fe80::e881:676b:51b6:905d%12]) with mapi id 14.03.0487.000; Tue, 15 Dec 2020 14:22:21 -0500
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>, "secdir@ietf.org" <secdir@ietf.org>
CC: "last-call@ietf.org" <last-call@ietf.org>, "bmwg@ietf.org" <bmwg@ietf.org>, "draft-ietf-bmwg-b2b-frame.all@ietf.org" <draft-ietf-bmwg-b2b-frame.all@ietf.org>
Thread-Topic: [bmwg] Secdir telechat review of draft-ietf-bmwg-b2b-frame-03
Thread-Index: AQHW0tWfW/48KRvlBkmQMYKHh09ZYqn4I0XwgABl5oD///zl4A==
Date: Tue, 15 Dec 2020 19:22:19 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF014766F108@njmtexg5.research.att.com>
References: <160803178079.7403.9358014699248845740@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CF014766EE92@njmtexg5.research.att.com> <5C525F90-FAB1-46D9-A399-8AB493345A48@inria.fr>
In-Reply-To: <5C525F90-FAB1-46D9-A399-8AB493345A48@inria.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [24.148.42.167]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-15_12:2020-12-15, 2020-12-15 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 clxscore=1015 priorityscore=1501 bulkscore=0 mlxlogscore=999 spamscore=0 impostorscore=0 mlxscore=0 malwarescore=0 lowpriorityscore=0 adultscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012150127
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/OrNQb9YwLqES2hqZFjZS9GSnG0w>
Subject: Re: [secdir] [bmwg] Secdir telechat review of draft-ietf-bmwg-b2b-frame-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 15 Dec 2020 19:22:36 -0000

Hi Mališa,
please see below...

> -----Original Message-----
> From: Mališa Vučinić [mailto:malisa.vucinic@inria.fr]
> Sent: Tuesday, December 15, 2020 9:21 AM
> To: MORTON, ALFRED C (AL) <acm@research.att.com>om>; secdir@ietf.org
> Cc: last-call@ietf.org; bmwg@ietf.org; draft-ietf-bmwg-b2b-
> frame.all@ietf.org
> Subject: Re: [bmwg] Secdir telechat review of draft-ietf-bmwg-b2b-frame-03
> 
> Hi Al,
> 
> Thanks, that is clear. I think that discussing the assumption of honesty
> among the parties involved in benchmarking  would be a useful addition to
> the Security Considerations section in the draft.
[acm] 

I don't mind explaining the requirement using the term "honesty", but I can only imagine raised eyebrows and subsequent DISCUSS/comments if we try to assert a need for/assumption of honesty anywhere in the memo.

Do you have suggested wording?

Do others have opinions whether or not this is needed?

thanks,
Al

> 
> Mališa
> 
> On 15/12/2020 14:45, "MORTON, ALFRED C (AL)" <acm@research.att.com> wrote:
> 
>     Hi Mališa,
>     thanks for your review, please see below for one reply to your
> question (acm].
>     Al
> 
>     > -----Original Message-----
>     > From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Mališa
> Vucinic via
>     > Datatracker
>     > Sent: Tuesday, December 15, 2020 6:30 AM
>     > To: secdir@ietf.org
>     > Cc: last-call@ietf.org; bmwg@ietf.org; draft-ietf-bmwg-b2b-
>     > frame.all@ietf.org
>     > Subject: [bmwg] Secdir telechat review of draft-ietf-bmwg-b2b-frame-
> 03
>     >
>     > Reviewer: Mališa Vučinić
>     > Review result: Ready
>     >
>     > I 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
>     > authors, document editors, and WG chairs should treat these comments
> just
>     > like
>     > any other IETF Last Call comments.
>     >
>     > Thank you for this well-written document, it was a pleasure to read
> and I
>     > think
>     > it is ready to proceed. Since the document updates RFC2544
> benchmarking
>     > procedure for estimating the buffer time of a Device Under Test
> (DUT), it
>     > does
>     > not raise any security issues. Security Considerations section is
> quite
>     > clear
>     > and it stresses that these tests are performed in a lab environment.
>     >
>     > I do have a question regarding the last paragraph of the Security
>     > Considerations on special capabilities of DUTs for benchmarking
> purposes.
>     > Currently, the sentence reads: "Special capabilities SHOULD NOT
> exist in
>     > the
>     > DUT/SUT specifically for benchmarking purposes." Why is this a
> SHOULD NOT
>     > and
>     > not a MUST NOT? Could you give an example when such special
> capabilities
>     > in a
>     > DUT are appropriate?
>     [acm]
>     We can only make a strong recommendation in this area. As
> testers/benchmarkers are often independent from the DUT developers and
> conduct testing external to the DUT, we assume honesty among other parties
> but we cannot require it. If someone constructed a DUT that recognized
> test conditions and operated differently to perform better somehow, our
> tests would measure the intended "better" performance. It takes a
> special/additional test effort to prove that a DUT has "designed to the
> test" (consider Volkswagen and fuel efficiency testing [0]).
> 
>     We simply do not have any authority in this matter, but we can let all
> parties know that gaming the test can be discovered and reported (albeit
> with more testing that we do not describe).
> 
>     [0] https://urldefense.com/v3/__https://www.consumerreports.org/fuel-
> economy-efficiency/volkswagen-used-special-software-to-exaggerate-fuel-
> economy/__;!!BhdT!0KS_VCF5ZQfIGkVyPLoJXuAxdcoS3-
> xJTE0LoKZPWuSiHjQZM1u0H9M36YXByCk$
> 
>     >
>     >
>     >
>     > _______________________________________________
>     > bmwg mailing list
>     > bmwg@ietf.org
>     >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bmwg__;!
>     > !BhdT!1JFeLsENzMU-ew89jxmJKxfp4wj5Zo3AZ6V8iULU3hWAentH1dymqJmDOvw7$
> 
>