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