Re: [dtn] Éric Vyncke's No Objection on draft-ietf-dtn-bpsec-18: (with COMMENT)

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

Éric,

  I have posted a new version of bpsec (bpsec-21) which I believe addresses the two outstanding comments C1 and C3.

-Ed

Ps. :)

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


> -----Original Message-----
> From: Eric Vyncke (evyncke) <[e-mail]>
> Sent: Tuesday, February 18, 2020 4:18 PM
> To: Birrane, Edward J. <[e-mail]>; The IESG
> <[e-mail]>
> Cc: [e-mail]; Scott Burleigh
> <[e-mail]>; [e-mail]; [e-mail]
> Subject: [EXT] Re: Éric Vyncke's No Objection on draft-ietf-dtn-bpsec-18:
> (with COMMENT)
> 
> APL external email warning: Verify sender [e-mail] before
> clicking links or attachments
> 
> Edward,
> 
> Thank you for considering the non-blocking comments and, hopefully,
> improving the quality of the document. But, it seems to me that **C1 should
> really be addressed in the revised ID (and your text should be enough).
> 
> I still believe that **C3 should also be addressed in this document, this is a
> little too "hand waving" to me
> 
> Thank you again for the work done but I hope that the next I-D will address
> the above
> 
> Regards
> 
> -éric
> 
> PS: thank you for managing to type a "É" on your keyboard __
> 
> On 08/02/2020, 01:42, "Birrane, Edward J." <[e-mail]>
> wrote:
> 
>     Éric,
> 
>       Thank you for the review of BPSEC.  I have updated a new BpSec (BpSec-
> 20) and a new interop-sc (ietf-dtn-bpsec-interop-sc-01) which addresses
> some of your comments below.
> 
>       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: Éric Vyncke via Datatracker <[e-mail]>
>     Sent: Thursday, February 6, 2020 6:11 AM
>     To: The IESG <[e-mail]>
>     Cc: [e-mail]; Scott Burleigh
> <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
>     Subject: [EXT] Éric Vyncke's No Objection on draft-ietf-dtn-bpsec-18: (with
> COMMENT)
> 
>     APL external email warning: Verify sender [e-mail] before clicking
> links or attachments
> 
>     Éric Vyncke 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:
>     ----------------------------------------------------------------------
> 
>     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 ?
> 
>     **C1: The WG decision was to decouple routing and security. A gateway
> node may encrypt using a BCB and the bundle could get to the destination
> without going through a decrypting node. In cases where this is a practical
> problem, the WG recommends encapsulating the bundle into another
> bundle and addressing the encapsulating bundle to a waypoint known to be
> able to decrypt. It is not expected that this encryption is only hop-by-hop
> encryption. If a bundle with a BCB reaches a waypoint which can (and has
> policy to) decrypt, it is expected that the security context ID plus the values
> of any security context parameters are sufficient to allow the waypoint to
> decrypt.
> 
>     -- 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.
> 
>     **C2: The WG approach was to - later - define a security context that
> carried these signatures as multiple security results in 1 BIB instead of
> multiple BIBs.
> 
>     -- Section 8.2.4 --
>     More details about anti-replay of a DTN message would be welcome. E.g.,
> is the bundle age field used ?
> 
>     **C3: It is not clear that any additional analysis for that would change the
> normative portions of BPSec. There may be some additional analysis here
> using different extension blocks but that is still analysis ongoing within the
> WG.
> 
>     -- 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.
> 
>     **C4: It is envisioned  that the WG will provide multiple security contexts
> to cover multiple cases. The interop security contexts should  be going to WG
> last call, and we will draft a security context (1 or more) relating to security on
> the Internet for BPSec nodes that operate on the Internet.
>