On Wed, Jun 3, 2015 at 2:20 AM, Liuyuanjiao <[email protected]> wrote: > Dear Tom: > > The GUE can resolve the VNI to be shown, but GUE means another > module, not vxlan module. So the vxlan packet or vxlan payload should be > encrypted into the GUE payload. > I feel this is a little heavy for the device and network. But I am not > sure for it. > I don't believe it's possible to add payload encryption to VXLAN without breaking forward compatibility since the protocol is not extensible (we already saw this with the attempt to add a next header protocol number, and this is also is the problem with the security option proposal). So this would mean a new port number which essentially implies a new protocol anyway.
Maybe it's possible to do this in VXLAN-GPE with some NSH header? Tom > > Best Regards > Liu Yuanjiao > > -----邮件原件----- > 发件人: Tom Herbert [mailto:[email protected]] > 发送时间: 2015年6月3日 10:59 > 收件人: Dacheng Zhang > 抄送: Michael Shieh; David Mozes; Xuxiaohu; [email protected]; Liuyuanjiao > 主题: Re: [nvo3] VxLAN Security Consideration > > On Tue, Jun 2, 2015 at 6:57 PM, Dacheng Zhang <[email protected]> > wrote: >> I think both ipsec and dtls would work. >> >> The middle network is not controlled by customer and the service >> provider, it’s provided by 3nd company, so the environment is not >> trusted, we need to encrypt the VxLAN packets or VxLAN payload for our user >> data. >> >> Currently, no such specific method, I think we need to provide one >> way to resolve it. >> >> A question for Yuanjian, are there any cases in which we need to only >> encrypt the vxlan payloads while transporting the headers in plain >> text? If so, the condition could be a little more complex. >> > We have a payload encryption option in GUE using DTLS > (https://tools.ietf.org/html/draft-hy-gue-4-secure-transport-02). This allows > the GUE headers to be sent in plaintext for inspection by middleboxes. One > nice feature is that this is done as an extension to the protocol so that we > don't need another port like just doing DTLS over UPD payload would require. > We do though need to consider security of the header itself in this case > though. > > Tom > >> >> Cheers >> >> Dacheng >>> >>> >>> >>> >>> >>> >>> >>> Best Regards >>> >>> Liu Yuanjiao >>> >>> >>> _______________________________________________ >>> nvo3 mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >> >> >> This message is for the designated and authorized recipient only and >> may contain privileged, proprietary, confidential or otherwise private >> information relating to vArmour Networks, Inc. and is the sole >> property of vArmour Networks, Inc. Any views or opinions expressed >> are solely those of the author and do not necessarily represent those of >> vArmour Networks, Inc. >> If you have received this message in error, or if you are not >> authorized to receive it, please notify the sender immediately and >> delete the original message and any attachments from your system >> immediately. If you are not a designated or authorized recipient, any >> other use or retention of this message or its contents is prohibited. >> _______________________________________________ nvo3 mailing list >> [email protected] https://www.ietf.org/mailman/listinfo/nvo3 >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 >> > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
