Re: [dtn] [EXTERNAL] Roman Danyliw's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)

"Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov> Thu, 06 February 2020 19:45 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 ED7471200F3; Thu, 6 Feb 2020 11:45:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_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 ZrDQAQvDFsoY; Thu, 6 Feb 2020 11:45:09 -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 B3E5312009E; Thu, 6 Feb 2020 11:45:09 -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 016Jj2KQ185696; Thu, 6 Feb 2020 11:45:05 -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 : content-transfer-encoding : mime-version; s=InSight1906; bh=/3/BjyCigY7I2X5UUrZ1lIo0QuxyvuxU/C5ySTkoVRo=; b=w2r04EwCReRcioybIGmfR9bkG1WtVB6haPRkrDyGZsh0SXkpJqGXzI1zVBShv0Z74hrn QJRdYv0KFfNKZudpq4uN5MVCtVCg3DdUrqp9QIo+hs+uoBqzFWVdETU7IkDasKL2JypI 2EYvWUjAAd23kdA1IPdqA5Yd1L5I9k2QswAsFMXnUyHKMOZdfaj2j/cqWrsM0ISeY3n7 NZSTJyK633CEhcT54Ti6h4+0D7H8wx3oawlC8/c9rW6QsA9vbOmHMNvOzNZpx3FS/SIB FS7RH4+vz1ig/f/N7PGZ6fJz3tEo9GUx4lpMa77TibecPx1RMRGV+wN5a1aQ7U/FZjRj 8A==
Received: from mail.jpl.nasa.gov (altphysenclup03.jpl.nasa.gov [128.149.137.120]) by ppa02.jpl.nasa.gov with ESMTP id 2y0mm7h609-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Feb 2020 11:45:05 -0800
Received: from ap-embx16-sp50.RES.AD.JPL (ap-embx16-sp50.jpl.nasa.gov [128.149.137.140]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id 016Jj42A023508 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Thu, 6 Feb 2020 11:45:04 -0800
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp50.RES.AD.JPL (2002:8095:898c::8095:898c) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 6 Feb 2020 11:45:03 -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; Thu, 6 Feb 2020 11:45:04 -0800
From: "Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>
To: Roman Danyliw <rdd@cert.org>, 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: [EXTERNAL] Roman Danyliw's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)
Thread-Index: AQHV3IjrufM0Tdr4tkupi/W3VQOdeqgObF0w
Date: Thu, 6 Feb 2020 19:45:04 +0000
Message-ID: <727063bcf4d24ab3a5509eb6f6013a13@jpl.nasa.gov>
References: <158095086532.31210.725213242109741420.idtracker@ietfa.amsl.com>
In-Reply-To: <158095086532.31210.725213242109741420.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp50.jpl.nasa.gov [128.149.137.140]
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-06_03:, , 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-2002060145
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/GLHm0ugxzQXWFEZZGhk3W6Bmew8>
Subject: Re: [dtn] [EXTERNAL] Roman Danyliw's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)
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 19:45:13 -0000

Excellent catch.  The next version of the BPv7 draft will contain modified language in section 4.1.5.1 that I hope will make more sense.  The intent is, just as you say, to register additional any number of URI schemes in that new URI scheme type code registry as needed, and to allow only URI schemes drawn from that registry in the formation of BP endpoint IDs.

On your COMMENTS:

** Figure 1.  Does the second from the left column running “T1/T2” and “N1/N2”
mean that this node has a dual stack of N1+T1 and N2+T2?

	Yes, exactly.  That second node is bridging between an N1+T1 subnet and an N2+T2 subnet.

** Section 3.1.  Can a node be part of multiple bundle endpoints?  I would assume yes, but don't see that said anywhere?

	Yes.  I'll add a sentence to this effect in 3.1.

** Section 3.1.  Per the definition of Bundle endpoint, there is a reference to Section 4.4.1 but that section doesn’t exist.  Did you mean Section 4.1.5?

	Yes (actually 4.1.5.1).  Fixing that.

** Section 3.1.  Per the definition of Registration, and registrations having two states (active and passive), could you please clarify why one would choose to be in either state.

	This needs to be inferred from the procedures in section 5.7.  The bundle protocol agent assumes that bundles can be delivered automatically and immediately to any registration that is in active state, but that registrations in passive state must be polled for their readiness for bundle delivery.  This has implications for implementation strategies, and in particular it has implications for the design of delivery failure actions (for example, the BPA may be required to run a script that starts the application that should consume the bundle's payload).

** Section 3.3. Per this list of BPA services, please add clarifying language to the effect that the details of this registration functionality is out of scope.

	Certainly.

** Section 4.
   (Note that, while CBOR permits considerable flexibility in the
   encoding of bundles, this flexibility must not be interpreted as
   inviting increased complexity in protocol data unit structure.)

What is practical guidance should an implementer take from this text?

	This is intended as an admonition to designers of new BP extension blocks and administrative records, not as guidance to implementers.  Basically, we would prefer that extensions to the bundle protocol be made as simple as possible. 

** Section 4.1.5.2  Per “A node's membership in a given singleton endpoint MUST be sustained at least until the nominal operation of the Bundle Protocol no longer depends on the identification of that node using that endpoint's ID.” -- what does it mean to “sustain” the membership? -- how would a node know that the "nominal operation of the BP no longer depends" of this address binding?

	Sustaining a node's membership in an endpoint means refraining from terminating the applicable registration.  If a node terminates its registration is some endpoint, then it can no longer receive bundles destined for that endpoint.  If reception of those bundles -- the nominal operation of the Bundle Protocol with regard to that endpoint -- is important to that node, then that registration must not be terminated, even if the node remains a member of several other endpoints.

** Section 4.2.2.  Per “Note that, in general, the creation of two distinct
bundles with the same source node ID and bundle creation timestamp may
result in unexpected network behavior and/or suboptimal performance”, where is that behavior described?

	I think that behavior can be fairly readily guessed: fragments of different bundles might be reassembled into a Frankenstein bundle, status reports purporting to pertain to one bundle might actually pertain to a different bundle, etc.  Any BP procedure that relies on bundle ID could malfunction.

** Section 5.1.  Per “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.”, can way points also choose not for forward these reports based on configuration?

	There's no explicit authorization for that in this specification.  In practice, any waypoint actually may be configured in ways that preclude the forwarding of any sort of bundle.
	A note on this: we expect network managers will configure their nodes to avoid forwarding through nodes that are known to be maliciously configured; the network management protocol to support these kinds of adjustments is under development (https://datatracker.ietf.org/doc/draft-ietf-dtn-ama/, https://datatracker.ietf.org/doc/draft-birrane-dtn-amp/).

** Section 6.1.1.
   Valid status
   report reason codes are defined in Figure 4 below but the list of
   status report reason codes provided here is neither exhaustive nor
   exclusive; supplementary DTN protocol specifications (including, but
   not restricted to, the Bundle Security Protocol [BPSEC]) may define
   additional reason codes.

Shouldn’t the text point to the associated IANA sub-registry (“Bundle Status Report Reason Codes” sub-registry) as the canonical place to understand semantics of future values?

	Sure, have added that reference.

** Section 9.  Recommend being clearer on the scope of the protections.

OLD:
Because the security mechanisms are extension blocks that are
   themselves inserted into the bundle, the integrity and
   confidentiality of bundle blocks are protected while the bundle is
   at rest, awaiting transmission at the next forwarding opportunity,
   as well as in transit.

NEW:
Because the security mechanisms are extension blocks that are
   themselves inserted into the bundle, the protections they afford
   apply when while the bundle is at rest, awaiting transmission at
   the next forwarding opportunity,
   as well as in transit.

	Sure.

** Section 9.  How is an implementor supposed to use the guidance in “Note that, while the primary block must remain in the clear for routing purposes,
the Bundle protocol could be protected against    traffic analysis to some
extent by using bundle-in-bundle encapsulation … [which] is a current research topic”?  There is no actionable guidance or pointers to more information.

	I'll include a reference to BIBE in section 9.

**   Section 9.  .  How is an implementor supposed to use the guidance in
paragraph starting with “The bpsec extensions accommodate an open-ended range ...”.  If there is a concrete proposal for “to sign and/or encrypt blocks using symmetric keys securely formed by Diffie-Hellman procedures”, BpSec suggest a spec needs to be written to register a security context to realize this approach.  Recommend removal.

	Okay.

Editorial Nit
-- Figure 2.  “CL1”, “CL2 …” is “Convergence Layer 1”, “2”?  “CL” is not defined anywhere

	Adding some explanatory text.

-- Section 5.4.  s/adapter(s) in order to effect/adapter(s) in order to affect/

	No, "effect" is used correctly here.

Scott

-----Original Message-----
From: Roman Danyliw via Datatracker <noreply@ietf.org> 
Sent: Wednesday, February 5, 2020 5:01 PM
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] Roman Danyliw's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-dtn-bpbis-22: Discuss

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 4.1.5.1. Can the permissible schemes for the Endpoint ID URL be clarified.

Initially the text says:

The scheme identified by the < scheme name > in an endpoint ID is a
   set of syntactic and semantic rules that fully explain how to parse
   and interpret the SSP. The set of allowable schemes is effectively
   unlimited. Any scheme conforming to [URIREG] may be used in a bundle
   protocol endpoint ID.

[URIREG] would suggest that any schema in IANA "Uniform Resource Identifier
(URI) Schemes" Registry’ is valid.  However, later, the text says:

The first item of the array SHALL be the code number identifying the
   endpoint's URI scheme [URI], as defined in the registry of URI
   scheme code numbers for Bundle Protocol maintained by IANA as
   described in Section 10. [URIREG].

This text suggests that the new Bundle Protocol URI Scheme Type registry should govern the EID schemes.  However, then the text again cites URIREG.  Perhaps the intent is that URI's valid per [URIREG] would be registered in the new bundle protocol registry and values in this new registry would be used.


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

** Figure 1.  Does the second from the left column running “T1/T2” and “N1/N2”
mean that this node has a dual stack of N1+T1 and N2+T2?

** Section 3.1.  Can a node be part of multiple bundle endpoints?  I would assume yes, but don't see that said anywhere?

** Section 3.1.  Per the definition of Bundle endpoint, there is a reference to Section 4.4.1 but that section doesn’t exist.  Did you mean Section 4.1.5?

** Section 3.1.  Per the definition of Registration, and registrations having two states (active and passive), could you please clarify why one would choose to be in either state.

** Section 3.3. Per this list of BPA services, please add clarifying language to the effect that the details of this registration functionality is out of scope.

** Section 4.
   (Note that, while CBOR permits considerable flexibility in the
   encoding of bundles, this flexibility must not be interpreted as
   inviting increased complexity in protocol data unit structure.)

What is practical guidance should an implementer take from this text?

** Section 4.1.5.2  Per “A node's membership in a given singleton endpoint MUST be sustained at least until the nominal operation of the Bundle Protocol no longer depends on the identification of that node using that endpoint's ID.” -- what does it mean to “sustain” the membership? -- how would a node know that the "nominal operation of the BP no longer depends" of this address binding?

** Section 4.2.2.  Per “Note that, in general, the creation of two distinct
bundles with the same source node ID    and bundle creation timestamp may
result in unexpected network behavior and/or suboptimal performance”, where is that behavior described?

** Section 5.1.  Per “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.”, can way points also choose not for forward these reports based on configuration?

** Section 6.1.1.
   Valid status
   report reason codes are defined in Figure 4 below but the list of
   status report reason codes provided here is neither exhaustive nor
   exclusive; supplementary DTN protocol specifications (including, but
   not restricted to, the Bundle Security Protocol [BPSEC]) may define
   additional reason codes.

Shouldn’t the text point to the associated IANA sub-registry (“Bundle Status Report Reason Codes” sub-registry) as the canonical place to understand semantics of future values?

** Section 9.  Recommend being clearer on the scope of the protections.

OLD:
Because the security mechanisms are extension blocks that are
   themselves inserted into the bundle, the integrity and
   confidentiality of bundle blocks are protected while the bundle is
   at rest, awaiting transmission at the next forwarding opportunity,
   as well as in transit.

NEW:
Because the security mechanisms are extension blocks that are
   themselves inserted into the bundle, the protections they afford
   apply when while the bundle is at rest, awaiting transmission at
   the next forwarding opportunity,
   as well as in transit.

** Section 9.  How is an implementor supposed to use the guidance in “Note that, while the primary block must remain in the clear for routing purposes,
the Bundle protocol could be protected against    traffic analysis to some
extent by using bundle-in-bundle encapsulation … [which] is a current research topic”?  There is no actionable guidance or pointers to more information.

**   Section 9.  .  How is an implementor supposed to use the guidance in
paragraph starting with “The bpsec extensions accommodate an open-ended range ...”.  If there is a concrete proposal for “to sign and/or encrypt blocks using symmetric keys securely formed by Diffie-Hellman procedures”, BpSec suggest a spec needs to be written to register a security context to realize this approach.  Recommend removal.

Editorial Nit
-- Figure 2.  “CL1”, “CL2 …” is “Convergence Layer 1”, “2”?  “CL” is not defined anywhere

-- Section 5.4.  s/adapter(s) in order to effect/adapter(s) in order to affect/