draft-ietf-dtn-bpsec-21.txt   draft-ietf-dtn-bpsec-22.txt 
Delay-Tolerant Networking E. Birrane Delay-Tolerant Networking E. Birrane
Internet-Draft K. McKeever Internet-Draft K. McKeever
Intended status: Standards Track JHU/APL Intended status: Standards Track JHU/APL
Expires: September 2, 2020 March 1, 2020 Expires: September 9, 2020 March 8, 2020
Bundle Protocol Security Specification Bundle Protocol Security Specification
draft-ietf-dtn-bpsec-21 draft-ietf-dtn-bpsec-22
Abstract Abstract
This document defines a security protocol providing data integrity This document defines a security protocol providing data integrity
and confidentiality services for the Bundle Protocol. and confidentiality services for the Bundle Protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2020. This Internet-Draft will expire on September 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 17 skipping to change at page 5, line 17
This specification addresses neither the fitness of externally- This specification addresses neither the fitness of externally-
defined cryptographic methods nor the security of their defined cryptographic methods nor the security of their
implementation. Completely trusted networks are extremely uncommon. implementation. Completely trusted networks are extremely uncommon.
Amongst untrusted networks, different networking conditions and Amongst untrusted networks, different networking conditions and
operational considerations require varying strengths of security operational considerations require varying strengths of security
mechanism. Mandating a cipher suite in this specification may result mechanism. Mandating a cipher suite in this specification may result
in too much security for some networks and too little security in in too much security for some networks and too little security in
others. It is expected that separate documents will be standardized others. It is expected that separate documents will be standardized
to define security contexts and cipher suites compatible with BPSec, to define security contexts and cipher suites compatible with BPSec,
to include those that should be used to assess interoperability and to include those that should be used to assess interoperability and
those fit for operational use in various network scenarios. A sample those fit for operational use in various network scenarios. An
security context has been defined ([I-D.ietf-dtn-bpsec-interop-sc]) example security context has been defined
to support interoperability testing and serve as an exemplar for how ([I-D.ietf-dtn-bpsec-interop-sc]) to support interoperability testing
security contexts should be defined for this specification. and illustrate how security contexts should be defined for this
specification.
This specification does not address the implementation of security This specification does not address the implementation of security
policy and does not provide a security policy for the BPSec. Similar policy and does not provide a security policy for the BPSec. Similar
to cipher suites, security policies are based on the nature and to cipher suites, security policies are based on the nature and
capabilities of individual networks and network operational concepts. capabilities of individual networks and network operational concepts.
This specification does provide policy considerations when building a This specification does provide policy considerations when building a
security policy. security policy.
With the exception of the Bundle Protocol, this specification does With the exception of the Bundle Protocol, this specification does
not address how to combine the BPSec security blocks with other not address how to combine the BPSec security blocks with other
skipping to change at page 32, line 48 skipping to change at page 32, line 48
validated to identify replay attacks. Finally, security context validated to identify replay attacks. Finally, security context
parameters within BIB and BCB blocks may include anti-replay parameters within BIB and BCB blocks may include anti-replay
mechanisms such as session identifiers, nonces, and dynamic passwords mechanisms such as session identifiers, nonces, and dynamic passwords
as supported by network characteristics. as supported by network characteristics.
9. Security Context Considerations 9. Security Context Considerations
9.1. Mandating Security Contexts 9.1. Mandating Security Contexts
Because of the diversity of networking scenarios and node Because of the diversity of networking scenarios and node
capabilities that may utilize BPSec there is no one security context capabilities that may utilize BPSec there is a risk that a single
mandated for every possible BPSec implementation. For example, a security context mandated for every possible BPSec implementation is
security context appropriate for a resource-constrained node with not feasible. For example, a security context appropriate for a
limited connectivity may be inappropriate for use in a well- resource-constrained node with limited connectivity may be
resourced, well connected node. inappropriate for use in a well-resourced, well connected node.
This does not mean that the use of BPSec in a particular network is This does not mean that the use of BPSec in a particular network is
meant to be used without security contexts for interoperability and meant to be used without security contexts for interoperability and
default behavior. Network designers must identify the minimal set of default behavior. Network designers must identify the minimal set of
security contexts necessary for functions in their network. For security contexts necessary for functions in their network. For
example, a default set of security contexts could be created for use example, a default set of security contexts could be created for use
over the terrestrial Internet and required by any BPSec over the terrestrial Internet and required by any BPSec
implementation communicating over the terrestrial Internet. implementation communicating over the terrestrial Internet.
Implementations of BPSec MUST support the mandated security contexts Implementations of BPSec MUST support the mandated security contexts
of the networks in which they are applied. If a node serves as a of the networks in which they are applied. If no set of security
contexts is mandated for a given network, then the BPSec
implementation MUST, at a minimum, implement the security context
defined in [I-D.ietf-dtn-bpsec-interop-sc]. If a node serves as a
gateway amongst two or more networks, the BPSec implementation at gateway amongst two or more networks, the BPSec implementation at
that node MUST support the union of security contexts mandated in that node MUST support the union of security contexts mandated in
those networks. those networks.
BPSec has been designed to allow for a diversity of security contexts BPSec has been designed to allow for a diversity of security contexts
and for new contexts to be defined over time. The use of different and for new contexts to be defined over time. The use of different
security contexts does not change the BPSec protocol itself and the security contexts does not change the BPSec protocol itself and the
definition of new security contexts MUST adhere to the requirements definition of new security contexts MUST adhere to the requirements
of such contexts as presented in this section and generally in this of such contexts as presented in this section and generally in this
specification. specification.
Implementors should monitor the state of security context
specifications to check for future updates and replacement.
9.2. Identification and Configuration 9.2. Identification and Configuration
Security blocks must uniquely define the security context for their Security blocks must uniquely define the security context for their
services. This context MUST be uniquely identifiable and MAY use services. This context MUST be uniquely identifiable and MAY use
parameters for customization. Where policy and configuration parameters for customization. Where policy and configuration
decisions can be captured as parameters, the security context decisions can be captured as parameters, the security context
identifier may identify a cipher suite. In cases where the same identifier may identify a cipher suite. In cases where the same
cipher suites are used with differing predetermined configurations cipher suites are used with differing predetermined configurations
and policies, users can define multiple security contexts that use and policies, users can define multiple security contexts that use
the same cipher suite. the same cipher suite.
 End of changes. 7 change blocks. 
13 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/