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

[Martin Duke <[e-mail]>]

This looks good, sorry for all the mistakes.

On Tue, Dec 1, 2020 at 6:53 AM Birrane, Edward J. <[e-mail]>
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
>
>
> 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 <[e-mail]>
> > Sent: Monday, November 30, 2020 6:08 PM
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail]; [e-mail];
> Scott
> > Burleigh <[e-mail]>; [e-mail]
> > 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.
>
>
>