Bundle Protocol Security (BPSec)
draft-ietf-dtn-bpsec-27

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dtn-bpsec-26. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Bundle Block Types registry on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

two new registrations are to be made as follows:

Value: [ TBD-at-Registration ]
Description: Block Integrity Block
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Block Confidentiality Block
Reference: [ RFC-to-be ]

These registrations have already been reviewed and approved by the designated experts.

Second, in the Bundle Status Report Reason Codes registry also on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

five new registrations are to be made as follows:

Value: [ TBD-at-Registration ]
Description: Missing Security Operation
Reference: [ RFC-to-be; Section 7.1 ]

Value: [ TBD-at-Registration ]
Description: Unknown Security Operation
Reference: [ RFC-to-be; Section 7.1 ]

Value: [ TBD-at-Registration ]
Description: Unexpected Security Operation
Reference: [ RFC-to-be; Section 7.1 ]

Value: [ TBD-at-Registration ]
Description: Failed Security Operation
Reference: [ RFC-to-be; Section 7.1 ]

Value: [ TBD-at-Registration ]
Description: Conflicting Security Operation
Reference: [ RFC-to-be; Section 7.1 ]

These registrations have already been reviewed and approved by the designated experts.

Third, a new registry is to be created called the BPSec Security Context Identifiers registry.

The range of values in the registry is a signed 16-bit integer -32,768 through 32,767. The registry will be managed via Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

|-------------|---------------|---------------|
| Value | Description | Reference |
|-------------|---------------|---------------|
| -32768 - -1 | Reserved | [ RFC-to-be ] |
| 0 | Reserved | [ RFC-to-be ] |
| 1 - 32767 | Unassigned | |
|-------------|---------------|---------------|

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-01-18):

From: The IESG
To: IETF-Announce
CC: Scott.C.Burleigh@jpl.nasa.gov, dtn@ietf.org, dtn-chairs@ietf.org, Scott Burleigh , magnus.westerlund@ericsson.com, draft-ietf-dtn-bpsec@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Bundle Protocol Security Specification) to Proposed Standard


The IESG has received a request from the Delay/Disruption Tolerant Networking
WG (dtn) to consider the following document: - 'Bundle Protocol Security
Specification'
  as Proposed Standard

This is a second IETF last call due to extensive changes since previous IETF
last call.

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-01-18. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a security protocol providing data integrity
  and confidentiality services for the Bundle Protocol.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6255: Delay-Tolerant Networking Bundle Protocol IANA Registries (Informational - IRTF Stream)

[Ballot comment]
Thank you for this document, this is somewhat outside of my area of expertise and has previously been reviewed by the IESG.

A couple of minor comments related to section 3.6:

(1) When reading section 3.6, I was questioning whether explicit or arbitrary length CBOR arrays were used.  I found that this behavior was only clarified once I got to section 4.  From a document structure perspective, I wonder whether it wouldn't be better for section 4 to be part of section 3.

(2) In some places, I was surprised that a CBOR array is used in place of a CBOR map.  E.g., both in the Security Context Parameters and the Security Results.  Is there a reason why CBOR arrays was chosen here over maps?

3) For security context flags, it states: "Implementations MUST set reserved bits to 0 when writing this field".  However, I find that somewhat confusing given how CBOR encodes integers and only encodes what is required and effectively leaves out all most significant 0 bits from the encoding.  Perhaps this text could be clarified?

Regards,
Rob

[Ballot comment]
The shepherd writeup, last updated over a year ago, indicates a possible IPR issue that the WG was investigating at that time.  Was this resolved?

Quite a lot of text changed in this document between the last time it came to the IESG and now, including some new normative text, but the document history doesn't show anything about a second last call either in the WG or in the IETF generally.  Should there have been one?

[Ballot comment]
I'll not disagree with my predecessor, but "[[ discuss ]]" has some random
thoughts that were rattling around in my head.


[[ discuss ]]

[ section 4.* ]

* Instead of upgrading in-session to TLS after CH version and magic field
  verification, Can the TLS session be negotiated first and perhaps quickly
  closed based on some DTN-specific ALPN (perhaps "dtn")?

  Can the use of a DTN-specific ALPN be any help even with in-session TLS
  upgrade (as currently described)?

[ section 4.7 ]

* Selecting the minimum of the two session keepalive parameters, in the case
  where one side uses a value of zero, allows one side to disable all
  keepalives altogether.

  I think this might not be the best negotiated outcome if one node knows that
  it is behind a NAT gateway: that node might need to send session keepalives
  in order to maintain NAT binding state.


[[ nits ]]

[ section 3.4 ]

* "This situation not ideal" -> "This situation is not ideal"

[ section 4.4 ]

* "entity MAY attempt use" -> "entity MAY attempt to use"

[Ballot comment]
All my previous comments seem to be addressed.

Section 8

I still really like the security considerations section here, and want
to retain my note that it is well-thought-out, from my previous ballot
positions.

[Ballot discuss]
- Is this meant to obsolete RFC 6257?

- Section 3.8 says "BCB blocks MUST NOT have the 'block must be removed from bundle if
      it can't be processed' flag set." However, the notes for this section ask that "designers carefully consider the effect" of setting this flag. I presume the latter should have been deleted?

- Sec 11.3 specifies an unsigned integer with certain meanings attached to negative values.

[Ballot comment]
Sec 3.1 While there is no formal IETF policy, there has been some concern that "MITM" is exclusionary. How would you feel about replacing this with "On-Path Attacker" and "Mallory" with a suitable replacement (Olive?)?

I am somewhat unsure of the implications of Section 3.9, where the waypoint is supposed to delete the BIB and replace it with another BIB. Presumably, policies will generally require authentication from a specific source? I kept waiting for some discussion of these issues in 3.9, 7, and/or 8.2.2, and was disappointed. There are many ways to resolve this, including just explaining that I'm wrong, but text in 3.9 like "this technique is incompatible with policies that require integrity checking with the bundle source as security source" or something to that effect would be one way.

