Re: [dtn-security] Updated SBSP Document - BAB

"Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" <david.a.zoller@nasa.gov> Mon, 02 June 2014 17:07 UTC

Return-Path: <david.a.zoller@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 485821A021F for <dtn-security@ietfa.amsl.com>; Mon, 2 Jun 2014 10:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 R8MOFmC6H1wm for <dtn-security@ietfa.amsl.com>; Mon, 2 Jun 2014 10:07:06 -0700 (PDT)
Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::102]) by ietfa.amsl.com (Postfix) with ESMTP id 408881A01ED for <dtn-security@irtf.org>; Mon, 2 Jun 2014 10:07:06 -0700 (PDT)
Received: from ndmsppt102.ndc.nasa.gov (ndmsppt102.ndc.nasa.gov [198.117.0.67]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 728ECA80B2; Mon, 2 Jun 2014 12:07:00 -0500 (CDT)
Received: from NDMSCHT116.ndc.nasa.gov (ndmscht116-pub.ndc.nasa.gov [198.117.0.216]) by ndmsppt102.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s52H70q9031876; Mon, 2 Jun 2014 12:07:00 -0500
Received: from NDMSMBX404.ndc.nasa.gov ([169.254.4.107]) by NDMSCHT116.ndc.nasa.gov ([198.117.0.216]) with mapi id 14.03.0174.001; Mon, 2 Jun 2014 12:07:00 -0500
From: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" <david.a.zoller@nasa.gov>
To: "Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]" <scott.c.burleigh@jpl.nasa.gov>, "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>, "dtn-security@irtf.org" <dtn-security@irtf.org>
Thread-Topic: Updated SBSP Document - BAB
Thread-Index: Ac9+bH1OvS/DGr4rQCGazJjgMCXvZg==
Date: Mon, 2 Jun 2014 17:06:59 +0000
Message-ID: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E29@NDMSMBX404.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [198.119.225.34]
Content-Type: multipart/alternative; boundary="_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E29NDMSMBX404ndcnasa_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-02_02:2014-06-02,2014-06-02,1970-01-01 signatures=0
Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/r7WsStYzWxTC8_H3qq3ZnESj32s
Subject: Re: [dtn-security] Updated SBSP Document - BAB
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 17:07:11 -0000

<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
<SB>

Ø  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.

<AA>
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.

<SB>
>>           I see what you're saying, and I think it goes to the lament in your next comment: the interaction between fragmentation and BSP really is a mess.  But I thought SBSP simplified things somewhat by not allowing any non-security-aware nodes between the BAB source and BAB destination.  At least, that's what I hoped we were doing, and it's how I interpret "BABs operate between topologically adjacent nodes" on page 6.  If that's not the case then I think there are additional problems to resolve.

<KS>
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).

<SB>

Ø 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.


<DZ>
Having outgoing email issues so some of this is now late and could be later by the time it gets through - if it gets there.

o   This is true when all traversed nodes are SBSP compliant and we probably do not want to overly complicate SBSP trying to anticipate and handle all possible off-nominal scenarios. One of the off-nominal scenarios that I would not be surprised to see with the Space Station is the case where our gateway nodes are running pre-SBSP software and a payload developer installs a cutting edge SBSP implementation. In this scenario, if the payload node applies a BAB to a large bundle [or fragment] then there is the possibility that the pre-SBSP gateway node will fragment [or further fragment] the bundle and not remove the BAB resulting in its misinterpretation when it makes to the end node that is SBSP compliant.

o   I am okay with not specifically handling this scenario as we can recommend not using the BAB until the gateway nodes are updated to SBSP compliance or that their local policy set the 'Discard block if it can't be processed' flag on the BAB.

§  Amy mentioned the DO_NOT_FRAGMENT" flag as another possible option before I could send this reply due to system and email issues (and maybe I am a slow typist)...

·         What happens if there is a conflict between DO_NOT_FRAGMENT and "must fragment if bigger than x"? Is the bundle sent whole, trapped, or deleted?

§  And now - the suggested BIBE is another good approach

o   If this particular scenario might impact other folks as well and the consensus is to handle it then a refinement would be to use the <block type> to hold the fragment offset so that a further fragmented fragment could be more reliably reconstituted and BAB verified. I "think" this would make the BAB "SBSP_hop - to - SBSP_hop" regardless of the compliance of any intervening nodes.