Thanks for the feed back. We have a document [1] that provides the threat model and security requirements with the current Geneve specification. The threat model considers the read-only transit devices, however, it is very unclear to me how the document should evolve. This will depend on whether geneve moves more toward a end-to-end protocol versus a protocol with transit devices. In the latest case, if trasit device are so essential, it seems to unrealistic that these devices will remain read-only for a long time. As a result, the threat model may evolve toward its initial version.
You are however more than welcome to comment on the threat model and see how group communication meets the requirements - or need additional requirements. Yours, Daniel [1] https://datatracker.ietf.org/doc/draft-mglt-nvo3-geneve-security-requirements/ On Mon, Mar 4, 2019 at 3:11 PM Michael Kafka <[email protected]> wrote: > 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 >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
