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

Peter,

  > However, an EID list is specific to security blocks and doesn't occur in other block types.

 Non-security extension blocks may have EID references and RFC6257 has language that associates non-security-block EID references to security-block EID references.

  So, if I have a non-security extension block with 10 EID references in it, what happens when I try to encapsulate it in an ESB? 

  If the ESB EID Reference list does *not* represent those 10 EIDs, they could be deleted from the dictionary (see RFC5050 Section 4.7 "Dictionary Revision").  That would cause some pain when we unpack the extension block at the security destination.

-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 Peter Lovell
> Sent: Thursday, August 02, 2012 5:40 PM
> To: ahennes1@math.umd.edu; dtn-security@irtf.org; Stephen Farrell
> Subject: Re: [dtn-security] Issue implementing security source/destination
> with ESB blocks
> 
> 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.
> 
> 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