[Ballot comment]
Section 1.2

  This specification addresses neither the fitness of externally-
  defined cryptographic methods nor the security of their
  implementation.  Completely trusted networks are extremely uncommon.
  Amongst untrusted networks, different networking conditions and
  operational considerations require varying strengths of security
  mechanism.  [...]

nit/editorial: the transition between the first and second sentences is
a bit abrupt.

  others.  It is expected that separate documents will be standardized
  to define security contexts and cipher suites compatible with BPSec,
  to include those that should be used to assess interoperability and
  those fit for operational use in various network scenarios.  An

nit: it looks like "those" (in "to include those") binds to "security
contexts and cipher suites", but neither of those seems like a good fit
for "assess interoperability".  The latter "those" also seems a bit off.

  example security context has been defined
  ([I-D.ietf-dtn-bpsec-interop-sc]) to support interoperability testing
  and illustrate how security contexts should be defined for this
  specification.

I think some of the other changes made that draft into more than just
for testing and illustration (it's mandatory to implement in some cases,
IIRC).

Section 1.4

  o  Security Operation - the application of a security service to a
      security target, notated as OP(security service, security target).
      For example, OP(confidentiality, payload).  Every security
      operation in a bundle MUST be unique, meaning that a security
      service can only be applied to a security target once in a bundle.

nit: I suggest "a given security service", since different security
services targeting the same target can be okay.

Section 2.2

  The Bundle Protocol allows extension blocks to be added to a bundle
  at any time during its existence in the DTN.  When a waypoint adds a
  new extension block to a bundle, that extension block MAY have
  security services applied to it by that waypoint.  Similarly, a
  waypoint MAY add a security service to an existing extension block,
  consistent with its security policy.

nit: IIUC a waypoint could also add a security service to the payload
block, so just "an existing block" in the last sentence seems more
accurate to me.

  In cases where the security source and security acceptor are not the
  bundle source and bundle destination, it is possible that the bundle
  will reach the bundle destination prior to reaching a security
  acceptor.  [...]

(side note) I note that the definition for "Bundle Destination" says
that it acts as the security acceptor for every security target in every
security block in the bundle it receives, which suggests that the
scenario described here should never happen.  That said, I think it is
wise do leave this text in place as-is!

Section 3.7

  o  Since OP(integrity, target) is allowed only once in a bundle per
      target, it is RECOMMENDED that users wishing to support multiple
      integrity signatures for the same target define a multi-signature
      security context.

I know we had talked about this text a bit previously, but I just wanted
to check whether the thing that does multi-signatures would be a
security *context* or a security block type.

Section 3.9

  In cases where a security source wishes to calculate both a plain
  text integrity mechanism and encrypt a security target, a BCB with a
  security context that generates such signatures as additional
  security results MUST be used instead of adding both a BIB and then a
  BCB for the security target at the security source.

["signatures" may be overly specific, as there are other
integrity-protection mechanisms possible in principle.]

Section 5.1.1

  If the security policy of a security-aware node specifies that a node
  should have applied confidentiality to a specific security target and
  no such BCB is present in the bundle, then the node MUST process this
  security target in accordance with the security policy.  It is
  recommended that the node remove the security target from the bundle.

[need to check the motivation for this recommendation]

Section 5.1.2

  If the security policy of a security-aware node specifies that a node
  should have applied integrity to a specific security target and no
  such BIB is present in the bundle, then the node MUST process this
  security target in accordance with the security policy.  It is
  RECOMMENDED that the node remove the security target from the bundle
  if the security target is not the payload or primary block.  If the

We should probably be consistent about lowercase vs uppercase
"recommended" for BCB/BIB in this situation.

Section 7

      1.  At the time of encryption, a security context can be selected
          which computes a plain text integrity signature and included
          as a security context result field.

nit: maybe "that is included" or "and includes it"?

Section 8

I still really like the security considerations section here, and want
to retain my note that it is well-thought-out, from my previous ballot
position.

Section 11.2

Carving off a range of values (maybe even all negative 16-bit integers?)
for local/site-specific use would probably be useful.

[Ballot comment]
I support Mirja's and Benjamin's DISCUSSes.

Please respond to the Gen-ART review.

In Section 3.8:

"o  It is RECOMMENDED that designers carefully consider the effect of
      setting flags that either discard the block or delete the bundle
      in the event that this block cannot be processed.

  o  The BCB block processing control flags can be set independently
      from the processing control flags of the security target(s).  The
      setting of such flags SHOULD be an implementation/policy decision
      for the encrypting node."
   
Both of these uses of normative language seem inappropriate.

[Ballot comment]
I support Mirja's and Benjamin's DISCUSSes.

In Section 3.8:

"o  It is RECOMMENDED that designers carefully consider the effect of
      setting flags that either discard the block or delete the bundle
      in the event that this block cannot be processed.

  o  The BCB block processing control flags can be set independently
      from the processing control flags of the security target(s).  The
      setting of such flags SHOULD be an implementation/policy decision
      for the encrypting node."
   
Both of these uses of normative language seem inappropriate.

[Ballot comment]
Thank you for the work put into this document.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 2.3 --
About
  "a waypoint node, representing a
  gateway to an insecure portion of the DTN, may receive the bundle and
  choose to apply a confidentiality service"
how could the bundle destination could recover the plain text if there is no security association with the encrypting waypoint? Or is it simple hop-by-hop encryption ?

-- Section 3.2 --
Why not supporting multiple integrity-checks/signatures? After all, this would allow the support of more than 1 integrity check / signature algorithm? (Obvioulsy, this cannot be done for confidentility -- except if transmitting multiple copies). There are some text related to this in section 3.7.

-- Section 8.2.4 --
More details about anti-replay of a DTN message would be welcome. E.g., is the bundle age field used ?

