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

"Birrane, Edward J." <Edward.Birrane@jhuapl.edu> Fri, 03 August 2012 20:13 UTC

Return-Path: <edward.birrane@jhuapl.edu>
X-Original-To: dtn-security@ietfa.amsl.com
Delivered-To: dtn-security@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0136221F8DEE for <dtn-security@ietfa.amsl.com>; Fri, 3 Aug 2012 13:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.199
X-Spam-Level:
X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CRcG3ooZBD3 for <dtn-security@ietfa.amsl.com>; Fri, 3 Aug 2012 13:13:29 -0700 (PDT)
Received: from jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id F27E821F8DEC for <dtn-security@irtf.org>; Fri, 3 Aug 2012 13:13:28 -0700 (PDT)
Received: from ([128.244.198.91]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.141767261; Fri, 03 Aug 2012 16:07:07 -0400
Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Fri, 3 Aug 2012 16:07:07 -0400
From: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>
To: "elwynd@folly.org.uk" <elwynd@folly.org.uk>, Peter Lovell <plovell@mac.com>
Date: Fri, 3 Aug 2012 16:07:07 -0400
Thread-Topic: [dtn-security] Issue implementing security source/destination with ESB blocks
Thread-Index: Ac1xIgrOv62pyZX5Q86gUzjckYf6EwAkRvAw
Message-ID: <329D879C76FDD04AAAE84BB1D89B397006842FE3A0@aplesfreedom.dom1.jhuapl.edu>
References: <20120802214016.1861780438@smtp.mail.me.com> <501B3B2F.5090508@folly.org.uk>
In-Reply-To: <501B3B2F.5090508@folly.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dtn-security@irtf.org" <dtn-security@irtf.org>, "ahennes1@math.umd.edu" <ahennes1@math.umd.edu>
Subject: Re: [dtn-security] Issue implementing security source/destination with ESB blocks
X-BeenThere: dtn-security@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." <dtn-security.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-security>
List-Post: <mailto:dtn-security@irtf.org>
List-Help: <mailto:dtn-security-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Aug 2012 20:13:30 -0000

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
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 Elwyn Davies
> Sent: Thursday, August 02, 2012 10:45 PM
> To: Peter Lovell
> Cc: dtn-security@irtf.org; ahennes1@math.umd.edu
> Subject: Re: [dtn-security] Issue implementing security source/destination
> with ESB blocks
> 
> Hi.
> 
> Comment in line below...
> 
> On 03/08/12 07:40, Peter Lovell wrote:
> > 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.
> But not that difficult since the flag fields are SDNVs - so adding extra flags will
> not break the ASB definition.
> 
> Regards,
> Elwyn
> >
> > 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
> 
> _______________________________________________
> dtn-security mailing list
> dtn-security@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-security