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

[Peter Lovell <[e-mail]>]

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
>