-- Section 9.2 --
This section is a list of issues with BPsec but are there other WG items attempting to solve those issues ? draft-ietf-dtn-bpsec-interop-sc does not seem to cover those issues.

[Ballot comment]
I support Ben’s DISCUSS and comments.

— Section 1.4 —
Please use the current BCP 14 boilerplate from RFC 8174, and add a normative reference to that RFC.

[Ballot discuss]
I think we need to discuss how this document refers to the level of security
provided by the network, "insecure network"s or portions thereof, etc..  In
the normal RFC 3552 threat model, we assume the entire network is under the
control of an attacker.  Any exception to that is going to be treated as a
special case (usually only grudgingly so), e.g., if a portion of a network
is under administrative control of a single entity and physically controlled
as well, or if a network uses MAC-layer security technologies.  I don't
think this mindset is well-reflected in the current text.

I agree with Mirja that we need more clarity on usable security contexts for
interoperable implementation.  My suggestion would be to define a security
context that is usable for normal Internet hosts over the normal Internet
(i.e., not a stressed network) to have as a baseline secure configuration,
and customizations for other environments would be treated as deviations
from that well-established baseline in terms of algorithms and security
strength.  I furthermore note that even after reading
draft-ietf-dtn-bpsec-interop-sc I do not have a clear picture of exactly
which bytes are used as input to the various cryptographic algorithms and
how the output is encoded.  For example, is the block data contents of a
target block always going to be a fixed-length bstr?  Can the process of
applying protection change whether the #6.24 tag is present?

I understand the need to provide a defined processing order for message
deprotection (and thus to avoid having the same operation applied to the
same target), but I still don't have a clear picture of why we can't define
things in such a way that allows (e.g.) nested signatures over the same
content block.  I understand the current mechanics where in the abstract
model we only can protect a single block at a time (not a combination of
blocks), so that blindly applying the current mechanics to an attempt at a
nested signature would produce the problematic ambiguity of processing
order, but I don't understand why it has to be that way.  Relatedly, I think
that the current formulation where the target list can be freely
modified/split into separate BIB/BCBs by any waypoint will probably leave us
open to some semantic attacks that drop some blocks but not others, when
there is supposed to be semantic interdependence between those blocks.

The diagram in Figure 2 seems to incorrectly indicate a degree of freedom in
the number of results per target: if we are applying the same operation to
all blocks in the target array, the operation should produce the same number
of results for all target blocks, thus constraining 'K' to be equal to 'M'.

Exclusion of most of the block parameters from confidentiality processing
seems to be a critical flaw in the cryptographic hygeine; I think we should
include the Block Type Code, Block Number, possibly Block Processing Control
Flags, CRC Type and CRC Field (if present), and Block Data Length fields as
"additional data" input to the AEAD to provide integrity protection, as well
as use them as input to BIB calculation.  Failing to include these
parameters seems to leave us prone to "slice and dice" style attacks.  Also,
the description in Section 4 is unclear about whether the surrounding CBOR
array encoding is excluded from AEAD iput (though it doesn't really seem
like it would make sense to re-encode as a one-item CBOR array prior to
applying message protection, the current text is worded such that one might
think the array framing is not explicitly excluded).

Section 9.1 gives an example of using a (presumed unprotected in the absence
of any disclaimer) cryptographic key as a security context parameter; given
that (per Section 3.6) the parameters are included in the wire-format
abstract security block, and not subject to BCB protection, this is wholly
insecure and cannot reasonably be used as an example.  (At least
draft-ietf-dtn-bpsec-interop-sc had a bit of note about "encoded or
protected by the key management system" to give this a veneer of
respectability.)

There's a couple places (noted in the COMMENT) where we claim some
combination of things to be "insecure" without justification; in the noted
instances this doesn't seem to be immediately obvious, so I think the
justification is needed (or the claim should be removed).

Section 7 includes a note that "It is recommended that security operations
only be applied to the blocks that absolutely need them.  If a BPA were to
apply security operations such as integrity or confidentiality to every
block in the bundle, regardless of need, there could be downstream errors
processing blocks whose contents must be inspected or changed at every hop
along the path."  While this statement, taken literally, is true, it also
seems inconsistent with, e.g., BCP 188, as well as the RFC 3552 threat
model, let alone the BPSec threat model of Section 8.  I suggest phrasing
that makes applying security operations the default behavior and requiring
justification to diverge from that.

[Ballot comment]
Thanks for the well-thought-out security considerations section; it's a
pretty good treatment of the relevant issues for DTN-relevant scenarios and
I only have minor comments about it.  Unfortunately, I have pretty
substantial comments on much of the rest of the document, which in many
places seems internally inconsistent as if some sweeping changes were
attempted but not completely implemented.  (E.g., are security contexts
IANA-registered values or site-local, including user-defined?  Is there a
single target block of a security operation or a list of targets?)  Even
among the comments that do not quite rise to Discuss level, there are some
pretty significant flaws, especially relating to cryptographic terminology
and usage.

Section 1.1

  3.  Hop-by-hop authentication is a special case of data integrity and
      can be achieved with the integrity mechanisms defined in this
      specification.  Therefore, a separate authentication service is
      not necessary.

Data integrity is one thing that can be provided by hop-by-hop
authentication (in combination with trust in the nodes on the path), but it
is not the only benefit provided by hop-by-hop authentication; I don't think
we should conflate them in this way.

Section 1.3

  The Bundle Protocol [I-D.ietf-dtn-bpbis] defines the format and
  processing of bundles, defines the extension block format used to
  represent BPSec security blocks, and defines the canonicalization
  algorithms used by this specification.

I see a specification in draft-ietf-dtn-bpbis for a "canonical block
structure" but not for a "canonicalization algorithm" used to produce them.

