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

[Magnus Westerlund <[e-mail]>]

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

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. 


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)
   Manifes
t 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. 

 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------