Subject: [nvo3] Geneve architecture and question around transit devices

From: Daniel Migault <[email-masked]>
Date: Fri, 1 Mar 2019 11:23:10 -0500

Hi,

>From the current specification of Geneve I see a strong willingness to
use of DTLS or IPsec.

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. As such, my understanding is that  the use of DTLS or IPsec does
not work - at least with transit devices. (see [1] Annex.  For full
disclosure I am one of the co-authors)

The presence of transit devices raises most of the concerns and I
question such devices that seem optional with only a read capability to
be part of the architecture.  On a security point of view, there is no
differences between an attacker and a transit device.  Transit device
can only be used over Geneve overlay that are not secured
- DTLS and IPsec do not enable transit devices. As such nothing prevents
a transit device injecting/redirecting/sniffing and none of the
considerations regarding the transit device can be enforced.
Architecturally speaking, transit devices seems like middle boxes or
on-path elements. I am also wondering how much thoughts on this topic -
especially from the transport area have been considered for the transit
devices - among others [2-3].

In my opinion, given the additional complexity provided by the transit
devices, I suspect the Geneve architecture would be better without
transit device. I am happy to understand a bit more from the WG whether
transit devices needs to be part of the Geneve architecture and why.

Yours,
Daniel

[1]
https://datatracker.ietf.org/doc/draft-mglt-nvo3-geneve-security-requirements/
[2] tools.ietf.org/html/draft-hardie-path-signals-03
[3] https://tools.ietf.org/html/rfc7663

---

From: Michael Kafka <[email-masked]>
Date: Fri, 01 Mar 2019 18:07:32 +0100

On 19/03/01/ 17:23, Daniel Migault wrote:

> 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

---

From: Daniel Migault <[email-masked]>
Date: Sat, 2 Mar 2019 12:04:30 -0500

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. 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.

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...

Yours,
Daniel
~

On Fri, Mar 1, 2019 at 12:07 PM Michael Kafka <[email-masked]> wrote:

> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Michael Kafka <[email-masked]>
Date: Mon, 04 Mar 2019 21:10:45 +0100

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.

> 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-masked] 
> <mailto:[email-masked]>> wrote:
> 
>> security between three or more party has not yet been solved at
>> the IETF.
> 
> 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

---

From: Daniel Migault <[email-masked]>
Date: Fri, 8 Mar 2019 22:02:31 -0500

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]