Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-security-requirements-02.txt

From: Zu Qiang <[email-masked]>
Date: Mon, 3 Mar 2014 14:11:18 +0000

The question I have given in the WG discussion is that you have added a new threat model that "Attacks from malicious TSes". Do you mean this attack is initiated by a TS. And the TS will attack the NVO3 directly using data plane. Or you mean the TS will try to crash the hypervisor and then attack the attached NVE using the hypervisor-NVE control plane? Please clarify it. 

Have a nice day
Zu Qiang

>-----Original Message-----
>From: nvo3 [mailto:[email-masked]] On Behalf Of Zhangdacheng
>(Dacheng)
>Sent: Friday, January 24, 2014 4:40 AM
>To: [email-masked]
>Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-security-requirements-02.txt
>
>Hello:
>
>We just finished an update of the security requirement document according
>to the comments we got in the list and the last meeting.
>In this update, we:
>
>1) update the diagram of the NOV3 overlay architecture
>2) propose a new classification of attacks
>3) re-write the contents related with key management
>4) add the discussion of NVA-NVA control plane
>5) re-write the scope of this work
>6) change the confidentiality requirements to optional
>
>In addition, we list some security issues (e.g., accountability, security
>protection on management interface) in section 8.2 for discussion. We need
>your suggestions before adding anything in the list into the document as
>requirements.
>
>So, please let us know if you have any comments or suggestions. ^_^
>
>Cheers.
>
>Dacheng
>
>
>> -----Original Message-----
>> From: nvo3 [mailto:[email-masked]] On Behalf Of
>> [email-masked]
>> Sent: Friday, January 24, 2014 5:20 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [nvo3] I-D Action:
>> draft-ietf-nvo3-security-requirements-02.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>>  This draft is a work item of the Network Virtualization Overlays
>> Working Group of the IETF.
>>
>>         Title           : Security Requirements of NVO3
>>         Authors         : Sam Hartman
>>                           Dacheng Zhang
>>                           Margaret Wasserman
>> 	Filename        : draft-ietf-nvo3-security-requirements-02.txt
>> 	Pages           : 18
>> 	Date            : 2014-01-24
>>
>> Abstract:
>>    The draft describes a list of essential requirements in order to
>>    benefit the design of NOV3 security solutions.  In addition, this
>>    draft introduces the candidate techniques which could be used to
>>    construct a security solution fulfilling these security requirements.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-nvo3-security-requirements
>> /
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-nvo3-security-requirements-02
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-security-requirements
>> -02
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> nvo3 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nvo3
>_______________________________________________
>nvo3 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nvo3

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Mon, 3 Mar 2014 14:34:16 +0000

Hi, Zu:

Thank you for the question and your previous comments on this work. 

The attacks performed on both control plane and data plane should be considered. 
 
For instance, a malicious VM may try to compromise an attacker to perform attacks. The requirement related with the key management is used to confine this type of attack.
 
A malicious VM may also try to trigger a NVE to send large amount of control data by keep requiring the addresses of none-existing hosts. The requirement dealing with DoS attacks can be used to deal with this type attacks.
 
In addition, we also consider the possible attacks from compromised network appliances which located in the middle of NVEs and hypervisors. That is why we think the packet level protection for NVE-hypervisor data/control planes is important.

If there is anything missed, pleaes feel free to let us know.

Cheers

Dacheng
________________________________________
发件人: Zu Qiang [[email-masked]]
发送时间: 2014年3月3日 22:11
收件人: Zhangdacheng (Dacheng); [email-masked]
主题: RE: [nvo3] I-D Action: draft-ietf-nvo3-security-requirements-02.txt

Have a nice day
Zu Qiang

---

From: Zu Qiang <[email-masked]>
Date: Mon, 3 Mar 2014 15:52:40 +0000

>The attacks performed on both control plane and data plane should be
[Zu Qiang] Two questions:
- is there a control plane between TS and NVO3 defined by framework draft or architecture draft? 
- is there any TS data security requirement added in your draft? If yes, which one can prevent such data plane attach from a TS? 

