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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 02 August 2012 16:15 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 DB3D821E8041 for <dtn-security@ietfa.amsl.com>; Thu, 2 Aug 2012 09:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level:
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 s9+Wl4J1iIyD for <dtn-security@ietfa.amsl.com>; Thu, 2 Aug 2012 09:15:40 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4FE21F84AF for <dtn-security@irtf.org>; Thu, 2 Aug 2012 09:15:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D7795171477; Thu, 2 Aug 2012 17:15:39 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1343924139; bh=nZcuAEQPg+/Rbg CZT7C+VJyhERS4z3I/z/o9NMS5GNo=; b=CvMm5vAYtKi1aIVzyMRw78segQCnlb bJZpFU5jHqz831G6eLFrfGgy0wYOAARId9tZWovawJlAsrvKMrihNNExrJRLhN2Q yNdaxnNRDcJIu3uqJjjdXsYWZUEkdsiIk4hgQzX2L9E8LF13+cT1/UNNnBlj1YIx vlIyBXYbZSW0QE0DlSnXTowG0wiRpwOZs1Cn9cGmYMKGVG9VMeWU+uaCZsznZ1+i yjCNcziR3msTZEDJekCL00S2YV9ANqnn8P92He72TkTgwu+utrFyd1y3bkiD6adF KR7paNnvm6f2K5DQMoio9I9rj25l9zd0AREZwBIRLh3lb6gYuTEsXiUw==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id NkqPV+fjMp2c; Thu, 2 Aug 2012 17:15:39 +0100 (IST)
Received: from [IPv6:2001:df8:0:96:8853:ef9b:1b62:6a9b] (unknown [IPv6:2001:df8:0:96:8853:ef9b:1b62:6a9b]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 199BA17147A; Thu, 2 Aug 2012 17:15:34 +0100 (IST)
Message-ID: <501AA7A4.4040608@cs.tcd.ie>
Date: Thu, 02 Aug 2012 17:15:32 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: ahennes1@math.umd.edu
References: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu>
In-Reply-To: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: dtnbsp@gmail.com, dtn-security@irtf.org
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 16:15:42 -0000

Hi Angela,

On 08/02/2012 04:52 PM, 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.

Did you have a solution in mind? Since I'm at the IETF meeting I won't
have time this week to look into it, sorry. If you bug me next week,
I will:-)

S.


> 
> 
> 
> thanks,
> Angela
> 
> 
> Angela Hennessy
> Laboratory for Telecommunication Sciences (LTS)
> 
>