Section 1.4

  o  Cipher Suite - a set of one or more algorithms providing integrity
      and confidentiality services.  Cipher suites may define necessary
      parameters but do not provide values for those parameters.

Could we give examples of such parameters?  If it's things like "secret
keys" that seems okay, but if it's "key length" or "number of rounds" I
don't think that's appropriate to leave as a free parameter, and would be
better expressed as separate cipher suite values.
Is there a 1:1 mapping between security context and cipher suite?
Should this be "integrity and/or confidentiality services"?

  o  Security Service - the security features supported by this
      specification: either integrity or confidentiality.

I wonder if we could make the definition more general in case future
security services are defined in the future.

Section 2.2

  A bundle can have multiple security blocks and these blocks can have
  different security sources.  BPSec implementations MUST NOT assume
  that all blocks in a bundle have the same security operations and/or
  security sources.

nit: is it better to say "have the same security operations" or "have the
same security operations applied to them"?

  The Bundle Protocol allows extension blocks to be added to a bundle
  at any time during its existence in the DTN.  When a waypoint adds a
  new extension block to a bundle, that extension block MAY have
  security services applied to it by that waypoint.  Similarly, a
  waypoint MAY add a security service to an existing extension block,
  consistent with its security policy.

What about modifying existing blocks (e.g., Previous Node, Bundle Age)?

Section 2.3

  Some waypoints will determine, through policy, that they are the
  intended recipient of the security service and terminate the security
  service in the bundle.  For example, a gateway node could determine
  that, even though it is not the destination of the bundle, it should
  verify and remove a particular integrity service or attempt to
  decrypt a confidentiality service, before forwarding the bundle along
  its path.

This would not really be "end-to-end" as we claim in the Introduction.

  Some waypoints could understand security blocks but refuse to process
  them unless they are the bundle destination.

I'm a little confused as to why this would be desirable.

Section 2.4

  in the implementation of their security services.  BPSec must provide
  a mechanism for users to define their own security contexts.

That seems highly risky, since defining a security context involves getting
a value allocated by IANA in a 16-bit "Specification Required" codepoint
space and it seems pretty unlikely that all users would actually do that.

  For example, some users might prefer a SHA2 hash function for
  integrity whereas other users might prefer a SHA3 hash function.  The
  security services defined in this specification must provide a
  mechanism for determining what cipher suite, policy, and
  configuration has been used to populate a security block.

Doesn't this imply a requirement for a registry or registries of the
relevant types of values?  Or are we claiming that this will all be part of
the specification for the security context?

Section 3.1

      the bundle destination.  Security-aware waypoints add or remove
      BIBs from bundles in accordance with their security policy.  BIBs
      are never used to sign the cipher-text provided by a BCB.

nit: most of this text is good about using a generic treatement of
"integrity protection", but "sign" is a subset of the ways to get integrity
protection.

      of security policy.  BCBs additionally provide authentication
      mechanisms for the cipher-text they generate.

I suspect this is going to be authentication in the AEAD sense, that is,
protection against malleability (as opposed to source authentication that
provides an indication of the identity of the party applying the
protection).  I don't think it's best to refer to such properties as
"authentication mechanisms" as opposed to "integrity protection"

Section 3.2

  bundle.  Since a security operation is represented as a security
  block, this limits what security blocks may be added to a bundle: if
  adding a security block to a bundle would cause some other security
  block to no longer represent a unique security operation then the new
  block MUST NOT be added.  It is important to note that any cipher-

Is it permissible to remove the existing block before adding the new
(conflicting) one?

  o  Signing the payload twice: The two operations OP(integrity,
      payload) and OP(integrity, payload) are redundant and MUST NOT
      both be present in the same bundle at the same time.

They're not redundant if a recipient might have different levels of
confidence in the two (different) signers.  Though, IIUC, having the
"second" signature include the first BIB as the signed content is
permissible as a workaround, right?  [ed. reading further this understanding
seems contrary to the current text of the spec]

Section 3.3

  Under special circumstances, a single security block MAY represent
  multiple security operations as a way of reducing the overall number

I'm not so sure that this is "special circumstances"; I would expect wanting
to apply the same operation to multiple blocks to be quite common.

  o  The security source for the security operations is the same.
      Meaning the set of operations are being added by the same node.

nit: this second sentence is a sentence fragment.

  A security target is a block in the bundle to which a security
  service applies.  This target must be uniquely and unambiguously

Given that the ASB always uses an array of block numbers to identify the
target, this use of the singular "a block" seems inappropriate.

Section 3.5

  o  CRC Type and CRC Field (if present)

  o  Block Data Length

  o  Block Type Specific Data Fields

nit: draft-ietf-dtn-bpbis-21 has the CRC field as the last field, and the
block data length and type-specific data are encoded together as a
definite-length byte string.

Section 3.6

Does the array of block numbers in the "Security Targets" field need to be
sorted in a particular order?

  Security Context Flags:
        [...]
        Bit 1  (the least-significant bit, 0x01): Security Context
                Parameters Present Flag.

In draft-ietf-dtn-bpbis we start numbering bits at "bit 0", so it's
confusing to start at "bit 1" here.

  Security Context Parameters (Optional):

Why do we use an array of (index, value) tuples instead of a CBOR map?

  Security Results:
        This field captures the results of applying a security service
        to the security targets of the security block.  This field

(I note that here we properly refer to "targets" plural, in contrast to what
I noted above.)

        SHALL be represented as a CBOR array of target results.  Each
        entry in this array represents the set of security results for
        a specific security target.  The target results MUST be ordered
        identically to the Security Targets field of the security
        block.  This means that the first set of target results in this

Per the discuss point, what's the motivation for having an array of results
instead of applying the operation to the concatenation of the blocks in
question and having a single result?  Having multiple results negates most
of the space savings we could get from coalescing an operation via "target
multiplicity".  I see that the BCB procedures can require splitting a BIB if
only some of its targets are covered by the BCB (which requires an array of
results), but the mechanics of processing would still be possible by
encrypting the whole BIB.  Are there reasons why that is not feasible?

