Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt

"Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov> Fri, 13 September 2019 03:14 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 A448212003F; Thu, 12 Sep 2019 20:14:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_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 MOQVC6HYKcv1; Thu, 12 Sep 2019 20:14:15 -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 AE88B12000F; Thu, 12 Sep 2019 20:14:15 -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 x8D3AQvw078696; Thu, 12 Sep 2019 20:14:10 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpl.nasa.gov; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=InSight1906; bh=+qOzAKMI0PfEVwFv4wLsNgZ5+HtGxA3Zxq3F6tifgt0=; b=RyOltAurAOjO86FOVi2g30m8Za8dvGyHokfkgJgVE7LTt1VEYtJ4sr7yr/cjjdpLCpw8 wtyvhSE9eUt0jm0n8dJNSkvkUSOmIYQBHT2Bjxfy6O0/VMFJhAG7COAVyjiylYE9OSow FP02HsOfwf9ZoooBiktnru29zDwsHVqx+/2Yr1taMl+bVt6d7hkpmxVHn77krLuRCFTD 37zE9FbiUQnuCgzv9PcSx3c8/HxtQyTm9OmHK8Bu6DlUKoi8tazbt8I0yxDCI8xpGj0x atUyT/F/7R/WbSFL7wILVw2BB6eBVzTKfBBZuGBGF4E6SEycZONwOV6HSqo1EGR9LOuP 3Q==
Received: from mail.jpl.nasa.gov (altphysenclup01.jpl.nasa.gov [128.149.137.52]) by ppa01.jpl.nasa.gov with ESMTP id 2uytdpadnr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Sep 2019 20:14:10 -0700
Received: from ap-embx16-sp40.RES.AD.JPL (ap-embx16-sp40.jpl.nasa.gov [128.149.137.86]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id x8D3E8fE018127 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Thu, 12 Sep 2019 20:14:09 -0700
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp40.RES.AD.JPL (2002:8095:8956::8095:8956) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 12 Sep 2019 20:14:08 -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; Thu, 12 Sep 2019 20:14:08 -0700
From: "Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
CC: "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: AQHVaWGUxqn8AX0MuUW/YHJ4HCbV2Kco5Daw
Date: Fri, 13 Sep 2019 03:14:08 +0000
Message-ID: <5ff198b335184d5e854797ec27d2067e@jpl.nasa.gov>
References: <156494879521.26442.11081790719587421210@ietfa.amsl.com> <0d943b23f2d6d3bc929864ea59350958b296d481.camel@ericsson.com>
In-Reply-To: <0d943b23f2d6d3bc929864ea59350958b296d481.camel@ericsson.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_0071_01D569A6.9EE58FF0"
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp40.jpl.nasa.gov [128.149.137.86]
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-13_02:, , 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-1908290000 definitions=main-1909130031
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/fu0TAcV8tH1efhYbHPaTlqXFuoo>
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: Fri, 13 Sep 2019 03:14:18 -0000

Hi, Magnus.  Responding here (-->) only to the points that still remain open:

-----Original Message-----
From: Magnus Westerlund <magnus.westerlund@ericsson.com> 
Sent: Thursday, September 12, 2019 5:00 AM
To: draft-ietf-dtn-bpbis@ietf.org; dtn@ietf.org
Subject: [EXTERNAL] Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt

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.

	-->  (Response to this was sent in an earlier email today.)
 
> 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. 

	-->  I googled "Unix programmer's manual 1974" and the top entry returned was https://www.tuhs.org/Archive/Distributions/Research/Dennis_v5/v5man.pdf.

....

> 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.

	-->  That seems to be the consensus on the mailing list so far, and bpbis draft 14 notes that inclusion of BP security in any BP implementation is RECOMMENDED.  Is this item then resolved?

....

> 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? 

	-->  My original response to this item (July 17) was: '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.'  That is, bpbis draft 14 includes a mechanism by which a bundle protocol agent can legally drop status reports (or, in fact, other bundles) when there is contention for resources, but it doesn't attempt to prescribe the policy governing exercise of this mechanism; I think that's an implementation matter that may be deployment-specific and is beyond the scope of the protocol specification.
	-->  I think we actually did discuss this at IETF 105.  From the Minutes:
=== Congestion From Status Report ===

(C) S. Burleigh: Added text that policy mst exist to reduce extra traffic. This
                 requires management mechanism to defend against that. Cannot 
                 legislate that in this spec. 

(C) M. Westerlund: Ok.

> 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.

	-->  I think that's right.  Do we need to say something to this effect explicitly in the specification, or is this item resolved?

....

>    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.

	-->  Right, this is pending resolution on the mailing list.

> 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. 

	-->  The requests for new registries in section 10 are modeled on the requests in RFC 6255 for the DTN registries that currently exist.  Can you point me to an example of a better model that we should be following?

....

> 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.

	-->  Yes, still pending consensus on the mailing list.