Subject: [dtn] Roman Danyliw's No Objection on draft-ietf-dtn-bpsec-18: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 03 Feb 2020 19:26:38 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-dtn-bpsec-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec/

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

---

From: "Birrane, Edward J." <[email-masked]>
Date: Sat, 8 Feb 2020 00:30:14 +0000

Roman,

  Thank you for the review and comments for BpSec.  I have updated the document to BPSEC20 which I believe addresses your comments.

  Specific comments are in-line below.  I have enumerated the comment items as ++C# to aid in referencing these points going forward.

Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Principal Staff, Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

-----Original Message-----
From: Roman Danyliw via Datatracker <[email-masked]> 
Sent: Monday, February 3, 2020 10:27 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; Scott Burleigh <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: [EXT] Roman Danyliw's No Objection on draft-ietf-dtn-bpsec-18: (with COMMENT)

APL external email warning: Verify sender [email-masked] before clicking links or attachments 

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

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

++C1: No issue. I have updated the text in BPSEC20.

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

++C2: No issue. I have updated the text in BPSEC20.

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

++C3: Agreed this needs to be clarified. I have updated text related to this in BPSEC20.

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

++C4: Agreed this is ambiguous. I have clarified these are the block processing control flags in BPSEC20.

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

++C5: Agreed this is a useful note. I have added it in BPSEC20.

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

++C6: Agreed this is a useful note. I have added it in BPSEC20.

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

++C7: This has been corrected in BPSEC20.

-- 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/

++C8: I have updated the text in BPSEC20.

++C9: I have fixed this in BPSEC20.

++C10: I have included the expansion in BPSEC20.