Re: [dtn] [EXTERNAL] Re: BPbis consensus status

Hi, Marc.  One note of clarification: BPSec does provide "end-to-end" encryption (and/or integrity protection) if by "ends" we mean the bundle protocol agent that the sending application entity utilizes to transmit the data and the bundle protocol agent that the receiving application entity utilizes to receive the data.

If by "ends" you instead mean the sending and receiving application entities themselves, then of course BPSec doesn't provide end-to-end security service at that layer of the stack; BPSec provides security service at the bundle layer, not at the application layer.

Scott

-----Original Message-----
From: dtn <dtn-bounces@ietf.org> On Behalf Of Marc Blanchet
Sent: Wednesday, September 16, 2020 5:14 PM
To: R. Atkinson <rja.lists@gmail.com>
Cc: DTN WG <dtn@ietf.org>
Subject: [EXTERNAL] Re: [dtn] BPbis consensus status

On 16 Sep 2020, at 19:36, R. Atkinson wrote:

>> On Sep 16, 2020, at 15:50, Marc Blanchet <marc.blanchet@viagenie.ca>
>> 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.

i know all this. been there. done a lot, specially on IPv6. I would love to have IP layer security, but that did not happened. What is deployed currently is that VPNs are not using IPsec but TLS over UDP. Zero trafic of real IPsec end-to-end. Hence my point: current IP stacks are not using IPsec.

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

right, the first one in the stack (from bottom to up) is TLS over TCP/UDP. reality now.

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

ok. that is the control plane. fine by me.

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

to me, security (i.e. auth/encryption) makes only sense at the transport layer (in the IP sense), since the application making the socket know and can enforce the security services it needs, including taking care of the key management. At the IP layer, it is not available to the application. Moreover, IPsec may only occur within some parts of the network, so the application does not have the ability to enforce full end-to-end encryption for example.  Back to BP, I see again that BPsec does not provide that facility to the application and does not warrant complete end-to-end security with the requirements the application wants/need.

> Over 35 years of deployed Internet experience all says that security 
> won’t be available in practice if it isn’t mandatory to implement.

we (I was involved a lot in IPv6, so…) tried hard to make IPsec mandatory for IPv6. I was one deeply involved in IPv6 and pushing IPsec, but it just did not happen. We failed.

> I doubt BP can get
> through the IETF approval processes without mandatory-to-implement 
> security of some sort in a standards-track RFC.

I’m fine with having security mandatory to implement, but not at the BP layer (e.g. BPSec). That is what I’m saying. I’m not against BPsec, on the contrary, I’m just saying that it should not be mandatory to implement for all BP implementations and that security can be handled higher in the stack.

Regards, Marc.

>
> Yours,
>
> Ran
>
> [1]
> "https://urldefense.us/v3/__https://www.usenix.org/legacy/publications/library/proceedings/sd96/atkinson.html__;!!PvBDto6Hs4WbVuu7!eVZ4Yi2LPtGgdO4l426u_10Z28qXwJkfCX-hKp8iI7mtkO2LnXkcJpScQqy_18hxoKEdLqFyYEk$ "
>
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://urldefense.us/v3/__https://www.ietf.org/mailman/listinfo/dtn__
> ;!!PvBDto6Hs4WbVuu7!eVZ4Yi2LPtGgdO4l426u_10Z28qXwJkfCX-hKp8iI7mtkO2LnX
> kcJpScQqy_18hxoKEdz3iyPDg$

_______________________________________________
dtn mailing list
dtn@ietf.org
https://urldefense.us/v3/__https://www.ietf.org/mailman/listinfo/dtn__;!!PvBDto6Hs4WbVuu7!eVZ4Yi2LPtGgdO4l426u_10Z28qXwJkfCX-hKp8iI7mtkO2LnXkcJpScQqy_18hxoKEdz3iyPDg$ 