Subject: [nvo3] FW: New Version Notification for draft-zu-nov3-security-requirements-00.txt

From: Zu Qiang <[email-masked]>
Date: Thu, 26 Sep 2013 13:45:49 +0000

FYI for the group.  

Have a nice day
Zu Qiang

___________________________________________________________________

A new version of I-D, draft-zu-nov3-security-requirements-00.txt
has been successfully submitted by Zu Qiang and posted to the IETF repository.

Filename:	 draft-zu-nov3-security-requirements
Revision:	 00
Title:		 Security Requirements of NVO3
Creation date:	 2013-09-26
Group:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-zu-nov3-security-requirements-00.txt
Status:          http://datatracker.ietf.org/doc/draft-zu-nov3-security-requirements
Htmlized:        http://tools.ietf.org/html/draft-zu-nov3-security-requirements-00

Abstract:
   This draft discusses the security requirements and several issues
   which need to be considered in securing a NVO3 network architecture
   based virtualized data center network for multiple tenants. In
   addition, the draft also discusses issues that could be addressed or
   mitigated.

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.

The IETF Secretariat

---

From: Lucy yong <[email-masked]>
Date: Thu, 26 Sep 2013 13:59:49 +0000

Hi Zu,

I am curious what is the intent of this draft? The chair has announced the WG adoption of draft-hartman-nvo3-security-requirements last week.

Thanks,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zu Qiang
Sent: Thursday, September 26, 2013 8:46 AM
To: [email-masked]
Subject: [nvo3] FW: New Version Notification for draft-zu-nov3-security-requirements-00.txt

FYI for the group.  

Have a nice day
Zu Qiang

Abstract:

The IETF Secretariat

_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Zu Qiang <[email-masked]>
Date: Thu, 26 Sep 2013 14:51:36 +0000

Hello, Lucy
	Thanks for your email. 
	As discussed in this mailing list a few days ago, I believe a WG security draft is needed. But the hartman draft does not contains all the network security requirements.  I feel that there are subtle issues that have not been considered and I plan to expand it on in a draft which I submitted today. The new submitted draft is the text which I believe shall be captured  by the WG security requirements draft. If you have any technical comments, it is welcomed. 

Have a nice day
Zu Qiang

>From: Lucy yong [mailto:[email-masked]]
>Sent: Thursday, September 26, 2013 10:00 AM
>To: Zu Qiang; [email-masked]
>Subject: RE: [nvo3] FW: New Version Notification for draft-zu-nov3-security-
>requirements-00.txt
>
>Hi Zu,
>
>I am curious what is the intent of this draft? The chair has announced the WG
>adoption of draft-hartman-nvo3-security-requirements last week.
>
>Thanks,
>Lucy
>
>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.
>
>The IETF Secretariat
>

---

From: Lucy yong <[email-masked]>
Date: Thu, 26 Sep 2013 15:13:20 +0000

Can you simply propose the text to the Hartman draft (now WG draft)?

I did not follow the discussion in this thread.
Lucy

-----Original Message-----
From: Zu Qiang [mailto:[email-masked]] 
Sent: Thursday, September 26, 2013 9:52 AM
To: Lucy yong; [email-masked]
Subject: RE: [nvo3] FW: New Version Notification for draft-zu-nov3-security-requirements-00.txt

Hello, Lucy
	Thanks for your email. 

Have a nice day
Zu Qiang

>Subject: RE: [nvo3] FW: New Version Notification for 
>draft-zu-nov3-security- requirements-00.txt
>
>Hi Zu,
>
>I am curious what is the intent of this draft? The chair has announced 
>the WG adoption of draft-hartman-nvo3-security-requirements last week.
>
>Thanks,
>Lucy
>
>Subject: [nvo3] FW: New Version Notification for 
>draft-zu-nov3-security- requirements-00.txt
>
>FYI for the group.
>
>Have a nice day
>Zu Qiang
>
>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.
>
>The IETF Secretariat
>

---

