Hi Daniel, (some answers inline below)
I believe secure group communication in the context of Geneve will provide an additional level of trust/compliance in a typical data center operation (where I see the primary focus of Geneve). What is the threat model in the context of Geneve? As you stated just a few days ago: "The threat model seems to me very vague, so the current security consideration is limited to solving a problem that is not stated." Would it be beneficial for the nvo3-wg to define a threat model so we can suggest solutions for a clearly defined problem? May I suggest as a seed for a discussion: Goal: Limit the possibility of Geneve end-points/transit-devices to participate in an nvo-network with authenticated and encrypted communication. Reason: Compliance with several industry standards (e.g. PCI) to encrypt sensitive information in transit and limit access to said information. Modern virtualization platforms allow to limit VM-migration to a set of defined virtualization hosts (e.g. affinity rules) which could support limitation to participate in nfv/nvo for selected VMs/applications if aligned with host-affinity and secure group communication. On 19/03/02/ 18:04, Daniel Migault wrote: > Hi, > > Thanks for the response. In my view group communication does not > address the threat model in the context of Geneve, more especially, I > am not sure that group communication considers that some piece of > information can be disclosed to a subset of the members of the group. GSAKMP has a group concept with a hierarchical key management (See e.g. Appendix A1, A2: LKH, logical key hierarchy). In addition we have merchant-silicon available to provide encryption for the needs of data center communication scaling up 10s or 100s Gbit/s for AES-GCM for the forwarding-plane. The control-plane in current network devices is typically multi-core/GHz, capable to negotiate keys in a reasonable time. Forwarding-plane encryption is currently implemented for 802.1AE in hardware but I don't see much more complexity e.g. for ESP-headers, allowing to communicate beyond L2-boundaries. > That said, if you believe that could be a way to address the threat > model, I am more than happy to hear from you. The mls WG may also > have interesting discussions related to group communications. Like mentioned above, we don't a clear definition of the threat model yet. The mls-wg mostly focuses on federated services for the (mostly untrusted) Internet services, mentioned are: S-MIME, PGP, TLS1.3. IMHO Genve has a different scope. Please correct me if I'm wrong. > Instead, what I had in mind were all discussions/proposals/academic > publications around TLS and the coexistence of middle boxes. > Discussions includes but are not limited to an explicit signaling of > the middle box, the disclosed information to the middle box versus > the information not disclosed... I fully subscribe to this. Last year I had a talk at CERT.at, our national CERT, discussing the mess of current practice for TLS- intercept and alignment with PKI-concepts, TLS1.3 and the need for "Rouge CAs". I hope we don't want to go this road for a new IETF-standard. A secure group communication could be a solution, we have the great opportunity now of defining green-field standards without bowing our knees to decades of industry practice. > Yours, Daniel ~ > > On Fri, Mar 1, 2019 at 12:07 PM Michael Kafka <[email protected] > <mailto:[email protected]>> wrote: > > On 19/03/01/ 17:23, Daniel Migault wrote: > >> As mentioned earlier, this cannot be true and providing end-to-end >> security between three or more party has not yet been solved at >> the IETF. > > Just off the top of my head: > > OSPFv3, 7. Key Management, static keys, > https://tools.ietf.org/html/rfc4552#page-5 Static keys could be > distributed in SDN environments through central controller. Requires > mutual trust. > > Much older GSAKMP from the era of IKE/ISAKMP, still standards track, > not obsoleted https://tools.ietf.org/html/rfc4535 > > Rgds, MiKa > Best regards from Vienna, MiKa _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
