[dtn] BPsec -22, Section 9.1

["R. Atkinson" <[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 !