Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt

[Magnus Westerlund <[e-mail]>]

Hi,

Please see inline for comments.


On Fri, 2019-09-13 at 03:14 +0000, Burleigh, Scott C (US 312B) wrote:
> Hi, Magnus.  Responding here (-->) only to the points that still
> remain open:
> 
> -----Original Message-----
> From: Magnus Westerlund <[e-mail]> 
> Sent: Thursday, September 12, 2019 5:00 AM
> To: [e-mail]; [e-mail]
> Subject: [EXTERNAL] Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt
> 
> 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.
> 
> 	-->  (Response to this was sent in an earlier email today.)
>  
> > 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. 
> 
> 	-->  I googled "Unix programmer's manual 1974" and the top
> entry returned was 
> https://protect2.fireeye.com/url?k=c009b4e1-9cddb28c-c009f47a-867011091b6c-4fe5a255ffb263c1&q=1&u=https%3A%2F%2Fwww.tuhs.org%2FArchive%2FDistributions%2FResearch%2FDennis_v5%2Fv5man.pdf
> .

And I tried version and not publication year. 

Maybe you should include the URL in the reference. 

> 
> ....
> 
> > 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.
> 
> 	-->  That seems to be the consensus on the mailing list so far,
> and bpbis draft 14 notes that inclusion of BP security in any BP
> implementation is RECOMMENDED.  Is this item then resolved?

Yes. 

> 
> ....
> 
> > 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? 
> 
> 	-->  My original response to this item (July 17) was: 'Yes.  To
> address this, an additional reason code “Traffic pared” has been
> added to Figure 4.  This authorizes the bundle protocol agent to drop
> status reports at its own discretion as described in Step 2 of
> 5.4.'  That is, bpbis draft 14 includes a mechanism by which a bundle
> protocol agent can legally drop status reports (or, in fact, other
> bundles) when there is contention for resources, but it doesn't
> attempt to prescribe the policy governing exercise of this mechanism;
> I think that's an implementation matter that may be deployment-
> specific and is beyond the scope of the protocol specification.
> 	-->  I think we actually did discuss this at IETF 105.  From
> the Minutes:
> === Congestion From Status Report ===
> 
> (C) S. Burleigh: Added text that policy mst exist to reduce extra
> traffic. This
>                  requires management mechanism to defend against
> that. Cannot 
>                  legislate that in this spec. 
> 
> (C) M. Westerlund: Ok.

Okay, that looks like it resolves the issue as well as possible at this
point. 

> 
> > 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.
> 
> 	-->  I think that's right.  Do we need to say something to this
> effect explicitly in the specification, or is this item resolved?
> 

I think it is a point to be explicit about this being implementation
and usage specification. 

> ....
> 
> >    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.
> 
> 	-->  Right, this is pending resolution on the mailing list.
> 
> > 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. 
> 
> 	-->  The requests for new registries in section 10 are modeled
> on the requests in RFC 6255 for the DTN registries that currently
> exist.  Can you point me to an example of a better model that we
> should be following?

One example of this type of registrations are the IANA Considerations
in this document: 

https://datatracker.ietf.org/doc/draft-ietf-quic-transport/



> 
> ....
> 
> > 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.
> 
> 	-->  Yes, still pending consensus on the mailing list.
> 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------