From: Zu Qiang <[email-masked]>
Date: Thu, 26 Sep 2013 16:41:24 +0000

Hello,
	The draft submission is just a follow-up of the discussion with Dacheng.  Here is the response I received from Dacheng a few days ago " I think It could be a good idea that you do some analysis work in your draft as well. If the work is solid, then we can ask the WG whether they would like to combine the work together. "	 

Have a nice day
Zu Qiang

>Sent: Thursday, September 26, 2013 11:13 AM
>	As discussed in this mailing list a few days ago, I believe a WG security
>draft is needed. But the hartman draft does not contains all the network
>security requirements.  I feel that there are subtle issues that have not been
>considered and I plan to expand it on in a draft which I submitted today. The
>new submitted draft is the text which I believe shall be captured  by the WG
>security requirements draft. If you have any technical comments, it is
>welcomed.
>
>Have a nice day
>Zu Qiang
>
>
>>__________________________________________________________
>_
>>________
>>
>>Htmlized:        http://tools.ietf.org/html/draft-zu-nov3-security-
>requirements-
>>00
>>
>>
>>Abstract:

---

From: Melinda Shore <[email-masked]>
Date: Thu, 26 Sep 2013 11:48:39 -0800

On 9/26/13 8:41 AM, Zu Qiang wrote:
> Hello, The draft submission is just a follow-up of the discussion
> with Dacheng.  Here is the response I received from Dacheng a few
> days ago " I think It could be a good idea that you do some analysis
> work in your draft as well. If the work is solid, then we can ask the
> WG whether they would like to combine the work together. "

As an IETF old-timer, as a working group chair, and as someone
who really wants to see work moving forward I have to say that
I'd prefer to see more cooperation and less competition.
There's nothing wrong with proposing text on the mailing list -
in fact, it's probably a sounder approach in terms of actually
moving work forward.

That said, I'm not in love with some of what's in your document.
Some of the issues I see are with underspecification and others
are with lack of explanation.  To wit:

Right off the bat you've got a problem with R1.  "High availability"
is one of those terms, like "simple," "scalable," "reliable,"
"secure," and so on that can mean a variety of things and
should probably be either avoided or explained in detail if it
can't be avoided.  In this case I'm pretty sure that HA
mechanisms for NVO3 would have to be out of scope for this
version of the charter.

Similarly, I wouldn't call R2 a requirement but rather a
design consideration.  Either describe in detail what
you mean, or drop it.

R4 and R5, explain what would happen if an attacker impersonated
an endpoint.  What's the relationship between those two
requirements and R6 - is the concern a flooding attack, or what?

Requirements 7 and 8 - why confidentiality?  What information
are you concerned might be exposed, and what are the issues with
exposing it?

As a side issue, I think you're conflating authentication and
integrity - one is applied to a network entity and the other
to traffic.

Isn't R13 an implementation issue?

Don't really understand R17.  But more generally, when you say
"security policies" do you mean things like IPSec policies, or
do you mean device-specific filtering rules?

R23: out of scope

R25: tautological

R27: why?  Isn't this out of scope, anyway?

R28 and R29 are out of scope.

R30 is marketing-speak.

And so on.  Your requirements would benefit from a lot more
explanation, specification, etc.  Dacheng is correct in
asking for some analysis, as there's not a lot in what you've
written.  Drop anything that looks like marketing recommendations.
But most of all, cooperation rather than competition.

Melinda

---

From: Zu Qiang <[email-masked]>
Date: Fri, 27 Sep 2013 14:06:10 +0000

Hello, Melinda
	Thanks for your comments. See inline below.

