Subject: Re: [nvo3] 答复: VxLAN Security Consideration

From: "Dacheng Zhang" <[email-masked]>
Date: Wed, 03 Jun 2015 22:55:30 +0800

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-masked]>
日期:  2015年6月3日 星期三 下午5:15
至:  dacheng de <[email-masked]>, Michael Shieh
<[email-masked]>, David Mozes <[email-masked]>
抄送:  Xuxiaohu <[email-masked]>, "[email-masked]" <[email-masked]>
主题:  [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-masked]]
发送时间: 2015年6月3日 9:57
收件人: Michael Shieh; David Mozes
抄送: Xuxiaohu; [email-masked]; 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-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nvo3
> <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-masked] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3
<https://www.ietf.org/mailman/listinfo/nvo3>
_______________________________________________ nvo3 mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/nvo3

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 3 Jun 2015 08:14:22 -0700

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-masked]> 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
> 
> 
> 至: dacheng de <[email-masked]>, Michael Shieh <[email-masked]>, David Mozes <[email-masked]>
>          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
>  
>  
>  
>     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
>> 
>> [email-masked]
> 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-masked]://www.ietf.org/mailman/listinfo/nvo3
> _______________________________________________ nvo3 mailing list [email-masked] https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________
> nvo3 mailing list
> [email-masked]

---

From: Lucy yong <[email-masked]>
Date: Wed, 3 Jun 2015 16:08:16 +0000

Please read this draft  https://tools.ietf.org/id/draft-hy-gue-4-secure-transport-02.txt

GUE provides the security mechanism for NVO3 encapsulation. Any VxLAN enhancement requirements are for GUE, VXLAN-GPE, and Geneve.

Lucy

From: nvo3 [mailto:[email-masked]] On Behalf Of Dacheng Zhang
Sent: Wednesday, June 03, 2015 9:56 AM
To: Liuyuanjiao; Michael Shieh; David Mozes
Cc: Xuxiaohu; [email-masked]
Subject: Re: [nvo3] 答复: VxLAN Security Consideration

Open for discussion… ^_^

Cheers

Dacheng

发件人: Liuyuanjiao <[email-masked]<mailto:[email-masked]>>
日期: 2015年6月3日 星期三 下午5:15
至: dacheng de <[email-masked]<mailto:[email-masked]>>, Michael Shieh <[email-masked]<mailto:[email-masked]>>, David Mozes <[email-masked]<mailto:[email-masked]>>
抄送: Xuxiaohu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
主题: [nvo3] 答复: VxLAN Security Consideration

Dear Zhang Dacheng:

Best Regards
         Liu Yuanjiao

发件人: Dacheng Zhang [mailto:[email-masked]]
发送时间: 2015年6月3日 9:57
收件人: Michael Shieh; David Mozes
抄送: Xuxiaohu; [email-masked]<mailto:[email-masked]>; Liuyuanjiao
主题: Re: [nvo3] VxLAN Security Consideration

Cheers

Dacheng

Best Regards
         Liu Yuanjiao

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/nvo3

---

From: "Dacheng Zhang" <[email-masked]>
Date: Thu, 04 Jun 2015 00:22:56 +0800

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-masked]> 写入:

>> 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
>> 
>> 
>>          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
>>  
>>  
>>  
>>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
>>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
>>> 
>> 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.
>>[email-masked]://www.ietf.org/mailman/listinfo/nvo3

---

From: Lucy yong <[email-masked]>
Date: Wed, 3 Jun 2015 16:29:26 +0000

Gue (draft-hy-gue-4-secuirty) leverages dtls for payload encryption, and option for header integrity protection. 

Lucy

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Dacheng Zhang
Sent: Wednesday, June 03, 2015 11:23 AM
To: Dino Farinacci
Cc: David Mozes; Xuxiaohu; Michael Shieh; Liuyuanjiao; [email-masked]
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-masked]> 写入:

>> On Jun 3, 2015, at 7:55 AM, Dacheng Zhang 
>><[email-masked]>
>>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 
>>          So the users could monitor the traffic in the way of VNI, 
>>only can monitor the vxlan tunnel overall traffic.
>>  
>>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.

---

From: Liuyuanjiao <[email-masked]>
Date: Fri, 5 Jun 2015 08:10:24 +0000

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-masked]
主题: RE: [nvo3] 答复: VxLAN Security Consideration

Lucy

---

From: Lucy yong <[email-masked]>
Date: Fri, 5 Jun 2015 15:32:52 +0000

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-masked]
Subject: 答复: [nvo3] 答复: VxLAN Security Consideration

Dear Lucy:

Best Regards
	Liu Yuanjiao

-----邮件原件-----
发件人: Lucy yong
发送时间: 2015年6月4日 0:29
收件人: Dacheng Zhang; Dino Farinacci
抄送: David Mozes; Xuxiaohu; Michael Shieh; Liuyuanjiao; [email-masked]
主题: RE: [nvo3] 答复: VxLAN Security Consideration

Lucy