Re: [dtn] [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Magnus,

On Mon, Feb 10, 2020 at 11:07:24AM +0000, Magnus Westerlund wrote:
> Hi,
> 
> Some comments and suggestions below regarding the mandatory security and the
> relationship of DTN specifications. 
> 
> On Fri, 2020-02-07 at 04:46 +0000, Burleigh, Scott C (US 312B) wrote:
> > Thanks for the very close reading, Ben.  Responses in-line below.
> > 
> > -----Original Message-----
> > From: Benjamin Kaduk via Datatracker <[e-mail]> 
> > Sent: Wednesday, February 5, 2020 7:17 PM
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; Fred Templin <[e-mail]>; 
> > [e-mail]; [e-mail]; [e-mail]
> > Subject: [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-22: (with
> > DISCUSS and COMMENT)
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-dtn-bpbis-22: Discuss
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > I support Roman's Discuss.
> > 
> > (1) It's not clear to me that we should be defining new (near-)application-
> > layer protocols on the standards track without mandatory security
> > mechanisms.  Even draft-ietf-dtn-bpsec defines a "BPSec threat model" that is
> > largly the same as the RFC 3552 threat model, in which the network is
> > completely untrusted and to provide end-to-end communications we must supply
> > additional security mechanisms, yet BPSec is not required to implement or
> > use.  I could perhaps see room for allowing waypoint nodes that do not act as
> > endpoints to remain security-unaware, but the justification for security-
> > unaware endpoints seems quite lacking.
> > 
> > 	The consensus position of the WG, I believe, is that BP may in some
> > cases be deployed in closed, highly resource-constrained systems where the
> > overhead of implementing, much less using, the security mechanisms would be
> > considered both prohibitive and needless.  For such environments, making those
> > mechanisms mandatory might result in either non-adoption of the IETF standard
> > or adoption of a non-compliant implementation, both undesirable.
> > 	The specification can easily be revised to require the implementation of
> > BPsec, but I think that shouldn't be done until the WG has reached a revised
> > consensus.
> 
> Yes, I think this question is important to discuss in the WG. However, I think

Definitely; I don't want to have this just coming from the IESG.

> so far it has been quite clear that deploying without a security solution in
> place is generally a bad idea. So from my perspective BPSec needs to be at least
> a SHOULD with a very tightly worded escape clause. I thinka a MUST would be
> better. I will note that BPSec will need to have a default to implement crypto
> context. I think that is more relevant to profile in some specific deployement
> environments if resource constraints is the issue. 
> 
> Ben, what are your opinions on these two parts.
> 
> a) Having a SHOULD with a tightly worded escape clause or do think a MUST is
> required? 

Conceptually what I want is "MUST have some reasonable security story,
and bpsec is fine for most people".  But of course, "reasonable" is not a
useful word in a protocol spec, so we may end up with just the
SHOULD-with-narrow-escape-clause.  If we can think up a wording that is
closer to "deployment MUST provide security services that SHOULD be bpsec
absent other considerations", even better.

> b) Having a default MTI algorithm to implement, but making clear that specific
> usages of the protocol may use a profile targeted to their envirionment. However
> not having a common MTI can result in non-interoperable islands. I think BPSec-
> 19 made the need for a algorithm clear. The only addition I would add would be
> to point to a specific solution unless you have requirements that says that you
> should have another MTI. 

This sounds good to me.

> 
> Maybe what is missing in BPBis is a section making it clear what is actually
> required to be using BPv7. Becasue at a minimal a secure deployment needs:
> 
> Existing in WG drafts
> - BPv7
> - BPSec
> - Crypto Context (crypto algorithm specification)
> - Convergence layer(s)
> 
> Parts that are not yet adopted as WG items are:
> - Addressing and Routing mechanism 
> - Key-exchange
> 
> However, the WG has clearly shown a desire to work on these parts and some
> additional to make this a more usable protocol. The WG has discussed the
> following work for an upcoming WG recharter:
> 
> Bundle Protocol Additional Blocks
>    Bundle-in-Bundle Encapsulation (D)
>    Manifest block
> Neighbor Discovery (X)
> Naming and Addressing
>    Naming (X)
>    Addressing (X)
>    Registry of Service Identifiers
> Asynchronous Management
>    AMA Application Data
> Model (ADM) (D)
>    Asynchronous Management Protocol (D)
>    Asynchronous Management
> Protocol Agent ADM (D)
>    Various protocol components agent ADM (D)
> Security Key
> Management (D)
> Additional Convergence Layers (X)
> 
> Legend:
> D an active or recent draft exists on this topic
> X RFCs or draft from dtnrg exists on this topic
> 
> However, not all components need to be IETF defined. They will be defined by
> another body to fit well in their usage. And there will be more IETF defined
> componets if we let the WG work on them. However, not publishing the core
> components and framework becasue not all parts exists will delay the WG and have
> negative impact also on the deployment of the protocol. 
> 
> I think the right way for the DTN WG is to get these core specifications
> published now, even if there are "missing" components. In the future one can
> publsish an updated version of some of the RFCs to point to the relevant
> references. 

In general I don't mind publishing the core works even when not all the
pieces needed to deploy are in a ready-to-publish state, provided that the
missing pieces are clearly documented and there's a "stable API" boundary
between the parts that we expect to be able to achieve.  AFAICT we should
be able to meet these criteria, though perhaps there are some specifics
that remain to be documented (e.g., with respect to what a CLA and routing
service will provide).

-Ben