Have a nice day
Zu Qiang

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Melinda Shore
>Sent: Thursday, September 26, 2013 3:49 PM
>To: [email-masked]
>Subject: Re: [nvo3] FW: New Version Notification for draft-zu-nov3-security-
>requirements-00.txt
>
>> Hello, The draft submission is just a follow-up of the discussion with
>> Dacheng.  Here is the response I received from Dacheng a few days ago
>> " I think It could be a good idea that you do some analysis work in
>> your draft as well. If the work is solid, then we can ask the WG
>> whether they would like to combine the work together. "
>
>As an IETF old-timer, as a working group chair, and as someone who really
>wants to see work moving forward I have to say that I'd prefer to see more
>cooperation and less competition.
>There's nothing wrong with proposing text on the mailing list - in fact, it's
>probably a sounder approach in terms of actually moving work forward.
[Zu Qiang] I totally agree with you that cooperation is more important. As I said early in the mailing list discussion that I would like to support and contribute to the security requirement draft. And here is my contribution. I do agree with you that this is a way moving forward. And it is my intention of the draft submission. 

>Some of the issues I see are with underspecification and others are with lack
>of explanation.  To wit:
>
>"secure," and so on that can mean a variety of things and should probably be
>either avoided or explained in detail if it can't be avoided.  In this case I'm
>pretty sure that HA mechanisms for NVO3 would have to be out of scope for
>this version of the charter.
[Zu Qiang] Just for my clarification, are you saying HA is not in the scope of network security? Or are you saying security is not in the scope of this version of the charter. If "High availability" is the problem, do you have a proposed text? 
The R1 requirement is to avoid DoS / DDOS attacks as a network design requirement. For instance, neither the NVA nor the NVE shall become the bottleneck of the control plane signalling. This is something that can be avoided at NVO3 architecture design, isn't it? 

>
>Similarly, I wouldn't call R2 a requirement but rather a design consideration.
>Either describe in detail what you mean, or drop it.
[Zu Qiang] R2 is a control plane design requirement. It is not a implementation consideration. I can add a bit more explications. 

>
>R4 and R5, explain what would happen if an attacker impersonated an
>endpoint.  What's the relationship between those two requirements and R6 -
>is the concern a flooding attack, or what?
[Zu Qiang] I can add some text to those bullets. 
R3/R4 is a security requirement on the NVA-NVE interface.  
R5/R6 is a security requirement on the NVE-NVE interface.  The NVE-NVE protocol may be used to update the inner-outer address mapping table. 
R5 is to avoid a comprised network component to redirect the traffic to itself, e.g. impersonating as a NVE to update others. NVE authentication could block any such kind attempts. 
R6 is to avoid a comprised NVE to send control plane messages which it is not supposed to send. 

>
>Requirements 7 and 8 - why confidentiality?  What information are you
>concerned might be exposed, and what are the issues with exposing it?
[Zu Qiang] R7/R8 is to avoid the control messages to be intercepted by a comprised network component. The comprised network component, who receives the access to the underlay network, may try to intercept the control traffic in order to find out the weakest point by learning the network architecture and topologic. 

>
>As a side issue, I think you're conflating authentication and integrity - one is
>applied to a network entity and the other to traffic.
[Zu Qiang] Good point. I can split the R7/R8.

>Isn't R13 an implementation issue?
[Zu Qiang] I wouldn't say it is update to implementation which minimum granularity of the security policy management shall be. The standard shall indicate what the minimum requirement is. Then it is up to the implementation if additional granularity of the security policy management it would like to support. 

>
>Don't really understand R17.  But more generally, when you say "security
>policies" do you mean things like IPSec policies, or do you mean device-
>specific filtering rules?
[Zu Qiang] R17 is referring to the generic network security requirement on any incoming public traffic, like a DC firewall function.  

>R23: out of scope
[Zu Qiang] Cross DC connection shall be protected. Otherwise, it becomes the weakest point of the data plane traffic. Is a "MAY" better than a "MUST" if there is a concern? 

>R25: tautological
[Zu Qiang] Do you mean it is covered by another item already? 

>R27: why?  Isn't this out of scope, anyway?
[Zu Qiang] Just for my clarification, what is out of scope, the NVO3 O&M function or the security on the NVO3 O&M traffic? 

>R28 and R29 are out of scope.
[Zu Qiang] I would like to consider this as minimum network requirement. 

>R30 is marketing-speak.
[Zu Qiang] I can try to reword it. Do you have any proposed text?

