DTN Security

© 2004 The MITRE Corporation. All rights reserved

DTN Security

Susan Symington

([email protected])

March 2005 IETF

DTN meeting


DTN Security: a unique environment

A DTN is an overlay on top of multiple regional networks, some of which are challenged by limitations such as– Intermittent and possibly unpredictable loss of connectivity– Long or variable delay– Asymmetric data rates– High error rates

The purpose of the DTN is to support interoperability among these underlying stressed regional networks

The stressed environment of the underlying regional network both:

– Poses challenges to the mechanisms needed to secure the DTN and thereby constrains available solutions

– Drives the design principle that security mechanisms must be designed to protect the already-limited DTN infrastructure from unauthorized use.


How does the stressed DTN environment constrain the available security mechanisms?

High round-trip times and frequent disconnection – Security solutions should not depend on frequent distribution of a

large number of certificates and encryption keys end-to-end across the DTN.

– A system that does not require each user’s keys and credentials to be distributed throughout the network, but that requires them only at neighboring or nearby nodes, is more scalable.

Delayed or frequent loss of connectivity to a key or certificate server – multiple certificate authorities/key servers may be desirable.– User credentials should expire periodically rather than depend

on certificate revocation messages Long delays

– messages may be valid for days or weeks, so message expiration may not be able to be depended on to rid the network of unwanted messages as efficiently as in other types of networks.

Constrained bandwidth– Want to minimize cost of security in terms of header bits


Existing DTN Security

The DTN Architecture document and the Bundle Protocol Specification both include discussion of security services and mechanisms.

We have evaluated the existing security services and mechanisms and come up with recommended enhancements. These recommendations have been discussed on dtn-interest.

This presentation will describe DTN Security as it will look after the enhancements are incorporated.


We propose defining security as an optional component of DTN

Goal is to remove discussion of security from the DTN Security Architecture and Bundle Protocol Specification documents.

Bundle Agents will not be required to implement security, but those that want to claim to implement secure DTN will be required to comply with the requirements enumerated in the following two planned DTN security documents that are under development:

– DTN Security Overview and Motivation document

– DTN Security Protocol

Planned DTN Security Documentation


DTN Security Goals

Due to the resource-scarcity that characterizes DTNs, the emphasis of DTN security is on protecting the DTN infrastructure from unauthorized access and use

– Prevent access by unauthorized applications,

– Prevent unauthorized applications from asserting control over the DTN infrastructure,

– Prevent authorized applications from sending bundles at a rate or class of service for which they lack permission,

– Promptly detect and discard bundles that were not sent by authorized users, (early detection within infrastructure rather than at destination),

– Promptly detect and discard bundles whose headers have been modified

– Promptly detect and disable compromised entities

Secondary emphasis is on providing optional end-to-end security services to bundle applications.


Mandatory Bundle Agent Security Services for Protecting the DTN Infrastructure

Access Control— to ensure that only legitimate applications with appropriate authority and permissions are allowed to inject bundles into the network

Hop-by-hop sender authentication— to verify the identity of the previous-hop bundle agent that claims to have sent a bundle

Hop-by-hop bundle header integrity— to detect bundles that have had their headers modified since being sent from the previous-hop router, and

Limited protection against denial of service— to ensure that some types of illegitimate traffic on the DTN are detected as soon as possible and dropped immediately upon detection, e.g.– Bundles from legitimate applications but not at an authorized CoS– Bundles from illegitimate bundle agents– Legitimate bundles that have had their headers modified


Bundle Authentication Header (BAH): the infrastructure protection mechanism

The Bundle Authentication Header is computed at every sending bundle agent and checked at every receiving bundle agent on every hop along the way from the source to the destination.It contains an encrypted hash of the entire bundle, minus the payloadIf the received hash does not match the hash calculated at the receiver, the bundle is discarded.

Bundle Agent

Bundle Application

Region Region

Source

Application Node

Destination

Application Node

BAHBAH BAH BAH

Source vs. SenderDestination vs. Receiver

Sender Receiver/Sender

Receiver/Sender

Receiver/Sender

Receiver


Optional Bundle Agent Security Services for protecting DTN applications

Source authentication— to enable the destination bundle agent to verify the identity of the source that claims to have originated the bundle

Destination authentication— to enable the destination bundle agent to verify that all bundles that it receives were in fact intended for it

End-to-end bundle integrity— to enable the destination bundle agent to detect bundles (including bundle payload) that have been modified since being sent from the source

Replay detection— to enable the destination bundle agent to detect and discard bundles that are replays of previously-received bundles

Support for DTN application data confidentiality— providing mechanisms to identify the algorithm and key that has been used by the source DTN application to encrypt application data


Payload Security Header (PSH): the optional application protection mechanism

Bundle Agent

Bundle Application

Region Region

Source

Application Node

Destination

Application Node

The Payload Security Header is computed once at the source bundle agent, carried unchanged throughout the DTN, and checked at the destination bundle agent.It contains an encrypted hash of the entire bundle, minus the BAH and other mutable fields, such as the custodian and sender fieldsIf the received hash does not match the hash calculated at the destination, the bundle is discarded.

PSH



