Re: [ippm] Secdir early review of draft-ietf-ippm-capacity-protocol-04
"MORTON JR., AL" <acmorton@att.com> Sun, 07 May 2023 22:55 UTC
Return-Path: <acmorton@att.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6A7C14CF15; Sun, 7 May 2023 15:55:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level:
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.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 2-_pEiyom7Dr; Sun, 7 May 2023 15:55:06 -0700 (PDT)
Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 2E7DBC14CF13; Sun, 7 May 2023 15:55:06 -0700 (PDT)
Received: from pps.filterd (m0288869.ppops.net [127.0.0.1]) by m0288869.ppops.net-00191d01. (8.17.1.19/8.17.1.19) with ESMTP id 347IwvBt007748; Sun, 7 May 2023 18:55:04 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0288869.ppops.net-00191d01. (PPS) with ESMTPS id 3qe3x6h53k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 07 May 2023 18:55:04 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 347Mt4c1032054; Sun, 7 May 2023 18:55:04 -0400
Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 347Mt1E4031998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 7 May 2023 18:55:01 -0400
Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 0F88E4005C27; Sun, 7 May 2023 22:55:01 +0000 (GMT)
Received: from GAALPA1MSGED2CA.ITServices.sbc.com (unknown [135.50.89.132]) by zlp30484.vci.att.com (Service) with ESMTP id C386E4000350; Sun, 7 May 2023 22:55:00 +0000 (GMT)
Received: from GAALPA1MSGEX1CE.ITServices.sbc.com (135.50.89.112) by GAALPA1MSGED2CA.ITServices.sbc.com (135.50.89.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Sun, 7 May 2023 18:55:00 -0400
Received: from GAALPA1MSGETA02.tmg.ad.att.com (144.160.249.124) by GAALPA1MSGEX1CE.ITServices.sbc.com (135.50.89.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23 via Frontend Transport; Sun, 7 May 2023 18:55:00 -0400
Received: from NAM02-BN1-obe.outbound.protection.outlook.com (104.47.51.41) by edgeal.exch.att.com (144.160.249.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.23; Sun, 7 May 2023 18:55:00 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YdWamPv7LXtDLFGA/iHlyQf8MPjTBbkHKzXN7dcsyzLIEKa4iblB3Q6sY07UthIQQqqAQ2EZ8lVtvK1kF8ZSetQOF3sGdzMmGPVTCL0UmpQrw0bUH/RUrdJ5eV0DvGGRisdIuLBSXaG/oCCtnl0fu4w+OcAZoWBMpIosV3MOVLLoFM9Re3QvJeBUBZYDBOR5XQMz30xq0uNoWfft2sHgWkt1Ubb6ouYPpmhwg3ZqbrKQ9+MVq0fKCQAss3YsU1KaDzhud+WooIPZZnHMZ6ZeRvfe46jwdj4i+O/0x/+IYDKeCLMcjMquN1Q/wlZZLQPBftolRMpk5/fimJKmB+dtVg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zFr4R1+0B75y83cXqtQbBLH/2DO6YZNj/yImTppHB+U=; b=ZbW/RUTV9RhLNaSYTkaleZVAM0cYdEG8jH4wV0mKRAB3Zwq87CPzNEOJqCe9qpvA1Jpe6qHloUkguiNyB8sR7nlpGp0X3/4i0UoMcuxRnj7HliEAUjeMWu2f4PPtWwNgQVD/0+1USPp8AAkqt1GXMJSZ7o0HuLkOEY8ZTiLJH7oqWdKeyT0iwR26/y+V0+6lfxw9rbaihNlqqOV4J8nyjDf3MhihfRcbfOmtRm+DEHT0PkZYT0Yhd0a/+k9zeQaJvaYv/aL991YZDoYjkV4czLrirsi5M3W2feEnZ84QJrZUTh0EBWyOHwtAPM/we0DLnY+BlBw0mD/H1G2ZapUG6g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zFr4R1+0B75y83cXqtQbBLH/2DO6YZNj/yImTppHB+U=; b=LeO+89l+AUvArtl99QFbx99SB5W0pAofruwAYLuVHa/YuhdNx5MprbMAlKCB8ouObRY/nQu3MFsNdB7kKOxi9DDoeMXA8RvaBJk9ciLWHRjolFBcdECp5nVwDQ/oEN23P+UgVRSS+WlLhhbTBO3IjQmJRdkz5T2FR7epOOf5Urc=
Received: from CH0PR02MB7980.namprd02.prod.outlook.com (2603:10b6:610:105::17) by CH0PR02MB8210.namprd02.prod.outlook.com (2603:10b6:610:f3::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6363.32; Sun, 7 May 2023 22:54:58 +0000
Received: from CH0PR02MB7980.namprd02.prod.outlook.com ([fe80::4ee4:9c4a:6c2a:e758]) by CH0PR02MB7980.namprd02.prod.outlook.com ([fe80::4ee4:9c4a:6c2a:e758%7]) with mapi id 15.20.6363.032; Sun, 7 May 2023 22:54:58 +0000
From: "MORTON JR., AL" <acmorton@att.com>
To: Brian Weis <bew.stds@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>
CC: "draft-ietf-ippm-capacity-protocol.all@ietf.org" <draft-ietf-ippm-capacity-protocol.all@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: [ippm] Secdir early review of draft-ietf-ippm-capacity-protocol-04
Thread-Index: AQHZTuzbYBLPZe9D0kiW5s+CN9dy268CrwaggDaADfCAFqDKcA==
Date: Sun, 07 May 2023 22:54:58 +0000
Message-ID: <CH0PR02MB798059496506CFADD6577240D3709@CH0PR02MB7980.namprd02.prod.outlook.com>
References: <167797065961.46817.5654760092907121117@ietfa.amsl.com> <CH0PR02MB79807F2F36C90E0C668CF04DD3839@CH0PR02MB7980.namprd02.prod.outlook.com> <CH0PR02MB79803DDAAF360B4E44E5E5F7D3669@CH0PR02MB7980.namprd02.prod.outlook.com>
In-Reply-To: <CH0PR02MB79803DDAAF360B4E44E5E5F7D3669@CH0PR02MB7980.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CH0PR02MB7980:EE_|CH0PR02MB8210:EE_
x-ms-office365-filtering-correlation-id: 791d998d-1b24-4cd8-8021-08db4f4e156a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: JSGki8cIQo4RuorUCu10vpQujE0Evhffp2VCschsF7bgL46uDm/7+JOWamb3rwTtX3HKcMxmAJTBDevOmNAwrn0erDtUUEPTycbr9WpvR4OJDX2dfvm+c6c5wwWJjVPh5vc09YrjAU/DJV648EAYdNgUP/2uQgJV8HJDwgYr5UjNDBb8FQC7OpQ3GxCUuovxOydwJHqcWf7l20UKkNB97DA2/PLyeDtzZ/oVMU2tpvE841CYr4/M3yQ5qh99fWzV7NnUiCJULYATtkr5RguOjjfuswLK9/jWmfuNd8OidfbCs9QYEdlMemWBCx0P5DE3QC4hL/+lxuLpHWN0qRNYf9KYvqh0sBGOVYz7767T4S04bRDMXDTxFW6+i+ox1MEYzX6oHdY3FIu2ZXjI0wnZ8rCZiwTipu0PQDmADlrfNGiJzxZG0I9yKI3iW78XDwDSXHAlI0KRHrIruTGGIe9c4YogqB72UiWSW/RB5wcZv4mdBE/6YibRS3qK+n8JXgT3vycfL8O9l9AnYaW7O6b4Yu3JtqLMFLnxfgX3Ez/fRPl+PXSVxH4ENJc06W7CQ0tLlLM9PAZj/5IIRYNq4grGnBPF9p3jXrBpqM556oSci6o=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH0PR02MB7980.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(396003)(346002)(376002)(366004)(136003)(39860400002)(451199021)(6506007)(9686003)(82202003)(53546011)(26005)(7696005)(966005)(83380400001)(55016003)(33656002)(122000001)(38100700002)(86362001)(38070700005)(82960400001)(186003)(5660300002)(64756008)(4326008)(66446008)(66556008)(66946007)(54906003)(66476007)(2906002)(478600001)(8676002)(8936002)(110136005)(76116006)(52536014)(41300700001)(71200400001)(316002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: dzJOAnaV4psu5+8hflzF5M/zhoTQIUgJcBWm6WTlsP/iIoOlCy39XLrIvK+oqc9Wdqt68MVsVXHpmHpVnvnlD5M0SeNwjRZTrozImCG4jgJNAof0QOPSsm40OeUwaf+hie0O8CCsfax77xDRWvs90dNFtxmU+csQXCKvlo2IA4Fsd4yU/cNPqzxZi/ptac28cP9vi5oVnt1EpewJpzUALh7d/nDE+A2ZTgjp0Y9Lsfsg/snfkaTjSsKj5uRjDo9xGi/AkgdcdJfZvy402h9uW25a9T+NjcNnQDE6KPzQzd/7Cq6snEj8KgzL35/Eyefk7F5JtBvrrTChZ2PPX45/dlkxNnR3KOX9S4LCYYi0po/4HFy0oPOBIr6PiLnG1oZWbsrzmOm3xCdHeE9zR2VU3GBGzr9zQ10/qRmg7mDrAKZv7iIJEY5lhCS0oy46phqtBl+fFiq4GnyActl/wA18TcNcOZhuwMjWm31fq3jE2ZD6AU+M0rvxOeFXuLFIBlPIxXvjBRhf/eHd1JAt6FQo9q+dopbbfzG+54Z7gqr8K4cnlqjzUDahF9Q2WZlM53A56SC5DRYbG9Man52Xr70bCxrkLhrJ2Xji8OLwk/p7iDNEAE47cam2FRq+HCpezbJOO/qGFv2AWbmXngnZ4tKjMOb+dH258cpzQezyUMy6svX63Akq2mgJ/y19LrGtLdSG7UqIn893z33dosoz2ujILGfouhZiSIuCYeAGSojhhChQCGtqrtBEbjo7Thb1dhtv4/Vzj2FBZpFtpk+DJiPchZ3ausQFyQ+opXbSs07W7wn/9huS605hsWF8i+StKUlUXCEhgEO07k/sSOHVtXKjjL6TpSa3iLwGJlZpSIe4aLe/ipoa3r3SDj91bDS6nQH4RrkKLUX+nilLSnsFO0l+ZhBYPI2JxTKTrO38pwmJ2e1pwIjvgtHR37RJd31W22RbkkLiEINnIzsJk0SixahbuOAqR5+29XRGFYbwn6ZcvxGhjWD/A9gTFuJaiQeXS9jFBgDBty7vt2rp8InyXg2Be9DO+fUEyccN9I6191cb3WpXY/XOVs4C+SzzJAZ9j+b/3/x1to9mu6myXVqQRmjRAW6hvkWbaYY4PnYdpPsWG2aLla3JBbo3HosGAGF6IYbXi6lorHV0/YGZY29FakwRo3u88CHPXSvQamsBgmD2taB5PsUxr8LDflEdpKyP8sqh82CaPD2s+SHJjipn6igUhb9oZPGH9Tdg2dfpzfxWnYMaAFYSieFKvhWGA/nd2L9rQIKuhzMn/Ah0+TGX0ki/yMsHalTUCqxY5VXYCKtJ6Peq+jYamTVeCp67mQhW4EKneoYW4cA8ivGxhzhOqcdtEM1BewRNUw/bQDK5R843EvyiH+DGLZYnRl7TGkSiQItr5cK+CVR6Lfhpombf6/cbiNBHGpg+riCohB4CfceL+Oej2yI1xs25/mfq2S60O0Hhhpcjf06Q758OpbnvQEz83QB8dZWBTBjcIF/HbD9DOul0eEqeIqXG0JyfUKNJY7HjZfb/NURgBS1Ig7pNey4xcADowItRZNFXveu5GiAhh+0=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH0PR02MB7980.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 791d998d-1b24-4cd8-8021-08db4f4e156a
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2023 22:54:58.8137 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: gTQTNdUE1ZPSdOig+Jv6tq8Y8EdLWrdpH6WffbifDHOE35swa+Q4xdqi7pQIQxrX
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR02MB8210
X-TM-SNTS-SMTP: 7B094AEA5A855DCB8805BE0B3242400F14D7A08155958E98C748F6D55C88A68D2
X-Proofpoint-ORIG-GUID: F1RI5Oi8FrFecPtb8kIWkydW0nVLJsy9
X-Proofpoint-GUID: F1RI5Oi8FrFecPtb8kIWkydW0nVLJsy9
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-05-07_09,2023-05-05_01,2023-02-09_01
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 impostorscore=0 phishscore=0 mlxlogscore=999 lowpriorityscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 adultscore=0 clxscore=1015 bulkscore=0 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2305070178
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/XViC8IhCHFcjFtO6P41J-cbcQc0>
Subject: Re: [ippm] Secdir early review of draft-ietf-ippm-capacity-protocol-04
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 May 2023 22:55:10 -0000
Hi Brian, reminder of our key question, below, Al > -----Original Message----- > From: MORTON JR., AL > Sent: Sunday, April 23, 2023 9:26 AM > To: Brian Weis <bew.stds@gmail.com>; secdir@ietf.org > Cc: draft-ietf-ippm-capacity-protocol.all@ietf.org; ippm@ietf.org > Subject: RE: [ippm] Secdir early review of draft-ietf-ippm-capacity-protocol- > 04 > > Hi Brian, > > We would like to receive your feedback on our proposal for a replacement > encryption algorithm: > > > Ok. We were attracted to the "authenticated encryption" aspect of GCM, but > we > > can get that with AES-CCM too. > > Does AES-CCM alleviate the issues and fit our plans to use long-lived keys, > etc.? > > With this feedback, we can proceed with updates to the draft. > thanks, > Al > > > -----Original Message----- > > From: MORTON JR., AL > > Sent: Sunday, March 19, 2023 5:08 PM > > To: Brian Weis <bew.stds@gmail.com>; secdir@ietf.org > > Cc: draft-ietf-ippm-capacity-protocol.all@ietf.org; ippm@ietf.org > > Subject: RE: [ippm] Secdir early review of draft-ietf-ippm-capacity- > protocol- > > 04 > > > > Hi Brian, > > > > Thanks for your reply on the second SEC-DIR early review! > > > > We have summarized the topics for reply, below. Your review is appended. > > > > Al and Len > > > > > > # Key comments and replies for discussion: > > > > > — The use of AES-GCM with a long-lived symmetric key (such as one > > > on an RFC 7210 key chain) is not safe. ... (suggests a CBC mode) ... > > and > > > — Unauthenticated encryption is generally seen as risky, so when... > > > > Ok. We were attracted to the "authenticated encryption" aspect of GCM, but > we > > can get that with AES-CCM too. The Initialization Vector (IV) will be > > generated by a pseudo-random generator with unique seed for each session, > and > > have sufficient size to avoid duplication over the life of a long-lived key. > > The IV can be communicated in the clear, so we will. > > > > > — Also, there are some additional parameters that need to determined > > > to guarantee interoperability. For example, which octets are > > > encrypted, if a partial block needs to be encrypted how is it padded > > > out before encryption to make a full block, and requirements on IV > > > generation (e.g., that is must be from a good quality random number > > > generator). > > > > We need to check if padding is needed for any of our PDUs, but the PDUs will > > be fixed size so it's a static fix. > > We'll specify the IV generation method. > > > > > > > > # Tension between Security and Measurement operation: > > > > > — Section 5.1.1 doesn’t say the network addresses and headers are > > > included in the digest. It’s generally good practice to include (them)... > > > > Our test scope includes ISP Subscribers, so NAPT transversal is critical and > > precludes including the addresses. > > > > > ... a valid message > > > (e.g., Setup Request) can be extracted and placed in a different > > > measurement flow that is not intended by the original sender. This is > > > a substitution attack. > > > > All of the IPPM test protocols are susceptible to the substitution attack, > and > > there is no thorough mitigation that we know-of (including time in the > digest > > is a partial mitigation). > > > > Packet De-duplication, in DTLS and IPsec: > > > This is generally seen as a feature for network > > > encryption methods. > > Right, but measurement systems expect to observe packet duplication when it > > occurs. A trade-off is required, and the primary goal is measurement. > > > > > > # Edits and Nits: > > We will take care of other requests for clarifications requested > > - digest coverage > > - MBZ definition > > - “Support for client-server authentication ….”. > > - four Security modes, but encrypted tunnel makes five - becomes a paragraph > > - mismatch > > > > > -----Original Message----- > > > From: ippm <ippm-bounces@ietf.org> On Behalf Of Brian Weis via Datatracker > > > Sent: Saturday, March 4, 2023 5:58 PM > > > To: secdir@ietf.org > > > Cc: draft-ietf-ippm-capacity-protocol.all@ietf.org; ippm@ietf.org > > > Subject: [ippm] Secdir early review of draft-ietf-ippm-capacity-protocol- > 04 > > > > > > Reviewer: Brian Weis > > > Review result: Has Issues > > > > > > 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. > > > > > > General comments > > > > > > (1) The guidance of what bytes are included in the SHA-256 calculation > > > and result placed in the authDigest field might need some enhancement. > > > > > > — Some places say that the authDigest field is zeroed (e.g., Section > > > 4.2.2 ) and some says “The SHA-256 calculation SHALL cover all the > > > preceding fields.”, which seems to omit the auhDigest field. I guess > > > these aren't mutually exclusive statements, but it would be cleaner > > > to have all of the description in one place so it is clear. > > > > > > — Section 5.1.1 doesn’t say the network addresses and headers are > > > included in the digest. It’s generally good practice to include > > > more context into the digest calculation so that a valid message > > > (e.g., Setup Request) can’t be extracted and placed in a different > > > measurement flow that is not intended by the original sender. This is > > > a substitution attack. > > > > > > — If network addresses and headers aren’t included in the digest, > > > then it will be important to describe why the substitution attack > > > isn’t a threat. I understand that if NAT on the client that including > > > it's network address is not possible, but there's still an issue. > > > > > > — Note that the inclusion of authUnixTime with the receiver > > > checking “acceptable immediacy” is only a partial mitigation for a > > > substitution attack, since the receiver’s notion of “acceptable > > > immediacy” is apparently quite long from an attacker's perspective > > > “(+/- 2.5 minutes)” and any other message including this PDU sent > > > fron an attacker (e.g., with different network headers) during this > > > period will be acceptable to the receiver. Reducing the window > > > size won’t completely mitigate this attack either. > > > > > > (2) There doesn’t seem to be a definition for the MBZ octets and > > > remainder bits, or a description of their purpose. (I’m guessing > > > it’s “must be zero” but even that should be defined for the reader.) > > > > > > Specific comments > > > > > > Section 4.2.4. > > > > > > — The use of AES-GCM with a long-lived symmetric key (such as one > > > on an RFC 7210 key chain) is not safe. The IV used by GCM is not a > > > random IV such as used by some other modes of which you might be > > > aware (e.g., CBC), but rather it is a counter that must NEVER > > > repeat with that key. Ensuring no repeats is not operationally > > > feasible for a key kept on a key chain. I.e., The counter must keep > > > incrementing between packets, reliably stored over a reboot so that > > > it isn't used again, and when the counter reaches the maximum value > > > the key is not longer usable. I would recommend specifying CBC mode > > > and a randomly chosen IV. > > > > > > — Also, there are some additional parameters that need to determined > > > to guarantee interoperability. For example, which octets are > > > encrypted, if a partial block needs to be encrypted how is it padded > > > out before encryption to make a full block, and requirements on IV > > > generation (e.g., that is must be from a good quality random number > > > generator). > > > > > > — Unauthenticated encryption is generally seen as risky, so when > > > encryption is included the the authDigest should also be used as > > > it is in the other modes. Figure 2 should have both authDigest AND > > > IV fields. > > > > > > Section 4.2.5. This section mentions that DTLS is not useful because > > > “The replay protection would remove duplicated packets and prevent > > > transparent measurement of this impairment.”. IPsec will also > > > transparently remove duplicate packets, and since TLS is based on > > > TCP, which has duplicate segment protection, I would expect that > > > the application would also never see duplicate measurement PDUs > > > from TLS either. This is generally seen as a feature for network > > > encryption methods. > > > > > > Section 10. “Client-server authentication and integrity protection > > > for feedback messages conveying measurements is REQUIRED.” Since > > > one of the methods allows “unauthenticated mode for all messages”, > > > I think this is meant to start with “Support for client-server > > > authentication ….”. That is, the REQUIRED language means > > > it must be implemented, but not used. > > > > > > Nits > > > > > > — Section 4.2 says “There are four security modes of operation”, > > > which is also stated elsewhere, but there seems to actually be five. > > > I understand that the fifth one is actually an external security > > > mode that can be combined with one of the four modes (e.g., > > > “unauthenticated mode for all messages”) in the PDU. It might be > > > clearer to take the fifth one out of the list and just make it a > > > paragraph. > > > > > > — Section 4.2.1 s/miss-match/mismatch/ > > > > > > > > > _______________________________________________ > > > ippm mailing list > > > ippm@ietf.org > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd > > > T!lLiKK4svDahYLFenpa6d7FQa-qA1f4ltd7wjaRx1S- > > YZCr9cEveGl5UOAc3B7KuEPYEWE3uif4c$
- [ippm] Secdir early review of draft-ietf-ippm-cap… Brian Weis via Datatracker
- Re: [ippm] Secdir early review of draft-ietf-ippm… MORTON JR., AL
- Re: [ippm] Secdir early review of draft-ietf-ippm… MORTON JR., AL
- Re: [ippm] Secdir early review of draft-ietf-ippm… MORTON JR., AL
- Re: [ippm] Secdir early review of draft-ietf-ippm… MORTON JR., AL
- Re: [ippm] Secdir early review of draft-ietf-ippm… Brian Weis
- Re: [ippm] Secdir early review of draft-ietf-ippm… MORTON JR., AL