Re: [dtn] AD review of draft-ietf-dtn-bpsec-10
Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 19 September 2019 10:59 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BCA1200E9; Thu, 19 Sep 2019 03:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 gs6Jv4xr8wGN; Thu, 19 Sep 2019 03:59:39 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60087.outbound.protection.outlook.com [40.107.6.87]) (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 92932120033; Thu, 19 Sep 2019 03:59:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VKC132ZbbgAejSDtghXMK8ttyUcAWH0heyV8dfSKlpSaad7znNJguKK4D3dR+NbC5EfqFkHdzXI2yWnyBtdbEMUWg5SpGbVQrmVf7olaIxbLTzkr14BxVsuvn7aih6WRM/5FMHNtlpIqDUht47mUyAx1G11717WiaqCe1n6+ZnHg2/opONZuyvGKsXJJ7U2j7mq5KQhhu9TPihbXIzABlYtmACbhnmEG1MQBZDGblTx+h1MxZ6Zm0W8hJ2mFdAPg+ykxBui1F47Z1Pog54qMa63NwjHZ9olnoNWCJ3sp67ACky/AZS23rXHOoX4gZEqHR/3arYW0puhogvYAzT+mcw==
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-SenderADCheck; bh=GDKaBguYCAChEloFoLM2vgMFg2P2ldISkuPnvxVq0K4=; b=nebY7Odk8o6CHSuZ+QVZsgHmwFWlb1TGDCjhgebwkS26n51HSRGSlf9l8N+3nz2RE23oZzbxln6SyBq/5KUeVuC8INB3L51jV9SDW8PEDUjs/mtCLsuHhEw5lLMeZi8/uZWFLIE9jl+u7YFowceoCOFNqtQSNEKtqGengITuciWzyFdHfIm0hE4g+UOgsPcSmEpMleWsVw0G5y+bWoV3mFcuzrXbxaqAr7f8PvNZdGN58Cx0KcEIWAtFe1ypE7NA6ow3JyTq74fV/255nZpnvfgkyOrBxXYw7otFL+RDBxsEPkccEXGxmW3OS0u6mjwLdxkBNYeTbj7dUFn514IJhg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GDKaBguYCAChEloFoLM2vgMFg2P2ldISkuPnvxVq0K4=; b=Yuv/HZKjIev48yMc4z7NwQbyFYCbU+O6XP4EHKDRF35ilZx6tlgNf/yxnCSdF/nG4TmhqMfpSt+pMHvGohCiElUIqTuBIJGatl3Bxbax+VlxIURfU/eOvBGbkiHrHAidC/+g8C5IUcQ0joy41GmL0JhHK3pZCTj+egeEESMo5Dg=
Received: from DB7PR07MB5736.eurprd07.prod.outlook.com (20.177.194.155) by DB7PR07MB4731.eurprd07.prod.outlook.com (52.135.139.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.15; Thu, 19 Sep 2019 10:59:36 +0000
Received: from DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::e48c:a942:9682:2ce4]) by DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::e48c:a942:9682:2ce4%7]) with mapi id 15.20.2284.009; Thu, 19 Sep 2019 10:59:36 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "draft-ietf-dtn-bpsec@ietf.org" <draft-ietf-dtn-bpsec@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>, "magnus.westerlund=40ericsson.com@dmarc.ietf.org" <magnus.westerlund=40ericsson.com@dmarc.ietf.org>
Thread-Topic: [dtn] AD review of draft-ietf-dtn-bpsec-10
Thread-Index: AdVCaDVgtsriZb2MRq2bQxmFSoSCwArL6w+AAFBcP4A=
Date: Thu, 19 Sep 2019 10:59:36 +0000
Message-ID: <c39cbe2d2782ea8f7ae4e4a8617abc1499ffebe1.camel@ericsson.com>
References: <HE1PR0701MB2522907507ED316584289CDF95C60@HE1PR0701MB2522.eurprd07.prod.outlook.com> <4f41e7e9c66f4f5cc07f2e79b1670792c0dda4f1.camel@ericsson.com>
In-Reply-To: <4f41e7e9c66f4f5cc07f2e79b1670792c0dda4f1.camel@ericsson.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com;
x-originating-ip: [192.176.1.80]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 03e21ba3-7e7f-4cd0-1dbf-08d73cf075c3
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:DB7PR07MB4731;
x-ms-traffictypediagnostic: DB7PR07MB4731:
x-microsoft-antispam-prvs: <DB7PR07MB47317092B5F88E756894C93395890@DB7PR07MB4731.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 016572D96D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(136003)(346002)(39860400002)(396003)(189003)(199004)(15404003)(8936002)(14444005)(3846002)(5660300002)(6116002)(256004)(66446008)(64756008)(66556008)(446003)(91956017)(66476007)(11346002)(86362001)(66616009)(186003)(476003)(76116006)(66946007)(486006)(44832011)(76176011)(478600001)(26005)(36756003)(25786009)(8676002)(6506007)(81156014)(102836004)(81166006)(6512007)(305945005)(6246003)(2906002)(7736002)(316002)(966005)(110136005)(71200400001)(71190400001)(14454004)(66066001)(2501003)(99936001)(6306002)(229853002)(6436002)(6486002)(118296001)(2616005)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4731; H:DB7PR07MB5736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: iaIpyV5TafDg0porTTq4Zp2zkE3+mM2aYXkNrtrooriJsBeHB/rbNWIay0kT6nQarJ0aS2lFBauGCi3x8vpV3roIPy147nGV6+/O4IMUebv+IS0qvvW/RlxuBgeJMJpTZrLztah3RjiWkkrUERdVU+yL85ukitp4p44iNRUNw/7rGCnSvLwE2yfUg51ZkD8w2I6WSaN1LGp6wBhaGGbXMO/TZih42isPICPvu8APGDO30ND6Q5lgoO/eEZT3t7ibJ5wePQa0IxuOsQjwdgYDMnkrKtYvrZzIrTOvVC3QieSGRqkaRIePytiFD0tlKa4Rp7//v9BZQnCfiNX8tTEoJU/e4LrIk4b22EDiPSwOiaY0yVwbotYS11PsNxBXefLetgBuOZMtH+F8NoiQQiYUyeCD6F91WswLglzVI3SWC0s=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-ayzBHueqyMUsJIAZoW9Q"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 03e21ba3-7e7f-4cd0-1dbf-08d73cf075c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2019 10:59:36.1223 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bR42wOsRh8c1q7Sv0tntiYUtc0zqum4PFDpCmVu8yChDjf5iUiffCYbfgUU2Bwqd2VTYujzCRT1qLD2uG/PZ2lfy/TGbj0Eb+ZSk+yTLyjA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4731
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/OiOqbTjQcnPZGz-J3ez9O9TX7vY>
Subject: Re: [dtn] AD review of draft-ietf-dtn-bpsec-10
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Sep 2019 10:59:43 -0000
Hi, With the new draft version, this document is ready for IETF last call. I going to go ahead and start the last call. I expect BPbis and tcpcl to follow soon. I will not bring BPsec to the IESG before BPbis, but most likely together. Cheers Magnus On Tue, 2019-09-17 at 20:38 +0000, Magnus Westerlund wrote: > Hi, > > So finnaly following up on the new revision. See inline for my > comments > and remarks. I think there are potentially two minor text changes and > one question to answer. > > > On Wed, 2019-07-24 at 23:01 +0000, Magnus Westerlund wrote: > > Hi, > > > > I have now done my AD review of draft-ietf-dtn-bpsec-10. I want to > > point out that I am going to ask about the reasons behind certain > > choices in the document. Note the intention here is not to change > > what your specified but to understand the choices made. > > > > 1. Section 1.2: > > It is expected that separate documents will be standardized to > > define > > security contexts and cipher suites compatible with BPSec, to > > include > > those that should be used to assess interoperability and those > > fit > > for operational use in various network scenarios. > > > > As the WG actually have one example specification for a security > > context and cipher suits, it would be good to reference this so > > that > > people realize that it exist and can be looked at in parallel. > > Fixed > > > > > 2. Section 1.4: I am missing a term for the receiver / target > > either > > if that is any holder of the security context or an intended bundle > > receiver, in other words the peer to security source. > > > > Fixed. > > > 3. Section 3.1: > > > > The BIB is used to ensure the integrity of its plain-text > > security > > target(s). The integrity information in the BIB MAY be > > verified > > by any node along the bundle path from the BIB security > > source > > to > > the bundle destination. Security-aware waypoints add or > > remove > > BIBs from bundles in accordance with their security policy. > > BIBs > > are never used to sign the cipher- text provided by a BCB. > > > > This is only part of a conflict between the order between BIB and > > BCB > > processing and the possibility for a node along the Bundle path to > > verify the integrity of parts of the bundle. So my thoughts here is > > that bundle sender has two security contexts. One with the receiver > > that it will use to secure the BUNDLE Payload and other Blocks that > > are of end-to-end nature and not needed on path. Then I will have > > another security context that a set of the bundle forwarding nodes > > share so that they can verify the bundle being sent. However, to my > > understanding this is not possible as any BIB using the second > > context can’t use encrypted payload block as its input. > > > > So although the documents talks about this, it appears to have > > limited utility. Any comments about this limited utility? > > So this was resolved in discussion that the solution to this is the > Bundle-in-bundle encapsulation. > > > > > 4. Section 3.2: > > Security operations in a bundle MUST be unique; the same security > > service MUST NOT be applied to a security target more than once > > in > > a > > bundle. > > > > This uniqueness requirement, isn’t this missing a dependency on > > security context? To me there appear that being able to use more > > than > > one security context has some benefits, or is it making things to > > complex, or are there other reasons? > > Same as 3. > > > > > 5. Section 3.6: > > Security Context Flags: > > > > What is the meaning of the Reserved bits? What should the sender > > and > > receiver do with these bits. Can they be assigned in the future? > > > > I think the changes made things clearer, but didn't fully resolve the > question I have about if it intended that future extension may > reserve > any of the other bits? Which would imply a ignore values of for > implementation undefined bits. > > If that is the intention please be explicit about that. > > > > > 6. Section 3.8: > > The Security Context Id MUST utilize a confidentiality cipher > > that > > provides authenticated encryption with associated data > > (AEAD). > > > > Why is AEAD a requirement? If the requirement is that no > > confidentiality without integrity, then that can be stated in an > > other way than requiring AEAD. > > Discussed, no change needed. > > > > > 7. Section 3: > > > > Looking at the BIB and how it is structured and how the signature > > is > > created and stored with one signature per block implies that any on > > path attacker can remove individual blocks without it being > > noticed. > > So aren’t there a missing possibility to create a BIB that actually > > ensures that if it validates a set of blocks was correctly > > provided? > > I know that with the current mechanisms such a BIB could be > > stripped. > > However, such a block could easily be required in a security policy > > for a particular deployment. Was such aspects considered? > > This was discussed and no furhter changes required. > > > > > 8. Section 3.9: > > o When adding a BCB to a bundle, if some (or all) of the > > security > > targets of the BCB match some (but not all) of the security > > targets of a BIB, then a new BIB MUST be created and all > > entries > > relating to those BCB security targets MUST be moved from the > > original BIB to the newly created BIB. > > > > This comment is linked to the pervious one. When reading this, I > > had > > a hard time to understand what “moved” in the above text actually > > meant. Finally I realized that you could actually move a signature > > from one BIB to another. I think this could be made a bit clearer. > > Fixed. > > > > > 9. Section 3.10: > > Individual BPSec security context identifiers SHOULD use > > existing > > registries of identifiers and CBOR encodings, such as those > > defined > > in [RFC8152], whenever possible. Contexts SHOULD define their > > own > > identifiers and CBOR encodings when necessary. > > > > I find the above paragraph unclear. I think one part is what > > “security context identifiers”. > > Fixed. > > > > > 10. Section 5.1.1: > > If the receiving node is > > not the destination of the bundle, the node MUST decrypt the BCB > > if > > directed to do so as a matter of security policy. > > > > I think this is an example of the unclarity of who is to process a > > particular security block, because I don’t understand how the node > > will be able to do this. > > Addressed. > > > > > Section 11: > > > > A registry of security context identifiers will be required. > > > > If you need a registry for security context identifiers then you > > need > > to create it and defines its rules. > > The new registry looks reasonable. The comment I have is that as > draft- > ietf-dtn-bpsec-interop-sc is a example / template for future security > context identifiers, then it is actually good to perform the > registration with IANA in that document also, so that part of the > process is not forgotten. > > Cheers > > Magnus Westerlund > > > ------------------------------------------------------------------- > --- > Network Architecture & Protocols, Ericsson Research > ------------------------------------------------------------------- > --- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ------------------------------------------------------------------- > --- > > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn -- Cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [dtn] AD review of draft-ietf-dtn-bpsec-10 Magnus Westerlund
- Re: [dtn] AD review of draft-ietf-dtn-bpsec-10 Magnus Westerlund
- Re: [dtn] AD review of draft-ietf-dtn-bpsec-10 Magnus Westerlund