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

["Eric Vyncke (evyncke)" <[e-mail]>]

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.