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

"Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov> Fri, 07 February 2020 17:52 UTC

Return-Path: <scott.c.burleigh@jpl.nasa.gov>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62597120073; Fri, 7 Feb 2020 09:52:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jpl.nasa.gov
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OlKSFNzW41U; Fri, 7 Feb 2020 09:52:08 -0800 (PST)
Received: from ppa01.jpl.nasa.gov (ppa01.jpl.nasa.gov [128.149.137.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C72120026; Fri, 7 Feb 2020 09:52:08 -0800 (PST)
Received: from pps.filterd (ppa01.jpl.nasa.gov [127.0.0.1]) by ppa01.jpl.nasa.gov (8.16.0.27/8.16.0.27) with SMTP id 017Hq65c121723; Fri, 7 Feb 2020 09:52:06 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpl.nasa.gov; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=InSight1906; bh=f+hEIKppQEXbsNIDWYlgmOARgpH109MpmKutQf22CFU=; b=R+ocdxw1mY4xbaebprL4Rp/1rZPmPaOhsGWYW1VbGxPYMcpW7dNfA1yvoNNHRQk/7p5E lOTfuii35YjcGWqoG1xnIHp83L2ehKXyezFs0mfX7eZO3SsY3ewQvTn0P1Y602Enac9a T3IfDU7vpBXRve97RoPHTdriotTahfb/SG7dzJXM1WdhSEm9RLP4vJ6LS7/5ix6aDYx9 5TtqzuWJl3QUUCCEj6HVjHDlJJtmvmdCx2tV1yx1e+lqo2bmbarljfQYDUCv/dSyYCTq SFS9b1p7d/CjRTjfsdrp8Mcrv8jo3wBcPj3pNl5mTvQUf6ZM4xr5wGBxARdEJnC3bVFm SA==
Received: from mail.jpl.nasa.gov (altphysenclup01.jpl.nasa.gov [128.149.137.52]) by ppa01.jpl.nasa.gov with ESMTP id 2y1b2rrdt6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Feb 2020 09:52:05 -0800
Received: from ap-embx16-sp10.RES.AD.JPL (ap-embx16-sp10.jpl.nasa.gov [128.149.137.83]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id 017Hq4Sr000737 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Fri, 7 Feb 2020 09:52:04 -0800
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Fri, 7 Feb 2020 09:52:03 -0800
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.1591.008; Fri, 7 Feb 2020 09:52:03 -0800
From: "Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
CC: The IESG <iesg@ietf.org>, "fred.l.templin@boeing.com" <fred.l.templin@boeing.com>, "dtn-chairs@ietf.org" <dtn-chairs@ietf.org>, "draft-ietf-dtn-bpbis@ietf.org" <draft-ietf-dtn-bpbis@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: =?utf-8?B?W0VYVEVSTkFMXSBbZHRuXSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBv?= =?utf-8?B?biBkcmFmdC1pZXRmLWR0bi1icGJpcy0yMTogKHdpdGggRElTQ1VTUyBhbmQg?= =?utf-8?Q?COMMENT)?=
Thread-Index: AQHV2oJPHNjM/1XpWE6fKkJvVjgtDqgOPk3QgAI/bQD//4dRcA==
Date: Fri, 7 Feb 2020 17:52:03 +0000
Message-ID: <93729005ff4346f0929ce0ff1913bda7@jpl.nasa.gov>
References: <158072811912.28544.4475168797987237276.idtracker@ietfa.amsl.com> <2eb42b3d2d9e40edb2531e5ba0102b41@jpl.nasa.gov> <2AE0C0EF-B4DB-4A56-ADBA-061825E9757A@kuehlewind.net>
In-Reply-To: <2AE0C0EF-B4DB-4A56-ADBA-061825E9757A@kuehlewind.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.151.104.72]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp10.jpl.nasa.gov [128.149.137.83]
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-07_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002070133
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/hoDi1vKZR4NtsT9Bu7lfsgZipWc>
Subject: Re: [dtn] =?utf-8?q?=5BEXTERNAL=5D__Mirja_K=C3=BChlewind=27s_Discuss?= =?utf-8?q?_on_draft-ietf-dtn-bpbis-21=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2020 17:52:11 -0000

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>rg>; 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