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

Peter Lovell <plovell@mac.com> Thu, 02 August 2012 21:40 UTC

Return-Path: <plovell@mac.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 B519A21F8976 for <dtn-security@ietfa.amsl.com>; Thu, 2 Aug 2012 14:40:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, 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 5WQZrAWXV2nz for <dtn-security@ietfa.amsl.com>; Thu, 2 Aug 2012 14:40:25 -0700 (PDT)
Received: from st11p00mm-asmtpout004.mac.com (st11p00mm-asmtpout004.mac.com [17.172.81.3]) by ietfa.amsl.com (Postfix) with ESMTP id B072A21F856D for <dtn-security@irtf.org>; Thu, 2 Aug 2012 14:40:25 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from [192.168.1.98] (pool-96-255-127-40.washdc.fios.verizon.net [96.255.127.40]) by st11p00mm-asmtp004.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M8500LHODJ5M340@st11p00mm-asmtp004.mac.com> for dtn-security@irtf.org; Thu, 02 Aug 2012 21:40:19 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-02_08:2012-08-02, 2012-08-02, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208020258
From: Peter Lovell <plovell@mac.com>
To: ahennes1@math.umd.edu, dtn-security@irtf.org, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Thu, 02 Aug 2012 17:40:16 -0400
Message-id: <20120802214016.1861780438@smtp.mail.me.com>
X-Mailer: CTM PowerMail version 6.1.1b2 build 4649 English (intel) <http://www.ctmdev.com>
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:40:26 -0000

re-send for list members as my origib=nal one bounced :(
I guess I need to revise my addresses

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