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

From: Peter Lovell <[email-masked]>
Date: Thu, 02 Aug 2012 17:40:16 -0400

re-send for list members as my origib=nal one bounced :(
I guess I need to revise my addresses

On Thu, Aug 2, 2012, [email-masked] <[email-masked]> 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

---

From: "Birrane, Edward J." <[email-masked]>
Date: Thu, 2 Aug 2012 19:10:37 -0400

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: [email-masked] [mailto:[email-masked]]
> On Behalf Of Peter Lovell
> Sent: Thursday, August 02, 2012 5:40 PM
> To: [email-masked]; [email-masked]; 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
> 
> >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
> 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.
> 
> 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].
> 
> _______________________________________________
> dtn-security mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-security

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 03 Aug 2012 12:45:03 +1000

Hi.

Comment in line below...

On 03/08/12 07:40, Peter Lovell wrote:
> On Thu, Aug 2, 2012, [email-masked]<[email-masked]>  wrote:
>
But not that difficult since the flag fields are SDNVs - so adding extra 
flags will not break the ASB definition.

Regards,
Elwyn

---

From: "Birrane, Edward J." <[email-masked]>
Date: Fri, 3 Aug 2012 16:07:07 -0400

Angela and I had some off-line e-mails to synchronize on our understanding of the issue.  I believe the following capture the needed behavior for ESBs:

 1. The EID reference list of an ESB *must* be the union of all EID references of all blocks encapsulated by the ESB.

 2. Because the EID reference list has variable size, we must place a count in front. (a-la RFC5050 canonical spec)

 3. We may add a secsrc and secdst to the encapsulating EID reference list IFF they are available and not already represented in the EID  list

 4. The EID ref count (added in #2 above) can therefore be increased by a max. value of 2 on each encapsulation.

 5. At a security destination, any EIDs added from #3 above to the encapsulating EID list must be removed and any changes made in-situ to the encapsulating EID list must be propagated back to the encapsulated EID list.

 6. Ciphersuite parameters in the ESB give some level of disposition as to the what/how of the security source and security destination in the encapsulating EID list. The mechanism for this is TBD.

Are there any disagreements with any of the above?

-Ed

---
Ed Birrane

> On Behalf Of Elwyn Davies
> Sent: Thursday, August 02, 2012 10:45 PM
> To: Peter Lovell
> Cc: [email-masked]; [email-masked]
> > re-send for list members as my origib=nal one bounced :( I guess I
> > need to revise my addresses
> >
> > On Thu, Aug 2, 2012,
> [email-masked]<[email-masked]>  wrote:
> >
> >> 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.
> >> 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
> > 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
> >

---

From: Peter Lovell <[email-masked]>
Date: Fri, 03 Aug 2012 18:17:01 -0400

Hi all,

Ed is is quite correct that non-security blocks can have an EID list. I'd been looking too closely at RFC6257 and not at 5050. And as I was checking today I noticed an omission in 6257. Do we have an errata list for it? If not, we need one.

The omission is in Section 2.1 describing EID-references. It does not mention that the EID-refs are preceded by a count field, although it does rather cryptically say that "a count field of zero is not permitted". Lao, in the discussion that follows, it says that there can be two EIDs at most, which is incorrect. These errors probably came about because the EID-reference-list things were developed mostly with the BSP discussion rather than the design of the Bundle Protocol, and when we changed it for inclusion in BP, I didn't edit BSP hard enough.

Now, back to the main issue at hand. Ciphersuite PC3 does use the notion of carrying forward an existing EID-list, and adding one or two new EID-refs to the front of the list. I'm rusty on this code - not have dealt with it for several years - but it seems to me that the sec-src and sec-dest EIDs would be added  at the end of the list rather than the front, and that obviously needs correcting. The code in "validate" seems to decrypt and reconstitute the encapsulated block correctly. As you mention, an encapsulated block wouldn't have either of these which is why it never showed up before.

The general scheme is  ...
1. create an empty working block
2. copy necessary things from the existing block into the new one,
   especially the EID list
3. if there's a security-dest, push it on the front of the list
4. if there's a security-src, push it on the front of the list
5. get keys etc and encrypt the entire original block, encapsulating it
   in the security-result field of the new block
6. replace the existing block with the working copy (care needed here with
   locals as things such as block-type may have changed)

At the receiving end, the process is a reverse of the sending one,
in general ...
7. create an empty working block
8. process the incoming block info, extract keys and decrypt the block
9. assemble the new block from the pieces in the decrypted block
10. in particular, you have to get the EID list of the incoming block
    and step over EIDs for security-src and/or security-dest, if present.
    Then you copy the rest of the list (count plus EID-refs) from the
    incoming block onto the EID-list in the working block. Conceptually,
    this is popping them off the front of the list and copying the remainder.
11. copy the rest of the block, and update locals as necessary for block-type
    change etc

The PC3 code does most of this so it should serve as a reasonable guide, with the correction I mentioned.

Regards.....Peter

On Fri, Aug 3, 2012, Birrane, Edward J. <[email-masked]> wrote:

>Angela and I had some off-line e-mails to synchronize on our
>understanding of the issue.  I believe the following capture the needed
>behavior for ESBs:
>
> 1. The EID reference list of an ESB *must* be the union of all EID
>references of all blocks encapsulated by the ESB.
>
> 2. Because the EID reference list has variable size, we must place a
>count in front. (a-la RFC5050 canonical spec)
>
> 3. We may add a secsrc and secdst to the encapsulating EID reference
>list IFF they are available and not already represented in the EID  list
>
> 5. At a security destination, any EIDs added from #3 above to the
>encapsulating EID list must be removed and any changes made in-situ to
>the encapsulating EID list must be propagated back to the encapsulated
>EID list.
>
> 6. Ciphersuite parameters in the ESB give some level of disposition as
>to the what/how of the security source and security destination in the
>encapsulating EID list. The mechanism for this is TBD.
>
>> > However, an EID list is specific to security blocks and doesn't
>occur in other
>> block types.
>> >

---

From: [email-masked]
Date: Mon, 6 Aug 2012 11:51:17 -0400

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

---

From: Peter Lovell <[email-masked]>
Date: Mon, 06 Aug 2012 12:20:08 -0400

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

---

From: [email-masked]
Date: Mon, 6 Aug 2012 16:12:41 -0400

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
>
>

---

From: Peter Lovell <[email-masked]>
Date: Tue, 07 Aug 2012 12:13:03 -0400

Hi Angela,

you're correct in that item 2 doesn't apply to PC3.

However it might be too strong to say that it doesn't apply to any, as-yet-undesigned, PC ciphersuite. Right now, the only EIDs defined are for sec-src and sec-dest but I can imagine ciphersuites that might have additional ones.

I think that the description for PC3 should be quite specific, but that the general description for PI and PC ciphersuites should be permissive.

Regards.....Peter

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Aug 2012 17:26:46 +0100

Hi,

Sorry I've not been reading this since I was running around
madly IETFing last week;-)

I'd say best is if maybe Pete and Angela could draft an
erratum and post that here. We can stick into the system
once folks have had a few days to consider it. Probably also
worth a mention on dtn-interest at that point too since
that list has more people on it than this.

Once approved, it'll show up on the tools page for the RFC.
The RG chairs can approve errata like this.

Cheers,
S.

---

From: Peter Lovell <[email-masked]>
Date: Tue, 07 Aug 2012 12:28:39 -0400

Sounds like a plan …

Cheers…..Peter

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 7 Aug 2012 12:56:15 -0400

All,

  If, when writing the errata list, a proposed solution for surgery on the EID list is proposed, I would ask that you consider the following.

  If the existing EID list from the encapsulated block *already* contains the security source, security destination, or both (but not at the front of the EID-list) then I recommend we not repeat the security source and/or destination in the encapsulating block by prepending them.

  I would recommend flags and EID-list indices in the ciphersuite parameters rather than repetition or EID-list re-ordering.

-Ed

---
Ed Birrane

> From: Peter Lovell [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2012 12:29 PM
> To: Stephen Farrell
> Cc: [email-masked]; [email-masked]; Corbett, Cherita L.;
> Birrane, Edward J.; Elwyn Davies; [email-masked]
> Sounds like a plan ...
> Cheers.....Peter
> > Sorry I've not been reading this since I was running around madly
> > IETFing last week;-)
> >
> > I'd say best is if maybe Pete and Angela could draft an erratum and
> > post that here. We can stick into the system once folks have had a few
> > days to consider it. Probably also worth a mention on dtn-interest at
> > that point too since that list has more people on it than this.
> >
> >> However it might be too strong to say that it doesn't apply to any, as-yet-
> undesigned, PC ciphersuite. Right now, the only EIDs defined are for sec-src
> and sec-dest but I can imagine ciphersuites that might have additional ones.
> >>
> >> I think that the description for PC3 should be quite specific, but that the
> general description for PI and PC ciphersuites should be permissive.
> >>
> >> Regards.....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
> >>>>
> >>>> 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.
> >>>>
> >>>> describe it as copying the EID-list to the new block and then
> >>>> prepending sec-src and sec-dest if necessary.
> >>>>
> >>>> Regards.....Peter
> >>>>
> >>>>
> >>>>> 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
> >>>>> 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
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Aug 2012 18:36:43 +0100

Just in case it wasn't clear: I'd like if we had consensus
on the text of the erratum on this list before we post it
to the RFC editor site. If we have a huge row about that
first, then so be it, but I'd hope that won't be needed:-)

