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

[Eric Rescorla <[e-mail]>]

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.


   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.

-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>
>