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

"Birrane, Edward J." <Edward.Birrane@jhuapl.edu> Thu, 02 August 2012 16:54 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 3193D11E8158 for <dtn-security@ietfa.amsl.com>; Thu, 2 Aug 2012 09:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Hj-GPaDA6qkH for <dtn-security@ietfa.amsl.com>; Thu, 2 Aug 2012 09:54:47 -0700 (PDT)
Received: from jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8B211E8153 for <dtn-security@irtf.org>; Thu, 2 Aug 2012 09:54:46 -0700 (PDT)
Received: from ([128.244.198.90]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.141679301; Thu, 02 Aug 2012 12:54:41 -0400
Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Thu, 2 Aug 2012 12:54:41 -0400
From: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>
To: "ahennes1@math.umd.edu" <ahennes1@math.umd.edu>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Thu, 2 Aug 2012 12:54:40 -0400
Thread-Topic: [dtn-security] Issue implementing security source/destination with ESB blocks
Thread-Index: Ac1wzVEX6m2V1cLITPmo3Rv4L9RTzQAADPJg
Message-ID: <329D879C76FDD04AAAE84BB1D89B397006842FE0B6@aplesfreedom.dom1.jhuapl.edu>
References: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu> <501AA7A4.4040608@cs.tcd.ie> <614d049ab50809bfdb47ebf4934ae42a.squirrel@webmail.math.umd.edu>
In-Reply-To: <614d049ab50809bfdb47ebf4934ae42a.squirrel@webmail.math.umd.edu>
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: "dtnbsp@gmail.com" <dtnbsp@gmail.com>, "dtn-security@irtf.org" <dtn-security@irtf.org>
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: Thu, 02 Aug 2012 16:54:48 -0000

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: dtn-security-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org]
> On Behalf Of ahennes1@math.umd.edu
> Sent: Thursday, August 02, 2012 12:39 PM
> To: Stephen Farrell
> Cc: dtnbsp@gmail.com; dtn-security@irtf.org
> 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,
> >
> > On 08/02/2012 04:52 PM, 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.
> >
> > 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
> >> Laboratory for Telecommunication Sciences (LTS)
> >>
> >>
> >
> 
> _______________________________________________
> dtn-security mailing list
> dtn-security@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-security