Re: [nvo3] Geneve architecture and question around transit devices (Threat Model)

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 <m.kafka@aon.at> 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 <m.kafka@aon.at
> > <mailto:m.kafka@aon.at>> 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
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>