Anyway, if Pete/Angela can craft text we can thrash it
as needed.

S

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 7 Aug 2012 15:03:40 -0400

Sorry, didn't mean to be fussy. But since it is a niche case that I am interested in, I wanted to toss it out there early.

-Ed

---
Ed Birrane

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2012 1:37 PM
> To: Birrane, Edward J.
> Cc: Peter Lovell; [email-masked]; [email-masked]; Corbett,
> Cherita L.; Elwyn Davies; [email-masked]
> Just in case it wasn't clear: I'd like if we had consensus on the text of the
> erratum on this list before we post it to the RFC editor site. If we have a huge
> row about that first, then so be it, but I'd hope that won't be needed:-)
> 
> Anyway, if Pete/Angela can craft text we can thrash it as needed.
> 
> S
> 
> >   If, when writing the errata list, a proposed solution for surgery on the EID
> list is proposed, I would ask that you consider the following.
> >
> >   If the existing EID list from the encapsulated block *already* contains the
> security source, security destination, or both (but not at the front of the EID-
> list) then I recommend we not repeat the security source and/or destination
> in the encapsulating block by prepending them.
> >
> >   I would recommend flags and EID-list indices in the ciphersuite parameters
> rather than repetition or EID-list re-ordering.
> >
> > -Ed
> >
> >
> > ---
> > Ed Birrane
> > Senior Professional Staff, Space Department Johns Hopkins Applied
> > Physics Laboratory
> >> Subject: Re: [dtn-security] Issue implementing security
> >> source/destination with ESB blocks
> >>
> >> Sounds like a plan ...
> >>
> >> Cheers.....Peter
> >>
> >> On Aug 7, 2012, at 12:26 PM, Stephen Farrell
> >> <[email-masked]>
> >> wrote:
> >>
> >>>
> >>> Hi,
> >>>
> >>> post that here. We can stick into the system once folks have had a
> >>> few days to consider it. Probably also worth a mention on
> >>> dtn-interest at that point too since that list has more people on it than
> this.
> >>>
> >> undesigned, PC ciphersuite. Right now, the only EIDs defined are for
> >> sec-src and sec-dest but I can imagine ciphersuites that might have
> additional ones.
> >>>>
> >>>>> 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.
> >>>>>
> >>>>> 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
> >>>>>>
> >>>>>> 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
> >>>>>>
> >>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> 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