Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt
Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 12 September 2019 11: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 6443C12080E; Thu, 12 Sep 2019 04:59:38 -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 TTk9QVgv4Okn; Thu, 12 Sep 2019 04:59:34 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140083.outbound.protection.outlook.com [40.107.14.83]) (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 566E3120091; Thu, 12 Sep 2019 04:59:33 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=co7X9UH6Z1CWlqEjbHAZ0p/mx/VLhCZUYal9lU4v4yCXhvureMoYUOIr3x2sK58RLfemxqTSUAVoAosyp7HLTnQrDZnbuuaU2058gIaDqx1TByszFZ9eahiwYcprraGfOBKCRS8t+DqYCS6egLFWqYJ8mxo+uaNX7wiTMeZPLCnwehkTjBPkVC8uecxWyGxKmGfpOZYLOyo9ETO3E/ysQCgfe/BRijoxHQk4a7rhIh3EJr1BBppTFus9K90TeN9QsOzL5xECH/vBji208kYmESuRWnnWVFLxJ8e9Wh+a/TJGiQ59C81gocctey7Plnr0q7LdPoAt2Yq0IuH/jHRejA==
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=n+27a0+dbPTsYCg8aflOIV/vQwhFv/e0pYrAu3kt8tI=; b=BLqMXMM4HO/mviQ+WUCILKgF/lUfqpgbfvTV0n0tCFaMY/PDNIXBg573M1azWlQHk0Ge378YwrhTR4mxtMj0cyRNTU8T4O7QrTGgitTEFM99tlGVjABBCgilx3/9E7xh4123js9Mi5Qy+LS/FEjaHIyubUyka+FQKwD5MWzOhacPrS3cdjxydmCvxfaENLtzgQFJgQibMt9uiSV0s2Ql6QoTjtJYrnGilzEhJwFmO/2Rdg9TtFs6WY1uRhrwI0KDAWkjruiMTO6jDjNtQDPYzrAA2v7wsWCAI9SSvpktjBf1YIKxv8N5uR3MJrWdQAdn4tXDdbKLc5TKpMPZH90LzA==
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=n+27a0+dbPTsYCg8aflOIV/vQwhFv/e0pYrAu3kt8tI=; b=S1Rl4sEgRSJxYbF+O5t7lmuvBrTVN7u0/sVI02tkfbHUbfkMwHk2oMUplrOgmW1yyeYB2L3xNozfja9q5s1lbsOi6kzEgGFYX+0tHtXCJrsV0mFtNxDLOX7+o0vzENbpZkE9ATGFytzJuY7IPc0FOFPcf91e0/14aBc5c3zx/VQ=
Received: from DB7PR07MB5736.eurprd07.prod.outlook.com (20.177.194.155) by DB7PR07MB5130.eurprd07.prod.outlook.com (20.178.40.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.5; Thu, 12 Sep 2019 11:59:31 +0000
Received: from DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::a935:4edd:29a2:9772]) by DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::a935:4edd:29a2:9772%6]) with mapi id 15.20.2263.015; Thu, 12 Sep 2019 11:59:31 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "draft-ietf-dtn-bpbis@ietf.org" <draft-ietf-dtn-bpbis@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt
Thread-Index: AQHVSv85SA+HnuXANkKMNtoZWII0tKcoLRIA
Date: Thu, 12 Sep 2019 11:59:31 +0000
Message-ID: <0d943b23f2d6d3bc929864ea59350958b296d481.camel@ericsson.com>
References: <156494879521.26442.11081790719587421210@ietfa.amsl.com>
In-Reply-To: <156494879521.26442.11081790719587421210@ietfa.amsl.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.87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 35af2438-1afe-4a99-6ac7-08d73778abcd
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:DB7PR07MB5130;
x-ms-traffictypediagnostic: DB7PR07MB5130:
x-microsoft-antispam-prvs: <DB7PR07MB5130C569EFF857AB27710BE795B00@DB7PR07MB5130.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01583E185C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(136003)(346002)(396003)(376002)(39860400002)(366004)(199004)(189003)(450100002)(99286004)(2616005)(86362001)(3846002)(6116002)(14444005)(14454004)(66616009)(66556008)(64756008)(66446008)(66476007)(11346002)(446003)(71200400001)(71190400001)(99936001)(66066001)(2906002)(478600001)(36756003)(102836004)(5660300002)(76176011)(316002)(186003)(26005)(110136005)(6506007)(118296001)(8936002)(66946007)(2501003)(256004)(81156014)(81166006)(53936002)(25786009)(486006)(6246003)(476003)(229853002)(6486002)(91956017)(76116006)(7736002)(44832011)(8676002)(305945005)(6436002)(30864003)(6512007)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5130; H:DB7PR07MB5736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: nl42U2RB3Gm1Rfr/EJmC7LbTpFxRTNmZC0YPnSh8PXZiCouS1Dw/z5GE9KB0m2Sdh8SLvJJbXNUkGPVn/SfNReoB2zDHgpbxh2d4Tr8uoqxZ2Yee77jM74kWVnPkC0/W/jhgzw+Sm5PROldRRvuhIw/BhHgvphNYUSP/zOdgvYFtY/+M9Y2FxbzcYvzpPlIGP8b4TvH4e5OIz5M8o3NtnQsSGShlCFNXKESPwJAwvN0ubGhOgNJCEOUMXcNCGF1xH1nY/g+dPZoYMUR/TkdKgM89qLoyKZMvyL+Y51H36UYqXYPGKb4tzEHO5gMu1v9uLQ5KvQbVUYx1E9O+xH1MXXqKYFNKPvD9z+LUW4F0agzqtyx52M83z+BJgFK7QVrYtws8+paLcsmsS6XAEo3OqyxuC/qoe814vOzYx0yTS5w=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-E4Vsb5IdX3TVZ2vJnVtA"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 35af2438-1afe-4a99-6ac7-08d73778abcd
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2019 11:59:31.2844 (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: vX5/EeqoBgEy1BucsKiOCP3CdWT1h8TtVTIrk/aoyhRtuwkhmIhXD4dyp8BPfzkLMiLZR/+lZ844zIBNjH0811qEoB4u/kK28amYF2L4nsE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5130
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/9cZ7PooumYdg3mSBUShC17hwYzg>
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt
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, 12 Sep 2019 11:59:38 -0000
Hi, I have reviewed how this document addresses my AD comments. > 1. Section 4.1.5.1 and 10 : > > As this document uses the "dtn" URI scheme and the "dtn" scheme was > only provisional registered by RFC 5050 I think this document should > formally register the DTN URI scheme and thus a new subsection in > Section 10 is needed. I note the new section 10.7 registering dtn. However, shouldn't the Status be permanent rather than provisional? Secondly, is there any need to discuss how DTN scheme deals with BP versions? > > Also, maybe similar effort to move "ipn" to permeant is needed? And to my understanding IPN will stay with RFC 6260 and that is fine by me. > > 2. Section 4.1.6: > > I think the format and definition of this field are insufficient. It > is lacking a reference or a normative description of what "Unix Epoch > Time" in an unsigned int format actually is. Is the intention here to > simply measure the number of seconds since the start of year 2000? > Which Unix epoch time is not due to leap seconds. And I become > uncertain as UTC time scale is something else than Unix Epoch time at > least when it comes to leap seconds handling. Due to that Unix Time > have discontinuities in the time scale at leap seconds I would > recommend strongly against using it. Select UTC or TAI depending on > where you want the leap second handling pain to exist. > > Also, you specified only CBOR unsinged integer which is a > representation that can use 64-bit and thus not have the issues with > 32-bit signed integer seconds epochs that regular unix time has, but > that should probably be made explicit that it is expected to handle > that. Even if the first wrap of this unsigned 32-bit format will not > occur until 2136. > > And please provide necessary normative references, not informative > ones. THe new text I think is good. My only comments are that I the I was unable to google for the specific [EPOCH] reference. > > > 3. Section 4.2.2: > > The Lifetime field appears problematic if the creating node doesn't > have a reliable clock and uses timestamp 0 for all bundles. I think > that special case needs to be discussed. Which it is later done, but > there is missing reference to that. This is also resolved. > > 4. Section 4.2.2: Report-to EID > > Is this field set by bundle creator and never changed? It is not > clear and appear to have implications on how this field should be > treated. Primarily considering integrity options over these fields. Resolved. > > 5. Section 4.3.3. > Maximum Hop count upper limit? Can I insert a max UiNT64 here and > expect that to be acceptable? Resolved. > > 6. Section 5.1: > Under some circumstances, the requesting of status reports could > result in an unacceptable increase in the bundle traffic in the > network. For this reason, the generation of status reports MUST be > disabled by default and enabled only when the risk of excessive > network traffic is deemed acceptable. > > I find the above paragraph rather unclear. First of all what are the > circumstances. Secondly, shouldn't the type of status report > requested be discussed. What I can see the different types results in > at most 1, N-1 or N times the number of sent bundles with the status > report set depending on type, where N is the number of nodes on the > path including receiving endpoint. > > So are there any recommendations to when it might be acceptable to > request status delivery. To me it appears the trace route like > options, like forwarding status report should only be used on a small > number of bundles sent for debuging or monitoring purposes. > > Use of the bundle deletion status report appear to have other > motivations for its use. I assume that this is fine for cases when it > occurs for a small fraction of the bundles for some reasons, but when > you have real failures on next hop links it appears that this may > cause high volumes of deletion. Thus a rate limitation makes sense. I > assume that this is one of the not specified reasons the below > paragraph indicates: > > When the generation of status reports is enabled, the decision on > whether or not to generate a requested status report is left to > the > discretion of the bundle protocol agent. Mechanisms that could > assist in making such decisions, such as pre-placed agreements > authorizing the generation of status reports under specified > circumstances, are beyond the scope of this specification. I think the added text is good enough. I appreciate the difficulty in how to balance this. > > 7. Section 5.3: > > Step 1: If the bundle's destination endpoint is an endpoint of > which > the node is a member, the bundle delivery procedure defined in > Section 5.7 MUST be followed and for the purposes of all > subsequent > processing of this bundle at this node the node's membership in > the > bundle's destination endpoint SHALL be disavowed. > > I don't understand why and what implications the disavowing has for a > local bundle being dispatched from a member node part of the > destination. The new text clarifies thing, issue resolved. > > 8. Section 5.4 > > Step 3: If forwarding of the bundle is determined to be > contraindicated for any of the reasons listed in Figure 4, then > the > Forwarding Contraindicated procedure defined in Section 5.4.1 MUST > be followed; the remaining steps of Section 5 are skipped at this > time. > > Should that last Section 5 be Section 5.4? Resovled. > > 9. Section 6.1.1 > What does Destination endpoint ID unintelligible actually mean? > Same with Block unintelligible. > > Are these the combination for corrupted blocks or EIDs? Are there a > point of separating out the case where the CRC indicate a corruption? Resolved. > > 10. Section 7.2 > > So the service description appears very high level. How is the actual > interface working when it comes to dealing with that there is either > possibility to send, as well as rate control in the API. When can > more data be accepted and when is the convergence layer not ready. > Also don't the Bundle Agent need a signal when this side thinks it > has delivered as a signal of when the forwarding has completed? > > I was expecting this section to actually be explicit about what > functionalities the Bundle Agent really need from the convergence > layer. Resolved. > > 11. Section 9 > > I think this section needs to be more explicit about mandating > implementation support for BPSEC. The IETF do not publish a protocol > today that doesn't have a mandatory to implement security solutions > for the protocol's major properties. In this case communication > security, i.e. confidentiality, integrity and authentication of the > data communicated is very relevant. I have not yet read BPSEC so I > may have additional concerns about that issues are not handled in the > combined protocol. I hope the BPSEC has some discussion of the > privacy properties of the protocol. Discussed separately. What I understand the consensus appears to be a SHOULD level on support of BPSec. > > 12. Section 9: > Additionally, convergence-layer protocols that ensure authenticity > of communication between adjacent nodes in BP network topology > SHOULD be used where available, to minimize the ability of > unauthenticated nodes to introduce inauthentic traffic into the > network. > > In this context wouldn't it be reasonable to also recommend using > encryption on the convergence layer to avoid eavsedropping on the > part that is in clear and prevent traffic analysis by third parties? > Addressed. > 13. Section 9. > > Note that the generation of bundle status reports is disabled by > default because malicious initiation of bundle status reporting > could result in the transmission of extremely large numbers of > bundle, effecting a denial of service attack. > > I think there is a clear lack of mitigations proposed for this issue. > As I mentioned in Issue 6 I think one both needs to consider amount > of generated traffic versus utility for the sender. Also I will have > to read BPSec to understand what integrity and source authentication > there is of the request for status reports. Next is the issue of rate > limiting and prioritization of status reports versus other bundles. > Also due to the multi-hop store and forward nature of this protocol > the actual bottle neck may only occur several hops towards the > receiver. What can be said about dropping status reports versus other > bundles when there is a resource contention, either in storage or in > convergence layers capability of forwarding messages within time. I don't see this issue having been addressed, nor discussed on the mailing list. I don't remember what was said if anything about this at the DTN WG meeting at IETF 105. From my perspective I think my biggest question mark about this, is if there are things that can be done, and if they should or should not be done in a situation where a relaying node thinks there is an issue with the amount of status reports? > > 14. Section 6 > I fail to see any discussion of how the sender of a status report > should set the lifetime and max hop. Can it actually take that > information from the Bundle it is reporting on? If I remember correclty the discussion was that this is implementation and usage specific and there is lack of experience to provide explicit recommendations. > > 15. Section 10. > > I think this section needs to be clearer. Several improvements that > can be made. > > · I recommend individual sub-sections per registry operation > · Can you be clearer in references to point to specific > sections of definitions that makes it simpler to find the relevant > from the IANA registry? Addressed. > > More specific parts. > > This document defines the following additional Bundle Protocol > block > types, for which values are to be assigned from the Bundle > Administrative Record Types namespace [RFC6255]: > > First of all according to the registry, this registry is actually > created by RFC 7116. > > This and the observation that the things you attempt to register in > this registry you are actual called Bundle Block Types in your > document. Thus, I have to ask are you actually addressing the right > registry, or is the issue that you actually need per version specific > registries for example Bundle Block Types? If it is the later, then > lets define new registries. Possibly there should be a new major page > for BPv7. Not having read all the old documents, you likely have to > consider which registries are version specific and which are not. Apparently needs more discussion. See seperate thread. > > 16. Section 10: > > For the new registry, do you have any requirements for registrations > that should be written out. And in addition any criteria you want the > expert to consider when approving or rejecting registries? And is > this registry version 7 specific or not? So, I think this question is still relevant for the new registries with Specification Required policy. It is good to be explicit about what information should be provided in a registration. Don't forget for example that you maybe should include in the registry who has the change control over a registry entry. > > 17. Section 4.1.1: > > The CRCs are lacking proper normative references. Needed for both 1 > and 2. Note that you have [CRC] that is currently unused. > Fixed. > 18. Section 11.2: > [BPSEC] is a normative reference. > [RFC6255] is normatively referenced for their registration > procedures. Addressed. > > 19. Section 13, Section 4.2.2 > > This Section 13 item was something I wondered over: > > . Restructure primary block, making it immutable. Add optional > CRC. > > Did I simply miss where that is said in the context of Section 4.2.2? Resolved. > > 20. Optional CRCs > > Why are the primary block CRC optional? I assume the intention with > it is to do a verification that the primarily block with the > addressing information hasn't become corrupted in the transmission > between nodes, similar to the checksums we have in other protocols. > Under which conditions will not using it be a reasonable idea? Are > you expecting other mechanisms to cover for it, or are you reasoning > that having corrupted bundles being delivered to the wrong places is > not an issue? As the primarily block is the main addressing part, I > would think the considerations that went into discussion of the > (almost) always usage of the UDP checksum for IPv6 applies here. Also > the implications for corruptions and cost in some DTNs for stray data > appears quite high. > Discussion has been raised by not concluded to my understanding. 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] I-D Action: draft-ietf-dtn-bpbis-14.txt internet-drafts
- Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt Magnus Westerlund
- Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt Burleigh, Scott C (US 312B)
- Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt Burleigh, Scott C (US 312B)
- Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt Magnus Westerlund
- Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt Magnus Westerlund
- Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt Burleigh, Scott C (US 312B)