Re: [dtn] new BIBE I-D

"Burleigh, Scott C (312B)" <scott.c.burleigh@jpl.nasa.gov> Mon, 21 May 2018 22:22 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 5212E12D94C for <dtn@ietfa.amsl.com>; Mon, 21 May 2018 15:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 mjwzHo3u4ikC for <dtn@ietfa.amsl.com>; Mon, 21 May 2018 15:22:49 -0700 (PDT)
Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) (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 9858112D88E for <dtn@ietf.org>; Mon, 21 May 2018 15:22:49 -0700 (PDT)
Received: from mail.jpl.nasa.gov (ap-embx16-sp40.jpl.nasa.gov [128.149.137.86]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id w4LMMmc7010796 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified OK) for <dtn@ietf.org>; Mon, 21 May 2018 15:22:49 -0700
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp40.RES.AD.JPL (2002:8095:8956::8095:8956) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1415.2; Mon, 21 May 2018 15:22:24 -0700
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::156f:dcf8:9cdf:e7ec]) by ap-embx16-sp10.RES.AD.JPL ([fe80::156f:dcf8:9cdf:e7ec%21]) with mapi id 15.01.1415.002; Mon, 21 May 2018 15:22:24 -0700
From: "Burleigh, Scott C (312B)" <scott.c.burleigh@jpl.nasa.gov>
To: "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: [dtn] new BIBE I-D
Thread-Index: AdPwq7sXmIkg+ocnQ1ai9bfJOMkkigAePwwAAAsRlqA=
Date: Mon, 21 May 2018 22:22:24 +0000
Message-ID: <709e892baaea48898f9c795a94aa5729@jpl.nasa.gov>
References: <734a179fe593429ca1c38f4e20ab954c@jpl.nasa.gov> <1738164354.6006651.1526896612434@mail.yahoo.com>
In-Reply-To: <1738164354.6006651.1526896612434@mail.yahoo.com>
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-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/gDkz50ON37LBCj1jQ5m4ea0dH98>
Subject: Re: [dtn] new BIBE I-D
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 21 May 2018 22:22:52 -0000

I remember this conversation.  Now as then, I think it's better policy to rely on authentication and firewall configuration, rather than routing, to address these kinds of security issues.

Scott

-----Original Message-----
From: Lloyd Wood <lloyd.wood@yahoo.co.uk> 
Sent: Monday, May 21, 2018 2:57 AM
To: Burleigh, Scott C (312B) <scott.c.burleigh@jpl.nasa.gov>; dtn@ietf.org
Subject: Re: [dtn] new BIBE I-D

https://tools.ietf.org/html/draft-burleigh-dtn-bibect-01


"  . Moreover, in the event that no single point of egress from an insecure region of network topology can be determined at the moment a bundle is to be encapsulated, multiple copies of the bundle may be encapsulated individually and forwarded to all candidate points of egress."



I've previously raised the issue of multiple tunnel encaps effectively recapitulating source routing, with all the problems that source routing entails. That concern still stands. (June 2017 on this list)

generating BIBE-in-BIBE-in-BIBE... that DoSses and crashes bundle nodes (multiple nodes! with copying!) and allows spoofing of traffic from nodes is inevitable, and the draft needs to address that, by discussion recursion and source routing, and any introduced limits to same.

I don't have a view on whether ACS is a mistake; I see larger errors.

Lloyd Wood
http://sat-net.com/L.Wood/dtn


________________________________
From: "Burleigh, Scott C (312B)" <scott.c.burleigh@jpl.nasa.gov>
To: "dtn@ietf.org" <dtn@ietf.org> 
Sent: Monday, 21 May 2018, 12:39
Subject: [dtn] new BIBE I-D



Hi.  I just now posted a new edition of the Bundle-in-Bundle Encapsulation draft.  It differs from the initial edition mainly in the Custody Transfer mechanism it defines.  Some years of experience with the prototype Aggregate Custody Signal in ION on the International Space Station have convinced the ISS guys that ACS is important and is superior to the baseline custody transfer system originally defined in BIBE, lifted from RFC 5050.  My original thought was simply to add ACS as an option in BIBE, but on closer examination I couldn't spot any scenario in which the original custody transfer mechanism would be more efficient than the aggregated variant.  So the custody transfer procedures in this BIBE draft are now very similar to those of that ACS prototype.  Please speak up if you think this is a mistake.


Scott


_______________________________________________

dtn mailing list

dtn@ietf.org

https://www.ietf.org/mailman/listinfo/dtn