Security Primitives for Packetized Data Links

Utilizing the CCSDS DTN Bundle Protocol

Edward BirraneEdward.Birrane@jhuapl.edu

443-778-7423

2

Overview• Packetized Data Links

− The case for space Internetworks.

− The need for application-layer security.

• Current and Proposed Standards

− IRTF Bundle Security Protocol (BSP) - RFC6257

– Bundle-in-Bundle Encapsulation

– Simplified Bundle Security Protocol (SBSP)

• Deployment

– Flight Software Considerations

– Current Implementations

• Questions

Packetized Data Links

An Opportunity

How do we practically exploit the path diversity of evolving space networks?

− Use Packetized, Multi-Hop, Multi-Path Communications.– No need to establish/maintain end-to-end data stream for all data.

– Reclaim storage space in finer-grained increments.

– Data return increases with increased transmission opportunities.

Small packets comprising large observation/file/status do not need to

follow the same path back to ground.

No need to wait for contact that can receive whole observation.

– Securing the Internetwork.– Spacecraft operate on “far side” of delayed/disrupted links.

No guarantee of immediate access to Certificate Authorities

Very difficult to apply keys uniformly throughout the network.

– Rich application security needed for packetized models

Link-level security ineffective when multiple applications share links.

Need end-to-end security in overlays spanning multiple links.

Motivation

We cannot deploy space internetworks until we can secure them.

The Bundle Protocol Data Unit

Bundle comprised of blocks Order is important

First block is the header

Single payload block

Everything else an “extension

block”

• During processing, blocks

kept in data structures. For transmit/receipt, bundle is

a serialized bitstream.

• Extension blocks each have

their own lifecycle

They are processed

independently of each other

6

DTNs for overlays in a

network Spanning multiple data link

layers

Passing multiple

administrative domains

Some link layers untrusted Shared circuits

Shared physical facilities

Gaps in security rigor

Need security at the overlay Per-hop Authentication

E2E Integrity

E2E Confidentiality

Application Security

Current and Proposed

Standards

Bundle Security Protocol Overview

Defines 4 Extension Blocks (BAB, PIB, PCB, ECB)• Bundle Authentication: Covers entire bundle• Payload Integrity: Integrity signature of payload-related blocks• Payload Confidentiality: Crypto-text of other payload-related

blocks, or describes crypto-text residing in payload block.• Extension Security: Security for non-payload-related blocks.

• May have multiple blocks for a single service• Often a pre-payload block working with a post-payload block.• Example: Bundle Authentication of a large bundle

• Ciphersuites populate blocks• BSP blocks contain ciphersuite identifiers and associated

information.• Bundle agents expected to support multiple ciphersuites.

• Protocol does not address management issues• Key management is an open problem.• Security policy enforcement and configuration is an open area.

9

BSP: Abstract Block Structure

Software implements this structure and uses it for processing

When creating/forwarding bundles, structure is populated and

then serialized into the bundle bitstream.

When receiving a bundle, bitstream is desearialized into this

structure and then validated.

Some fields omitted based on whether 1 or 2 blocks are used to

implement a security service.

10

All BSP Blocks follow a standard block structure

Security Source/Destinations

Layered Security

Security-sources may differ from

the bundle source.

Security-destinations may differ

from the bundle destination.

Caveats

Up to the security-aware node to

ensure there are no conflicts

amongst all security-destinations in

all security blocks in the bundle.

Cannot reach the bundle

destination before reaching all

necessary security-destinations.

11

Each security block has a security source and destination

− Decouple the routing and security functions– Security-destinations separate from bundle destinations problematic

in certain deployment scenarios.

– Increase support for non-payload security– RFC6257 has no integrity mechanism for extension blocks separate

from integrity signatures computed as part of confidentiality.

– A mechanism to sign a canonical form of the primary block would be

appreciated.

– Encapsulation provides equivalent security with simpler

processing rules.– Require fewer nested security blocks to provide super-encryption

– Support security tunnels without any changes to the security spec.

Lessons Learned from RFC6257

As we began implementing RFC6257, the community discovered lessons learned to inform a next revision of the specification.

Proposed Changes (IETF 87)

1. Specify a bundle-in-bundle encapsulation (BIBE) protocol2. Build a “simplified” BSP which assumed the existence of BIBE.3. Write a security practices document showing how SBSP+BIBE provides security

services equivalent to those provided by BSP.

Bundle Security ProtocolRFC6257

Security Practices

Simplified Bundle Security Specification

(SBSP)

Bundle-in-Bundle Encapsulation

Extension Blocks Defs

Ciphersuites, Policies, Configurations

Encapsulated Bundle

− Implements security tunnels in a graceful way

– Encapsulated bundle source/destination never changes.

– Encapsulating bundle src/dest set to the security-src/security-dest

– Lets existing routing mechanisms figure out the routing portion.

– Provides mechanism for hiding primary block

– Encapsulating bundle can have simpler primary block than encapsulated

bundle.

Bundle-in-Bundle Encapsulation

Make an entire bundle the payload of another bundle.

PR

IMA

RY

PAYL

OA

D

PC

B

BA

B

BA

B

Encapsulating Bundle

PR

IMA

RY

PAYL

OA

D

− Three security blocks, not four– Bundle Authentication Block (BAB), Block Confidentiality Block (BCB),

Block Integrity Block (BIB)

– Concept of “security operation” as (service, target)– (integrity, payload), (confidentiality, payload)

– Only 1 unique instance of an operation in a bundle.

– Extension blocks treated same as payloads– Extension block no longer replaced by security block.

– Support for integrity of extension blocks

– (integrity, extension_block_1), (integrity, extension_block_2)

– Support for primary block integrity

– (integrity, primary_block)

– Goal: Backwards compatible with BSP for simple cases– “Simple” cases capture most deployments today.

Simplified BSP

Deployment

ION Scoring against RFC6257

Requirements

121 identified requirements from BSP (MUST)

45 requirements satisfied by ION

16 requirements non-compliant in their ION implementation

45 requirements not applicable to ION implementation

15 requirements unclear on their disposition

Other Statistics

25 recommendations in the specification (SHOULD/RECOMMENDED)

4 adopted by ION

13 allowed optional processing directives identified (MAY) 4 functions performed by ION

ION/BSP Disparities

BSP Requirement ION Disposition

PIB/PCB must specify what parts of the payload are protected.

ION protects entire payload.

Many requirements for support of multiple, related PCBs

ION supports a single PCB protecting the payload.

Support for ESBs ION does not implement ESBs at this time

Ciphersuites must define/populate key information and integrity signatures to standard formats.

ION does not want to generate or parse ASN.1 BER-style OIDs as part of its security suite.

Requirements for configurable security policy ION security DB does not have controls for all security configurations. Just keys and EIDs right now.

Do not specify security destinations that conflict with other security destinations in the bundle.

ION does not do this.

Support for multiple BABs ION supports a single BAB instance (in 2 blocks)

Many requirements involving fragmentation ION does not support BSP-rules for fragments.

Default ION Security Policy

1. Under what conditions are received bundles forwarded?

• Well-formed bundles passing security checks at security destinations.

2. Under what conditions must received bundles have BAB/PIB/PCB?

• RX rules set up in the ion security database

3. What information must be in a BAB/PIB/PCB for it to be evaluated?

• Critical parameters must be present, but aside from syntax checking, all

parameters are accepted.

4. Under what conditions are BABs/PIBs/PCBs added to outgoing bundles?

• TX rules set up in the ion security database

5. What actions are taken when a security check fails?

• The bundle is dropped and error messages are added to log files.

6. When are security blocks evaluated along a path?

• Only at their security destination. Never in transit.

BSP requires a security policy addressing several policy questions

Supported BSP Extension Blocks

• BAB

• PIB

• PCB

• ~ 30 unit tests also checked in

• Debugging issue with one unit test that fails on the build-bot (test configuration issue)

Looking at CCSDS document for BSP for flight applications

• Scored ION against BSP requirements

• Reviewed BSP requirements against flight practices

• In FY14, we will be updating ION to support BIBE/SBSP.

20

Current Status

Continued implementing BSP in ION and customizing it for flight software.

• Compelling use-case for building space internetworks– More effectively use emerging path diversity.

– Less need to support own stand-alone RF system.

• Security required at the application layer at the overlay– Individual link security not enough

– IPSec not enough unless IP runs everywhere.

• Experimental Protocols authored by IRTF (RFC6257)– Forms foundation of security recommendations

– Implemented, in part, in ION/DTN2 today

• Proposed updates based on lessons learned– A simplified BSP may achieve same goals more simply by leveraging

encapsulation.

Wrap-Up

Security over challenged links is both non-trivial and necessary for the operational deployment of a packetized space internetwork.

22

Thank you!

Questions?