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

Hi.

Comment in line below...

On 03/08/12 07:40, Peter Lovell wrote:
> 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.
But not that difficult since the flag fields are SDNVs - so adding extra 
flags will not break the ASB definition.

Regards,
Elwyn
>
> 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
>
>
>
> _______________________________________________
> dtn-security mailing list
> dtn-security@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-security