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

"Birrane, Edward J." <Edward.Birrane@jhuapl.edu> Thu, 02 August 2012 17: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 1AD0C11E8123 for <dtn-security@ietfa.amsl.com>; Thu, 2 Aug 2012 10:13:09 -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 0FTe0fWDqNEp for <dtn-security@ietfa.amsl.com>; Thu, 2 Aug 2012 10:13:08 -0700 (PDT)
Received: from jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0469D11E8091 for <dtn-security@irtf.org>; Thu, 2 Aug 2012 10:13:07 -0700 (PDT)
Received: from ([128.244.198.91]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.141680843; Thu, 02 Aug 2012 13:12:58 -0400
Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Thu, 2 Aug 2012 13:12:58 -0400
From: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>
To: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>, "ahennes1@math.umd.edu" <ahennes1@math.umd.edu>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Thu, 2 Aug 2012 13:12:57 -0400
Thread-Topic: [dtn-security] Issue implementing security source/destination with ESB blocks
Thread-Index: Ac1wzVEX6m2V1cLITPmo3Rv4L9RTzQAADPJgAADZU/A=
Message-ID: <329D879C76FDD04AAAE84BB1D89B397006842FE0CA@aplesfreedom.dom1.jhuapl.edu>
References: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu> <501AA7A4.4040608@cs.tcd.ie> <614d049ab50809bfdb47ebf4934ae42a.squirrel@webmail.math.umd.edu> <329D879C76FDD04AAAE84BB1D89B397006842FE0B6@aplesfreedom.dom1.jhuapl.edu>
In-Reply-To: <329D879C76FDD04AAAE84BB1D89B397006842FE0B6@aplesfreedom.dom1.jhuapl.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 17:13:09 -0000

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
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 Birrane, Edward J.
> Sent: Thursday, August 02, 2012 12:55 PM
> To: ahennes1@math.umd.edu; Stephen Farrell
> Cc: dtnbsp@gmail.com; dtn-security@irtf.org
> Subject: Re: [dtn-security] Issue implementing security source/destination
> with ESB blocks
> 
> 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
> _______________________________________________
> dtn-security mailing list
> dtn-security@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-security