Re: [dtn] Fwd: BPsec -22, Section 9.1

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

Ran,

  I really liked your proposed working for Section 9.1.

  I am waiting a bit longer for any other accumulated comments/edits (hopefully from ADs with open DISCUSS as to whether BPsec-22 resolves their concerns…) before posting a new version.  But if it helps I can certainly post a -23 and then a -24 later.

-Ed

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


From: dtn <[e-mail]> On Behalf Of R. Atkinson
Sent: Thursday, September 03, 2020 9:35 AM
To: Magnus Westerlund <[e-mail]>
Cc: DTN WG <[e-mail]>
Subject: [EXT] [dtn] Fwd: BPsec -22, Section 9.1

APL external email warning: Verify sender [e-mail]<mailto:[e-mail]> before clicking links or attachments



Magnus,

I would gently suggest that if DTN WG combined my proposed edits below (email to DTN list August 7th) -- along with the proposed edits I offered earlier (email to DTN list July 29th w/ Subject: Re: [dtn] BPbis - mandatory BPsec) —that ought to be sufficient to resolve the ”MUST implement security" concerns.

I defer to the WG Chairs and AD for formal consensus determination, but I haven’t seen substantial objections to either of my notes referenced above.

For context, I’m the ghost author of RFC 3552 (most of the words are mine, which is acknowledged explicitly) and I’ve done IETF security work for about 3 decades now (e.g. RFC-1704, RFC-1825 thru RFC-1827, RFC-2082, et alia).

Thanks,

Ran Atkinson



Begin forwarded message:

From: "R. Atkinson" <[e-mail]<mailto:[e-mail]>>
Subject: BPsec -22, Section 9.1
Date: August 7, 2020 at 09:25:55 EDT
To: DTN WG <[e-mail]<mailto:[e-mail]>>

All,

Some belated feedback on the BPsec -22 draft follows, organised by section/page.etc.

Section 9.1, page 34, 2nd paragraph, which begins “Implementations of BPsec MUST…"

I am open to wordsmithing, but I propose to replace that one paragraph with these 3 paragraphs.  I am using separate paragraphs to talk about separate concepts primarily for readability.

PROPOSED NEW TEXT:

 "To ensure interoperability among various implementations, all BPSec implementations
   MUST support at least the current IETF standards-track mandatory security context(s).
   As of this writing, that BCP mandatory security context is specified in
   [I-D.ietf-dtn-interop-sc], but the mandatory security context(s) might change
   over time in accordance with usual IETF processes.  Such changes are likely to occur
   in future if/when flaws are discovered in the applicable cryptographic algorithms,
   for example.

   "Additionally, BPsec implementations need to support the security contexts which
    are specified and/or used by the BP networks in which they are deployed.

  "If a node serves as a gateway amongst two or more networks, the BPSec
    implementation at that node needs to support the union of security contexts
    mandated in those networks.”

REASONING:

An implementer of BPsec might or might not have any idea where his/her implementation might be deployed.  So the existing paragraph inadvertently requires an implementer to have knowledge which they very likely cannot have.

Extensive prior experience with IETF security protocols at various layers (e.g., IPsec tunnel-mode, IPsec transport-mode, TLS, routing protocol authentication) has consistently shown that at least one mandatory-to-implement security context needs to be specified.  As noted just above, an implementer might well not know where and how a BPsec implementation might be deployed in future.  So it is important to require implementation of at least one security context which will be common across all implementations.

Experience also has shown that over time the mandatory-to-implement security context will need to change.  The two most common reasons are (a) newly discovered flaw in a cryptographic algorithm (e.g., MD4, MD5, SHA) and (b) improved computational power making an existing algorithm computationally-feasible to attack (e.g., DES).

There is a practical requirement that implementations within a given network support whichever security context that network deploys and also that a gateway between networks support applicable security context(s).  However, those are not something which IETF reasonably can mandate, since an implementer can’t always know where a given BPsec implementation might be deployed in future.  IETF standards normally focus on implementations rather than on deployments.  Where IETF does focus on deployment matters, the usual approach is to publish a “Best Current Practice (BCP)” document rather than a “standard”.


QUESTION:

Should we maybe avoid mandating [ID.bpsec-interop-sc] above and instead re-word the text above to say "as per the latest IETF BCP specifying mandatory-to-implement BPsec security contexts" (and then create a 1 paragraph BCP that says ID.bpsec-interop-sc is the current mandatory-to-implement security context) ??

That would have the hassle of creating an additional (BCP) document now, but would avoid the future hassle of needing to deprecate the entire BPsec RFC ONLY because some other security context became the mandatory-to-implement security context.  If the BPsec protocol is fine, then it would be nice to be able to change mandatory-to-implement security contexts WITHOUT changing the BPsec protocol specification.  This type of thing has happened in the past with other IETF security protocols.


Feedback very welcome…


Thanks !