Hi Yuanjiao, This is what GUE does, i.e. only encrypt for the GUE payload. GUE is an encap. protocol for "VxLAN" applications.
I am not sure what is your intent hear. "VxLAN enhancement" means GUE, VXLAN-gpe, geneve now. Continually suggesting an enhancement on VxLAN header is misleading and not helpful at all. GUE already takes care of the security. Lucy -----Original Message----- From: Liuyuanjiao Sent: Friday, June 05, 2015 3:10 AM To: Lucy yong; Dacheng Zhang; Dino Farinacci Cc: David Mozes; Xuxiaohu; Michael Shieh; [email protected] Subject: 答复: [nvo3] 答复: VxLAN Security Consideration Dear Lucy: So I think maybe we can do the encryption only for the vxlan payload, this is a light way, and the IP, UPD, VxLAN Headers, we keep them. And only do the modification in the payload part. And also, we need to use 1 or 2 reserved bits of VxLAN Headers to do this payload encryption. I think this is a way which can resolve the problem. Best Regards Liu Yuanjiao -----邮件原件----- 发件人: Lucy yong 发送时间: 2015年6月4日 0:29 收件人: Dacheng Zhang; Dino Farinacci 抄送: David Mozes; Xuxiaohu; Michael Shieh; Liuyuanjiao; [email protected] 主题: RE: [nvo3] 答复: VxLAN Security Consideration Gue (draft-hy-gue-4-secuirty) leverages dtls for payload encryption, and option for header integrity protection. Lucy -----Original Message----- From: nvo3 [mailto:[email protected]] On Behalf Of Dacheng Zhang Sent: Wednesday, June 03, 2015 11:23 AM To: Dino Farinacci Cc: David Mozes; Xuxiaohu; Michael Shieh; Liuyuanjiao; [email protected] Subject: Re: [nvo3] 答复: VxLAN Security Consideration I know this draft, and I think you are right. Neither ipsec nor dtls can fulfill the requirements. A security mechanism designed for vxlan could be a good idea... 在 15-6-3 下午11:14， "Dino Farinacci" <[email protected]> 写入: >See draft-farinacci-lisp-crypto-01.txt. It addresses many of these >concerns. > >Dino > >> On Jun 3, 2015, at 7:55 AM, Dacheng Zhang >><[email protected]> >>wrote: >> >> Ok, if there are really such requirements, maybe it is a good idea >>for us to design a security mechanism for vxlan, which can protect the >>integrity of the vxlan headers while encrypting the payloads. >> >> Open for discussion… ^_^ >> >> Cheers >> >> Dacheng >> >> >> 发件人: Liuyuanjiao <[email protected]> >> 日期: 2015年6月3日 星期三 下午5:15 >> 至: dacheng de <[email protected]>, Michael Shieh >><[email protected]>, David Mozes <[email protected]> >> 抄送: Xuxiaohu <[email protected]>, "[email protected]" <[email protected]> >> 主题: [nvo3] 答复: VxLAN Security Consideration >> >> Dear Zhang Dacheng: >> >> Now, in the middle network, we need to monitor the traffic >>basing on the VNI. But if we use IPSec, we could not see VNI anymore. >> So the users could monitor the traffic in the way of VNI, >>only can monitor the vxlan tunnel overall traffic. >> >> Another scenario is: we want to adjust the users traffic >>basing on VNI into different underlay paths. But if VNI do not see, we >>could not do it. Because in one vxlan tunnel, we may have server VNIs. >> >> >> Best Regards >> Liu Yuanjiao >> >> >> >> 发件人: Dacheng Zhang [mailto:[email protected]] >> 发送时间: 2015年6月3日 9:57 >> 收件人: Michael Shieh; David Mozes >> 抄送: Xuxiaohu; [email protected]; Liuyuanjiao >> 主题: Re: [nvo3] VxLAN Security Consideration >> >> 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.Dear >> 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. >> >> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
