Re: [I2nsf] AD Review of draft-ietf-i2nsf-applicability-07

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Eric,
I discussed with my authors about your last two comments.
I put the answers inline below.

On Fri, Dec 28, 2018 at 4:09 AM Eric Rescorla <[e-mail]> wrote:

>
>
> On Thu, Dec 27, 2018 at 7:21 PM Mr. Jaehoon Paul Jeong <
> [e-mail]> wrote:
>
>> Eric,
>> Let me answer your further questions below.
>>
>> On Thu, Dec 27, 2018 at 11:59 PM Eric Rescorla <[e-mail]> wrote:
>>
>>>
>>>
>>> On Wed, Dec 26, 2018 at 6:42 PM Mr. Jaehoon Paul Jeong <
>>> [e-mail]> wrote:
>>>
>>>> Hi Eric,
>>>> Here are my answers inlines below.
>>>>
>>>> On Thu, Dec 27, 2018 at 3:44 AM Eric Rescorla <[e-mail]> wrote:
>>>>
>>>>> Paul,
>>>>>
>>>>> Thanks for your new version. Some responses below.
>>>>>
>>>>>
>>>>> On Tue, Dec 25, 2018 at 6:42 AM Mr. Jaehoon Paul Jeong <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> Hi Eric, Linda and Yoav,
>>>>>> I have reflected all the comments from Eric and submitted the
>>>>>> revision -08 as follows:
>>>>>> https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-08
>>>>>>
>>>>>> The changes are described in Appendix A of -08 document as follows:
>>>>>>
>>>>>> -------------------------------------------------------------------------------------------------
>>>>>> Appendix A.  Changes from draft-ietf-i2nsf-applicability-07
>>>>>>
>>>>>>    The following changes have been made from
>>>>>>    draft-ietf-i2nsf-applicability-07:
>>>>>>
>>>>>>    o  This version has reflected all the comments from Eric Rescorla
>>>>>> who
>>>>>>       is a Security Area Director as follows.
>>>>>>
>>>>>>    o  In Section 1, Network Security Function (NFV) is defined in the
>>>>>>       viewpoint of the I2NSF framework.
>>>>>>
>>>>>>    o  In Section 1, a user using the I2NSF User is clarified as a
>>>>>> system
>>>>>>       administrator in the I2NSF framework.
>>>>>>
>>>>>>    o  In Section 1, as the applicability of the I2NSF framework, four
>>>>>>       different scenarios are represented with a standard bulleted
>>>>>> list.
>>>>>>
>>>>>>    o  The standard document about ETSI-NFV is moved to Normative
>>>>>>       References.
>>>>>>
>>>>>>    o  In Section 2, key terms (e.g., Network Function, Network
>>>>>> Security
>>>>>>       Function, Network Functions Virtualization, and Servive Function
>>>>>>       Chaining) are internally defined along with the reference to
>>>>>> open
>>>>>>       specifications.
>>>>>>
>>>>>>    o  In Section 2, the definition of Firewall is corrected such that
>>>>>>       some suspicious packets are inspected by the firewall rather
>>>>>> than
>>>>>>       every packet.
>>>>>>
>>>>>>    o  In Section 3, for a Developer's Management System, the problem
>>>>>> of
>>>>>>       an inside attacker is addressed, and a possible solution for the
>>>>>>       inside attacks is suggested through I2NSF NSF monitoring
>>>>>>       functionality.
>>>>>>
>>>>>
>>>>> I'm still pretty concerned about this. Standardizing a situation in
>>>>> which the
>>>>> developer of your firewall has real-time management-level access to
>>>>> that firewall seems extremely insecure, especially when that access is
>>>>> authenticated via conventional credentials that are online as part of
>>>>> the transaction (as opposed to software builds which can be signed
>>>>> offline). This doesn't seem like a best practice. Why is it necessary?
>>>>>
>>>>
>>>>
>>>>>  =>  The developer of a firewall does not have real-time
>>>> management-level access
>>>>        even though its management system works the control plane as
>>>> part of the I2NSF system.
>>>>        The developer's management system provides the Security
>>>> Controller with
>>>>        the interface (i.e., Registration Interface) that is used to
>>>> register the capability of
>>>>        the developer's security network function (i.e., firewall), to
>>>> search an NSF for the required capability for a high-level security policy,
>>>> and to help the lifecycle management
>>>>        of such an NSF for the Security Controller through an NFV
>>>> interface (i.e., Ve-Vnfm interface) with the NFV's MANO.
>>>>
>>>
>>> I don't understand the distinction you are drawing here. Under what
>>> conditions can the developer modify the behavior of the I2NSF system? Can
>>> it do so at any time and without explicit action by the admin.
>>>
>>>  =>  The developer means a security solution vendor (e.g., McAfee and
>> Symantec) who provides the I2NSF system with security solutions,
>>        such as firewall, web filter, DPI, IDS/IPS, and DDoS-attack
>> mitigator. Actually, the developer's management system
>>        cannot modify the behavior of the I2NSF system in run-time as long
>> as the vendor doesn't have any backdoor to
>>        their developer's management system.
>>        This developer's management system facilitates the security
>> service government by the Security Controller
>>        by providing the Security Controller with the Registration
>> Interface for the capability registration and
>> instantiation/de-instantiation
>>        of the image of a security service function.
>>        Thus, only the administrator can modify the behavior of the I2NSF
>> system.
>>
>>        Maybe,
>>        Diego Lopez can clarify my answer because he is the editor of RFC
>> 8329 (Framework for Interface to Network Security Functions):
>>        https://tools.ietf.org/html/rfc832
>> <https://tools.ietf.org/html/rfc8329>
>>
>
> Yeah, I'm not really following this. What functions can the Developer
> perform on the system.
>

 => Your comments make sense to me. I would like to put the following text
