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
>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On Behalf Of
>Melinda Shore
>Sent: Friday, September 27, 2013 3:56 PM
>To: Zu Qiang
>Cc: [email protected]
>Subject: Re: [nvo3] FW: New Version Notification for draft-zu-nov3-security-
>requirements-00.txt
>
>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
>_______________________________________________
>nvo3 mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
