Subject: Re: [dtn] Security in BPv7

From: Angela Hennessy <[email-masked]>
Date: Thu, 12 Jun 2014 08:25:01 -0400

I agree, it's much easier to work on a security document while
addressing BPv7 (so for example, we can include things like block
identification). Ed makes a good case for a separate BSP/SBSP
document, which could specify having some security services on by
default.

-Angela

---

From: Angela Hennessy <[email-masked]>
Date: Thu, 12 Jun 2014 08:29:43 -0400

-Angela

---

From: Amy Alford <[email-masked]>
Date: Thu, 12 Jun 2014 11:11:10 -0400

BSP felt overcomplicated.  The proposed BP7 draft meshes really nicely with
the SBSP draft to simplify things.

In particular:
- block ids solve the problem of not being able to specify which extension
block a security block is acting on (usually signing)
- moving mutable fields to extension blocks (from the primary block)
simplifies hashing
- getting rid of the dictionary eliminates the risk of the dictionary
changing between signing and verification
- simplifying src addresses and singleton destination addresses will help
with key management.  It wasn't clear in BSP what a key should be
associated with (a node, a part of the eid, the whole eid?)

I would also like to see something in the BP about managing extension
blocks during fragment reassembly.  There is no reasonable way for a node
that doesn't understand an extension block to manage it during the
reassembly process.  Why not specify that nodes may only reassemble
fragments if they are able to process all the extension blocks present in
them?  In that case, the specs for the extension blocks themselves can
specify how they should be handled on reassembly.

On Thu, Jun 12, 2014 at 8:25 AM, Angela Hennessy <[email-masked]> wrote:

> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>