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

["R. Atkinson" <[e-mail]>]

> On Oct 26, 2020, at 23:49, Brian Sipos <[e-mail]> wrote:

> It's also inconsistent with a desire
> to make TLS support mandatory to implement (but not mandatory to use),
> since mandatory to implement implies mandatory to be "capable of
> exchanging messages with TLS", thus mandatory to use.

The quote above is a confusion, I think. 

Please bear with me while I try to explain why that claim about “mandatory
to use" is only a confusion, not what “mandatory to implement” actually means.

The key distinction is that “mandatory to implement” means something must
be fully implemented and supported in the code (or logic if one were to have a
a Verilog implementation), but it does NOT mean that it have a default run-time 
configuration of “security is enabled”.

As a trivial example, possibly unrealistic in life but still useful for understanding...

 Some implementation (which I will call “X”) of DTN implements support for BPsec
 and TLS, but it also has a *user* (or maybe system administrator) configurable 
 switch which allows TLS to be enabled or disabled for a given system which has
 that implementation X installed on it.

 Such a switch might have various degrees of granularity,  It could be set
 to default to respond to TLS but not initiate TLS.  It could be set to try to
 initiate TLS but continue without TLS if the other end is not willing to do TLS.
 Ideally, it would enable security to be invoked on a per DTN-session basis,
 perhaps through some API.
 
 As an example from another protocol family, one’s smart phone handset almost
 certainly _implements_ AH, ESP, and IKE.  That doesn’t mean that the handset
 will respond to an unsolicited IKE initiation packet from an unknown remote IP
 address.  Many IPsec deployments have been _configured_ to ignore unsolicited
 IKE packets, for example.  One’s smart phone likely drops unsolicited / unexpected
 incoming IKE initiation packets, unless it has been configured otherwise in some
 manner.  

 (Example: For an iPhone, the “managed deployment” software generally provides
 ways for a corporate IT department to automatically bring up an IPsec VPN, an
 SSL/TLS VPN, or to have some security-protocol policies configured a certain way
 inside the smart phone handset.)

 Common UNIX implementations of AH, ESP, and IKE use setsockopt() to enable
 and/or configure the use of AH or ESP for a given IP session.  On my Mac, the
 most immediately relevant man pages (man pages are only accessible if one has 
 developer tools installed on MacOS, AFAIK) are:
     setsockopt(2)
     sysctl(8)
     ipsec(4)

 On other flavours of UNIX, the relevant set of man pages might vary.

 So to use IPsec for a given IP session, one probably has a line of code which
 invokes setsockopt() with the applicable socket option to enable IPsec.  This
 might manifest in an application as a command-line switch or flag, for example.

So, to be very clear, the IETF meaning of “mandatory to implement” is that ALL
implementations must support the feature/capability.  It does NOT mean that a
given _deployment_ of that implementation on a _particular system_ is required 
to configure that capability to be on by default.

Yours,

Ran