Re: [dtn-security] Updated SBSP Document

"Burleigh, Scott C (312G)" <scott.c.burleigh@jpl.nasa.gov> Mon, 02 June 2014 16:53 UTC

Return-Path: <scott.c.burleigh@jpl.nasa.gov>
X-Original-To: dtn-security@ietfa.amsl.com
Delivered-To: dtn-security@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672DF1A03C1 for <dtn-security@ietfa.amsl.com>; Mon, 2 Jun 2014 09:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.85
X-Spam-Level:
X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 q4ksRjwtE4AZ for <dtn-security@ietfa.amsl.com>; Mon, 2 Jun 2014 09:53:51 -0700 (PDT)
Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23DD11A0360 for <dtn-security@irtf.org>; Mon, 2 Jun 2014 09:53:51 -0700 (PDT)
Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s52GriP8031678 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 2 Jun 2014 09:53:45 -0700
Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.156]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0174.001; Mon, 2 Jun 2014 09:53:44 -0700
From: "Burleigh, Scott C (312G)" <scott.c.burleigh@jpl.nasa.gov>
To: "Scott, Keith L." <kscott@mitre.org>, Amy Alford <aloomis@sarn.org>
Thread-Topic: [dtn-security] Updated SBSP Document
Thread-Index: Ac96egHBtIlHfqjpRHK8eG5est6OOQA736HgADK/lpAAn4L4gAAB6Q+AAA47H4A=
Date: Mon, 2 Jun 2014 16:53:44 +0000
Message-ID: <A5BEAD028815CB40A32A5669CF737C3B423B4FCB@ap-embx-sp40.RES.AD.JPL>
References: <329D879C76FDD04AAAE84BB1D89B3970094FBF9EAA@aplesfreedom.dom1.jhuapl.edu> <94CFB3711B4CAE4DBFC5BEB3374BF0C60D1835@NDMSMBX404.ndc.nasa.gov> <A5BEAD028815CB40A32A5669CF737C3B423B369E@ap-embx-sp40.RES.AD.JPL> <CAB9rx+9RDz3nudRifan8Sfo+44EjnPsvm=G0z5S53qCo6GOUJg@mail.gmail.com> <5EE81C5C4CFFF4418C5EAD12F49D64EE4C2219F2@IMCMBX01.MITRE.ORG>
In-Reply-To: <5EE81C5C4CFFF4418C5EAD12F49D64EE4C2219F2@IMCMBX01.MITRE.ORG>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.149.137.26]
Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B423B4FCBapembxsp40RESAD_"
MIME-Version: 1.0
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/xlswC2nvclyH1_HUjf_17G1q268
Cc: "dtn-security@irtf.org" <dtn-security@irtf.org>
Subject: Re: [dtn-security] Updated SBSP Document
X-BeenThere: dtn-security@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." <dtn-security.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-security/>
List-Post: <mailto:dtn-security@irtf.org>
List-Help: <mailto:dtn-security-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jun 2014 16:53:53 -0000

One more comment on one of these topics, also in-line.

From: Scott, Keith L. [mailto:kscott@mitre.org]
Sent: Monday, June 02, 2014 9:27 AM
To: Amy Alford; Burleigh, Scott C (312G)
Cc: dtn-security@irtf.org
Subject: RE: [dtn-security] Updated SBSP Document

Some comments in-line below.

                        --keith

From: dtn-security [mailto:dtn-security-bounces@irtf.org] On Behalf Of Amy Alford
Sent: Monday, June 02, 2014 11:33 AM
To: Burleigh, Scott C (312G)
Cc: dtn-security@irtf.org<mailto:dtn-security@irtf.org>
Subject: Re: [dtn-security] Updated SBSP Document

I'm also responding inline.

On Fri, May 30, 2014 at 3:17 PM, Burleigh, Scott C (312G) <scott.c.burleigh@jpl.nasa.gov<mailto:scott.c.burleigh@jpl.nasa.gov>> wrote:
A couple of remarks on David’s comments, in-line below.
Scott
From: dtn-security [mailto:dtn-security-bounces@irtf.org<mailto:dtn-security-bounces@irtf.org>] On Behalf Of Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
Sent: Thursday, May 29, 2014 12:09 PM
To: Birrane, Edward J.; dtn-security@irtf.org<mailto:dtn-security@irtf.org>
Subject: Re: [dtn-security] Updated SBSP Document

Ed,

Good work - the SBSP spec continues to evolve nicely. I’ll kick off the discussions with my comments below.

Cheers,

DZ
[Page 12] 2.4 Bundle Authentication Block
The security-target MUST be the entire bundle, which MUST be
represented by a <block type><occurrence number> of <0x00><0x00>.
•         Per 3.4 Bundle Fragmentation and Reassembly, bundle authentication may be applied to bundle fragments as well as non-fragmented bundles.
•         If a bundle fragment is received that has a BAB, there is no way to determine if the BAB applies to the bundle fragment or if it applies to an entire bundle that was later fragmented by a non-security-aware BA.
o    I propose that a <block type><occurrence number> of <0x00><payload frag length> indicate that the BAB applies to a bundle fragment
•         If such a bundle fragment is further fragmented by a non-security-aware BA then the <payload frag length> can be used to determine that the original fragmented bundle must be reassembled before authentication is checked because it will not match the length field in the payload block.
o    Some discussion may be desirable in section 3.4 as well as 2.4 if accepted

>  When a BAB is attached to a bundle that is a fragment, the bundle that it applies to is always that fragment, never the bundle that carried the original payload (of which the current bundle’s payload is a fragment).  Since BABs are not end-to-end, the BAB for an original un-fragmented bundle will never be carried forward in any fragments generated from that bundle (see the last paragraph of 3.3.1), so there’s no ambiguity.  But this does bring up an important point: the block processing control flags of the BAB must always have the “replicate in every fragment” flag set to 0.
Maybe I'm misunderstanding here, but fragmentation can happen between a BAB source and a BAB dest if a non-security aware node is between the two.  Requiring the "DO_NOT_FRAGMENT" flag solves this.

BABs should be applied ‘point-to-point’ between bundle agents; there shouldn’t be an opportunity for a non-security-aware node to fragment a bundle with a BAB on it.  I’ll have to check the cross-product between encapsulation and BAB (i.e. whether you can encapsulate a bundle with a BAB on it (and then possibly fragment the encapsulating bundle) or not).  I suspect that the answer is ‘no’ (i.e. you check / remove the BAB immediately on receipt and before you encapsulate and/or fragment for transmission).


Ø There isn’t really any accepted spec to consult on encapsulation, but within the concept that I’ve been working with (https://datatracker.ietf.org/doc/draft-irtf-burleigh-bibe/) the encapsulation protocol is a convergence-layer adapter.  In that case, the entire, complete outbound bundle – including any BAB that was attached at the last moment before serialization for the CLA – would become the payload of the new encapsulating bundle.  The encapsulating bundle might or might not be security-aware, but that doesn’t matter.  The destination of the encapsulating bundle would extract the encapsulated bundle (the “outer” bundle’s payload) and simulate reception of that bundle, which would still have its BAB.  That bundle would, in effect, have traversed only a single hop (direct transmission between sender and receiver at the convergence layer), so there was no intervening non-security-aware forwarding node between the sending node that attached the BAB and the receiving node that would validate it.  So no opportunity for fragmentation, no problem.