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

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
>