[dtn-security] Re: Bundle Security Protocol: one more item

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sat, 18 November 2006 17:37 UTC

Received: from imx2.tcd.ie (wpad.iss.tcd.ie []) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id kAIHb9Y28287 for <dtn-security@mailman.dtnrg.org>; Sat, 18 Nov 2006 09:37:09 -0800
Received: from Vams.imx2 (imx2.tcd.ie []) by imx2.tcd.ie (Postfix) with SMTP id 9D3A7682F6; Sat, 18 Nov 2006 17:37:03 +0000 (GMT)
Received: from imx2.tcd.ie ([]) by imx2.tcd.ie ([]) with SMTP (gateway) id A0483B9068F; Sat, 18 Nov 2006 17:37:03 +0000
Received: from [] (csvpn.cs.tcd.ie []) by imx2.tcd.ie (Postfix) with ESMTP id 3D41A682F6; Sat, 18 Nov 2006 17:37:03 +0000 (GMT)
Message-ID: <455F44F5.8050808@cs.tcd.ie>
Date: Sat, 18 Nov 2006 17:37:57 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird (Windows/20061025)
MIME-Version: 1.0
To: Peter Lovell <peter.lovell@sparta.com>
Cc: Susan <susan@mitre.org>, Howard Weiss <howard.weiss@sparta.com>, dtn-security@mailman.dtnrg.org
References: <455DABC2.6050200@cs.tcd.ie> <8E507634779E22488719233DB3DF9FF0012296F0@IMCSRV4.MITRE.ORG> <20061118042320.974753071@>
In-Reply-To: <20061118042320.974753071@>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: MessageID = A1483B9068F
X-AntiVirus-Status: Host: imx2.tcd.ie
X-AntiVirus-Status: Action Taken:
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.56.3 VDF=8.1402)
Subject: [dtn-security] Re: Bundle Security Protocol: one more item
Sender: dtn-security-admin@mailman.dtnrg.org
Errors-To: dtn-security-admin@mailman.dtnrg.org
X-BeenThere: dtn-security@mailman.dtnrg.org
X-Mailman-Version: 2.0.13
Precedence: bulk
Reply-To: dtn-security@mailman.dtnrg.org
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=unsubscribe>
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>
List-Post: <mailto:dtn-security@mailman.dtnrg.org>
List-Help: <mailto:dtn-security-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-security/>


Those are really broader that the security spec. You should
raise these issues on dtn-interest/dtn-dev and see what
consensus emerges there. (And quickly would be good since we
want to finish the BP spec asap.)


Peter Lovell wrote:
> Hi Susan,
>> Now that I think about it, there may be more to consider with regard to
>> how this bit works in relation to the security blocks.  It is all bound
>> up in the issue of how security works if some nodes don't support it.
>> Suppose for example there are nodes 1, 2, and 3 and only nodes 1 and 3
>> implement the Bundle Security Protocol. This means that if node 1
>> inserts a BAB and forwards the bundle to node 2, and node 2 doesn't
>> understand the BAB and isn't configured to delete the BAB or delete the
>> bundle, then node 2 will forward the bundle to node 3 with this "block
>> was forwarde without being processed" bit set in the BAB. When node 3
>> receives the bundle and tries to authenticate the security result in
>> the BAB, it won't authenticate (because of this bit change). This may
>> be okay for the BAB, but it would work the same for the PSH and I'm not
>> sure that's okay.  
>> If node 1 is a PSH-source, node 2 doesn't understand the PSH and node 3
>> is a PSH-dest, then if node 2 forwards the bundle with this bit set in
>> the PSH, then I think we either have to specify that this bit must be
>> reset by a node before the node validates the security result in the
>> PSH or that this bit must be masked out so that it is omitted from the
>> mutable canonicalization form of the bundle. (same for CH I think.)
>> Assuming this is true, does anyone have a preference for whether we
>> should mandate that nodes processing the PSH reset this bit before
>> calculating the security result or whether we should just leave this
>> bit out of the mutable canoncial form?
>> Any other thoughts?
> in fact, yes :)  Two of them.
> -----
> First is that we need to better define what "processing" is. I mentioned
> this the other day in a somewhat different context (intermediate
> validation) but it certainly is a big issue here.
> Do the various block-processors define what processing is, and what is
> meant by "success" and "failure", or are these topics for the bundle spec? 
> And when the bit can be turned on here and off there and on again in yet
> a third place, what real meaning does it have??
> With regard to processing, what does it mean, for example, for a PS
> block if the current node is not the security destination? Does that
> change if the current node does in fact have sufficient information to
> verify the payload? If it does and the verification fails, does the
> current node still forward the bad bundle?
> Another example is to think of what it means to receive a bundle but not
> have the extension necessary to interpret it, and then to receive a
> bundle with a security block and have that block fail the validation
> check. The latter is clearly a "failure" but what about the former? It's
> not a success but is it a failure? If we mark it as "could not be
> processed" then might other nodes interpret that to mean it really failed.
> I'm sure we can't specify "processing" in particular detail but we
> should define how it is specified, and the various limits.
> -----
> My second issue is less closely related to your original question. The
> bundle spec at present refers to extensions but doesn't define them,
> which is OK. But there are problems which arise because, as you
> describe, a bundle may be processed differently at various nodes. Your
> 1-2-3 example in the second paragraph above is a good example.
> I believe that the base bundle specification should contain a certain
> minimum requirement with regard to extension blocks in order that
> predictable processing can happen. For example, the bundle specification
> describes extension blocks but does not specify that block types 2, 3
> and 4 are used by and reserved for the security protocol. So an
> implementation could define its own set of 2,3 and 4 and still be
> conformant with the bundle protocol. What a mess that would be.
> We need the base specification to require that extensions are
> implemented in accord with the appropriate specification. The extensions
> are optional and you can omit them and be in conformance, but you can't
> be in conformance if your implementation + extensions violates the
> various specifications. So, you don't have to do them, but you can't do
> them differently.
> Especially in the case of security, we might provide a small description
> in the base spec which defines 2, 3 and 4 and specifies what a non-
> security implementation should do if it encounters blocks of those
> types. I suggest that this specify that 2 [BA] be discarded and 3 and 4
> [PS and C] be forwarded unchanged for someone else to deal with. This
> might override the "discard" flag setting, or might not. That's an open
> question, and should be decided and specified [there are good arguments
> for and against].
> -----
> Regards.....Peter