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

"Scott, Keith L." <kscott@mitre.org> Tue, 03 June 2014 20:03 UTC

Return-Path: <kscott@mitre.org>
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 590DB1A02F0 for <dtn-security@ietfa.amsl.com>; Tue, 3 Jun 2014 13:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.25
X-Spam-Level:
X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, 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 Vz7MPrb7WLJ6 for <dtn-security@ietfa.amsl.com>; Tue, 3 Jun 2014 13:03:08 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 160CF1A035B for <dtn-security@irtf.org>; Tue, 3 Jun 2014 13:03:08 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4CD701F04E1; Tue, 3 Jun 2014 16:03:02 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3170D1F0361; Tue, 3 Jun 2014 16:03:02 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.73]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 16:03:01 -0400
From: "Scott, Keith L." <kscott@mitre.org>
To: "Burleigh, Scott C (312G)" <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/DGr4rQCGazJjgMCXvZgA7MfsQAAI18LAAAJ4NUA==
Date: Tue, 3 Jun 2014 20:03:01 +0000
Message-ID: <5EE81C5C4CFFF4418C5EAD12F49D64EE4C222364@IMCMBX01.MITRE.ORG>
References: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E29@NDMSMBX404.ndc.nasa.gov> <329D879C76FDD04AAAE84BB1D89B3970094FBFAAC8@aplesfreedom.dom1.jhuapl.edu> <A5BEAD028815CB40A32A5669CF737C3B423B6637@ap-embx-sp40.RES.AD.JPL>
In-Reply-To: <A5BEAD028815CB40A32A5669CF737C3B423B6637@ap-embx-sp40.RES.AD.JPL>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.140.19.249]
Content-Type: multipart/alternative; boundary="_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C222364IMCMBX01MITREOR_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/XzrWBtjMdzYBNFVsWWsft1vTEPs
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: Tue, 03 Jun 2014 20:03:17 -0000

I agree with Scott.  I don't think setting the don't fragment bit is a good solution as it might be used / wanted / needed for other purposes.

If the question is: "what to do when a bundle with a BAB arrives at a node that doesn't know how to process BABs" then I think we just have to decide what behavior we want (based on the bundle processing control flags):

0)    Transmit status report if block can't be processed (bpcf 0x02)

1)    Drop the bundle (bpcf 0x04)

2)    Drop the BAB, pass the bundle (bpcf 0x10)

3)    Forward the bundle WITH the BAB, noting that we didn't know what to do with it (bpcf 0x20)

Realistically I think 1) is the right answer.  BABs are supposed to protect the network from bad traffic getting in.  Once traffic is 'in' then the only thing we have protecting against things like denial-of-service attacks would be the bptables capability, and I don't think that's mature enough to be a good solution.

                        --keith

From: dtn-security [mailto:dtn-security-bounces@irtf.org] On Behalf Of Burleigh, Scott C (312G)
Sent: Tuesday, June 03, 2014 3:38 PM
To: Birrane, Edward J.; dtn-security@irtf.org
Subject: Re: [dtn-security] Updated SBSP Document - BAB

Ed, I like (A) but I think there's a possible problem.  Because the flag was set to protect the BAB operation, it really ought to be re-set to its original value upon reception by the next BAB-aware node.  But we don't have any way of knowing what value to reset it to - that is, the flag might have already been set by another node for some other reason (in which case it shouldn't be set to zero now), or it might not have been (in which case it should).

How about instead always setting the "Delete bundle if block can't be processed" flag in the BAB, to drive out the network misconfigurations?

Scott

From: dtn-security [mailto:dtn-security-bounces@irtf.org] On Behalf Of Birrane, Edward J.
Sent: Tuesday, June 03, 2014 12:24 PM
To: dtn-security@irtf.org<mailto:dtn-security@irtf.org>
Subject: Re: [dtn-security] Updated SBSP Document - BAB

Dave,

  Thank you for fragmenting the discussion into separate threads; it is much easier to parse this way.

I recommend the following:

- It is the intention that when adding a BAB, the next BP hop for the bundle is a security-aware node, but this cannot be guaranteed (e.g., there may be a misconfiguration in the network). The language in the spec should be updated to reflect this.

We should do one (not both) of the following:

A: When adding a BAB to a bundle, ensure that the bundle's "Bundle must not be fragmented" field is set. This will result in a delivery failure if the next BP-hop is unable to deliver the bundle as-is, but also ensures there is no payload surgery between BP-hops that require BAB authentication.

B: Use the content range for the ciphersuite parameters to identify the offset,length of the bundle being protected. Then, require BPAs to wait until all fragments of a bundle are received, and then do the authentication check.

My preference is to do "A". It is simple and strict when requiring authentication, as should be the case with authentication.

My concern regarding approach "B" is that we have to use up memory and other resources for partial bundles. Part of the job of authentication is to prevent some types of resource attacks on the network, and "B" seems to re-enable some of those attacks.

-Ed

---
Ed Birrane
Principal Professional Staff, Space Department
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839


From: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] [mailto:david.a.zoller@nasa.gov]
Sent: Monday, June 02, 2014 1:07 PM
To: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane, Edward J.; dtn-security@irtf.org<mailto:dtn-security@irtf.org>
Subject: RE: Updated SBSP Document - BAB

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