Re: [dtn] [EXTERNAL] Éric Vyncke's No Objection on draft-ietf-dtn-bpbis-21: (with COMMENT)

"Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov> Thu, 06 February 2020 03:04 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 56C9B120072; Wed, 5 Feb 2020 19:04:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 yAX6MWeVtBoE; Wed, 5 Feb 2020 19:04:55 -0800 (PST)
Received: from ppa02.jpl.nasa.gov (ppa02.jpl.nasa.gov [128.149.137.113]) (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 E12D012006E; Wed, 5 Feb 2020 19:04:54 -0800 (PST)
Received: from pps.filterd (ppa02.jpl.nasa.gov [127.0.0.1]) by ppa02.jpl.nasa.gov (8.16.0.27/8.16.0.27) with SMTP id 01630Dvf043684; Wed, 5 Feb 2020 19:04:51 -0800
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=GycTuMK8rY5UiI0FiKhSmU733yREWwXFWBYpfbo1tVY=; b=ccUPzyZg++a2MaReP1Sdbc+NiPGm7DIKE3NEfdUggtioPWiNy+QcC1HDLO/xYOIkn6Aa aVZotIYXZ5VIftMMezP5oO8xgFL8F6vqbcxBn8z3JCzIP/KIKG3lAuOclzjUa6eYZnGV hkzuGJ+y4xQg3TEJtiDbkP9t9hbTqoAz+XKbpVAy+SO1bgRlUykB4Rc0q5O1t5X99+nT Gq+846rxnLKJ1f8CKMoZLTzvBrxGl4oLWZckePjMCNN54NFCgdO7AWnYZGqPgb0E+CVo tvGTCFSYh2h/maFLVYLGDMcvdvLTXFN8g9XlJu5wWGQIObv+443Qz1iqsjbQSEi3mHJ9 iA==
Received: from mail.jpl.nasa.gov (altphysenclup03.jpl.nasa.gov [128.149.137.120]) by ppa02.jpl.nasa.gov with ESMTP id 2xykcbmdkw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Feb 2020 19:04:51 -0800
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 01634n3V029930 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Wed, 5 Feb 2020 19:04:50 -0800
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, 5 Feb 2020 19:04:49 -0800
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, 5 Feb 2020 19:04:49 -0800
From: "Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>
To: =?iso-8859-1?Q?=C9ric_Vyncke?= <evyncke@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-dtn-bpbis@ietf.org" <draft-ietf-dtn-bpbis@ietf.org>, "Fred Templin" <fred.l.templin@boeing.com>, "dtn-chairs@ietf.org" <dtn-chairs@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: =?iso-8859-1?Q?[EXTERNAL]_=C9ric_Vyncke's_No_Objection_on_draft-ietf-dtn-?= =?iso-8859-1?Q?bpbis-21:_(with_COMMENT)?=
Thread-Index: AQHV2sFPHBd9t24890SfrlM9eC4rbagNOaUA
Date: Thu, 6 Feb 2020 03:04:49 +0000
Message-ID: <f2d80711d3c8488895f8eab6cb84f1db@jpl.nasa.gov>
References: <158075518324.28576.1883680195513357461.idtracker@ietfa.amsl.com>
In-Reply-To: <158075518324.28576.1883680195513357461.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.151.104.72]
Content-Type: multipart/alternative; boundary="_000_f2d80711d3c8488895f8eab6cb84f1dbjplnasagov_"
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=2020-02-05_06:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002060021
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/WRxkq8ZUwRleRsaZMBV44Wzrj1Q>
Subject: Re: [dtn] =?iso-8859-1?q?=5BEXTERNAL=5D_=C9ric_Vyncke=27s_No_Objecti?= =?iso-8859-1?q?on_on_draft-ietf-dtn-bpbis-21=3A_=28with_COMMENT=29?=
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, 06 Feb 2020 03:04:57 -0000

Éric, thanks for your review.  Version 22 of the bpbis spec has been posted, and it responds to some of your comments, but here are some more detailed remarks:

C1) is there any reason why the reserved bits in section 4.3.1 are not specified with the usual 'transmitted as 0 and ignored by receiver' ?
The style of sections 4.1.3 and 4.1.4 is inherited from RFC 5050, but certainly we can change it if there's a convention we need to follow.

C2) in section 4.1.5, is there a registry or a mechanism to avoid / detect identifier collisions ?
There isn't one yet; for now, each network operator is responsible for assigning the IDs of endpoints in its own network.  When one is developed, it will likely be defined in its own RFC(s) rather than in this protocol specification.

C3) just curious, why is it version 7 ?
It's descended from BP version 6, which is defined in RFC 5050.

