Re: [dtn] [EXTERNAL] Mirja Kühlewind's Discuss on draft-ietf-dtn-bpbis-21: (with DISCUSS and COMMENT)

Hi, Mirja.  The current safety measures in the specification are (a) the generation of status reports is disabled by default and (b) all procedures that generate status reports are SHOULDs rather than MUSTs.

We could impose some sort of arbitrary limit on status report generation, e.g., the BPA must not generate more than 1 status report per second.  But I am reluctant to make that sort of provision part of the standard because we don't yet know what a reasonable value for that limit would be; under some circumstances, network troubleshooting might require that a large number of status reports be generated in the course of a very brief investigation.

Moreover, declaring such a limit and enforcing it are two different things.  A BP implementation can always be non-compliant, accidentally or maliciously.  If enforcement (the deletion of excess traffic as enabled by the new language in 4.2.2) is absent, then we have no defense against non-compliant nodes and the rule is moot; if it is present, then the rule is redundant -- the current warning that status report generation should be "enabled only when the risk of excessive network traffic is deemed acceptable" seems sufficient.

What would you suggest?

Scott

-----Original Message-----
From: Mirja Kuehlewind <ietf@kuehlewind.net> 
Sent: Tuesday, February 11, 2020 4:31 AM
To: Burleigh, Scott C (US 312B) <scott.c.burleigh@jpl.nasa.gov>
Cc: fred.l.templin@boeing.com; dtn-chairs@ietf.org; The IESG <iesg@ietf.org>; dtn@ietf.org; draft-ietf-dtn-bpbis@ietf.org
Subject: Re: [EXTERNAL] [dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn-bpbis-21: (with DISCUSS and COMMENT)

Hi Scott,

Not sure if that is sufficient because the attack I would see is that an attacker would send a message with a report request and a spoofed IP address which would then generate one message by each hop on the path to that IP address.

To encounter this attack, you would need to implement some safety measures in the nodes generating the reports.

Mirja

> On 7. Feb 2020, at 18:52, Burleigh, Scott C (US 312B) <scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org> wrote:
> 
> Hi, Mirja.  Ban Kaduk had similar concerns about DOS attacks, and I agree.  I have ventured to add some language in 4.2.2 that authorizes a BP agent to impose a (temporary, local) lifetime override when it detects a bundle that seems to constitute a threat - excessive status reporting, excessive fragmentation, or other types of traffic threats not yet identified.  Shortening the lifetime will cause the bundle to be deleted if it does turn out to degrade the operation of the node; it's a bit less arbitrary and more tunable than simply deleting the bundle immediately.  I'll post the updated draft in a few minutes; let me know if you think that addresses the problem?
> 
> On the bpv7 identification question: if the BPA receives something that starts with a 7 but isn't a bpv7 bundle, then I would expect that non-bundle to be discarded immediately as malformed (Step 3 of 5.6).  But do you have a better mechanism in mind?
> 
> Scott
> 
> -----Original Message-----
> From: Mirja Kuehlewind <ietf@kuehlewind.net>
> Sent: Friday, February 7, 2020 8:48 AM
> To: Burleigh, Scott C (US 312B) <scott.c.burleigh@jpl.nasa.gov>
> Cc: The IESG <iesg@ietf.org>; fred.l.templin@boeing.com; 
> dtn-chairs@ietf.org; draft-ietf-dtn-bpbis@ietf.org; dtn@ietf.org
> Subject: Re: [EXTERNAL] [dtn] Mirja Kühlewind's Discuss on 
> draft-ietf-dtn-bpbis-21: (with DISCUSS and COMMENT)
> 
> Hi Scott,
> 
> Thanks for addressing my points.
> 
> Thanks for adding some text on congestion control. I would prefer to have this in an own/new section (7.2. maybe) to increase visibility. I think it could also be useful to be even more concrete and say something like “transport protocols like TCP [RFC793] that provide congestion control should be used by the converge layer or if a UDP-based protocol is used, guidelines in [RFC8085] should be followed” however this seems more editorial now and I think my discuss on this is addressed.
> 
> Regarding the reports however I still think it is necessary to say more. I understand that this was widely discussed and is a not an easy topic but the risk of an amplification attack is serious here. I would like to see more recommendations towards additional safety measures a network could implement, e.g. filtering of reports or rate limiting of reports at the hops. Is there any good advice that could be given?
> 
> Then I was asking about how to identify a bundle, as actually only relying on the 7 in the first byte seems a bit brittle to me. I means, yes anything that does not have a 7 can not be bundle v7 but it also seems wrong to assume that everything starting with a 7 is bundle v7.
> 
> Mirja
> 
> 
> 
>> On 6. Feb 2020, at 15:42, Burleigh, Scott C (US 312B) <scott.c.burleigh@jpl.nasa.gov> wrote:
>> 
>> Good point on congestion.  Version 22 of the bpbis I-D, posted yesterday, now includes a paragraph at the end of section 7.2 that identifies the requirement for rate limiting or congestion control in the underlying transport protocols.
>> 
>> Controlling the proliferation of status reports has been a topic of lively discussion in the DTN WG and its antecedent RG for many years.  I have tried to clarify a bit, in new language in the second paragraph of section 5.1.
>> 
>> The "musts" in 4.1.3 and 4.1.4 have been changed to MUST.
>> 
>> On your last comment: I think the answer is yes, a received item of network traffic that does not begin with a "7" represented as a CBOR unsigned integer can't be a BPv7 bundle.  Does that answer your question?
>> 
>> Scott
>> 
>> -----Original Message-----
>> From: dtn <dtn-bounces@ietf.org> On Behalf Of Mirja Kühlewind via 
>> Datatracker
>> Sent: Monday, February 3, 2020 3:09 AM
>> To: The IESG <iesg@ietf.org>
>> Cc: fred.l.templin@boeing.com; dtn-chairs@ietf.org; 
>> draft-ietf-dtn-bpbis@ietf.org; dtn@ietf.org
>> Subject: [EXTERNAL] [dtn] Mirja Kühlewind's Discuss on 
>> draft-ietf-dtn-bpbis-21: (with DISCUSS and COMMENT)
>> 
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-dtn-bpbis-21: Discuss
>> 
>> ---------------------------------------------------------------------
>> -
>> DISCUSS:
>> ---------------------------------------------------------------------
>> -
>> 
>> I looked up RFC 4838 and there is a section on congestion control, however it only says: "Congestion control is an ongoing research topic." Unfortunately this document also doesn't give any further advise about congestion control but as a PS it really should. I understand that the bundle protocol is basically an application layer protocol on top of a transport that should care about congestion control, however, the document doesn't talk much about anything related to that underlying protocol. It would be important to specify requirements for the underlying transport protocol, indicating that is must be congestion controlled or rate limited (see RFC8085 as a reference for rate limiting of (uni-direction) UDP-based protocols).
>> 
>> Further this sentence in Sec 5.1 needs more clarification:
>> “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.”
>> It is not clear when it makes sense to enable and if enables one should probably also implement some filtering and rate limiting.
>> 
>> 
>> ---------------------------------------------------------------------
>> -
>> COMMENT:
>> ---------------------------------------------------------------------
>> -
>> 
>> 1) One general comment on the style of the document: I found it actually quite hard to read. I think it would help to add some overview text from time to time instead of going into all the details right away. E.g. maybe provide some kind of short summary/overview at the beginning of section 5 like the “Life cycle of a bundle“. In contrast I think you could cut down the section on concepts a bit (move some the implementation related notes to the appendix). Further, compared to the previous RFC, now that CBOR is used the text because actually more abstract. I think it would actually help to put CDDL fragment in body of document.
>> 
>> 2) Sec 4.1.3 and 4.1.4: Maybe use normative language here for all or 
>> most of the musts, e.g. s/then all status report request flag values 
>> must be zero/then all status report request flag values MUST be zero/
>> 
>> 3) Quick question on Sec 4.2.2:
>> “Version number SHALL be
>>  represented as a CBOR unsigned integer item.”
>> The document says that this version is not backward compatible. Is the version number the only field that can be used to identify the bundle protocol?
>> 
>> 
>> _______________________________________________
>> dtn mailing list
>> dtn@ietf.org
>> https://www.ietf.org/mailman/listinfo/dtn
> 