in our draft.
      The role of the developer's management system (DMS) should be
restricted to providing an I2NSF system
      with the software package/image for NSF execution, and the DMS should
never be able to access NSFs
      in online/activated status for the I2NSF system's security. On the
other hand, an access to running (online)
      NSFs should be allowed only to the security controller, not the DMS.


>
>
>    o  In Section 4, an XML file for the RESTCONF/YANG for the time-
>>>>>>       dependent web access control is pointed out with a reference to
>>>>>>       the Consumer-Facing Interface's data model
>>>>>>       [consumer-facing-inf-dm].
>>>>>>
>>>>>
>>>>> I didn't follow this change. The example you give of a high level
>>>>> security
>>>>> policy is clearly freeform text and then you talk about XML. Is this
>>>>> just
>>>>> example a summary of the semantics of something which would actually
>>>>> be an
>>>>> XML file? Something else?
>>>>>
>>>>
>>>>   => Even though the high-level security policy looks like a freeform
>>>> text,  it is formatted
>>>>       in an XML according to the high-level security policy YANG model
>>>> for the Consumer-Facing Interface.
>>>>       Yes, it is just an example of a summary of the semantics for such
>>>> a high-level security policy,
>>>>       which is represented as an XML file.
>>>>       Here it an XML file for the web filter from the Consumer-Facing
>>>> Interface Data Model document
>>>>       (
>>>> https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-02
>>>> ):
>>>>
>>>>       You can see the XML file from
>>>>
>>>> https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-02#page-49
>>>>
>>>>       <?xml version="1.1" encoding="UTF-8"?>
>>>>  <rpc message-id="4" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0">
>>>>   <edit-config>
>>>>    <target>
>>>>     <running/>
>>>>    </target>
>>>>     <config>
>>>>      <i2nsf-cf-interface-wf-req nc:operation="create">
>>>>          <policy-wf>
>>>>              <rule-wf>
>>>>                  <rule-wf-id>03</rule-wf-id>
>>>>                  <rule-wf-name>wf-policy-example</rule-wf-name>
>>>>                  <rule-wf-date>2018.10.26/14:03:17</rule-wf-date>
>>>>                  <event>
>>>>                      <event-id>04</event-id>
>>>>                      <event-name>wf</event-name>
>>>>                      <event-date>2018.10.26/14:03:17</event-date>
>>>>                      <event-type>wf</event-type>
>>>>                      <event-map-group>04</event-map-group>
>>>>                      <enable>True</enable>
>>>>                  </event>
>>>>                  <condition>
>>>>                      <condition-id>04</condition-id>
>>>>                      <source-ip>192.168.1.3</source-ip>
>>>>                      <destination-url>www.facebook.com
>>>> </destination-url>
>>>>                      <time-information>
>>>>                          <begin-time>09:00</begin-time>
>>>>                          <end-time>18:00</end-time>
>>>>                      </time-information>
>>>>                      <match-direction>default</match-direction>
>>>>                      <exeption>00</exeption>
>>>>                  </condition>
>>>>                  <action>
>>>>                      <action-id>04</action-id>
>>>>                      <action-name>action-wf</action-name>
>>>>                      <action-date>2018.10.26/14:03:17</action-date>
>>>>                      <primary-action>REJECT</primary-action>
>>>>                      <secondary-action>LOG</secondary-action>
>>>>                  </action>
>>>>                  <precedence>none</precedence>
>>>>                <owner>
>>>>                  <owner-id>03</owner-id>
>>>>                  <name>i2nsf-admin</name>
>>>>                </owner>
>>>>              </rule-wf>
>>>>          </policy-wf>
>>>>      </i2nsf-cf-interface-wf-req>
>>>>     </config>
>>>>   </edit-config>
>>>>  </rpc>
>>>>   => In the above, source ip is used for the employees.
>>>>   Instead of the source ip, we can make and use "source group" for
>>>> employees that can be translated
>>>>   into a set of IP addresses of the source group.
>>>>
>>>
>>> You need to make this clear, then. It would probably be easier to just
>>> show the XML and then provide the text summary.
>>>
>>>   => Okay. I will include a simplified example XML code for web filter
>> and provide the text summary as below.
>>
>>    This service scenario assumes that an enterprise network
>>    administrator wants to control the staff members' access to a
>>    particular Internet service (e.g., Example.com) during business
>>    hours.  The following is an example high-level security policy rule
>>    for a web filter that the administrator requests: Block the staff
>> members' access to Example.com from 9 AM to 6 PM.
>>    Here is an example XML code for this web filter:
>> <I2NSF>
>>     <name>block_website</name>
>>         <cond>
>>             <src>Staff_Member's_PC</src>
>>             <dest>Example.com</dest>
>>     <time-span-start>9:00AM</time-span-start>
>>             <time-span-end>-6:00PM</time-span-end>
>>         </cond>
>>         <action>block<action>
>> </I2NSF>
>>
>>    The security policy name is "bloc_website" with the tag "name".
>>    The filtering condition has the source group "Staff_Member's_PC" with
>> the tag "src",
>>    the destination website "Example.com" with the tag "dest",
>>    the filtering start time is the time "9:00AM" with the tag "
>> time-span-start",
>>    and the filtering end time is the time "6:00PM" with the tag "
>> time-span-end".
>>    The action is to "block" the packets satisfying the above condition,
>>    that is, to drop those packets
>>
>
> LGTM.
>
>
>
>>
>>>
>>>    o  In Section 6, the definitions of an SDN forwarding element and an
>>>>>>       NSF are clarified such that an SDN forwarding element is a
>>>>>> switch
>>>>>>       running as either a hardware middle box or a software virtual
>>>>>>       switch, and an NSF is a virtual network function for a security
>>>>>>       service.
>>>>>>
>>>>>
>>>>> This wasn't clear to me either. Based on this text it would seem that
>>>>> you could run an NSF on an SDN element, so it's not clear why they
>>>>> are disjoint sets. Can you give me more information here?
>>>>>
>>>>
>>>>  => An SDN switch can run as a virtual network function like an NSF,
>>>> but the main functionality of the SDN switch is packet forwarding with a
>>>> flow table along with simple filtering rules. More complicated security
>>>> services can be done at dedicated NSFs. For example, there is the Open
>>>> Virtual Switch (OVS) project for such a software-based SDN switch:
>>>> https://www.openvswitch.org
>>>>
>>>> Thus, the SDN switches and NSFs are logically disjoint sets though all
>>>> of them  can run physically as virtual network functions.
>>>>
>>>
>>> I'm sorry, this still isn't clear, at least to me. How can I look at a
>>> given software element and determine whether it's an NSF or a virtualized
>>> SDN switch?
>>>
>>
>>  => The distinction is logically done such that the NFV system having the
>> I2NSF system categorizes some VNFs as NSFs for dedicated security services
>>       and some VNFs as virtualized SDN switches for packet switching and
>> simple filtering rule enforcement.
>>
>>      If there is an expert in the NFV, please let us know for further
>> clarification.
>>
>
> I'm not following this either, so that would definitely help.
>

 => I would like to clarify your question as follows in the text:
      In the NFV MANO, there is a subsystem that maintains the descriptions