>
>And so on.  Your requirements would benefit from a lot more explanation,
>specification, etc.  Dacheng is correct in asking for some analysis, as there's not
>a lot in what you've written.  Drop anything that looks like marketing
>recommendations.
[Zu Qiang] Again, I totally agree with you that cooperation is more important. As I said early in the mailing list discussion that I would like to support and contribute to the security requirement draft.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 27 Sep 2013 11:56:25 -0800

On 9/27/13 6:06 AM, Zu Qiang wrote:
> [Zu Qiang] Just for my clarification, are you saying HA is not in the
> scope of network security? Or are you saying security is not in the
> scope of this version of the charter. If "High availability" is the
> problem, do you have a proposed text? The R1 requirement is to avoid
> DoS / DDOS attacks as a network design requirement. For instance,
> neither the NVA nor the NVE shall become the bottleneck of the
> control plane signalling. This is something that can be avoided at
> NVO3 architecture design, isn't it?

I think probably not - part of the problem here is that
you haven't specified what you mean by "high availability"
(and I'll note that underspecification is a consistent
problem throughout your document).  If you're talking about
something like failover, which I think you might be (?),
it's largely orthogonal to the problem of communication
among network elements, and it's hard.  You'd need to deal
with problem around detecting events, moving device state,
and so on.  Out of scope.

I could answer your points one by one but I think that
it'd be a little beside the point, since we have a security
requirements draft that's been accepted by the working group.
A better approach might be to propose individual requirements
on the mailing list and then start discussion around them.

Also, I'll note that you justified having written this draft
by saying that there were subtle security issues in the nvo3
architecture that were not addressed by the security requirements
draft, but you did not explain what those were, nor did you
give the reasoning behind most of your requirements.  And to
be honest, I did not see much of anything that was not in the
working group draft that was both correct and in-scope.

Melinda

---

From: Zu Qiang <[email-masked]>
Date: Sat, 28 Sep 2013 02:18:24 +0000

Hi, Melinda
	First of all, this is requirement document. So solution shall not be specified. Failover is not part of this item. 
	Second, since you don't want to discuss it point by point, let's take one example for our discussion.  Ingress filter can prevent a compromised NVE of sending control plane and data plane traffic which it is not supposed to send. Is this out of the scope of the WG? Another example is that the control plane broadcast address shall be avoided or restricted to avoid a compromised network component to initiate a DRDoS attack by sending request message to the broadcast address, which the control plane may be exploited to act as reflectors of the DNS amplification attacks. Is this requirement out of the WG scope? 
	Again, the hartman draft contains many good security analysis text. However, not all the security requirements are not clearly defined. My draft is only to propose additional text to the hartman draft as discussed in the mailing list. This is the reason that I didn't repeat too many analysis text. 

Have a nice day
Zu Qiang

>Sent: Friday, September 27, 2013 3:56 PM
>To: Zu Qiang
>Cc: [email-masked]
>> neither the NVA nor the NVE shall become the bottleneck of the control
>> plane signalling. This is something that can be avoided at
>I think probably not - part of the problem here is that you haven't specified
>what you mean by "high availability"
>(and I'll note that underspecification is a consistent problem throughout your
>document).  If you're talking about something like failover, which I think you
>might be (?), it's largely orthogonal to the problem of communication among
>network elements, and it's hard.  You'd need to deal with problem around
>detecting events, moving device state, and so on.  Out of scope. 
>
>I could answer your points one by one but I think that it'd be a little beside the
>point, since we have a security requirements draft that's been accepted by
>the working group.
>A better approach might be to propose individual requirements on the mailing
>list and then start discussion around them.
>
>Also, I'll note that you justified having written this draft by saying that there
>were subtle security issues in the nvo3 architecture that were not addressed
>by the security requirements draft, but you did not explain what those were,
>nor did you give the reasoning behind most of your requirements.  And to be
>honest, I did not see much of anything that was not in the working group draft
>that was both correct and in-scope.
>
>Melinda