Re: [dtn] BPbis consensus status

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

> On Sep 16, 2020, at 15:50, Marc Blanchet <[e-mail]> wrote:
> 
> I’m still opposed to have BPSEC be mandatory to implement as I think the security services can be done within the payload. IP is currently not secured on the Internet.

For over 25 years now, IP has had IP-layer security in the form of IPsec (ESP & AH).

See RFC-1825 through RFC-1827 to see just how far back IPsec goes.  My team
demonstrated open-source running code for IPsec in 4.4 BSD in August 1995.[1]

For many years, all IPv6 implementations were required to implement IPsec,
although I believe that constraint has been lifted recently (LONG AFTER IPsec
was nearly universally implemented by IPv6 devices and I believe the exemption
is for tiny IoT devices).

Automated key management (which BPsec does not provide yet) came a bit
later with RFC-2407, RFC-2408 and RFC-2409.

IPsec BOTH supports end-to-end security and also can support VPN access. 
In practice, IPsec is probably used more with VPNs but it does still support
end-to-end security.

Virtually every IP-capable device (laptops, paid OSs, free OSs, smart handphones) 
has implemented IPsec for many years now.  

While the original goal of IPsec was end-to-end (e.g., host-to-host) security

Whether one uses IPsec is a very different question from whether it is widely
implemented, just as whether one uses BPsec for a given session is quite 
separate from whether it should be mandatory to implement.

If security is NOT mandatory-to-implement, then users in practice will not be able
to use it in situations where they would like to use it.  The deployed Internet
has over 35 years experience with this operational reality.

> It is within the IP payload (TLS) that security services are applied.

Security services are offered at MANY layers in the deployed Internet.  

TLS is far from being the only game in town.  I discuss IPsec above,
but there are numerous other mandatory security capabilities both
within TCP and below.

Routing protocols have had built-in cryptographic security (e.g., RFC-2082 et seq
for RIP; RFC-2178 et seq for OSPFv2; RFC-2385 eq seq for BGP) for over 20 years.
Even newer routing protocols such as BABEL have been required to have 
cryptographic authentication (e.g., RFC-7298).

> I want a fully conformant BP implementation to ship without BPSec and without any specific use case (e.g. forwarding vs non-forwarding). However, I expect many use cases to require security, but again, in those cases, it can be accomplished within the payload, not at the BP level.

I am open to hear what you have to say, but right now it is FAR from obvious to me

(a) precisely what you mean by “accomplished within the payload”,

(b) where that specification is documented, 

or (c) how you propose that [hypothetical] security service would be mandated. 

Over 35 years of deployed Internet experience all says that security won’t be
available in practice if it isn’t mandatory to implement.  I doubt BP can get
through the IETF approval processes without mandatory-to-implement security
of some sort in a standards-track RFC.

Yours,

Ran

[1] "https://www.usenix.org/legacy/publications/library/proceedings/sd96/atkinson.html"