Re: [dtn] working group last call on draft-ietf-dtn-bpbis

[Stephen Farrell <[e-mail]>]

Hiya,

On 24/01/17 19:02, Templin, Fred L wrote:
> Hi Stephen,
> 
> I am still going through your comments, but one question that I have
> on one of your points for now:
> 
>     "4) it's not ok to omit
>      security mechanism definition, (making [BPSEC] normative and
>      waiting on that in the RFC editor queue would fix this, and is
>     IMO needed),
> 
> Wouldn't that create a circular dependency? 

That's not a problem. The RFC editor handles document clusters
like that all the time.

> If not, what do you see
> as a way forward that would not entail a prolonged blockage in the
> RFC editor queue?

I do think waiting for bpsec to be done is the right thing here.
I've no strong opinion as to whether it's better to have bpbis
wait "in" the WG or the RFC editor queue, though I can see why
folks would prefer the latter which I think is fine. (If some
aspect of bpsec called for some change in bpbis, your AD would
just help you get that done, but I'd say that's low probability.)

We had the equivalent (though imperfect:-) security mechanisms
defined for 5050, not having them while aiming for PS with
5050bis seems to me going backwards.

Not defining security mechanisms that are clearly needed (as
this document itself says) also runs counter to IETF BCPs on
security such as BCP61.

I'll also note that there's a history of efforts that try punt
on security mechanism definition taking longer in the end. (See
the history of the roll WG with RPL for example.)

So, functionally, formally and tactically I'd argue that the thing
to do is to have both RFCs issue at the same time.

Note though that I think it is reasonable to not aim to define
key management mechanisms that meet BCP107 for all possible uses
of the BP, so I also think finishing bpsec should be entirely
doable, e.g. via some kind of applicability statement text about
automated key management in bpsec (though there may be other ways
to handle that too).

Cheers,
S.