>In addition, we also consider the possible attacks from compromised network
>appliances which located in the middle of NVEs and hypervisors. That is why
>we think the packet level protection for NVE-hypervisor data/control planes is
>important.
>
[Zu Qiang] is this type of attack covered by any threat model in your draft?

Have a nice day
Zu Qiang

>The question I have given in the WG discussion is that you have added a new
>threat model that "Attacks from malicious TSes". Do you mean this attack is
>initiated by a TS. And the TS will attack the NVO3 directly using data plane. Or
>you mean the TS will try to crash the hypervisor and then attack the attached
>NVE using the hypervisor-NVE control plane? Please clarify it.
>
>Have a nice day
>Zu Qiang
>
>>Subject: Re: [nvo3] I-D Action:
>>We just finished an update of the security requirement document
>>according to the comments we got in the list and the last meeting.
>>In this update, we:
>>
>>In addition, we list some security issues (e.g., accountability,
>>security protection on management interface) in section 8.2 for
>>discussion. We need your suggestions before adding anything in the list
>>into the document as requirements.
>>

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Mon, 3 Mar 2014 19:17:09 +0000

发送时间: 2014年3月3日 23:52
 
   Dacheng: No. In the security requirement work, the control/plane protection between NVEs and hypervisors are discussed. 

   Dacheng: Actually, we do not try to introduce addition attacks that are not discussed before into the discussion. According to the comments in the last meeting, we just further break the outside attacks down into the attacks from compromised TSes and the attacks from underlying networks. 
   Dacheng: Req6 specifies that a NVE only can send control packets to the NVA with a limited rate. This requirement can be used to deal with the cases where an attacker tries to perform DoS attacks by generating large amount of, for instance, fake ARP packets. If you think the requirements in the documents are not sufficient, please give your comments. Thanks. ^_^

   Dacheng: According to the terms specified in the framework draft, a TS is a physical or virtual system that can play the role of a host or a forwarding element (router, switch, or firewall). So, this type of attack could be covered in the attack from the compromised TSes.

Comments?
 
Dacheng 

Have a nice day
Zu Qiang

Have a nice day
Zu Qiang

---

From: Zu Qiang <[email-masked]>
Date: Tue, 4 Mar 2014 01:28:03 +0000

>   Dacheng: No. In the security requirement work, the control/plane
>protection between NVEs and hypervisors are discussed.
>
[Zu Qiang] this is how it is confused. In the draft you have a statement that " Attacks from malicious TSes " and here you explained it means an attack on the NVE-hypervisor control plane from a compromised hypervisor. Those are two different kind attacks. In the draft you have both compromised hypervisor and compromised VM defined as compromised TS. Please make it correct! 
I guess what you mean is that a compromised TS may try to intercept the NVE-hypervisor control packet. Or an attacker may use the compromised hypervisor to attack the NVE control plane. Please make it clear in the draft.

>- is there any TS data security requirement added in your draft? If yes, which
>one can prevent such data plane attach from a TS?
>
>   Dacheng: Actually, we do not try to introduce addition attacks that are not
>discussed before into the discussion. According to the comments in the last
>meeting, we just further break the outside attacks down into the attacks from
>compromised TSes and the attacks from underlying networks.
>   Dacheng: Req6 specifies that a NVE only can send control packets to the NVA
>with a limited rate. This requirement can be used to deal with the cases where
>an attacker tries to perform DoS attacks by generating large amount of, for
>instance, fake ARP packets. If you think the requirements in the documents
>are not sufficient, please give your comments. Thanks. ^_^
[Zu Qiang] ARP or ND are sent in the TS data plane. A good implementation is that the NVE will only need to query the NVA for the first ARP message. Or it does not need to query the NVA in the push model. So how the faked ARP can flood the NVE-NVA control signalling?
Normally a good NVE implementation shall have some kind firewall function on the TS data traffic to drop any DOS type data plane traffic. This can avoid any flood on NVE-NVE data plane. Unless you want to add TS data plane FW requirement in the NVE, otherwise I don't see any new security issue here.

