> > 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? >
Right, if data is encrypted then we can't do message delineation on receive. KCM wouldn't help much on transmit either since the crypto state would need to be shared. The solution is to move TLS into the kernel. > 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. > TLS-in-kernel would be a lower layer so it shouldn't have to know anything about RDS or KCM. If it makes sent KCM could be used for parsing TLS records themselves... > 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.. > The design of TLS in the kernel is that it will be enabled on the TCP socket, so that receive and transmit path are below RDS and KCM. We have the transmit path for TLS-in-kernel running with good preliminary results, we will post that at least as RFC shortly. Receive side still seems to be feasible. Thanks, Tom > --Sowmini > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