> 
> Thanks - Fred
> [e-mail]
> 
>> -----Original Message-----
>> From: dtn [mailto:[e-mail]] On Behalf Of Stephen Farrell
>> Sent: Monday, January 23, 2017 7:33 PM
>> To: Marc Blanchet <[e-mail]>; dtn <[e-mail]>
>> Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis
>>
>>
>> Hiya,
>>
>> I've done a review of bpbis-06 and have many comments. (Sorry:-)
>>
>> Overall I don't think this is ready, and some more discussion
>> of some of the issues is needed. Since I've not followed the
>> list as closely as I'd have liked I may have missed some such
>> discussion in which case pointing me at the relevant bit(s) of
>> the archive would be a fine response.
>>
>> I've tried to separate stuff into things that'd cause me to
>> ballot DISCUSS in IESG evaluation (*), things that might not,
>> and nitty things. I hope that helps, but don't take that
>> categorisation too seriously:-)
>>
>> Cheers,
>> S.
>>
>> (*) Note that I'll likely not still be on the IESG when this
>> gets there (I escape in March) so the fact that I would ballot
>> DISCUSS is not that relevant to what other ADs might do.
>>
>>
>> Possibly major issues (DISCUSS like)
>> ------------------------------------
>>
>> (A) intro: The last bullet list of the things that are not
>> specified here seems problematic for a PS and I think needs
>> more discussion/work. I'm not sure if it's only the text that
>> needs work, or if the missing specification is required now.
>> Taking the bullets one at at time (numbers are in order of
>> presentation): 1) This isn't clear enough, I'm not sure what's
>> being omitted, 2) Omitting routing I think is fair, 3) It's
>> also fair to omot RIB/FIB issues, 4) it's not ok to omit
>> security mechanism definition, (making [BPSEC] normative and
>> waiting on that in the RFC editor queue would fix this, and is
>> IMO needed), 5) I'm not sure what's right here.  I think it'd
>> be good to have some list discussion about this, as it'll
>> certainly come up in IETF LC and IESG review and having list
>> traffic at which to point will help backup whatever conclusions
>> are reached.  In particular in 4.3, I don't think it's
>> acceptable for the BIB and BCB to not have a normative
>> reference. Similarly, the "TBD" for the other extension block
>> types are not appropritate. (But those can likely be
>> informative refs.)
>>
>> (B) The spec is overly prescriptive in many places and ought be
>> loosened up wherever possible. All we need is interop and not
>> the kind of conformance at which this spec seems to aim (but
>> maybe miss). For exmple the "retention constraint" stuff has
>> absoluely no reason to be a MUST. As another, I think section
>> 5.4 only needs a MUST in step 4 and all the rest are bogus and
>> a bad plan.  Also in 3.1, the text here is often far too
>> prescritpive and I suspect based on only a couple of
>> implementation strategies.  There are many more examples.  I
>> think it'd be a good plan to do an editing pass to get rid of
>> as many of the extraneous and unnecessary constraints that are
>> here.  Examples feature in other comments, but I've not tried
>> to be exhaustive in spotting all instances of this.
>>
>> (C) Many of the flags relaed to reporting provide ways in which
>> the BP, if it became widely deployed (even if not planned to be
>> widely used), could be a significant (D)DoS accelerator. Has
>> anyone figured out the scale factors involved, (e.g. if N bogus
>> blocks say report if this can't be processed) whether those
>> might be significant and if so what potential countermeasures
>> might apply? Absent such an analysis, or fixing the problem,
>> I'd argue it'd seem irresponsible to standardise the BP.  I'd
>> say for a PS, the minimum is that BPAs MUST default to not
>> sending all these new bundles except when specifically
>> configured to be so verbose.  This also affects 5.1 and maybe
>> elsewhere which says an agent MUST emit admin bundles if asked.
>> In 5.6, step 2: again the SHOULD needs to be qualified in order
>> to not have the BP be a fine DoS accelerator (given
>> non-singletons). Step 3's SHOULD for this is even worse as a
>> bad actor could include many such blocks.  In 5.13 - I think
>> that is too many custody signals. If one envisages DTNs with
>> custodians located at links that are particularly subject to
>> disruption, then those may be few in number and having all
>> other nodes/routers emit custody signals for each bundle not
>> taken into custody seems hugely inefficient and unnecessary.
>> There may be more examples.  FWIW, my guess is that if all the
>> current reporting is kept, then the IESG will require some kind
>> of applicability statement about the kind of network in which
>> the BP can safely be deployed. For me, fixing the problem is a
>> better approach than constraining it via an applicability
>> statement.
>>
>> A bit less major (maybe not DISCUSS-worthy)
>> -------------------------------------------
>>
>> (1) 3.1's definition of a bundle correctly says that bundles
>> are better when they include all the meta-data that might be
>> useful. If considered naively, that conflicts with modern
>> approaches to privacy where we want to ensure that meta-data is
>> only seen by those (nodes) that need to see meta-data, as one
>> form of data minimisation. OTOH, one could argue that such
>> bundles will ensure that meta-data and payloads enjoy the same
>> security services, which is a good thing. In any case, I think
>> it'd be useful to have a discussion about the privacy aspects
>> of the BP, esp the ways in which those may be different from
>> other protocols. For example, would we expect report-to URIs to
>> commonly allow re-identification of a person? I don't recall
>> we've ever really discussed such issues.
>>
>> (2) 3.1, destination: I think this ought be clear that delivery
>> to some node in the endpoint represents success, i.e.  that the
>> BP does not force successful delivery to all or failure as a
>> binary choice.
>>
>> (3) What bad things would follow if 3.2 was deleted?  It may be
>> that I'm too familiar with DTN (and hence not a good judge if
>> this section is useful or not) but I didn't find it useful.
>> Also - is 3.2 normative? If not, I'm even happier to see it go.
>> If it is, then I gotta wonder if it conflicts with other text
>> later. And I see there are a few 2119 MUSTs in there so I guess
>> you do mean it to be normative or did they sneak in in by
>> accident whilst editing? (As can happen.) If not deleting this
>> section, I'd argue to find all the bits of text in it that are
>> needed and move them all elsewhere and then delete the section.
>>
>> (4) 3.2: The idea that the EID fully determines the MRG seems
>> just wrong to me. While that might be a nice theory, I figure
>> it's way more likely that the routing scheme determines how
>> many copies of a bundle are rx'd at how many instances of the
>> destination EID. What'd be bad about losing that concept and
>> letting (the determinants of) the MRG be unspecified here?
>>
>> (5) 3.2, "Custody of a bundle MAY be taken only if the
>> destination of the bundle is a singleton endpoint." That's
>> plain wrong. Not all custodians can know about the desitnation
>> being a singleton or not. And before you say it, I don't
>> believe in the flag in 4.1.3 that allows an origin to specify
>> this - I've never seen a real example of when that's useful -
>> the only nearby case I recall was where the developer (me:-)
>> knew we wanted distibution to all nodes in a multi-member
>> endpoint but with best effort in terms of getting to them all
>> and with custody and less frequent application layer re-tx's to
>> ensure we got to as many as possible.  This also affects 5.2.
>>
>> (6) 3.3, I'm not sure this is useful either. What'd break if it
>> were deleted? (But then I never liked those bits of DTNRG's
>> work either;-)
>>
>> (7) Including some examples and an RFC 7942 implementation
>> status section would be a good thing, if easily done. That
>> would help progression and increase confidence in the
>> correctness of the spec.
>>
>> (8) 4.1.6: Was sub-second timing discussed by the WG?  I'm not
>> terribly pushed on that myself, but it'd be a shame to do an
>> interop breaking change in the BP without discussing that
>> topic. A reason to think about this is that there may be
>> inter-VM (or intra-data-centre) reasons to consider the BP with
>> sub-second timing as interesting.  It'd be a shame to make that
>> impossible just to make it slightly simpler to represent time.
>>
>> (9) 4.2.2, creation time rules: I don't see why it'd be a
>> problem if node-id=X, creation-time=0,counter=0,lifetime=2s is
>> used in two bundles emitted 3 seconds apart. Why does that
>> justify a MUST NOT in the spec?
>>
>> (10) 4.2.2: The "30 seconds" rule also seems wrong to me, as is
>> the "MUST NEVER" (not a 2119 term btw) for re-use of the seq
>> no, which is unrealistic.  As an example of that last: what do
>> you expect to happen with a node that usually knows the wall
>> clock time, but, at this moment, knows that it does not? E.g.
>> previous logs have some real dates, but current clock is
>> 1970-01-01 or whatever. I think this is fixable but the current
>> language is too prescriptive. Best might be to weaken the
>> language here and to see what implementations do in the real
>> world.
>>
>> (11) 4.3.1: Is the SHALL here right? I would have thought a
>> SHOULD is better to allow for legacy interop with 5050 via
>> gateways, in which case there may be no node ID. That might be
>> better off handled in some generic fashion though, and not
>> piecemeal with each mention of node ID.
>>
>> (12) 4.3.2: I don't believe it is correct to drop a bundle due
>> to the lack of a previous node block, which is what sems to be
>> implied here. Not all routing schemes need this and so it ought
>> not be a MUST. Maybe a SHOULD is enough, but even if you say
>> "MUST insert this" then I would like to argue that "receivers
>> can decide to not care" be stated explicitly e.g.  by saying
>> that bundles MUST NOT be rejected solely due to the lack of
>> this EB.
>>
>> (13) I'm not sure if you have all the right "watch out for the
>> null EID node ID" text needed. (I didn't go back over
>> everything, but it'd seem wrong e.g. in an current custodian
>> AR.
>>
>> (14) 5.4: "The bundle protocol agent MUST determine which
>> node(s) to forward the bundle to." That's ungrammatical and
>> close to BS - what if I want to multicast or broadcast the
>> bundle or use some other opportunistic CLA? Or a sneakernet
>> where nobody knows who'll be next hop.
>>
>> (15) 5.4: The text about the flow label should be deleted as it
>> says nothing. If includng this, then the flow label spec may
>> need to be a normative ref (arguably).
>>
>> (16) 5.4 - I think this is badly misleading. There will be many
>> cases where a bundle cannot be forwarded now but may be
>> forwarded later. Am I wrong in reading this section as
>> precluding that?
>>
>> (17) 5.6, step 4 says one MUST handle "custody transfer
>> redundancy" but that term seems undefined.
>>
>> (18) 5.6 (step 5) points back to 5.3 which points to 5.7 or
>> 5.4. I don't think such GOTOs are a good idea really.  I
>> suggest removing lots of this and adding in some informative
>> (i.e. non-normative) pseudo code (or real code) as an appendix.
>>
>> (19) I think some rules related to custody and fragmentation
>> may be missing. For example, if bundle A is multicast and
>> reaches two nodes on different paths who take custody
>> (custodians C1/C2) and who both fragment but differently (into
>> F11/F12 and F21/F22 resp) with eventually a custody ack for F21
>> reaching C1.  Assume F21 is longer than F11, what is C1 to do
>> with F11 when a custody timer expires?  Ought it re-transmit or
>> consider that the custody ack for F21 matched F11 sufficiently
>> well?  I'm not sure what'd be right here, if such cases can
>> happen.  I'd be fine with the spec admitting that some such
>> corner cases exist, or maybe it's easy enough to figure out,
>> not sure.
>>
>> (20) 5.10.1, I've always wondered why custody timer expiry is
>> covered here, and not really considered a part of DTN routing.
>> It seems to me to make more sense to couple custody timing and
>> routing. If that resonated with folks, I think the change would
>> be to make the timer-related text here into an illustrative
>> example and to say that such things are better considered
>> together with routing and/or by chunks of code that are
>> somewhat more topology/disruption-aware of the situation in the
>> particular DTN.
>>
>> (21) section 9 seems woefully incomplete - why is it ok to say
>> "will be required" at WGLC? Surely the WG should at least have
>> discussed the set of registries needed and the registration
>> rules for those? E.g. do we sill want CCSDS to be able to add
>> entries to some of those registries as we did with 5050?  And
>> has the WG considered how do all the things in this draft
>> relate to the set of IANA registries related to the BP? [1,2]
>> (In the case of [3], section 4.1.5.1 really probably does need
>> to say something.)
>>
>>   [1] https://www.iana.org/assignments/bundle/bundle.xhtml
>>   [2]
>> https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-1
>>
>> Seemingly more minor or nitty things
>> ------------------------------------
>>
>> - abstract: "This Internet Draft" is no longer appropriate
>> language.
>>
>> - abstract: I think this ought capture the fact that this
>> version is not interoperable with 5050. That's not a bad thing,
>> but worth noting here.
>>
>> - intro: I don't think the "sales" language is needed or
>> appropriate in the first couple of paras. It should be entirely
>> ok to say "we've learned stuff and fixed stuff."
>>
>> - intro: "Custodial forwarding" is too terse at this point but
>> also hard to explain briefly, is really a mechanism and not a
>> capabililty, and maybe not such a highlight, so I'd delete that
>> bullet
>>
>> - intro: "[TUT]" is quite outdated and using dtnrg.org for the
>> reference isn't wise (particularly at the moment when we're
>> seeing SERVFAIL from the relevant NS;-)
>>
>> - intro: this is a bit self-serving, but maybe a reference to
>> the architectural retrospective [3] that Kevin and I wrote
>> might be useful here, though I've not checked if it touches on
>> enough of the issues behind the differences between 5050 and
>> this.
>>
>>    [3] https://ieeexplore.ieee.org/document/4530739
>>
>> - Figure 1: I wonder if it'd be worth pointing out that the BP
>> does not have to run over a layer 4 that runs over a layer 3
>> etc. The figure and this text does give that impression that a
>> "proper" transport is needed, which isn't the case.
>> (Tactically, I'm not sure if the text as-is, or something more
>> correct, would make getting a new RFC easier or harder - I
>> guess it'll depend on the reader;-)
>>
>> - Figure 2: Few if any of the applications I've used with the
>> BP had an administrative element. That's maybe down to the
>> experimental nature of the work we've done but I don't think
>> it's correct to imply that all applications using the BP need
>> to be able to handle admin records, if that's what you're
>> implying. (I'm not sure.) I'd say indicating that that's an
>> optional thing would be right.
>>
>> - 3.1, singleton: not sure if it's clear enough that all
>> endpoints are sets, so this may puzzle folks. Maybe add e.g.
>> "remember that endpoints are sets," not sure.
>>
>> - 3.1, forwarding: the text is odd - "sustained effort" is not
>> mandatory, and what "that node" is meant here?
>>
>> - 4: The first two SHALL statements are odd in that there's no
>> way in which one could implement this spec and not conform to
>> those I think. In cases like that it's fine to avoid 2119
>> language. Not a big deal though, as the current IESG don't get
>> anal about that, though some ADs in the past have done;-)
>>
>> - 4: last item MUST be break stop code. Is a decoder supposed
>> to barf a bundle if this is not true? More generally, same
>> question applies for all MUSTs stated only in terms of what the
>> encoding must match.
>>
>> - 4.1.1: why >1 CRC type? That seems bogus. None or strong
>> seems better to me. (And I'd go for a crypto hash for strong.)
>> I assume the WG discussed this and found that there are real
>> use-cases for each of those specified. While those don't need
>> to be in the spec, can someone tell me what they are as I'm not
>> at all sure, e.g. why a 16 bit CRC is useful as an option.
>>
>> - 4.1.3: "enables anonymous bundle transmission" - that's
>> overstated, chances are that something in the CLA will be
>> identifying, or allow re-identification, so I think what you
>> want to say is that omitting the source EID helps with, but
>> does not ensure, nymity.
>>
>> - 4.1.5.1: RFC3986 is the correct reference here, so the spec
>> text is correct as-is. It may however be worth taking a look at
>> the whatwg web page that has sometimes claimed to supercede
>> 3986 for the browser-related things in which whatwg have an
>> interest.  That's just in case there're some useful error
>> handling considerations on the whatwg web page, (on the day you
>> look at it;-). It's also the case that since BP EIDs are URIs,
>> it's possible that strings that comply with today's or
>> yesterday's whatwg web page may end up in the BP, so it'd be
>> good to know if any of those (that are not valid according to
>> 3986) might cause a problem with the CBOR encoding.
>>
>> - 4.1.5.2: Danger, metaphysics! "Every node MUST be a member of
>> at least one singleton endpoint." This entire section is
>> over-thought.  I think all you need to say is that nodes the
>> emit bundles need to have an EID they can use as a source EID
>> for as long as necessary.
>>
>> - 4.2.1: this entire section is duplicative. That's a bad idea.
>>
>> - 4.2.2: 2nd para is badly written - that'd encourage coders to
>> use the values 8,9,10 and 11 in ways that might be unwise.
>>
>> - 4.2.2: wrt "anonymous" see earlier comment
>>
>> - 4.2.2: description of creation time is duplicative, except
>> the earlier text didn't cover relative time.
>>
>> - 4.3.3: Is "Bundle Age Block" a good name? BAB used to mean
>> another type of block, so that could confuse maybe. (That said,
>> I forget how long we're had this name.)
>>
>> - 4.3.4: Do you need to say that the hop limit MUST NOT be
>> changed, once a hop count EB is added. Also, can any node add
>> one of these, if one was not prevsiously present?
>>
>> - 5: It's not necessary to say that new RFCs can supercede
>> this.  That's just standard IEFF process.
>>
>> - 5.2: mentions "dispatch pending" as if I should know what
>> that is - is all the retention constraint stuff sufficiently
>> explained I wonder? (Personally I don't think you need to
>> mandate all this stuff and you cannot tell if an implementation
>> has done it or not so I'd not bother trying to be so
>> prescriptive.)
>>
>> - 5.4: "at the last possible moment... MUST..." that's a bit
>> silly as it seems to require BP code inside a NIC which is not
>> how this'll usually be implemented.
>>
>> - 5.5: I'm not convinced that the MUSTs here are right for all
>> DTNs. I reckon that 5.5 could just as well say "MAY delete" and
>> the BP would be fine. That might also provide some additional
>> flexibility for some rounting schemes. That said, I won't press
>> on this - if this doesn't resonate with folks now, and later
>> turns out to be useful, I don't think we'd have such a hard
>> time modifying BPAs where needed.
>>
>> - 5.6: Again, this is overly prescriptive.
>>
>> - 5.6, step 4: I wonder if an implementer will get all this
>> right.
>>
>> - 5.9: Badly implemented, re-assembly can create a memory
>> consumption DoS vector, perhaps esp. if attempted on a
>> non-destination node. It'd be better to warn about that. And
>> maybe change from MAY for in-path reassembly to SHOULD NOT.
>>
>> - 5.11: does this mean that a custodian MUST ignore a custody
>> signal destined for some other custodian?
>>
>> - Figure 6: I don't get when reason codes 5 to 8 would really
>> be used. Are they in fact needed?  (They seem a bit
>> implementation specific to me, but I've not gone looking.)
>>
>> - section 8: First sentence is bogus.
>>
>> - section 8: [SECO] isn't a good reference. It's outdated and I
>> doubt will be picked up.
>>
>>
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
>