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

[[e-mail]]

Hi Peter,

I don't think that item 2 applies to PCB. In ESB, there is a one-to-one
replacement of extension blocks with ESB blocks. In PCB, there's a "first"
PCB that contains the ciphersuite ID, parameters and the security src/dest
(if present):

   Put another way: when confidentiality will generate multiple blocks,
   it MUST create a "first" PCB with the required ciphersuite ID,
   parameters, etc., as specified above.  Typically, this PCB will
   appear early in the bundle.  This "first" PCB contains the parameters
   that apply to the payload and also to the other correlated PCBs.  The
   correlated PCBs follow the "first" PCB and MUST NOT repeat the
   ciphersuite-parameters, security-source, or security-destination
   fields from the first PCB.

Then this correlated PCB that encapsulates a PIB or PCB will copy the
eid-list from the encapsulated block. I think the eid-list from the PIB or
PCB will only contain the security src/dest of that block, so the new
encapsulating PCB will also have at most 2 eid-refs.


Thanks,
Angela




> Hi Angela,
>
> Item 1 is fine
>
> For item 2, the exception applies to both ESB and PCB. A PCB that
> encapsulates a block that already has an EID-list, such as PIB or PCB, may
> have a long list, just as ESB may. Your comments on items 3 and 4 also
> need revisiting in this light - I think that their treatment will be the
> same.
>
> I can draft some language for item 3 if you like. I would probably
> describe it as copying the EID-list to the new block and then prepending
> sec-src and sec-dest if necessary.
>
> Regards.....Peter
>
>
> On Mon, Aug 6, 2012, [e-mail] <[e-mail]> wrote:
>
>>All,
>>
>>I'm trying to summarize the issues with RFC6257 for an errata list. How
>>does this sound:
>>
>>1. In Section 2.1, in the description of the EID-references, it should
>>mention that the EID-refs are preceded by a count field.
>>
>>2. Also in Section 2.1, it states that there can be at most 2 eid refs in
>>an Abstract Security Block. An exception should be added for ESB, which
>>can have an arbitrary number of eid refs based on the number in the
>>original extension block and how many times it has been encapsulated.
>>
>>3. In Section 2.5, in the discussion of ESB, there needs to be some
>>language describing how the eid-ref list in the encapsulated block is
>>appended to the (optional) security src/dest of the encapsulating ESB. As
>>a result, the eid-ref list in the ESB may be of arbitrary length. Also in
>>Section 2.5, the statement that eid list entries should be handled
>>analogously to PCB should be removed (along with the reference to Section
>>2.4).
>>
>>4. In Section 4.4, in the description of ESB-RSA-AES128-EXT, the
>> statement
>>that eid list entries should be handled analogously to PCB should be
>>removed (along with the reference to Section 2.4).
>>
>>
>>Thanks,
>>Angela
>>
>
>