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

["Templin (US), Fred L" <[e-mail]>]

HI Magnus,

> -----Original Message-----
> From: dtn [mailto:[e-mail]] On Behalf Of Magnus Westerlund
> Sent: Monday, July 08, 2019 12:05 AM
> To: [e-mail]; [e-mail]
> Subject: Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13
> 
> WG,
> 
> 
> To clarify, I will not progress this document until the WG has
> established a consensus on what to do, if any, about the IPR.

Thank you for your review efforts. Regarding IPR, as part of my document
shepherd's writeup I polled the authors and no relevant IPRs were reported.
Can you say more about your concern?

Regards - Fred

> Cheers
> 
> Magnus
> 
> 
> 
> On Fri, 2019-07-05 at 14:06 +0000, Magnus Westerlund wrote:
> > 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
> >
> > _______________________________________________
> > dtn mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dtn
> --
> Cheers
> 
> Magnus Westerlund
> 
> 
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>