Subject: Re: [dtn] [EXT] Martin Duke's Discuss on draft-ietf-dtn-bpsec-24: (with DISCUSS and COMMENT)

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 1 Dec 2020 14:52:51 +0000

Martin,

  Thank you for the read and updates.  My comments are in-line below and I have numbered the Discusses as D# and the comments as C# in my response.

-Ed

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: Martin Duke via Datatracker <[email-masked]>
> Sent: Monday, November 30, 2020 6:08 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; Scott
> Burleigh <[email-masked]>; [email-masked]
> Subject: [EXT] Martin Duke's Discuss on draft-ietf-dtn-bpsec-24: (with
> DISCUSS and COMMENT)
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> - Is this meant to obsolete RFC 6257?

[D1] No. Were BPSec to obsolete RFC6257 that would imply that one should use BPSec in circumstances where one would otherwise use RFC6257. But, BPSec is specific to BPv7 (bpbis) and RFC6257 is specific to BPv6 (RFC5050). These two security protocols are specific to the version of BP because of structural differences between BPv7 and BPv6. 

> - Section 3.8 says "BCB blocks MUST NOT have the 'block must be removed
> from bundle if
>       it can't be processed' flag set." However, the notes for this section ask
>       that "designers carefully consider the effect" of setting this flag. I
>       presume the latter should have been deleted?

[D2] In BP, there are 2 different flags: "delete the block if the block cannot be processed" and "delete the bundle if the block cannot be processed".  The main body of section 3.8 refers to the first flag. The notes section refers to the second flag.

> - Sec 11.3 specifies an unsigned integer with certain meanings attached to
> negative values.

[D3] Agreed. This was discussed/discovered as a typo in the last DTNWG meeting. I updated BPSec (bpsec-25) to correct this error.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Sec 3.1 While there is no formal IETF policy, there has been some concern
> that "MITM" is exclusionary. How would you feel about replacing this with
> "On-Path Attacker" and "Mallory" with a suitable replacement (Olive?)?

[C1] I am completely in favor of removing exclusionary language. I have updated BPSec (bpsec-25) to make these changes. IMO, these changes do not alter the technical content of the security protocol nor do they make other parts of the protocol more difficult to understand. 

> I am somewhat unsure of the implications of Section 3.9, where the
> waypoint is supposed to delete the BIB and replace it with another BIB.
> Presumably, policies will generally require authentication from a specific
> source? I kept waiting for some discussion of these issues in 3.9, 7, and/or
> 8.2.2, and was disappointed. There are many ways to resolve this, including
> just explaining that I'm wrong, but text in 3.9 like "this technique is
> incompatible with policies that require integrity checking with the bundle
> source as security source" or something to that effect would be one way.

[C2] We discuss these issues as part of section 2.2 "Multiple Security Sources".  That section clarifies that a security operation occurs between a security source and a security acceptor which might not be the bundle source and bundle destination.  If one needs more certainty in selecting a specific security destination, mechanisms such as bundle-in-bundle encapsulation can be used. 

I agree that policy at a waypoint and policy at a bundle destination could be incompatible, and that policy misconfigurations in general are possible. But I am unsure that we need to state this in the BPSec specification beyond what is already in section 2.2.

---

From: Martin Duke <[email-masked]>
Date: Thu, 10 Dec 2020 11:38:45 -0800

This looks good, sorry for all the mistakes.

On Tue, Dec 1, 2020 at 6:53 AM Birrane, Edward J. <[email-masked]>
wrote:

> Martin,
>
>   Thank you for the read and updates.  My comments are in-line below and I
> have numbered the Discusses as D# and the comments as C# in my response.
>
> -Ed
>
>
> [D1] No. Were BPSec to obsolete RFC6257 that would imply that one should
> use BPSec in circumstances where one would otherwise use RFC6257. But,
> BPSec is specific to BPv7 (bpbis) and RFC6257 is specific to BPv6
> (RFC5050). These two security protocols are specific to the version of BP
> because of structural differences between BPv7 and BPv6.
>
>
> [D2] In BP, there are 2 different flags: "delete the block if the block
> cannot be processed" and "delete the bundle if the block cannot be
> processed".  The main body of section 3.8 refers to the first flag. The
> notes section refers to the second flag.
>
> [D3] Agreed. This was discussed/discovered as a typo in the last DTNWG
> meeting. I updated BPSec (bpsec-25) to correct this error.
>
>
> [C1] I am completely in favor of removing exclusionary language. I have
> updated BPSec (bpsec-25) to make these changes. IMO, these changes do not
> alter the technical content of the security protocol nor do they make other
> parts of the protocol more difficult to understand.
>
> [C2] We discuss these issues as part of section 2.2 "Multiple Security
> Sources".  That section clarifies that a security operation occurs between
> a security source and a security acceptor which might not be the bundle
> source and bundle destination.  If one needs more certainty in selecting a
> specific security destination, mechanisms such as bundle-in-bundle
> encapsulation can be used.
>
> I agree that policy at a waypoint and policy at a bundle destination could
> be incompatible, and that policy misconfigurations in general are possible.
> But I am unsure that we need to state this in the BPSec specification
> beyond what is already in section 2.2.
>
>
>