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

ahennes1@math.umd.edu Thu, 02 August 2012 16:38 UTC

Return-Path: <ahennes1@math.umd.edu>
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 92C9511E8107 for <dtn-security@ietfa.amsl.com>; Thu, 2 Aug 2012 09:38:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.299
X-Spam-Level:
X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 HdxcQjNIXcYG for <dtn-security@ietfa.amsl.com>; Thu, 2 Aug 2012 09:38:52 -0700 (PDT)
Received: from mailfilter.ece.umd.edu (mailfilter.ece.umd.edu [129.2.90.4]) by ietfa.amsl.com (Postfix) with ESMTP id CB45E11E80FA for <dtn-security@irtf.org>; Thu, 2 Aug 2012 09:38:51 -0700 (PDT)
X-ASG-Debug-ID: 1343925529-04739d104c316df0001-NoPDhg
Received: from svr4.math.umd.edu ([129.2.56.14]) by mailfilter.ece.umd.edu with ESMTP id wEmfpqciOE1h11dj; Thu, 02 Aug 2012 12:38:49 -0400 (EDT)
X-Barracuda-Envelope-From: ahennes1@math.umd.edu
X-Barracuda-Apparent-Source-IP: 129.2.56.14
Received: by svr4.math.umd.edu (Postfix, from userid 48) id 9414A6FC83; Thu, 2 Aug 2012 12:38:49 -0400 (EDT)
Received: from 65.127.220.136 by webmail.math.umd.edu with HTTP; Thu, 2 Aug 2012 12:38:49 -0400
Message-ID: <614d049ab50809bfdb47ebf4934ae42a.squirrel@webmail.math.umd.edu>
In-Reply-To: <501AA7A4.4040608@cs.tcd.ie>
References: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu> <501AA7A4.4040608@cs.tcd.ie>
Date: Thu, 2 Aug 2012 12:38:49 -0400
From: ahennes1@math.umd.edu
X-ASG-Orig-Subj: Re: Issue implementing security source/destination with ESB blocks
To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
User-Agent: SquirrelMail/1.4.20
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Barracuda-Connect: UNKNOWN[129.2.56.14]
X-Barracuda-Start-Time: 1343925529
X-Barracuda-URL: http://mailfilter.ece.umd.edu:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at ece.umd.edu
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=7.0 KILL_LEVEL=1000.0 tests=BSF_SC0_MISMATCH_TO, NO_REAL_NAME
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.104483 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header
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:38:52 -0000

Hi Stephen,

We were thinking the best solution might be to append the eid ref list of
the encapsulated block to the eid ref list of the ESB block (which would
contain the security src and dest). This would mean there might be 4 eid
references in this list, but this seems better than the alternative
solution, which would be to add an extra ESB block (as is done in PCB).

If there are other proposed solutions to this, we'd definitely be
interested in hearing them.


Thanks,
Angela

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