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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Sep 2019 11:59:31 +0000

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. 

>  
> 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. 

>  
>  
> 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.

This is also resolved. 

>  
> 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.

Resolved. 

>  
> 5.       Section 4.3.3.
> Maximum Hop count upper limit? Can I insert a max UiNT64 here and
> expect that to be acceptable?

Resolved. 

>  
> 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.

I think the added text is good enough. I appreciate the difficulty in
how to balance this. 

>  
> 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.

The new text clarifies thing, issue resolved. 

>  
> 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?

Resovled. 

>  
> 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?

Resolved. 

>  
> 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.

Resolved. 

>  
> 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. 

>  
> 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?
>  

Addressed. 

> 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? 

>  
> 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. 

>  
> 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?

Addressed. 

>  
> 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.

Apparently needs more discussion. See seperate thread. 

>  
> 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. 

>  
> 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.
>  

Fixed. 

> 18.   Section 11.2:
> [BPSEC] is a normative reference.
> [RFC6255] is normatively referenced for their registration
> procedures.

Addressed. 

>  
> 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?

Resolved. 

>  
> 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. 

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Thu, 12 Sep 2019 16:26:12 +0000

Magnus, thanks for this.  I haven't yet had time to read through all of your 
comments, but I wanted to get an early start on this first one.  I certainly 
agree that the Status of both the dtn and ipn URI schemes should be permanent, 
but it has been my impression that requesting provisional registries and then 
later asking for them to be made permanent would enable us to move forward 
more quickly.  (The URI registration page notes that "Requests for permanent 
registration must be preceded by mailing list review, per Section 7.2 of 
[RFC7595]".)  If that's not an issue, excellent, I'll revise the I-D.

I think the definition of the dtn scheme is broad enough to be compatible with 
all contemplated use in both BPv6 and BPv7, so I don't think 
BP-version-specific notes need to be included in the registry.

Scott

-----Original Message-----
From: Magnus Westerlund <[email-masked]>
Sent: Thursday, September 12, 2019 5:00 AM
To: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt

Hi,

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 13 Sep 2019 03:14:08 +0000

Hi, Magnus.  Responding here (-->) only to the points that still remain open:

-----Original Message-----
From: Magnus Westerlund <[email-masked]> 
Sent: Thursday, September 12, 2019 5:00 AM
To: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt

Hi,

	-->  (Response to this was sent in an earlier email today.)
 
> And please provide necessary normative references, not informative

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://www.tuhs.org/Archive/Distributions/Research/Dennis_v5/v5man.pdf.

....

	-->  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?

....

	-->  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.

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

....

	-->  Right, this is pending resolution on the mailing list.

	-->  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?

....

	-->  Yes, still pending consensus on the mailing list.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Sep 2019 11:26:57 +0000

Hi,

Regarding the URI Review. Yes, that URI review needs to occur. However,
we can initiate that as soon as we think we have an update document
where we are happy with these changes. In worst case it will result in
a slightly extended IETF last call. 

Cheers

Magnus

-- 
Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Sep 2019 11:51:19 +0000

Hi,

Please see inline for comments.

On Fri, 2019-09-13 at 03:14 +0000, Burleigh, Scott C (US 312B) wrote:
> 	-->  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. 

> 	-->  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. 

> 	-->  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.

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

> 	-->  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. 

> 	-->  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/

-- 
Cheers

Magnus Westerlund

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Tue, 17 Sep 2019 21:04:19 +0000

Hi, Magnus.  Responses in-line as well (---->>), with points of agreement 
removed.

Scott

-----Original Message-----
From: Magnus Westerlund <[email-masked]>
Sent: Tuesday, September 17, 2019 4:51 AM
To: Burleigh, Scott C (US 312B) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt

Hi,

> I have reviewed how this document addresses my AD comments.

...

	---->>	Sure, I'll do that.
 ...

	---->>	Okay, I will add language.

	---->>	Great!  I will revise along those lines.

-- 
Cheers

Magnus Westerlund