Re: [nvo3-dt-encap] Question on NVO3 header security/integrity

[Tom Herbert <[e-mail]>]

On Wed, Jan 11, 2017 at 7:29 AM, Pankaj Garg <[e-mail]> wrote:
> Tom -
>
> Recently a design team for NVO3 was formed to propose one
> encapsulation for standardization by NVO3. As part of this design
> team, we have been looking for a use case of extensions around NVO3
> header security/integrity. In the past, you have brought up this use
> case. Would you be able to describe this use case for us and how
> extensions can be used to enable this?
>
> We would appreciate this and use this example, along with 1-2 other
> examples to ensure that proposed encapsulation format meets the
> requirements of such use cases.
>
Hi Pankaj,

The need for security for nvo3 came up when I was working on the
Google Cloud networking protocol. We initially used GRE with keyid as
VNI (basically nvgre). At that point we didn't have spoofing enabled
on the switches so we were concerned about spoofing packets for
particular virtual networks or even the possibility that simple bit
corruption of VNI could deliver a packet to the wrong tenant. The
solution then was to overload the csum and seqno fields in GRE as a 64
bit security cookie. None of the hardware we tested had a problem with
using and overloading the GRE fields so this was a deployable
solution. The problem though was that there are no more bits available
in GRE so we hit the wall with any more extensions or to use any more
sophisticated security. This is why we invented GUE as a extensible
replacement for GRE.

The possibility of VNI spoofing with an nvo3 protocol is exacerbated
by the use of UDP. Systems typically have no restrictions on
applications being able to send to any UDP port so an unprivileged
application can trivially spoof VXLAN packets for instance (this is
harder to do in non-UDP protocols like GRE). To that end we've added
HMAC support in GUE that authenticates the header and IP addresses.

The other aspect of security that we support in GUE is payload
security. Essentially this is to make packets that look like
IP|UDP|GUE|DTLS|payload. GUE indicates the payload is secured (in the
transform option). This is nice since we still have the UDP header for
ECMP, the GUE header is in plane text so it can by read by network
elements, and different security or other payload transforms can be
supported on a single UDP port (we don't need a separate UDP for DTLS
in GUE for instance).

Tom

> Thanks
> Pankaj