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

ahennes1@math.umd.edu Thu, 02 August 2012 18:31 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 4FA0711E8229 for <dtn-security@ietfa.amsl.com>; Thu, 2 Aug 2012 11:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level:
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 jMVRU7THvpLs for <dtn-security@ietfa.amsl.com>; Thu, 2 Aug 2012 11:31:03 -0700 (PDT)
Received: from mailfilter.ece.umd.edu (mailfilter.ece.umd.edu [129.2.90.4]) by ietfa.amsl.com (Postfix) with ESMTP id 43B9B11E8209 for <dtn-security@irtf.org>; Thu, 2 Aug 2012 11:31:03 -0700 (PDT)
X-ASG-Debug-ID: 1343932260-04739d104c31f570001-NoPDhg
Received: from svr4.math.umd.edu ([129.2.56.14]) by mailfilter.ece.umd.edu with ESMTP id Q3G6pEoCXVfYgfzL; Thu, 02 Aug 2012 14:31:00 -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 9415E6FC83; Thu, 2 Aug 2012 14:31:00 -0400 (EDT)
Received: from 65.127.220.136 by webmail.math.umd.edu with HTTP; Thu, 2 Aug 2012 14:31:00 -0400
Message-ID: <b62550272163423b21d8db2b75a758e1.squirrel@webmail.math.umd.edu>
In-Reply-To: <329D879C76FDD04AAAE84BB1D89B397006842FE0CA@aplesfreedom.dom1.jhuapl.edu>
References: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu> <501AA7A4.4040608@cs.tcd.ie> <614d049ab50809bfdb47ebf4934ae42a.squirrel@webmail.math.umd.edu> <329D879C76FDD04AAAE84BB1D89B397006842FE0B6@aplesfreedom.dom1.jhuapl.edu> <329D879C76FDD04AAAE84BB1D89B397006842FE0CA@aplesfreedom.dom1.jhuapl.edu>
Date: Thu, 2 Aug 2012 14:31:00 -0400
From: ahennes1@math.umd.edu
X-ASG-Orig-Subj: RE: [dtn-security] Issue implementing security source/destination with ESB blocks
To: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>
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: 1343932260
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.104489 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" <dtnbsp@gmail.com>, "dtn-security@irtf.org" <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 18:31:04 -0000

Hi Ed,

Thanks for the quick reply! I think you're right that we'll need some
extra flags to cover these cases. I can't think of any other way to handle
this, but we're definitely open to other ideas.


Thanks,
Angela

> Drat, let me retract that recommendation, since it would result in secsrc
> and secdst perhaps not in the EID list and, therefore, make downstream
> dictionary pruning problematic.
>
> Given that we must potentially represent secsrc and/or secdst to the EID
> list,  I think we would need some mechanism to ensure that:
>
> 1. The secsrc and secdst are only added when they are known/supplied.
> (they are both optional)
> 2. You can have one but not the other
> 3. The ESB security parameters let you know whether the EIDs need to be
> copied back to the originating encapsulated EID list or not.
>
> I think adding some flags in the security parameters can cover these
> cases.  Is there a better way to handle this?
>
> -Ed
>
> ---
> Ed Birrane
> Senior Professional Staff, Space Department
> Johns Hopkins Applied Physics Laboratory
> (W) 443-778-7423 / (F) 443-228-3839
>
>
>> -----Original Message-----
>> From: dtn-security-bounces@irtf.org
>> [mailto:dtn-security-bounces@irtf.org]
>> On Behalf Of Birrane, Edward J.
>> Sent: Thursday, August 02, 2012 12:55 PM
>> To: ahennes1@math.umd.edu; Stephen Farrell
>> Cc: dtnbsp@gmail.com; dtn-security@irtf.org
>> Subject: Re: [dtn-security] Issue implementing security
>> source/destination
>> with ESB blocks
>>
>> Angela,
>>
>>   Nice catch.  Just spent a few minutes refreshing myself on 5050 and
>> 6257
>> and agree that this is a rather problematic contradiction in the RFC.
>>
>>   I understand the need to not change the EID list, as stitching
>> together the
>> updated EID list with the originally encapsulated EID list is tricky
>> enough at
>> the security destination without changing the order of things.
>>
>>   There are times when the security destination is omitted for some
>> reason
>> (i.e., it is the same as the bundle destination), or the security source
>> is
>> omitted (i.e. an anonymous bundle using a default group key, or the
>> security
>> source is the same as the bundle source).  So, guaranteeing that the 1st
>> two
>> items of the ESB EID list will be the secsrc and srcdst may not be
>> desirable for
>> all users.
>>
>>   I would recommend changing the language of 6257 to place security and
>> destination EIDs, when present, in the security parameters (Section 2.6)
>> and
>> avoid any surgery/dependency on the EID list itself.
>>
>> -Ed
>>
>> ---
>> Ed Birrane
>> Senior Professional Staff, Space Department Johns Hopkins Applied
>> Physics
>> Laboratory
>> (W) 443-778-7423 / (F) 443-228-3839
>>
>>
>> > -----Original Message-----
>> > From: dtn-security-bounces@irtf.org
>> > [mailto:dtn-security-bounces@irtf.org]
>> > On Behalf Of ahennes1@math.umd.edu
>> > Sent: Thursday, August 02, 2012 12:39 PM
>> > To: Stephen Farrell
>> > Cc: dtnbsp@gmail.com; dtn-security@irtf.org
>> > Subject: Re: [dtn-security] Issue implementing security
>> > source/destination with ESB blocks
>> >
>> > 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)
>> > >>
>> > >>
>> > >
>> >
>> > _______________________________________________
>> > dtn-security mailing list
>> > dtn-security@irtf.org
>> > https://www.irtf.org/mailman/listinfo/dtn-security
>> _______________________________________________
>> dtn-security mailing list
>> dtn-security@irtf.org
>> https://www.irtf.org/mailman/listinfo/dtn-security
>