Hello, Melinda
Thanks for your comments. See inline below.
Have a nice day
Zu Qiang
>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On Behalf Of
>Melinda Shore
>Sent: Thursday, September 26, 2013 3:49 PM
>To: [email protected]
>Subject: Re: [nvo3] FW: New Version Notification for draft-zu-nov3-security-
>requirements-00.txt
>
>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.
[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.
>
>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.
[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.
>But most of all, cooperation rather than competition.
[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.
>
>Melinda
>_______________________________________________
>nvo3 mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