Section 3.7

  o  The Security Context Id MUST utilize an end-to-end authentication
      cipher or an end-to-end error detection cipher.

Please don't use the word "cipher" here; "cipher" is a cryptographic term of
art and does not apply here (see RFC 4949).

  o  The EID of the security source MAY be present.  If this field is
      not present, then the security source of the block SHOULD be
      inferred according to security policy and MAY default to the
      bundle source.  The security source MAY be specified as part of
      security context information described in Section 3.10.

Isn't the security context identified by an IANA-assigned value?  I cannot
see how the contex would specify the source itself as opposed to the
procedure for inferring it from the bundle contents.

  o  Since OP(integrity, target) is allowed only once in a bundle per
      target, it is RECOMMENDED that users wishing to support multiple
      integrity signatures for the same target define a multi-signature
      security context.

As indicated above; I don't understand the need for this requirement.
I also don't understand what is meant by a "multi-signature security
context".

  o  For some security contexts, (e.g., those using asymmetric keying
      to produce signatures or those using symmetric keying with a group
      key), the security information MAY be checked at any hop on the
      way to the bundle destination that has access to the required
      keying information, in accordance with Section 3.9.

I am strongly reluctant to endorse the use of a group-shared symmetric key
in a standards-track document.
Also, nit: wouldn't an "error-detection cipher [sic]" also allow for a
waypoint node to check the integrity information?

Section 3.8

      The Block Processing Control flags value can be set to whatever
      values are required by local policy, except that this block MUST
      have the "replicate in every fragment" flag set if the target of
      the BCB is the Payload Block.  Having that BCB in each fragment

