© 2004 The MITRE Corporation. All rights reserved DTN Security Susan Symington March 2005 IETF DTN meeting

© 2004 The MITRE Corporation. All rights reserved DTN Security: a unique environment n 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 n The purpose of the DTN is to support interoperability among these underlying stressed regional networks n 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.

© 2004 The MITRE Corporation. All rights reserved How does the stressed DTN environment constrain the available security mechanisms? n 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. n 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 n 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. n Constrained bandwidth –Want to minimize cost of security in terms of header bits

© 2004 The MITRE Corporation. All rights reserved Existing DTN Security n The DTN Architecture document and the Bundle Protocol Specification both include discussion of security services and mechanisms. n We have evaluated the existing security services and mechanisms and come up with recommended enhancements. These recommendations have been discussed on dtn-interest. n This presentation will describe DTN Security as it will look after the enhancements are incorporated.

© 2004 The MITRE Corporation. All rights reserved n We propose defining security as an optional component of DTN n Goal is to remove discussion of security from the DTN Security Architecture and Bundle Protocol Specification documents. n 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

© 2004 The MITRE Corporation. All rights reserved DTN Security Goals n 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 n Secondary emphasis is on providing optional end-to-end security services to bundle applications.

© 2004 The MITRE Corporation. All rights reserved Mandatory Bundle Agent Security Services for Protecting the DTN Infrastructure n Access Control— to ensure that only legitimate applications with appropriate authority and permissions are allowed to inject bundles into the network n Hop-by-hop sender authentication— to verify the identity of the previous-hop bundle agent that claims to have sent a bundle n Hop-by-hop bundle header integrity— to detect bundles that have had their headers modified since being sent from the previous-hop router, and n 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

© 2004 The MITRE Corporation. All rights reserved Bundle Authentication Header (BAH): the infrastructure protection mechanism n 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. n It contains an encrypted hash of the entire bundle, minus the payload n If 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 BAH n Source vs. Sender n Destination vs. Receiver Sender Receiver/ Sender Receiver/ Sender Receiver/ Sender Receiver

© 2004 The MITRE Corporation. All rights reserved Optional Bundle Agent Security Services for protecting DTN applications n Source authentication— to enable the destination bundle agent to verify the identity of the source that claims to have originated the bundle n Destination authentication— to enable the destination bundle agent to verify that all bundles that it receives were in fact intended for it n 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 n Replay detection— to enable the destination bundle agent to detect and discard bundles that are replays of previously-received bundles n 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

© 2004 The MITRE Corporation. All rights reserved Payload Security Header (PSH): the optional application protection mechanism Bundle Agent    Bundle Application  Region  Region   Source Application Node Destination Application Node n The Payload Security Header is computed once at the source bundle agent, carried unchanged throughout the DTN, and checked at the destination bundle agent. n It contains an encrypted hash of the entire bundle, minus the BAH and other mutable fields, such as the custodian and sender fields n If the received hash does not match the hash calculated at the destination, the bundle is discarded. PSH n Source vs. Sender n Destination vs. Receiver

© 2004 The MITRE Corporation. All rights reserved Enable special bundle agents (Security Policy Routers) to optionally enforce a finer- granularity of access control n 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 n 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.

© 2004 The MITRE Corporation. All rights reserved 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 n Payload Security Header is computed once at the source bundle agent, carried unchanged, and may be checked at security boundary routers. n Verification of the PSH hash value authenticates the bundle as having been sent by the source and as being unmodified since being sent n The security policy router access control decision may be based on the source’s credentials; there is no need to trust upstream bundle agents n Source vs. Sender n Destination vs. Receiver Receiver/ Sender Source Bundle Agent may enforce access control and Reject traffic from a Bundle application. PSH

© 2004 The MITRE Corporation. All rights reserved n 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 n 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 n Security policy router capabilities for enforcing a finer-granularity of access control Summary of DTN Security Services

© 2004 The MITRE Corporation. All rights reserved Summary of DTN Security Mechanisms n 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 n 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 PSH n Source vs. Sender n Destination vs. Receiver Sender Receiver/ Sender Receiver/ Sender Receiver/ Sender Receiver Source Bundle Agent may enforce access control and Reject traffic from a Bundle application.

© 2004 The MITRE Corporation. All rights reserved n The ability to detect bundles that have had their payloads (as opposed to their headers) modified while in transit is not provided n Replay detection at arbitrary nodes is not provided (but optional replay detection at destination bundle agents is available) n Traffic flow analysis protection is not provided Security Services that are not provided at arbitrary bundle agents

© 2004 The MITRE Corporation. All rights reserved Why integrity of bundle payload is not provided at every hop (reactive fragmentation) n 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. n If the whole bundle must arrive in order to be able to verify the hash, reactive fragmentation cannot be used. n Calculating the BAH hash over the entire bundle except for the payload enables truncated bundles to be both authenticated and reactively fragmented. n Important header fields are protected: –Source, Destination, CoS, Timestamp, Payload length,…  Source Application Node BAH Receiver 2/ Sender 3 BAH (w/ signed Hash value All other Headers Primary Bundle Header Payload Class length Payload AE78F98D567BB32CAD5F4D17DA787CEAF50287 BAH (w/ signed Hash value All other Headers Primary Bundle Header Payload Class length Payload AE78F98D567 — Complete Bundle Truncated bundle; can’t be authenticated if the BAH hash was calculated over the entire bundle including the payload.

© 2004 The MITRE Corporation. All rights reserved n There is concern that detecting replays at arbitrary nodes would require each node to maintain an excessive amount of state n Some replays, such as retransmitted bundles and replicative routing information are legitimate; additional bundle headers would be required to distinguish legitimate from illegitimate replays n 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 n 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

© 2004 The MITRE Corporation. All rights reserved n 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 n 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