Enable special bundle agents (Security Policy Routers) to optionally enforce a finer-granularity of access control

Enable some DTN nodes to optionally enforce their own access control policies on bundles forwarded to them from other bundle agents, based on bundle source identity and permissions

These nodes may serve as security policy routers and possibly provide either

– a higher level of protection for specific designated links or subregions within a secure DTN that may require the source and legitimacy of the traffic that is admitted to be policed with a higher level of scrutiny than that which can be provided by simply trusting upstream bundle agents to have enforced an access control policy appropriate for those specific links or subregions, or

– perimeter protection to control access of bundles sent from an insecure bundle agent to a secure portion of the DTN.


Security Policy Router: for finer granularity of access control anywhere in the DTN

Bundle Agent

Bundle Application

Region Region

Security Policy Router(may check PSH value)

Source

Application Node

Destination

Application Node

Payload Security Header is computed once at the source bundle agent, carried unchanged, and may be checked at security boundary routers.Verification of the PSH hash value authenticates the bundle as having been sent by the source and as being unmodified since being sent The security policy router access control decision may be based on the source’s credentials; there is no need to trust upstream bundle agents


Receiver/Sender

Source BundleAgent may enforce access control andReject traffic from aBundle application.

PSH PSH


Mandatory protection of the DTN infrastructure from unauthorized use—detect illegitimate traffic ASAP and drop it immediately – Hop-by-hop bundle header integrity– Hop-by-hop bundle sender authentication– Access Control (only legitimate applications/users with

appropriate permissions may inject bundles)– Limited protection against DoS by detecting illegitimate traffic at

its first hop and discarding it immediately Optional protection of application data— destination application

provided with security even when a router may be compromised– End-to-end bundle integrity– End-to-end bundle source and destination authentication– Replay detection at destination– Support for end-to-end payload confidentiality

Security policy router capabilities for enforcing a finer-granularity of access control

Summary of DTN Security Services


Summary of DTN Security Mechanisms

Bundle Authentication Header is computed at every sending bundle agent and checked at every receiving bundle agent on every hop along the way from the source to destination.

Bundle Agent

Bundle Application

Region Region

Security Policy Router(may check PSH value)

Source

Application Node

Destination

Application Node

BAH

Payload Security Header is computed once at the source bundle agent, carried unchanged, and checked at the destination bundle agent (and possibly also at security boundary bundle agents).

BAH BAH BAH

PSH


Sender Receiver/Sender

Receiver/Sender

Receiver/Sender

Receiver

Source BundleAgent may enforce access control andReject traffic from aBundle application.


The ability to detect bundles that have had their payloads (as opposed to their headers) modified while in transit is not provided

Replay detection at arbitrary nodes is not provided (but optional replay detection at destination bundle agents is available)

Traffic flow analysis protection is not provided

Security Services that are not provided at arbitrary bundle agents


Why integrity of bundle payload is not provided at every hop (reactive fragmentation)

Reactive fragmentation is an important DTN feature that enables the receiving node to forward received data ASAP, without waiting for the entire bundle to arrive. If the whole bundle must arrive in order to be able to verify the hash, reactive fragmentation cannot be used.Calculating the BAH hash over the entire bundle except for the payload enables truncated bundles to be both authenticated and reactively fragmented.Important header fields are protected:

– Source, Destination, CoS, Timestamp, Payload length,…

SourceApplication Node

BAH BAH

Receiver 2/Sender 3

BAH(w/ signedHash value

All other Headers

PrimaryBundleHeader

PayloadClass

lengthPayloadAE78F98D567BB32CAD5F4D17DA787CEAF50287

BAH(w/ signedHash value

All other Headers

PrimaryBundleHeader

PayloadClass

lengthPayloadAE78F98D567

— Complete Bundle

Truncated bundle; can’t be authenticated if the

BAH hash was calculated over the entire

bundle including the payload.


There is concern that detecting replays at arbitrary nodes would require each node to maintain an excessive amount of state

Some replays, such as retransmitted bundles and replicative routing information are legitimate; additional bundle headers would be required to distinguish legitimate from illegitimate replays

DoS attacks as executed by replay attacks are expensive and difficult to mount versus other types of DoS attacks, and they would be costly to protect against, so it does not make sense to incorporate mechanisms for defending against them

By explicitly not defining mechanisms to detect replays, we may be leaving some networks that have bandwidth constraints vulnerable to unintended routing loops; to protect against unintentional routing loops, we probably want a mechanism for detecting and discarding bundles that circulate excessively in the network

Why replay detection is not provided at every hop


Given the resource-scarcity of DTNs, it would be counter-productive to perform typical traffic-flow analysis protection measures that are designed to disguise the legitimate traffic on the network, such as:– generating additional bogus traffic in addition to the legitimate traffic– Padding legitimate traffic to disguise the amount of traffic being

transmitted There is no provision for encrypting source or destination

addresses to prevent disclosure of the communicating endpoints– the constraints of frequent disconnection and high round-trip times

make the distribution of the key information that would be required for encryption and decryption of source and destination addresses at many hops throughout the network infeasible.

Traffic flow analysis is not provided

DTN Security

Documents

Transcript of DTN Security