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