(now we're back to "the target" singular)

      The Security Context Id MUST utilize a confidentiality cipher that
      provides authenticated encryption with associated data (AEAD).

nit: is it the Id or the Context that utilizes the cipher?

      Additional information created by a cipher suite (such as
      additional authenticated data) can be placed either in a security

nit: the "additional authenticated data" of an AEAD cipher is *input* to the
AEAD, not output; perhaps you mean "authentication tag" here.

      bundle source.  The security source MAY be specified as part of
      security context information described in Section 3.10.

[same comment as for 3.7]

  o  It is RECOMMENDED that designers carefully consider the effect of
      setting flags that either discard the block or delete the bundle
      in the event that this block cannot be processed.

Can we even allow setting "discard this block", since we modify the contents
of the target and the target would be wrongly interpreted in the absence of
this block?

  o  A BIB MUST NOT be added for a security target that is already the
      security target of a BCB.  In this instance, the BCB is already
      providing authentication and integrity of the security target and
      the BIB would be redundant, insecure, and cause ambiguity in block
      processing order.

The type of authentication that is provided by the BCB can be qualitatively
different than the authentication provided by a BIB; ambiguity in block
processing order alone is a sufficient reason to disallow this case and we
probably shouldn't mention the other alleged reasons.
I also don't understand why you say that this combination is "insecure"
based just on the description here; please either remove the claim of
justify it.

  o  A BIB integrity value MUST NOT be evaluated if the BIB is the
      security target of an existing BCB.  In this case, the BIB data is
      encrypted.

What does "evaluated" mean here, and by whom?

  o  A BIB integrity value MUST NOT be evaluated if the security target
      of the BIB is also the security target of a BCB.  In such a case,
      the security target data contains cipher-text as it has been
      encrypted.

I thought we already disallowed this from happening because the BIB contents
are encrypted.

Section 3.9

  Since any cipher suite used with a BCB MUST be an AEAD cipher suite,
  it is inefficient and insecure for a single security source to add
  both a BIB and a BCB for the same security target.  In cases where a

Again, please justify or remove the claim of "insecure".
Also, the authentication provided by a signature BIB remains qualitatively
different from that provided by an AEAD.

Section 3.10

I still don't have any real idea of what type(s) of parameters the "security
context parameters" might be, which is worryisome.

Section 3.11

It's not entirely clear to me what value is provided by using the Bn layer
of abstraction for block IDs, as opposed to actual integer values (which
makes it clear that the primary block has ID 0 and the payload has ID 1).

Section 3.11.1

  o  An integrity signature applied to the canonicalized primary block

[noting again that the core spec does not define a "canonicalization"
procedure.]

  o  Confidentiality for the first extension block (B4).  This is
      accomplished by a BCB (B3).  Once applied, the contents of
      extension block B4 are encrypted.  The BCB MUST hold an

nit(?): I don't think "contents" is the term used most often by the core
spec for the block-type-specific data.

      authentication signature for the cipher-text either in the cipher-
      text that now populates the first extension block or as a security

"authentication signature" is going to confuse people by its similarity to
the cryptographic signature concept, which this is not.  Please use
"authentication tag" instead.

Section 3.11.2

  The resultant bundle is illustrated in Figure 4 and the security
  actions are described below.  Note that block IDs provided here are
  ordered solely for the purpose of this example and not meant to
  impose an ordering for block creation.  The ordering of blocks added
  to a bundle MUST always be in compliance with [I-D.ietf-dtn-bpbis].

Is there a particular ordering requirement from bpbis that is relevant here?

  o  Since the waypoint node wishes to encrypt blocks B5 and B6, it
      MUST also encrypt the BIBs providing plain-text integrity over
      those blocks.  However, BIB B2 could not be encrypted in its
      entirety because it also held a signature for the primary block
      (B1).  Therefore, a new BIB (B7) is created and security results

[I still don't understand why this is not an artificial rule, but no need to
further discuss that here.]

Section 4

  the same target information (e.g., the same bits in the same order)
  is provided to the cipher suite when generating an original signature
  and when generating a comparison signature.  Canonicalization

For many integrity-protection algorithms it is not possible to "generate a
comparison signature" and instead the destination node must "validate the
signature" in a dedicated operation.

  Canonical forms are not transmitted, they are used to generate input
  to a cipher suite for security processing at a security-aware node.

nit: comma splice.
As far as I can tell from draft-ietf-dtn-bpbis, there is a single canonical
representation form defined and that is what is transmitted; I do not see a
separate canonicalization procedure specified.

  The canonicalization of the primary block is as specified in
  [I-D.ietf-dtn-bpbis].

[where?]

  All non-primary blocks share the same block structure and are
  canonicalized as specified in [I-D.ietf-dtn-bpbis] with the following
  exceptions.

[ibid]

  o  Reserved flags MUST NOT be included in any canonicalization as it
      is not known if those flags will change in transit.

So they're ... set to zero?  Or since the previous bullet says they're
excluded, there's no problem by definition?

  These canonicalization algorithms assume that Endpoint IDs do not
  change from the time at which a security source adds a security block
  to a bundle and the time at which a node processes that security
  block.

When might that not hold?  Shouldn't this be stated much earlier in the
document as a requirement/foundational assumption?

Section 5.1.1

  If the security policy of a security-aware node specifies that a
  bundle should have applied confidentiality to a specific security
  target and no such BCB is present in the bundle, then the node MUST
  process this security target in accordance with the security policy.
  This may involve removing the security target from the bundle.  If
  the removed security target is the payload block, the bundle MUST be
  discarded.

As written this seems to impose a requirement on security policies to
specify what happens in this case.  Perhaps we should give a default
behavior (discard the bundle?) to avoid accidental omissions that lead to
inesecure operation?
Also, nit: "a bundle should have applied confidentiality" is weird grammar;
I assume "a bundle should have had confidentiality applied" is the intended
meaning (or perhaps with s/bundle/block/), albeit in a very awkward
grammatical construction.  The difficulty comes in that it is not the bundle
that applies protection, but rather the BPA.

  If the Block Data Length field was modified at the time of encryption
  it MUST be updated to reflect the decrypted block length.

"How would the node removing BCB protection know this?" (The security
context and cipher suite, I know, but we should say it.)

Section 5.1.2

  If the security policy of a security-aware node specifies that a
  bundle should have applied integrity to a specific security target
  and no such BIB is present in the bundle, then the node MUST process
  this security target in accordance with the security policy.  This

[same comment as above about requirement on security policy and default
behavior, and same grammatical nit]

  may involve removing the security target from the bundle.  If the
  removed security target is the payload or primary block, the bundle
  MAY be discarded.  This action can occur at any node that has the

Removed from the bundle or as a security target?
I note that removing the payload or primary block from a bundle produces a
protocol violation, so "MAY" does not seem quite right...

Section 5.2

  Security processing in the presence of payload block fragmentation
  may be handled by other mechanisms outside of the BPSec protocol or
  by applying BPSec blocks in coordination with an encapsulation
  mechanism.

Wouldn't it be worth mentioning the possibility for the application to just
ensure that any needed confidentiality protection is applied prior to any
need for fragmentation?

Section 6

  There exist a myriad of ways to establish, communicate, and otherwise
  manage key information in a DTN.  Certain DTN deployments might
  follow established protocols for key management whereas other DTN
  deployments might require new and novel approaches.  BPSec assumes
  that key management is handled as a separate part of network
  management and this specification neither defines nor requires a
  specific key management strategy.

Just so we're clear: this is literally leaving the hardest part of building
a secure system out of scope by saying this, and it's pretty disappointing
to see no guidance at all for how one might do so.

Section 7

  o  If a bundle is received that contains more than one security
      operation, in violation of BPSec, then the BPA must determine how

Just to be clear: "more than one security operation" is not in and of itself
a violation of BPsec.  Perhaps we could rephrase to be more clear,
presumably about blocks that are the target of the same type of security
operation?

  o  It is recommended that BCBs be allowed to alter the size of
      extension blocks and the payload block.  However, care must be
      taken to ensure that changing the size of the payload block while
      the bundle is in transit do not negatively affect bundle
      processing (e.g., calculating storage needs, scheduling
      transmission times, caching block byte offsets).

How would block byte offsets be relevant, given that it's forbidden to apply
a BCB to fragments?

      1.  At the time of encryption, a plain-text integrity signature
          may be generated and added to the BCB for the security target
          as additional information in the security result field.

Would the need to do this be part of a ... security profile?  A security
context?  It remains unclear to me how these pieces are intended to interact.

      2.  The encrypted block may be replicated as a new block and
          integrity signed.

(ditto)

  o  It is recommended that security policy address whether cipher
      suites whose cipher-text is larger (or smaller) than the initial
      plain-text are permitted and, if so, for what types of blocks.

It is *extremely* unclear to me in what cases a cipher-text might be smaller
than the initial plaintext.  I suggest to remove the parenthetical.

Section 8.1

  provide appropriate capabilities if they are needed.  It should also
  be noted that if the implementation of BPSec uses a single set of
  shared cryptographic material for all nodes, a legitimate node is
  equivalent to a privileged node because K_M == K_A == K_B.

So sharing a key like that is NOT RECOMMENDED, right?

  A special case of the legitimate node is when Mallory is either Alice
  or Bob (i.e., K_M == K_A or K_M == K_B).  In this case, Mallory is
  able to impersonate traffic as either Alice or Bob, which means that

"either Alice or Bob, respectively", right?  Having K_B does not let Mallory
impersonate traffic as Alice?

Section 8.2.1

  When evaluating the risk of eavesdropping attacks, it is important to
  consider the lifetime of bundles on a DTN.  Depending on the network,
  bundles may persist for days or even years.  Long-lived bundles imply
  that the data exists in the network for a longer period of time and,
  thus, there may be more opportunities to capture those bundles.
  [...]

It's probably worth noting that Mallory is of course not limited by the
bundle lifetime in how long she retains a given bundle.

Section 8.2.2

  removal of blocks.  Within BPSec, both the BIB and BCB provide
  integrity protection mechanisms to detect or prevent data
  manipulation attempts by Mallory.

The protection against removal of blocks (or entire bundles) seems a lot
weaker, though.  The following paragraph is a pretty good treatment; thanks!

  only validating that the BIB was generated by a legitimate user, Bob
  will acknowledge the message as originating from Mallory instead of
  Alice.  In order to provide verifiable integrity checks, both a BIB

It might be worth saying something about how "validating a BIB indicates
only that the BIB was generated by a holder of the relevant key; it does not
provide any guarantee that the bundle or block was created by the same
entity".

Section 8.2.4

  BPSec relies on cipher suite capabilities to prevent replay or forged
  message attacks.  A BCB used with appropriate cryptographic
  mechanisms (e.g., a counter-based cipher mode) may provide replay
  protection under certain circumstances.  Alternatively, application

This seems to imply keeping counter state across bundles, something that's
pretty finicky to get right and risky to get wrong.  I don't think we should
be implying that this is a good idea without a lot more discussion of the
potential pitfalls and how to avoid them.  (Which basically means I don't
think it's worth mentioning this approach, given the work involved in
generating such discussion).

Section 9.2

  o  Security Results.  Security contexts MUST define their security
      result Ids, the data types of those results, and their CBOR
      encoding.

Are these result Ids expected to be global to a security context or scoped
to a specific block type?

      *  Place overflow bytes, authentication signatures, and any
        additional authenticated data in security result fields rather
        than in the cipher-text itself.

[same note as (far) above about "authenticated data"]

      *  Pad the cipher-text in cases where the cipher-text is smaller
        than the plain-text.

[same note about smaller ciphertext than plaintext]

Section 10

  o  Other security blocks (OSBs) MUST NOT reuse any enumerations
      identified in this specification, to include the block type codes
      for BIB and BCB.

I don't understand what this means.

  NOTE: The burden of showing compliance with processing rules is
  placed upon the standards defining new security blocks and the
  identification of such blocks shall not, alone, require maintenance
  of this specification.

nit: I suggest using a different word than "standards" ("specifications"?),
since the block type registry is just under the Specification Required
policy.

Section 11.1

  This specification allocates two block types from the existing
  "Bundle Block Types" registry defined in [I-D.ietf-dtn-bpbis].

draft-ietf-dtn-bpbis-21 does not contain a direction to IANA to update the
reference for the bundle block types registry away from its current
reference, RFC 6255, so it seems "defined in [RFC6255]" would be more
correct.

[Ballot comment]
** Section 2.  Per “The application of security services in a DTN is a complex endeavor that must consider …”, the current and future threat environment is also a needed consideration.

** Section 3.6, Please explicitly state that the values of this ID should come from the registry defined in Section 11.2.

** Section 3.7.  Per “The Security Context Id MUST utilize an end-to-end authentication cipher or an end-to-end error detection cipher.”, what is a “end-to-end” in this context?

** Section 4.  “Reserved flags  MUST NOT be included in any canonicalization as it is not known if those flags will change in transit.”, to which protocol fields is this “reserved flags” referring to?

** Section 8.2.1.  Please add text to note that irrespective of whether BPSec is used, traffic analysis will be possible

** Section 8.2.4.  Per “With these attacks Mallory's objectives may vary, but may be targeting either the bundle protocol or application-layer protocols conveyed by the bundle protocol.”, please add that the target could also be the storage and compute of the nodes running the bundle or application layer protocols (e.g., a denial of service to flood on the storage of the store-and-forward mechanism; or compute which would process the packets and perhaps prevent other activities)

** Editorial Nits
-- Section 3.8.  Editorial nit.  Section 3.7 uses a bulleted list for the properties of the block.  Here there are no bullets.

-- Section 3.8.  Per “The determination of where to place these data is a function of the cipher suite and security context used” -- s/place these data/place this data/

-- Section 5.1.1 and 5.1.2. s/be be treated/be treated/

-- Section 8.2.2. Expand the IND-CCA2 acronym.

[Ballot discuss]
Sec 1.2 says:
"A sample security
  context has been defined ([I-D.ietf-dtn-bpsec-interop-sc]) to support
  interoperability testing and serve as an exemplar for how security
  contexts should be defined for this specification."
However I don't really understand how interoperability can be reached if there is not at least one security context that is mandatory to implement in this draft (especially as ietf-dtn-bpsec-interop-sc is expired for more than half a year already)...?

An update on this assignment: we have converged on the registry questions in the new Bundle Protocol specification, agreeing to register new BPv7 block type numbers in the existing Bundle Block Types registry rather than starting up a new registry for BPv7 block types.

This means that block type numbers 2 and 3 -- originally requested for the BPsec BIB and BCB blocks -- are not available (they are used by the old Bundle Authentication Block and Payload Integrity Block), so we must assign from one of the unassigned ranges.

The BPbis specification requests that block types 11 and 12 be reserved for the Block Integrity Block and Block Confidentiality Block respectively, so those are the values that I would propose we assign.

My understanding is that a slightly revised BPsec Internet Draft will be posted that simply requests that IANA assign numbers for these two blocks, without specifically asking for any particular values, so in the end I think there will be no conflict.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dtn-bpsec-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Bundle Block Types registry located on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

two new registrations are to be made as follows:

Value: 2
Description: Block Integrity Block
Reference: [ RFC-to-be ]

Value: 3
Description: Block Confidentiality Block
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, a new registry is to be created called the BPSec Security Context Identifiers registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry will be managed via Specification Required as defined in RFC 8126. There are initial registrations in the new registry as follows:

Value Description Reference
----------+-----------------------+---------------
0 Reserved [ RFC-to-be ]
1 - 65535 Unassigned

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-10-03):

