Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13
"Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov> Wed, 17 July 2019 15:23 UTC
Return-Path: <scott.c.burleigh@jpl.nasa.gov>
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 EEBC81207FA; Wed, 17 Jul 2019 08:23:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jpl.nasa.gov
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 Y_3FwMtZDwNv; Wed, 17 Jul 2019 08:23:06 -0700 (PDT)
Received: from ppa01.jpl.nasa.gov (ppa01.jpl.nasa.gov [128.149.137.112]) (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 B4232120794; Wed, 17 Jul 2019 08:23:06 -0700 (PDT)
Received: from pps.filterd (ppa01.jpl.nasa.gov [127.0.0.1]) by ppa01.jpl.nasa.gov (8.16.0.27/8.16.0.27) with SMTP id x6HFJZ60142792; Wed, 17 Jul 2019 08:23:01 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpl.nasa.gov; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=InSight1906; bh=TRwnU+7xqfibGxGWAVnUJp4WkQlZ2GfoVAvnW7lLlCM=; b=t49ZOc0NOjamcfed3n8XcN631bHDFmuvvzI5DD7NSluRCW+GOHhJGtL7IMidQ/km1AQj NR5k1c+abCwbaYEafitT5IepTuAmz3svbI9A5vc0s6GpjC1ZuFsJWYpJaLu8gRLlEzFG WargJ3KiAMF91W84Dba/CyTAXjJKJihM2HeUEEHnmVCr57pY9JRqC85EY/iDIlme5JKI 3o9Fpt2hg9+oVeArkPqHSOfBMfdLgfhkL6w9jOpAfUJ9uSU1pZi6M85hqgpLl1oJXfn7 YQNsEbnNQluuSAqBD8eM99LjElb4Zy/AQRHDdEcdm+UiBpRvSolozsmLCJSrsZXcTCmU FA==
Received: from mail.jpl.nasa.gov (altphysenclup01.jpl.nasa.gov [128.149.137.52]) by ppa01.jpl.nasa.gov with ESMTP id 2tt5aj08yq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Jul 2019 08:22:59 -0700
Received: from ap-embx16-sp30.RES.AD.JPL (ap-embx16-sp30.jpl.nasa.gov [128.149.137.85]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id x6HFMwZF011897 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Wed, 17 Jul 2019 08:22:58 -0700
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp30.RES.AD.JPL (2002:8095:8955::8095:8955) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Wed, 17 Jul 2019 08:22:57 -0700
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.1591.008; Wed, 17 Jul 2019 08:22:57 -0700
From: "Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "dtn@ietf.org" <dtn@ietf.org>, "draft-ietf-dtn-bpbis@ietf.org" <draft-ietf-dtn-bpbis@ietf.org>
Thread-Topic: AD evaluation of draft-ietf-dtn-bpbis-13
Thread-Index: AdUzOQfkywWzmEnHT4iyH8+qUympAQJeKWzw
Date: Wed, 17 Jul 2019 15:22:57 +0000
Message-ID: <bee906661cb24e8a9b4430c811b76203@jpl.nasa.gov>
References: <HE1PR0701MB25224DF64B2B60A0C655E1CE95F50@HE1PR0701MB2522.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0701MB25224DF64B2B60A0C655E1CE95F50@HE1PR0701MB2522.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [207.151.104.72]
Content-Type: multipart/signed; micalg="SHA1"; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_002E_01D53C78.CF8268F0"
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp30.jpl.nasa.gov [128.149.137.85]
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-17_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907170178
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/mj4csyh9v56t9GVMYGiqnHoeZ7A>
Subject: Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13
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: Wed, 17 Jul 2019 15:23:12 -0000
Hi, all. Attached is a revised bpbis Internet-Draft, modified in response to Magnus's evaluation of draft 13. (The window for posting I-Ds is currently closed, so unfortunately the document has to be emailed.) Answers to the questions in the evaluation are proposed in-line within the evaluation, below. In addition to the modifications in response to the evaluation, this draft also responds to Brian's comments from May 16 and reflects some additional discussion among the authors. Also, it has been called to my attention that the thing I have been calling a flow label is not one; in the new draft, the term "data label" is adopted instead. Scott From: Magnus Westerlund <magnus.westerlund@ericsson.com> Sent: Friday, July 5, 2019 7:06 AM To: dtn@ietf.org; draft-ietf-dtn-bpbis@ietf.org Subject: [EXTERNAL] AD evaluation of draft-ietf-dtn-bpbis-13 Hi, I have now reviewed this document. Consider that there are a number of issues that likely need WG discussion I thought I should send out this, despite that I have not yet reviewed the BPSEC document that appears to be highly relevant and may result in additional changes needed in this document. But BPSEC is next in a my review pile. Also as this area is new, I read the architecture a long time ago so don't hesitate to clarify if it appears that I am missing things. 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. Yes. Section 10.3 has been added for this purpose. Also, maybe similar effort to move "ipn" to permeant is needed? By all means. But I think the first step is to get the "dtn" scheme provisionally registered. 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. As we've discussed, some explanatory text is needed; it has been inserted into section 4.1.6. 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. Noted in 4.1.6. And please provide necessary normative references, not informative ones. Some guidance needed here: which normative references are required? 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. Forward reference to 4.3.2 has been added in 4.2.2. 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. Text has been added in 4.2.2 to clarify that the primary block is immutable. 5. Section 4.3.3. Maximum Hop count upper limit? Can I insert a max UiNT64 here and expect that to be acceptable? We left this question as explicitly "beyond the scope", but we can assert a number. What should the maximum hop limit be? 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. Text acknowledging this has been added to 5.1. 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. That's the intent. A clarifying phrase has been added in 5.1. 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: That's right. We believe that policy mechanisms to accomplish this are going to be needed, but we don't know what form they will take. Again, beyond the scope. 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. 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. Some clarifying text has been added to 5.3. 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? Yes! Good catch - now fixed. 9. Section 6.1.1 What does Destination endpoint ID unintelligible actually mean? Same with Block unintelligible. It means that the receiving bundle protocol agent cannot process the block for some reason: either the block is malformed or it is corrupted (CRC doesn't match) or it is simply a type of extension block that the implementation does not recognize. Are these the combination for corrupted blocks or EIDs? Are there a point of separating out the case where the CRC indicate a corruption? Yes. Added a new Step 3 in 5.6. 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? We specifically don't want to constrain implementations of BP and convergence-layer adapters any more than necessary, as this has no impact on protocol interoperability. But yes, a "forwarding completed" signal is needed; inserted second bullet in list in 7.2. I was expecting this section to actually be explicit about what functionalities the Bundle Agent really need from the convergence layer. We really want to avoid over-constraining here. Implementation experience has shown that more extensive guidance is not needed. 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. Section 9 now states that inclusion of the Bundle Security Protocol in any Bundle Protocol implementation is REQUIRED. 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? Yes; added in 4th paragraph of section 9. 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. Yes. To address this, an additional reason code "Traffic pared" has been added to Figure 4. This authorizes the bundle protocol agent to drop status reports at its own discretion as described in Step 2 of 5.4. 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? There may be better ways to select values for these parameters, but none are known yet. The correct procedure may be wildly different in different kinds of delay-tolerant networks. We want to avoid over-constraining applications. 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? Yes, done. 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. RFC 7116 defines the Licklider Transmission Protocol. This sounds like an error in the registry. 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. "Bundle Block Types" is correct. The block types defined for BPv7 are a superset of the block type types defined for RFC 5050. 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? No known requirements or considerations aside from the obvious ones (e.g., a reference document is required). RFC 5050 has no notion of URI scheme type numbers, so while the new registry is specific to version 7 it doesn't supersede any other registry. 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. Right, added. (Brian Sipos commented on this as well.) 18. Section 11.2: [BPSEC] is a normative reference. [RFC6255] is normatively referenced for their registration procedures. Changed [BPSEC] to normative. Changed [RFC6255] to normative also, but since this is an informative RFC I worry that the nits filter won't like it. 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? Added text about primary block immutability in 4.2.2. 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. The thinking has been that you should virtually always have a bpsec BIB attached to the primary block, which not only authenticates the block but also protects the integrity of the block. In that scenario, a CRC on the primary block would not add much value. BIBs can also be attached to other blocks, but in some cases a BIB might be overkill and a CRC is all that's needed. So the CRCs are always an option. Cheers Magnus Westerlund
- [dtn] AD evaluation of draft-ietf-dtn-bpbis-13 Magnus Westerlund
- Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13 R. Atkinson
- Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13 Magnus Westerlund
- Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13 Magnus Westerlund
- Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13 Templin (US), Fred L
- Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13 Magnus Westerlund
- Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13 R. Atkinson
- Re: [dtn] [EXTERNAL] Re: AD evaluation of draft-i… Burleigh, Scott C (312B)
- Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13 Burleigh, Scott C (US 312B)
- Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13 Magnus Westerlund
- Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13 Magnus Westerlund
- Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13 Burleigh, Scott C (US 312B)