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

From: Martin Duke via Datatracker <[email-masked]>
Date: Mon, 30 Nov 2020 15:08:27 -0800

Martin Duke has entered the following ballot position for
draft-ietf-dtn-bpsec-24: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

- Is this meant to obsolete RFC 6257?

- 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?

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

----------------------------------------------------------------------
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?)?

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.