From: The IESG
To: IETF-Announce
CC: magnus.westerlund@ericsson.com, Scott Burleigh , draft-ietf-dtn-bpsec@ietf.org, dtn-chairs@ietf.org, Scott.C.Burleigh@jpl.nasa.gov, dtn@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Bundle Protocol Security Specification) to Proposed Standard


The IESG has received a request from the Delay/Disruption Tolerant Networking
WG (dtn) to consider the following document: - 'Bundle Protocol Security
Specification'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-10-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines a security protocol providing end to end data
  integrity and confidentiality services for the Bundle Protocol.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

A Proposed Standard is being requested.  The title page header indicates that the intended status is Standards Track, and the specification documented in the current Internet Draft is not yet mature enough to qualify as an Internet Standard.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document defines security features for the Bundle Protocol (BP)
[I-D.ietf-dtn-bpbis] and is intended for use in Delay Tolerant Networks
(DTNs) to provide end-to-end security services.

The Bundle Protocol specification [I-D.ietf-dtn-bpbis] defines DTN as
referring to "a networking architecture providing communications in
and/or through highly stressed environments" where "BP may be viewed
as sitting at the application layer of some number of constituent
networks, forming a store-carry-forward overlay network". The term
"stressed" environment refers to multiple challenging conditions
including intermittent connectivity, large and/or variable delays,
asymmetric data rates, and high bit error rates.

