[dtn] AD evaluation of draft-ietf-dtn-bpbis-13

[Magnus Westerlund <[e-mail]>]

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. 

 

Also, maybe similar effort to move "ipn" to permeant is needed? 

 

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. 

 

 

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. 

 

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. 

 

5.       Section 4.3.3.

Maximum Hop count upper limit? Can I insert a max UiNT64 here and expect
that to be acceptable? 

 

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.

 

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. 

 

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?

 

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?

 

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. 

 

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. 

 

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? 

 

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. 

 

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? 

 

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? 

 

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. 

 

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? 

 

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. 

 

18.   Section 11.2:

[BPSEC] is a normative reference.

[RFC6255] is normatively referenced for their registration procedures. 

 

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? 

 

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. 

 

 

Cheers

 

Magnus Westerlund