>
>
>>In addition, we also consider the possible attacks from compromised
>>network appliances which located in the middle of NVEs and hypervisors.
>>That is why we think the packet level protection for NVE-hypervisor
>>data/control planes is important.
>>
>   Dacheng: According to the terms specified in the framework draft, a TS is a
>physical or virtual system that can play the role of a host or a forwarding
>element (router, switch, or firewall). So, this type of attack could be covered
>in the attack from the compromised TSes.
>

[Zu Qiang] as I said in the meeting, please make this level of detail clear enough in the draft.  

>>The question I have given in the WG discussion is that you have added a
>>new threat model that "Attacks from malicious TSes". Do you mean this
>>attack is initiated by a TS. And the TS will attack the NVO3 directly
>>using data plane. Or you mean the TS will try to crash the hypervisor
>>and then attack the attached NVE using the hypervisor-NVE control plane?
>Please clarify it.
>>
>>Have a nice day
>>Zu Qiang
>>
>>>discussion. We need your suggestions before adding anything in the
>>>list into the document as requirements.
>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-nvo3-security-requiremen
>>>> t
>>>> s
>>>> /
>>>>
>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-security-requiremen
>>>> t
>>>> s
>>>> -02
>>>>
>>>>
>>The question I have given in the WG discussion is that you have added a
>>new threat model that "Attacks from malicious TSes". Do you mean this
>>attack is initiated by a TS. And the TS will attack the NVO3 directly
>>using data plane. Or you mean the TS will try to crash the hypervisor
>>and then attack the attached NVE using the hypervisor-NVE control plane?
>Please clarify it.
>>
>>Have a nice day
>>Zu Qiang
>>
>>>discussion. We need your suggestions before adding anything in the
>>>list into the document as requirements.
>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-nvo3-security-requiremen
>>>> t
>>>> s
>>>> /
>>>>
>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-security-requiremen
>>>> t
>>>> s
>>>> -02
>>>>
>>>>

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Tue, 4 Mar 2014 07:20:49 +0000

Dacheng: Ok, in the last version, we didn't try to explicitly distinguish the attacks which a melicious VM which tried to perfrom attakers by compromising its hypervisor from the attacks raised from compromised hypervisor.  I will think about this. 
[Zu Qiang] ARP or ND are sent in the TS data plane. A good implementation is that the NVE will only need to query the NVA for the first ARP message. Or it does not need to query the NVA in the push model. So how the faked ARP can flood the NVE-NVA control signalling?

Dacheng: Let's assume a scenario. An attacker generates large amount of fake ARP packet to query different non-existing hosts. In this case, when a NVE receive an ARP request which it does not know the answer, it may try to consult NVA, which may result DoS attacks. So, the capability of filtering the first packet is not sufficient here. We all know there are various way to deal with this type of attack. But we cannot say there is no security issue, right?

---

From: Zu Qiang <[email-masked]>
Date: Tue, 4 Mar 2014 09:57:07 +0000

>[Zu Qiang] ARP or ND are sent in the TS data plane. A good implementation is
>that the NVE will only need to query the NVA for the first ARP message. Or it
>does not need to query the NVA in the push model. So how the faked ARP
>can flood the NVE-NVA control signalling?
>
>Normally a good NVE implementation shall have some kind firewall function
>on the TS data traffic to drop any DOS type data plane traffic. This can avoid
>any flood on NVE-NVE data plane. Unless you want to add TS data plane FW
>requirement in the NVE, otherwise I don't see any new security issue here.
>
>Dacheng: Let's assume a scenario. An attacker generates large amount of fake
>ARP packet to query different non-existing hosts. In this case, when a NVE
>receive an ARP request which it does not know the answer, it may try to
>consult NVA, which may result DoS attacks. So, the capability of filtering the
>first packet is not sufficient here. We all know there are various way to deal
>with this type of attack. But we cannot say there is no security issue, right?

[Zu Qiang] I never say there is no security issue. I said there is no NEW security issue here. Data plane firewall is needed anyway. As an generic architecture consideration, the control plane design SHALL minimize the amplification effects which have the potential to be used by attackers to carry out reflection attacks. This is not a new security requirements.

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Fri, 7 Mar 2014 09:54:05 +0000

Ok, the issue you metioned has discussed in the revious versions. But thank you.