Re: [dtn] BPbis consensus status

[Marc Blanchet <[e-mail]>]

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

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

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://www.usenix.org/legacy/publications/library/proceedings/sd96/atkinson.html"
>
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn