Re: [dtn-security] Issue implementing security source/destination with ESB blocks

"Peter Lovell" <dtnbsp@gmail.com> Thu, 02 August 2012 21:36 UTC

Return-Path: <dtnbsp@gmail.com>
X-Original-To: dtn-security@ietfa.amsl.com
Delivered-To: dtn-security@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB3121F8A1A for <dtn-security@ietfa.amsl.com>; Thu, 2 Aug 2012 14:36:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level:
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtWoubioNx3L for <dtn-security@ietfa.amsl.com>; Thu, 2 Aug 2012 14:36:53 -0700 (PDT)
Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id F0ED521F8A19 for <dtn-security@irtf.org>; Thu, 2 Aug 2012 14:36:52 -0700 (PDT)
Received: by qcsg15 with SMTP id g15so4098qcs.13 for <dtn-security@irtf.org>; Thu, 02 Aug 2012 14:36:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=m37qIU82MoOvg2DxEpbkk49wpoAJ7C0+p4h0cgMBYno=; b=UQHsUf6lNit53XT/lb6DJK7K5GWEro4ogAxM5SvzeUkEj+dj0UBXJW9H1GMUfpPY7M 6aoPVwN+ejDr73hyqZY8+s6pv+QJbgl5olyeMRJHTR1fyXZlT7l/QHPzGg/qbhhfc3VC BhbULNHKpkuwlPmjThJJu/ikLoROZKL/jAMB4V+oh+ybLYAqqCU2qCnuRMK3qAFevAn6 rKTOFAIOrL5yBOqeRx2z86m6qIGdwmMrp7Dw3IBF+kDuWd58HosXcaTqXAiVDGhms0LI QnDB6BfcivfUbGgSGlgReJlpeyBaGKbkpIXhUCRGL1HQzRyVoij+cn87zzBW0lwdK8kd tfFA==
Received: by 10.229.137.148 with SMTP id w20mr11779390qct.155.1343943412354; Thu, 02 Aug 2012 14:36:52 -0700 (PDT)
Received: from [192.168.1.98] (pool-96-255-127-40.washdc.fios.verizon.net. [96.255.127.40]) by mx.google.com with ESMTPS id dr6sm5855924qab.16.2012.08.02.14.36.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 14:36:51 -0700 (PDT)
From: "Peter Lovell" <dtnbsp@gmail.com>
To: <ahennes1@math.umd.edu>, <dtn-security@irtf.org>, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
Date: Thu, 2 Aug 2012 17:36:48 -0400
Message-Id: <20120802213648.1651877815@smtp.gmail.com>
In-Reply-To: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu>
References: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu>
X-Mailer: CTM PowerMail version 6.1.1b2 build 4649 English (intel) <http://www.ctmdev.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 06 Aug 2012 16:48:45 -0700
Subject: Re: [dtn-security] Issue implementing security source/destination with ESB blocks
X-BeenThere: dtn-security@irtf.org
X-Mailman-Version: 2.1.12
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: Thu, 02 Aug 2012 21:36:53 -0000

On Thu, Aug 2, 2012, ahennes1@math.umd.edu <ahennes1@math.umd.edu> wrote:

>We've run into a problem while implementing the security source and
>destination in the ESB blocks.  When ESB encapsulates a block, the BSP RFC
>states that the eid ref list of the encapsulated block should be used as
>the eid ref list of the encapsulating block, as in PCB.  However, the eid
>ref list of the encapsulating block also needs to store the security
>source and destination. We aren't sure if the eid ref list of the
>encapsulated block should be appended to the eid ref list of the
>encapsulating block.  The RFC states that an Abstract Security Block
>should have at most 2 eid references, and this would contradict that
>statement.
>
>We get around this problem with PCB because the first PCB block's eid ref
>list stores the security source and destination, and an extra PCB block is
>added for any encapsulated blocks (and this extra PCB block contains the
>eid ref list of the encapsulated block).  With ESB, there is a one-to-one
>correspondence between the 'replacing' ESB block and the block to be
>encapsulated, so we do not have an extra block as in PCB.
>
>
>
>thanks,
>Angela
>
>
>Angela Hennessy
>Laboratory for Telecommunication Sciences (LTS)


Hi Angela,

you're right - this is an issue that is not addressed in the spec. Some of the ESB language was taken from that for PCB, which it closely resembles, but this is an edge case not foreseen. 

There can be only two EIDs in the list because there are only two flags to indicate their presence. The list is not length-counted for total size so one can't skip over it. 

However, an EID list is specific to security blocks and doesn't occur in other block types. 

ESBs and other security blocks are in separate spaces, i.e. an ESB must never encapsulate PIBs or PCBs, and vice-versa. 

So the issue you describe can only occur in the super-encapsulation of ESBs. For now, I'm not sure how best to deal with it, but my initial thought is to use the previous EID list as the starting EID list, and then push security-source and security-dest on the front, if needed and as appropriate. The problem is how to indicate that there are other EIDs because, if we do not, the processing of the block will fail. This will require some change to the header and that will be a slow and deliberate process.

In the meantime, let me suggest that you encapsulate the block and reconstitute it at the security-dest without special EID processing. THat means that any EID-munging between source and dest will be ineffective but I suspect that it isn't common anyway [please correct me if that's wrong].

The alternative is to avoid super-encryption of ESBs.

Regards.....Peter