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

Send comments for wrong document; withdrawing in the only way I know how.  My apologies.

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?

** 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.

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.

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.

I support Ben's DISCUSS.

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.

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