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

From: [email-masked]
Date: Thu, 2 Aug 2012 11:52:45 -0400

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)

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Aug 2012 17:15:32 +0100

Hi Angela,

> encapsulated, so we do not have an extra block as in PCB.

Did you have a solution in mind? Since I'm at the IETF meeting I won't
have time this week to look into it, sorry. If you bug me next week,
I will:-)

S.

---

From: [email-masked]
Date: Thu, 2 Aug 2012 12:38:49 -0400

Hi Stephen,

We were thinking the best solution might be to append the eid ref list of
the encapsulated block to the eid ref list of the ESB block (which would
contain the security src and dest). This would mean there might be 4 eid
references in this list, but this seems better than the alternative
solution, which would be to add an extra ESB block (as is done in PCB).

If there are other proposed solutions to this, we'd definitely be
interested in hearing them.

Thanks,
Angela

---

From: "Birrane, Edward J." <[email-masked]>
Date: Thu, 2 Aug 2012 12:54:40 -0400

Angela,

  Nice catch.  Just spent a few minutes refreshing myself on 5050 and 6257 and agree that this is a rather problematic contradiction in the RFC.  

  I understand the need to not change the EID list, as stitching together the updated EID list with the originally encapsulated EID list is tricky enough at the security destination without changing the order of things. 

  There are times when the security destination is omitted for some reason (i.e., it is the same as the bundle destination), or the security source is omitted (i.e. an anonymous bundle using a default group key, or the security source is the same as the bundle source).  So, guaranteeing that the 1st two items of the ESB EID list will be the secsrc and srcdst may not be desirable for all users.

  I would recommend changing the language of 6257 to place security and destination EIDs, when present, in the security parameters (Section 2.6) and avoid any surgery/dependency on the EID list itself.

-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 [email-masked]
> Sent: Thursday, August 02, 2012 12:39 PM
> To: Stephen Farrell
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dtn-security] Issue implementing security source/destination
> with ESB blocks
> 
> Hi Stephen,
> 
> We were thinking the best solution might be to append the eid ref list of the
> encapsulated block to the eid ref list of the ESB block (which would contain
> the security src and dest). This would mean there might be 4 eid references
> in this list, but this seems better than the alternative solution, which would
> be to add an extra ESB block (as is done in PCB).
> 
> If there are other proposed solutions to this, we'd definitely be interested in
> hearing them.
> 
> 
> Thanks,
> Angela
> 
> >
> > Hi Angela,
> >
> >> 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.
> >
> > have time this week to look into it, sorry. If you bug me next week, I
> > will:-)
> >
> > S.
> >
> >
> >>
> >>
> >>
> >> thanks,
> >> Angela
> >>
> >>
> >> Angela Hennessy
> _______________________________________________
> dtn-security mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-security

---

From: "Birrane, Edward J." <[email-masked]>
Date: Thu, 2 Aug 2012 13:12:57 -0400

Drat, let me retract that recommendation, since it would result in secsrc and secdst perhaps not in the EID list and, therefore, make downstream dictionary pruning problematic.

Given that we must potentially represent secsrc and/or secdst to the EID list,  I think we would need some mechanism to ensure that:

1. The secsrc and secdst are only added when they are known/supplied. (they are both optional)
2. You can have one but not the other
3. The ESB security parameters let you know whether the EIDs need to be copied back to the originating encapsulated EID list or not.

I think adding some flags in the security parameters can cover these cases.  Is there a better way to handle this?

-Ed

---
Ed Birrane

> On Behalf Of Birrane, Edward J.
> Sent: Thursday, August 02, 2012 12:55 PM
> To: [email-masked]; Stephen Farrell
>   Nice catch.  Just spent a few minutes refreshing myself on 5050 and 6257
> and agree that this is a rather problematic contradiction in the RFC.
> 
>   I understand the need to not change the EID list, as stitching together the
> updated EID list with the originally encapsulated EID list is tricky enough at
> the security destination without changing the order of things.
> 
>   There are times when the security destination is omitted for some reason
> (i.e., it is the same as the bundle destination), or the security source is
> omitted (i.e. an anonymous bundle using a default group key, or the security
> source is the same as the bundle source).  So, guaranteeing that the 1st two
> items of the ESB EID list will be the secsrc and srcdst may not be desirable for
> all users.
> 
>   I would recommend changing the language of 6257 to place security and
> destination EIDs, when present, in the security parameters (Section 2.6) and
> avoid any surgery/dependency on the EID list itself.
> 
> -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
> >
> > Hi Stephen,
> >
> > We were thinking the best solution might be to append the eid ref list
> > of the encapsulated block to the eid ref list of the ESB block (which
> > would contain the security src and dest). This would mean there might
> > be 4 eid references in this list, but this seems better than the
> > alternative solution, which would be to add an extra ESB block (as is done in
> PCB).
> >
> > >> 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.
> > >> 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.
> > >
> > > Did you have a solution in mind? Since I'm at the IETF meeting I
> > > won't have time this week to look into it, sorry. If you bug me next
> > > week, I
> > > will:-)
> > >
> > > S.
> > >
> > >
> > >>
> > >>
> > >>
> > >> thanks,
> > >> Angela
> > >>
> > >>
> > >> Angela Hennessy

---

From: [email-masked]
Date: Thu, 2 Aug 2012 14:31:00 -0400

Hi Ed,

Thanks for the quick reply! I think you're right that we'll need some
extra flags to cover these cases. I can't think of any other way to handle
this, but we're definitely open to other ideas.

Thanks,
Angela

> Drat, let me retract that recommendation, since it would result in secsrc
> and secdst perhaps not in the EID list and, therefore, make downstream
> dictionary pruning problematic.
>
> Given that we must potentially represent secsrc and/or secdst to the EID
> list,  I think we would need some mechanism to ensure that:
>
> 3. The ESB security parameters let you know whether the EIDs need to be
> copied back to the originating encapsulated EID list or not.
>
> I think adding some flags in the security parameters can cover these
> cases.  Is there a better way to handle this?
>
> -Ed
>
> ---
> Ed Birrane

---

From: "Peter Lovell" <[email-masked]>
Date: Thu, 2 Aug 2012 17:36:48 -0400

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