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

["Birrane, Edward J." <[e-mail]>]

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 <[e-mail]> 
Sent: Monday, February 3, 2020 10:27 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; Scott Burleigh <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: [EXT] Roman Danyliw's No Objection on draft-ietf-dtn-bpsec-18: (with COMMENT)

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

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.

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

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

++C9: I have fixed this in BPSEC20.

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

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