C4) in section 4.3.2, if the bundle age is expressed in microseconds, then I would suggest to define exactly 'most recently forwarded': by which component of the bundle node ? is it measured at the completion of the action (e.g., layer-2 serialization is finished). Section 5.4 adds some more information but not enough to my taste (is it when the forwarding decision is made or when the convergence layer has accepted it).
Excellent point.  Bundle age is expressed in microseconds for the benefit of future implementations that may be able to assert and utilize precise bundle age values in ways not yet identified.  For now, the only purpose of bundle age is to trigger deletion of the bundle when the bundle's expiration time is reached, and expiration time is only at 1-second granularity (creation time plus time-to-live).  Time-to-live values are themselves highly inexact guesses as well, for now; margins of several seconds or even minutes are not uncommon.  So for the time being I think the precision in definition you are suggesting would be overkill.

C5) in section 4.3.3., why not following the usual method of hop-limit starting at a non-zero value and being decremented at each forwarding operation ? it is like using DTN time from 2000 rather than the usual timestamp definition. Nothing bad or blocking, but, I wonder why re-inventing the wheel if there is no real reason
There is some possibility that the hop count might be used for mechanisms beyond loop detection, such as network metrics; for these purposes, it would likely be more useful for the hop count to be a genuine count, monotonically increasing.  The epoch for DTN time is 2000 to somewhat reduce the sizes of time values, saving a little bit of transmission overhead.

C6) the possibility of having a single bundle to generate multiple reports along its path to the 'report-to' endpoint ID per section 5.6 could possibly be used for an amplification attacks + resource exhaustion attack on traversed nodes. Should a rate limiting be mentioned ?
Mirja Kühlewind was concerned about this too.  New text has be inserted into section 5.1 to address the issue.

C7) section 5.9, should the re-assembly process time out ? E.g., taking into account the max bundle age ?
Because the fragments are themselves bundles, and all bundles have expiration times, reassembly will always time out when the fragments expire.

C8) section 8, I have hard time to parse the following "the Bundle Protocol version 7 specification draft (version 6)" even if I think I got it right
That text has been revised to make it a little easier to parse.

C9) section 8, an interop status (if any) between the three existing implementations would be welcome
The paragraph discussing PyDTN notes that PyDTN is interoperable with uPCN.  The interoperability of the Terra implementation is unknown at this time.
Scott

-----Original Message-----
From: Éric Vyncke via Datatracker <noreply@ietf.org>
Sent: Monday, February 3, 2020 10:40 AM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dtn-bpbis@ietf.org; Fred Templin <fred.l.templin@boeing.com>om>; dtn-chairs@ietf.org; fred.l.templin@boeing.com; dtn@ietf.org
Subject: [EXTERNAL] Éric Vyncke's No Objection on draft-ietf-dtn-bpbis-21: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-dtn-bpbis-21: No Objection

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. And it is a really interesting topic !

The document is not really easy to read with some long and convoluted sentence such as
  "An application data unit is the unit
   of data whose conveyance to the bundle's destination is the purpose
   for the transmission of some bundle that is not a fragment (as
   defined below)."

Another one:
  "The payload for a bundle
   forwarded in response to reception of a bundle is the payload of the
   received bundle."

The above sentences and others make the reading really difficult. Probably too late to change now...

The section 3.2 go a little too deep IMHO in details (do we care whether the BPA is general-purpose computer?)

As a side note, I would be interested by the potential use of this bundle protocol to transport the future webpack ;-)

Please find below some non-blocking COMMENTs.
C1) is there any reason why the reserved bits in section 4.3.1 are not specified with the usual 'transmitted as 0 and ignored by receiver' ? C2) in section 4.1.5, is there a registry or a mechanism to avoid / detect identifier collisions ? C3) just curious, why is it version 7 ? C4) in section 4.3.2, if the bundle age is expressed in microseconds, then I would suggest to define exactly 'most recently forwarded': by which component of the bundle node ? is it measured at the completion of the action (e.g., layer-2 serialization is finished). Section 5.4 adds some more information but not enough to my taste (is it when the forwarding decision is made or when the convergence layer has accepted it). C5) in section 4.3.3., why not following the usual method of hop-limit starting at a non-zero value and being decremented at each forwarding operation ? it is like using DTN time from 2000 rather than the usual timestamp definition. Nothing bad or blocking, but, I wonder why re-inventing the wheel if there is no real reason C6) the possibility of having a single bundle to generate multiple reports along its path to the 'report-to' endpoint ID per section 5.6 could possibly be used for an amplification attacks + resource exhaustion attack on traversed nodes. Should a rate limiting be mentionned ?
C7) section 5.9, should the re-assembly process time out ? E.g., taking into account the max bundle age ? C8) section 8, I have hard time to parse the following "the Bundle Protocol version 7 specification draft (version 6)" even if I think I got it right C9) section 8, an interop status (if any) between the three existing implementations would be welcome

I hope that this helps to improve the document,

Regards,

-éric