Thinking back a bit about the kcm proposal: https://www.mail-archive.com/netdev@vger.kernel.org/msg78696.html I had a question:
If the user-space has decided to encrypt the http/2 header using tls, the len (and other http/2 fields) is no longer in the clear for the kernel. My understanding is that http header encryption is common practice/BCP, since the http hdr may contain a lot of identity, session and tenancy data. If that's true, then wouldn't this break the BPF/kcm assumptions? There is a different but related problem in this space- existing TLS/DTLS libraries (openssl, gnutls etc) only know how to work with tcp or udp sockets - they do not know anything about PF_RDS or the newly proposed kcm socket type. In theory, it is possible to extend these libraries to handle RDS/kcm etc, but (as we found out with RDS and IP_PKTINFO/BINDTODEVICE), some things become tricky because of the many-to-one dgram-over-stream hybrid. I've looked at IPSEC/IKE in transport mode for RDS on the kernel tcp socket as we discussed at Plumbers in August, and that has some costs.. would be interesting to evaluate against other options.. --Sowmini -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
