Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
Security Primitives for Packetized Data Links
Utilizing the CCSDS DTN Bundle Protocol
Edward [email protected]
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?