of the capabilities each VNF can offer.
      This subsystem can determine whether a given software element (VNF
instance) is an NSF or a virtualized SDN switch.
      For example, if a VNF instance has anti-malware capability according
to the description of the VNF, it could be
      considered as an NSF. And the VNF onboarding system (
https://wiki.opnfv.org/display/mano/VNF+Onboarding) can be
      used as such subsystem that maintains the descriptions of each VNF to
tell whether an VNF instance is for an NSF or
      for a virtualized SDN switch.

     Eric,
     if these two last answers are fine to you, could we move forward with
the draft?

     Thanks.

     Best Regards,
     Paul


>
> -Ekr
>
>
>>      Thanks.
>>
>>      Best Regards,
>>      Paul
>>
>>
>>>
>>> -Ekr
>>>
>>>>
>>>> If you have further questions, please let me know.
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>> Paul
>>>>
>>>>>
>>>>> -Ekr
>>>>>
>>>>>
>>>>>>    o  In Section 6.3, a flow forwarding path management scheme in
>>>>>>       [AVANT-GUARD] is described in a self-contained way as follows.
>>>>>>       For DDoS-attack mitigation, the forwarding of traffic flows in
>>>>>>       switches can be dynamically configured such that malicious
>>>>>> traffic
>>>>>>       flows are handled by the paths separated from normal traffic
>>>>>> flows
>>>>>>       in order to minimize the impact of those malicious traffic on
>>>>>> the
>>>>>>       the servers.  This flow path separation can be done by a flow
>>>>>>       forwarding path management scheme based on [AVANT-GUARD].
>>>>>>
>>>>>>    o  Some typos are corrected such as "Interner -> Internet",
>>>>>>       "Registation -> Registration", "The low-level security rules for
>>>>>>       web filter checks -> The low-level security rules for web filter
>>>>>>       check", "fltering -> filtering", "illegal packets -> malicious
>>>>>>       packets", "manipulate rules -> configure rules", "managenent ->
>>>>>>       management", and "DDoS-attack mitigation operations ->
>>>>>> DDoS-attack
>>>>>>       mitigation".
>>>>>>
>>>>>> -------------------------------------------------------------------------------------------------
>>>>>>
>>>>>> Thanks and Merry Christmas!
>>>>>>
>>>>>> Best Regards,
>>>>>> Paul
>>>>>>
>>>>>> On Fri, Dec 21, 2018 at 11:33 PM Eric Rescorla <[e-mail]> wrote:
>>>>>>
>>>>>>> Rich version of this review at:
>>>>>>> https://mozphab-ietf.devsvcdev.mozaws.net/D3181
>>>>>>>
>>>>>>>
>>>>>>> I found a number of typographical and grammar errors. Please give
>>>>>>> this
>>>>>>> document a thorough read.
>>>>>>>
>>>>>>> IMPORTANT
>>>>>>> S 1.
>>>>>>> >
>>>>>>> >      Interface to Network Security Functions (I2NSF) defines a
>>>>>>> framework
>>>>>>> >      and interfaces for interacting with Network Security Functions
>>>>>>> >      (NSFs).  The I2NSF framework allows heterogeneous NSFs
>>>>>>> developed by
>>>>>>> >      different security solution vendors to be used in the Network
>>>>>>> >      Functions Virtualization (NFV) environment [ETSI-NFV] by
>>>>>>> utilizing
>>>>>>>
>>>>>>> Much of this document cannot be understood without reading ETSI-NFV,
>>>>>>> so it has to be a normative reference. It also would be helpful to
>>>>>>> provide a link.
>>>>>>>
>>>>>>>
>>>>>>> S 2.
>>>>>>> >      This document uses the terminology described in [RFC7149],
>>>>>>> >      [ITU-T.Y.3300], [ONF-OpenFlow], [ONF-SDN-Architecture],
>>>>>>> >      [ITU-T.X.1252], [ITU-T.X.800], [RFC8329], [i2nsf-terminology],
>>>>>>> >      [consumer-facing-inf-im], [consumer-facing-inf-dm],
>>>>>>> >      [i2nsf-nsf-cap-im], [nsf-facing-inf-dm],
>>>>>>> [registration-inf-dm], and
>>>>>>> >      [nsf-triggered-steering].  In addition, the following terms
>>>>>>> are
>>>>>>>
>>>>>>> Every term in this document needs to be understandable without
>>>>>>> reference to closed specifications or internally defined. Please
>>>>>>> ensure that this is so,
>>>>>>>
>>>>>>>
>>>>>>> S 3.
>>>>>>> >      used for the I2NSF NSF-Facing Interface.
>>>>>>> >
>>>>>>> >      The Registration Interface between the Security Controller
>>>>>>> and the
>>>>>>> >      Developer's Management System can be implemented by RESTCONF
>>>>>>> >      [RFC8040].  The data model defined in [registration-inf-dm]
>>>>>>> can be
>>>>>>> >      used for the I2NSF Registration Interface.
>>>>>>>
>>>>>>> What role does the Developer's Management System play in this? I
>>>>>>> think
>>>>>>> this refers to the text above starting with "The developers (or
>>>>>>> vendors)...". Is that correct?
>>>>>>>
>>>>>>> Assuming I am correct, this seems like a potentially serious security
>>>>>>> vulnerability in this design in that it potentially allows an inside
>>>>>>> attacker at the developer to seriously weaken a system's security.
>>>>>>> What protections exist to prevent this?
>>>>>>>
>>>>>>>
>>>>>>> S 4.
>>>>>>> >      administrator wants to control the staff members' access to a
>>>>>>> >      particular Interner service (e.g., Example.com) during
>>>>>>> business
>>>>>>> >      hours.  The following is an example high-level security
>>>>>>> policy rule
>>>>>>> >      that the administrator requests: Block the staff members'
>>>>>>> access to
>>>>>>> >      Example.com from 9 AM to 6 PM.  The administrator sends this
>>>>>>> high-
>>>>>>> >      level security policy to the Security Controller, then the
>>>>>>> Security
>>>>>>>
>>>>>>> The text above suggests that high-level policies are via
>>>>>>> RESTCONF/YANG, but this is clearly freeform text.
>>>>>>> COMMENTS
>>>>>>> S 1.
>>>>>>> >
>>>>>>> >   1.  Introduction
>>>>>>> >
>>>>>>> >      Interface to Network Security Functions (I2NSF) defines a
>>>>>>> framework
>>>>>>> >      and interfaces for interacting with Network Security Functions
>>>>>>> >      (NSFs).  The I2NSF framework allows heterogeneous NSFs
>>>>>>> developed by
>>>>>>>
>>>>>>> Please define "Network Security Functions" here.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> S 1.
>>>>>>> >      functions in the NFV platform.  In the I2NSF framework, each
>>>>>>> NSF
>>>>>>> >      initially registers the profile of its own capabilities into
>>>>>>> the
>>>>>>> >      system in order for themselves to be available in the
>>>>>>> system.  In
>>>>>>> >      addition, the Security Controller is validated by the I2NSF
>>>>>>> Client
>>>>>>> >      (also called I2NSF User) that the user is employing, so that
>>>>>>> the user
>>>>>>> >      can request security services through the Security Controller.
>>>>>>>
>>>>>>> In this case the user is the system administrator.
>>>>>>>
>>>>>>>
>>>>>>> S 1.
>>>>>>> >      [RFC7149] to provide different security functionality such as
>>>>>>> >      firewalls [opsawg-firewalls], Deep Packet Inspection (DPI),
>>>>>>> and
>>>>>>> >      Distributed Denial of Service (DDoS) attack mitigation; (iv)
>>>>>>> the use
>>>>>>> >      of NFV as supporting technology.  The implementation of I2NSF
>>>>>>> in
>>>>>>> >      these scenarios has allowed us to verify the applicability and
>>>>>>> >      effectiveness of the I2NSF framework for a variety of use
>>>>>>> cases.
>>>>>>>
>>>>>>> This would be easier to read with a standard bulleted list.
>>>>>>>
>>>>>>>
>>>>>>> S 2.
>>>>>>> >         network resources, which facilitates the design, delivery
>>>>>>> and
>>>>>>> >         operation of network services in a dynamic and scalable
>>>>>>> manner
>>>>>>> >         [ITU-T.Y.3300].
>>>>>>> >
>>>>>>> >      o  Firewall: A service function at the junction of two network
>>>>>>> >         segments that inspects every packet that attempts to cross
>>>>>>> the
>>>>>>>
>>>>>>> Nit: It might not inspect *every* packet.
>>>>>>>
>>>>>>>
>>>>>>> S 4.
>>>>>>> >
>>>>>>> >   4.  Time-dependent Web Access Control Service
>>>>>>> >
>>>>>>> >      This service scenario assumes that an enterprise network
>>>>>>> >      administrator wants to control the staff members' access to a
>>>>>>> >      particular Interner service (e.g., Example.com) during
>>>>>>> business
>>>>>>>
>>>>>>> Nit: "Internet"
>>>>>>>
>>>>>>>
>>>>>>> S 4.
>>>>>>> >      inspection capability is required to check whether the target
>>>>>>> URL of
>>>>>>> >      a received packet is in the Example.com domain or not.
>>>>>>> >
>>>>>>> >      The Security Controller maintains the security capabilities
>>>>>>> of each
>>>>>>> >      NSF running in the I2NSF system, which have been reported by
>>>>>>> the
>>>>>>> >      Developer's Management System via the Registation interface.
>>>>>>> Based
>>>>>>>
>>>>>>> Nit: "Registration"
>>>>>>>
>>>>>>>
>>>>>>> S 4.
>>>>>>> >      currently using the network.  Based on the retrieved
>>>>>>> information, the
>>>>>>> >      Security Controller generates low-level security rules to
>>>>>>> check
>>>>>>> >      whether the source IP address of a received packet matches
>>>>>>> any one
>>>>>>> >      being used by a staff member.  In addition, the low-level
>>>>>>> security
>>>>>>> >      rules should be able to determine that a received packet is
>>>>>>> of HTTP
>>>>>>> >      protocol.  The low-level security rules for web filter checks
>>>>>>> that
>>>>>>>
>>>>>>> Nit: "rules"... "checks" disagree.
>>>>>>>
>>>>>>>
>>>>>>> S 6.
>>>>>>> >      translated into their packet forwarding rules, whereas NSFs
>>>>>>> enforce
>>>>>>> >      NSF-related security rules requiring the security
>>>>>>> capabilities of the
>>>>>>> >      NSFs.  For this purpose, the Security Controller instructs
>>>>>>> the SDN
>>>>>>> >      Controller via NSF-Facing Interface so that SDN forwarding
>>>>>>> elements
>>>>>>> >      can perform the required security services with flow tables
>>>>>>> under the
>>>>>>> >      supervision of the SDN Controller.
>>>>>>>
>>>>>>> I'm having some trouble understanding the difference here between
>>>>>>> NSFs
>>>>>>> and SDN elements. They both seem to be software controlled network
>>>>>>> elements. Is this just some continuum about CPU power?
>>>>>>>
>>>>>>>
>>>>>>> S 6.
>>>>>>> >      can perform the required security services with flow tables
>>>>>>> under the
>>>>>>> >      supervision of the SDN Controller.
>>>>>>> >
>>>>>>> >      As an example, let us consider two different types of
>>>>>>> security rules:
>>>>>>> >
>>>>>>> >      Rule A is a simple packet fltering rule that checks only the
>>>>>>> IP
>>>>>>>
>>>>>>> Nit: "filtering"
>>>>>>>
>>>>>>>
>>>>>>> S 6.2.
>>>>>>> >          packets that have the same call-id.
>>>>>>> >
>>>>>>> >      6.  The SDN Controller installs new rules (e.g., drop
>>>>>>> packets) into
>>>>>>> >          underlying switches.
>>>>>>> >
>>>>>>> >      7.  The illegal packets are dropped by these switches.
>>>>>>>
>>>>>>> "Illegal" is probably the wrong wrod here.
>>>>>>>
>>>>>>>
>>>>>>> S 6.3.
>>>>>>> >         is helpful to determine security policies for such a
>>>>>>> network.
>>>>>>> >
>>>>>>> >   6.3.  Attack Mitigation: Centralized DDoS-attack Mitigation
>>>>>>> System
>>>>>>> >
>>>>>>> >      A centralized DDoS-attack mitigation can manage each network
>>>>>>> resource
>>>>>>> >      and manipulate rules to each switch through a common server
>>>>>>> for DDoS-
>>>>>>>
>>>>>>> "manipulate rules to" is not grammatical.
>>>>>>>
>>>>>>>
>>>>>>> S 6.3.
>>>>>>> >
>>>>>>> >      Servers are categorized into stateless servers (e.g., DNS
>>>>>>> servers)
>>>>>>> >      and stateful servers (e.g., web servers).  For DDoS-attack
>>>>>>> >      mitigation, traffic flows in switches are dynamically
>>>>>>> configured by
>>>>>>> >      traffic flow forwarding path management according to the
>>>>>>> category of
>>>>>>> >      servers [AVANT-GUARD].  Such a managenent should consider the
>>>>>>> load
>>>>>>>
>>>>>>> 1. This seems hard to understand without this reference, which is not
>>>>>>> public.
>>>>>>> 2. "management"
>>>>>>>
>>>>>>>
>>>>>>> S 6.3.
>>>>>>> >      mitigation, traffic flows in switches are dynamically
>>>>>>> configured by
>>>>>>> >      traffic flow forwarding path management according to the
>>>>>>> category of
>>>>>>> >      servers [AVANT-GUARD].  Such a managenent should consider the
>>>>>>> load
>>>>>>> >      balance among the switches for the defense against DDoS
>>>>>>> attacks.
>>>>>>> >
>>>>>>> >      The procedure of DDoS-attack mitigation operations in this
>>>>>>> system is
>>>>>>>
>>>>>>> "procedure of... operations" is ungrammatical
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> ===========================
>>>>>> Mr. Jaehoon (Paul) Jeong, Ph.D.
>>>>>> Associate Professor
>>>>>> Department of Software
>>>>>> Sungkyunkwan University
>>>>>> Office: [phone]
>>>>>> Email: [e-mail]
>>>>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
>>>>>> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> ===========================
>>>> Mr. Jaehoon (Paul) Jeong, Ph.D.
>>>> Associate Professor
>>>> Department of Software
>>>> Sungkyunkwan University
>>>> Office: [phone]
>>>> Email: [e-mail], [e-mail]
>>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
>>>> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>>>>
>>>
>>
>> --
>> ===========================
>> Mr. Jaehoon (Paul) Jeong, Ph.D.
>> Associate Professor
>> Department of Software
>> Sungkyunkwan University
>> Office: [phone]
>> Email: [e-mail], [e-mail]
>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
>> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>>
>

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>