The BP might be deployed such that portions of the network cannot be
trusted, posing the usual security challenges related to
confidentiality and integrity. However, the stressed nature of the
BP operating environment imposes unique conditions where usual
transport security mechanisms may not be sufficient. For example,
the store-carry-forward nature of the network may require protecting
data at rest, preventing unauthorized consumption of critical
resources such as storage space, and operating without regular
contact with a centralized security oracle (such as a certificate
authority).

An end-to-end security service is needed that operates in all of the
environments where the BP operates.

Working Group Summary

bpsec is descended from the Bundle Security Protocol specification documented
in RFC 6257.  That protocol was found to be impractical to implement in some
circumstances; simplifications were developed that were originally termed
"Streamlined Bundle Security Protocol" and then "bpsec" as of the DTN WG
meeting at IETF 94.  Technical discussion of the details of bpsec over the
ensuing 3 years has been lively and well-informed, without sharp controversy.
WG consensus on the draft is strong.

Document Quality

The Interplanetary Overlay Network (ION) open-source implementation of the DTN
architecture includes an implementation of Streamlined Bundle Security
Protocol, which is nearly identical to bpsec.  Marshall Space Flight Center
intends to add a similar implementation to the DTN2 code base.  Early review of
the specification by Dan Harkins (Security Area) was reported at IETF 102
(review-ietf-dtn-bpsec-06-secdir-early-harkins-2018-05-31): the review result
was Has Issues, but it was the sense of the Working Group that no serious
problems were found.

Personnel

The Document Shepherd is Scott Burleigh.  The Responsible Area Director is Magnus Westerlund.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The Document Shepherd has been reviewing and commenting on drafts of this specification since March of 2013.  The current edition of the specification is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No, reviews of the specification have been performed both by persons with good understanding of Bundle Protocol and by persons with good understanding of network security.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Early review of the specification by Dan Harkins (Security Area) was reported at IETF 102 (review-ietf-dtn-bpsec-06-secdir-early-harkins-2018-05-31): the review result was Has Issues, but it was the sense of the Working Group that no serious problems were found.  The Document Shepherd does not perceive any need for review from additional perspectives.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The Document Shepherd has no specific concerns or issues with this document.  Technical questions have been discussed at length and resolved by consensus within the WG.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Both authors have stated that they do not claim any intellectual property rights regarding this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

Kevin Fall has stated that patent USPTO 7,930,379 might or might not have a bearing on this document.  No formal IPR disclosure has been filed yet; the DTN WG is investigating.  No other claims of intellectual property rights regarding this document have been stated.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

It is the sense of the WG Chairs and the Document Shepherd that this document represents the solid consensus of the WG.  There are WG members whose expertise in the subject matter of the document is limited, who are therefore not active participants in bpsec discussions.  However, the WG as a whole understands the intent and, broadly, the design of the specification, and there is no audible dissent at the WG meetings or on the mailing list.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No extreme discontent pertaining to bpsec has been evident in the WG meetings or on the mailing list.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

According to idnits:
• There is one error: the document includes a normative reference to an Informational RFC (RFC 6255).
• There is one warning: the reference to the bundle protocol specification draft-ietf-dtn-bpbis-11 should be replaced by a reference to later version draft-ietf-dtn-bpbis-13.  (Not unexpected, as the current bpsec I-D was posted 65 days ago and work on bpbis has continued since then.)

In reference to the Internet-Drafts Checklist:
• The IANA Considerations section is present, but the details of the required new namespace (a registry of security context identifiers) are not provided.
• Verbatim replication of the IPR Disclosure, IPR Notice, and Copyright Notice and Disclosure are not provided.  The language provided is incomplete.
• While the bpsec specification supersedes RFC 6257, that RFC is experimental; the absence of Updates or Supersedes language in the Abstract seems appropriate.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review criteria are known to be applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes, with one error (detected by idnits) as noted above.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

The Internet Draft for Bundle Protocol Version 7 is referenced.  That document is being forwarded to the IESG at the same time as the bpsec document itself.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are no downward normative references, aside from the error (detected by idnits) noted earlier.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Publication of this document will not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

As noted earlier, the details of the sole required new namespace (a registry of security context identifiers) are not provided.  Allocation of two additional entries in the Bundle Block Types registry is noted appropriately.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

Allocations from the requested new registry of security context identifiers would likely require Expert Review by persons knowledgeable in cryptographic algorithms, applicable configuration values, and policies associated with the use of those algorithms.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No sections of the bpsec specification are written in any formal language.