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

[Roman Danyliw <[e-mail]>]

Hi Paul!

Thanks for this revision and all of the iteration. I’ve advanced the document to IETF LC.

Roman

On Jun 22, 2019, at 8:13 AM, Mr. Jaehoon Paul Jeong <[e-mail]<mailto:[e-mail]>> wrote:

Hi Roman,
Thanks for your quick review.

I have reflected your suggested text on #12 in Section 8 and
the mention about the lifecycle management from DMS in Section 3
on the version -13:
https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-13

- New Text for Security Issues and Discussion on DMS in Section 8
   The role of the DMS is to provide an I2NSF system with the software
   packages or images for NSF execution.  The DMS must not access NSFs
   in activated status.  An inside attacker or a supply chain attacker
   at the DMS can seriously weaken the I2NSF system's security.  A
   malicious DMS is relevant to an insider attack, and a compromised DMS
   is relevant to a supply chain attack.  A malicious (or compromised)
   DMS could register an NSF of its choice in response to a capability
   request by the Security Controller.  As a result, a malicious DMS can
   attack the I2NSF system by providing malicious NSFs with arbitrary
   capabilities to include potentially controlling those NSFs in real
   time.  An unwitting DMS could be compromised and the infrastructure
   of the DMS could be coerced into distributing modified NSFs as well.

   To deal with these types of threats, an I2NSF system should not use
   NSFs from an untrusted DMS or without prior testing.  The practices
   by which these packages are downloaded and loaded into the system are
   out of scope for I2NSF.

   I2NSF system operators should audit and monitor interactions with
   DMSs.  Additionally, the operators should monitor the running NSFs
   through the I2NSF NSF Monitoring Interface [nsf-monitoring-dm] as
   part of the I2NSF NSF-Facing Interface.  Note that the mechanics for
   monitoring the DMSs are out of scope for I2NSF.

- Mention about the Lifecycle Management from DMS in Section 3
   As shown in Figure 1, with a Developer's Management System (called
   DMS), developers (or vendors) inform the Security Controller of the
   capabilities of the NSFs through the Registration Interface
   [registration-inf-dm] for registering (or deregistering) the
   corresponding NSFs.  Note that the lifecycle management of NSF code
   from DMS (e.g., downloading of NSF modules and testing of NSF code)
   is out of scope for I2NSF.

Please let this draft go under the IESG submission.

Thanks for your help.

Best Regards,
Paul


On Sat, Jun 22, 2019 at 5:46 AM Roman Danyliw <[e-mail]<mailto:[e-mail]>> wrote:
Hello Paul!

Thanks for the revised text and answering all of my questions.  I have a few recommended text changes per items #12 below.  All other items have been addressed.

Thanks,
Roman

> From: Mr. Jaehoon Paul Jeong [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Tuesday, June 18, 2019 5:15 AM
> To: Roman Danyliw <[e-mail]<mailto:[e-mail]>>
> Cc: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; Yoav Nir <[e-mail]<mailto:[e-mail]>>;
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> Mr. Jaehoon Paul Jeong <[e-mail]<mailto:[e-mail]>>
> Subject: Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicability-09
>
> Hi Roman,
> I have addressed all of your comments again and submitted version -12:
> https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-12
>
> I attach my revision letter.
>
> Could you confirm that my addressing is good enough to move this
> draft forward to the IESG submission?
>
> Thanks.
>
> Best Regards,
> Paul
> > -----Original Message-----
> > From: I2nsf [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Roman Danyliw
> > Sent: Tuesday, June 4, 2019 6:35 PM
> > To: Mr. Jaehoon Paul Jeong <[e-mail]<mailto:[e-mail]>>; Linda Dunbar
> > <[e-mail]<mailto:[e-mail]>>; Yoav Nir <[e-mail]<mailto:[e-mail]>>
> > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> > Subject: Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicability-09
> >
> > Hello Paul!
> >
> > Thank you for the extensive changes you have made.  See follow-up
> > questions below.  If you don't see a previous item listed, please
> > consider it resolved.
> >
> > Since your comments were made with a word attachment (no problem!),
> > I'm just responding to my own original thread.
> >
> > > From: I2nsf [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Mr. Jaehoon
> > > Paul Jeong
> > > Sent: Thursday, May 02, 2019 5:13 AM
> > > To: Roman Danyliw <[e-mail]<mailto:[e-mail]>>; Linda Dunbar
> > > <[e-mail]<mailto:[e-mail]>>; Yoav Nir <[e-mail]<mailto:[e-mail]>>
> > > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> > > Subject: Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicability-09
> > >
> > > Hi Roman, Linda, and Yoav,
> > > I have reflected Roman's questions and comments in I2NSF
> > > Applicability Draft (version 10).
> > > Here is the link of the revised draft:
> > > https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-10
> > >
> > > I send you my revision letter that describes my answers and
> > > reflection in the text.
> > >
> > > If you have questions and comments, please let me know.
> > >
> > > Thanks.
> > >
> > > Best Regards,
> > > Paul
> > >
> > >
> > > On Wed, Apr 17, 2019 at 9:23 PM Roman Danyliw <[e-mail]<mailto:[e-mail]>> wrote:
> > > Hi!
> > >
> > > I'm picking up where ekr left off
> > >
> >
> (https://mailarchive.ietf.org/arch/msg/i2nsf/bVTGfSXR70UcFkwfkV4FsNHg8
> > > uo) with an AD review of draft-ietf-i2nsf-applicability-09.
> >
> > [snip]
> >
> > > (5) Section 1.  Per "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", this sentence
> > > doesn't parse
> > for me.
> > >
> > > Do you mean, "In the I2NSF framework, each NSF initially registers a
> > > profile of its capabilities in the system"?  If so, I think clarity
> > > of what system (I think "I2NSF system") is being referenced is needed.
> >
> > Per -11, I’d recommend making the text even more concise.
> >
> > OLD: In the I2NSF framework, each NSF initially registers the profile of its
> > own capabilities into the Security    Controller (i.e., network operator
> > management system [RFC8329]) in the I2NSF system via Registration
> > Interface [registration-inf-dm] so that each   NSF can be selected and used
> to
> > enforce a given security policy from I2NSF User (i.e., network
> > security administrator).
> >
> > NEW:
> > In the I2NSF framework, each NSF initially registers the profile of
> > its own capabilities with the Security Controller (i.e., network
> > operator management system [RFC8329]) of the I2NSF system via the
> > Registration Interface [registration-inf-dm].  This registration
> > enables an I2NSF User (i.e., network security administrator) to select
> > and use the NSF to enforce a given security policy.

Thanks for making the change.

> > > (6) Section 1.  Per "In addition, the Security Controller ...", this
> > > sentence introduces the concept of a Security Controller but doesn't
> > > define it.  Also, this seems like a level of detail not needed in
> > > the
> > introduction.
> >
> > I appreciate all of the new text in -11, but I don't think we need all
> > of it.  My concern is that some of it will unnecessarily duplicates
> > text already in Section 3 and [i2nsf-terminology].  The new text
> > “(i.e., network operator management system [RFC8329]).” sufficiently
> > defines the controller.  The new text “Security Controller is defined as …”
> isn’t needed.

Thanks for making this change.

> > > (11) Section 3.  Per "Note that an inside attacker at the DMS can
> > > seriously weaken the I2NSF system ...", I concur with the assessment
> > > that a DMS can subvert the I2NSF system.  Three related points:
> > >
> > > ** The boundary/scope of an I2NSF system wasn't  clear to me.  It
> > > appears to me that an I2NSF system is security controller + NSFs.
> > > There are several interfaces defined for the controller and NSFs.
> > > Everything else (e.g., DMS, I2NSF user) is outside the scope of the
> > > I2NSF system, correct?  I draw attention to this distinction because
> > > identifying where this insider is located needs to be clearer.
> > >
> > > ** If the DMS can provide the software package for the NSF, I'm not
> > > sure how the insider threat is mitigated.  The attacker can already
> > > run a software load of her choice on your network (that you have
> > permitted).
> > >
> > > ** Per
> > >
> >
> https://mailarchive.ietf.org/arch/msg/i2nsf/Xc92QkEPgRWC3FKuRvnaiNNFY
> > 2
> > > o, I concur with ekr that the text needs to be clearer on what the
> > > DMS can do to the I2NSF system.
> >
> > Despite the changes in -11, I still need help understanding the flow
> > between the security controller and DMS.  Like ekr posed in the thread
> > above, I’m trying to understand how the software is loaded into the
> > production I2NSF system.
> >
> > As I understand it, we’re talking about a software update process
> > facilitated through a NETCONF interface via the Internet.  Section 5
> > of draft-hyun-i2nsf- registration-interface-dm says:
> >
> >    1)  Security Controller first recognizes the set of capabilities
> >        (i.e., NSF Profile) or the signature of a specific NSF required
> >        or wasted in the current system.
> >
> >    2)  Developer's Management System (DMS) matches the recognized
> >        information to an NSF based on the information model definition.
> >
> >    3)  Developer's Management System creates or eliminates NSFs matching
> >        with the above information.
> >
> >    4)  Security Controller can then add/remove the corresponding NSF
> >        instance to/from its list of available NSF instances in the
> >        system.
> >
> > To test my understanding, the user interface sends a high-level action
> > to the Security Controller (SC); the SC sends to the DMS what
> > capabilities it wants; the DMS returns back what NSF
> > (modules/packages/code) it has that meet these capabilities; the SC
> > can then choose to download these NSF
> > (modules/package/code) from the DMS and provision these newly
> > downloaded NSF (modules/package/code) into the live system.  Is this
> > correct?
> >
> > How is the new code transported from the DMS to the SC?  Is that in
> scope?

Thanks for the new consolidated text in the Security Considerations section to address the above issues.  Given variety of issues it covers, I recommend being more precise in what the DMS can do and what operators should do about it.  I took a few editorial liberties in restructuring the text.  See below.  Does that make sense?

==[ start old ]==
Note that an inside attacker (or supply chain attacker) at the DMS can seriously weaken the I2NSF system's security. Note that a malicious NSF provider (as a DMS) is relevant to an insider attack, and a compromised NSF provider is relevant to a supply chain attack. Also, note that a malicious (or compromised) DMS sending the wrong NSF may not modify the original code of the NSF but may alter the sent NSF as an instant. As a result, a malicious (or compromised) DMS can attack the Security Controller by providing the Security Controller with malicious (or compromised) NSFs, and controlling those NSFs in real time. Also, an unwitting DMS vendor could be compromised and their infrastructure could be coerced into distributing modified NSFs. To deal with these types of threats, the role of the 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 activated status for the I2NSF system's security. On the other hand, an access to active NSFs should be allowed only to the Security Controller, not the DMS during the provisioning time of those NSFs to the I2NSF system. However, note that an inside attacker (or supply chain attacker) can access the active NSFs, which are being executed as either VNFs or middleboxes in the I2NSF system, through a back door (i.e., an IP address and a port number that are known to the DMS to control an NSF). However, the Security Controller may detect and prevent those inside attacks (supply chain attacks) by monitoring the activities of all the DMSs as well as the NSFs through the I2NSF NSF Monitoring Interface [nsf-monitoring-dm] as part of the I2NSF NSF-Facing Interface. Through the NSF Monitoring Interface, the Security Controller can monitor the activities and states of NSFs, and then can make a diagnosis to see whether the NSFs are working in normal conditions or in abnormal conditions including the insider threats (or supply chain threats). Note that the monitoring of the DMSs is out of scope for I2NSF. However, as a general caution, a mitigation strategy for insider attacks or supply chain attacks is not to use an NSF without prior testing for an automated security action in the I2NSF system.
==[ end old ]==

==[ start new ]==
The role of the DMS is to provide an I2NSF system with the software package or images for NSF execution.  The DMS must not access NSFs in activated status.   An inside attacker or a supply chain attacker at the DMS can seriously weaken the I2NSF system's security.  A malicious DMS is relevant to an insider attack, and a compromised DMS is relevant to a supply chain attack. A malicious (or compromised) DMS could register an NSF of its choice in response to a capability requests by the Security Controller.  As a result, a malicious DMS can attack the I2NSF system by providing a malicious NSFs with arbitrary capabilities to include potentially controlling those NSFs in real time. An unwitting DMS vendor could be compromised and their infrastructure could be coerced into distributing modified NSFs as well.

To deal with these types of threats, an I2NSF system should not use NSFs from untrusted DMS or without prior testing.  The practices by which these packages are downloaded and loaded into the system is out of scope for I2NSF.

I2NSF system operators should audit and monitor interactions with DMSs.  Additionally, the operator should monitor the running NSFs through the I2NSF NSF Monitoring Interface [nsf-monitoring-dm] as part of the I2NSF NSF-Facing Interface. Note that the mechanics monitoring of the DMSs is out of scope for I2NSF.
==[ end new ]==

The fact that lifecycle management of NSF code from DMS (e.g., downloading the modules, testing the code) is out of scope of I2NSF came up a few times in your revision letter (in response to my feedback and ekrs).  You point out that it's noted much later in the text of Section 7.  For clarity, I'd recommend adding such a short comment earlier in the text as well in the quick overview of the I2NSF Framework in Section 3 in the paragraph starting with "As shown in Figure 1, with a Developer's Management System  ..."

> > > (12) Section 3, Per "On the other hand, an access to running
> > > (online) NSFs should be allowed only to the Security Controller, not
> > > the DMS.", this sentence isn't clear to me.
> > >
> > > ** It doesn't parse so I don't know who is supposed to get what
> > > access
> > > -- specifically, "an access to running NSFs"
> > >
> > > ** "running (online) NSFs" is proposing an operational construct
> > > which is also not clear to me.  It that the equivalent of saying in
> > > production?  If it means production, is there a distinction being
> > > made between interacting with the DMS during the time of
> > > provisioning and
> > then after the fact?

Thanks for making the change to address the concern.

> > See comment in #13 about consolidating all threat mitigation in the
> > Security Considerations Section
> >
> > > (13) Section 3, Per "Also, the Security Controller can detect and
> > > prevent inside attacks by monitoring the activity of all the DMSs ...
> > > through the I2NSF NSF monitoring capability", is the monitoring
> > > interface also capable of observing the DMS?  I ask because the
> > > monitoring interface is described in
> > > RFC8329 as part of I2NSF NSF-Facing Interface (Section 3.2)..  The
> > > Registration Interface description (Section 3.3 of RFC8329) makes no
> > > reference to any monitoring capability.
> >
> > Per the following new text:
> >
> > However, the Security Controller can detect and prevent inside attacks
> > by monitoring the activities of all the DMSs as well as the NSFs
> > through the I2NSF NSF monitoring functionality [nsf-monitoring-dm].
> > Through the NSF monitoring, the Security Controller can monitor the
> > activities and states of NSFs, and then can make a diagnosis to see
> > whether the NSFs are working in normal conditions or in abnormal
> conditions including the insider threat.
> > Note that the monitoring of the DMSs is out of scope for I2NSF.
> >
> > This still confusing to me.  The first sentence explicitly says that
> > the Security Controller can monitoring the activities of all the DMSs,
> > but the last sentence says monitoring the DMS is out of scope.
> >
> > As I understand it, the DMS is operated by a vendor outside of the
> > deployed enclave of the I2NSF system.  Therefore, to me, this isn’t an
> > insider threat but a supply chain attack.  Furthermore, “Note that an
> > inside attacker at the DMS can seriously weaken the I2NSF system's
> > security” is true.  However, it’s more than an inside attack.  An
> > unwitting DMS vendor could be compromised and their infrastructure
> > could be coerced into distributing modified NSF.
> >
> > I recommend moving all of this discussion about the insider
> > threat/supply chain attacks and possible mitigation with monitoring
> > into the Security Considerations.  Additionally, RFC8329 Section 4 doesn’t
> seem to:
> >
> > ** distinguish between a malicious and compromised provider – the
> > mitigation would be different)
> >
> > ** a malicious/compromised DMS sending the wrong NSF (perhaps
> because
> > the attacker can’t modify the code but can alter what gets sent)
> >
> > ** general caution of not bringing your network down through automated
> > security action (using outside code) without prior testing
> >
> > > (15) Section 3.  What it intentional to say that the Consumer
> > > interface can be
> > > RESTCONF+YANG (with a reference); the NSF-Facing Interface is
> > > RESTCONF+NETCONF
> > > (but YANG with no reference); and the registration interface is
> > > RESTCONF (no reference to YANG)?
> >
> > This comment resulted in a lot more text changes than anticipated.  I
> > was intending to ask why certain interface mentioned the corresponding
> > YANG modules (and other did not).  Given the new language, “The xxx
> > interface _can_ be implemented as an _XML file_ ...”, a few additional
> questions:
> >
> > ** why the references to XML (in the new language)?
> > ** why the use “can be implemented” (in the old and new language)
> > because the alternative to the specified data model isn’t clear.
> >
> > Is it simpler to say, “The xxx interface _is_ implemented with the xxx
> > interface YANG model [xxx-reference] using …{RESTCONF or NETCONF}
> > which befits ...”?
> >
> > It looks like you some language has changed relative to RESTCONF vs.
> > NETCONF.  This is the new summary:
> > ** Consumer-Facing Interface = RESTCONF
> > ** NSF-Facing interface = NETCONF
> > ** Registration interface = NETCONF (was RESTCONF)
> >
> > I’d like to inquire about the consistency of this language with
> > [draft-ietf- i2nsf-nsf-facing-interface-dm].  It’s Section 7 says that
> > RESTCONF or NETCONF can both be used.

Thanks for making this language consistent and the explanation in your revision letter.  It addresses my concerns.

> > > (18) Section 5.  What is the purpose of including this section if
> > > there is an entire draft (draft-hyun-i2nsf-nsf-triggered-steering)
> > > focused on
> > the topic?
> >
> > Thanks for the changes from [draft-hyun-i2nsf-nsf-triggered-steering]
> > to [RFC7665].  The followed edits more precisely use the reference (as
> > having it after the “I2NSF architecture” made it read to me that this
> > was the reference).
> >
> > Per Section 3,
> > s/ Also, the I2NSF framework can enforce multiple chained NSFs for the
> > low- level security policies by means of SFC techniques for the I2NSF
> > architecture [RFC7665]./ The I2NSF framework can chain multiple NSFs
> > to implement low-level security policies with the SFC architecture
> > [RFC7665]./
> >
> > Per Section 4,
> > s/SFC technology can be utilized to support such packet forwarding in
> > the I2NSF framework [RFC7665]/ The SFC architecture [RFC7665] can be
> > utilized to support such packet forwarding in the I2NSF framework/

Thanks for the update.

> > > (19) Section 5, "To trigger an advanced security action in the I2NSF
> > > architecture, the current NSF appends a metadata describing the
> > > security capability required for the advanced action to the
> > > suspicious packet and sends the packet to the classifier."
> > >
> > > ** Editorial nit: s/NSF appends a metadata/NSF appends metadata/
> > > ** What is the reference for this meta-data format?
> >
> > Thanks for the updated text.  I recommend being more precise with the
> > following edit:
> >
> > OLD:
> > To trigger an advanced security action in the I2NSF architecture, the
> > current NSF appends metadata describing the security capability
> > required for the advanced action to the suspicious packet to the
> > network service header (NSH) of the packet [RFC8300].
> >
> > NEW:
> > To trigger an advanced security action in the I2NSF architecture, the
> > current NSF appends metadata describing the security capability
> > required to the suspicious packet via a network service header (NSH)
> > [RFC8300].

Thanks for the update.

> > > (20) Section 6.  What is the role of the DMS is this scenario?  Why
> > > does the controller need to rely on [NFV MANO] if all information
> > > about the capabilities is already provided by the DMS?  Since the
> > > SDN and other NSF operate using the same data model/interface, isn't
> > > the different between an SDN and NSF opaque to the controller?  I
> > > would have assumed that an SDN is simply a specific type of NSF with
> > > particular
> > capabilities.
> >
> > All my questions are addressed with the new text.  Thanks.  I’d
> > recommend looking at last few sentences of the new first and second
> > paragraph of this section.  They appear to be saying a very similar thing.

Thanks for the update.

> > > (21) Section 6.  "By taking advantage of this capability of SDN, it
> > > is possible to optimize the process of security service enforcement
> > > in the
> > I2NSF system."
> > > The proposed optimization isn't evident from this text.
> >
> > Thanks.  Check (20) because it appears this new language may introduce
> > more duplicate text.

Thanks for the update.

> > > (22) Section 6.  "Especially, SDN forwarding elements enforce simple
> > > packet filtering rules that can be translated into their packet
> > > forwarding rules, whereas NSFs enforce NSF-related security rules
> > > requiring the security capabilities of the NSFs."
> > >
> > > ** I found the use of the word "Especially" confusing
> > > ** I am not sure what distinction is being made between the SDN
> > > forwarding and NSF rules.
> >
> > Thanks.  Check (20) because it appears this new language may introduce
> > more duplicate text.  I think what you said for (21) obviates the need
> > for this new language. It’s now clear what you mean (based on your
> > language for (21)).

Thanks for the update.

> > > (23) Section 6, "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 wasn't sure what the "for this purpose" was referencing, what
> > > "purpose"?
> >
> > Editorial nit on the -11 edits.  s/ For the tasks for security
> > enforcement (e.g., packet filtering)//

Thanks for the update.

> > > (27) Section 7.  "Those NSFs are created or removed by a virtual
> > > network functions manager (VNFM) in the NFV architecture that
> > > performs the life- cycle management of VNFs.  The Security
> > > Controller controls and monitors the configurations (e.g., function
> > > parameters and security policy rules) of VNFs."
> > >
> > > Is the VNFM in scope for I2NSF?
> >
> > Thanks for the additional language about being out of scope.  An
> > editorial nit in this revised text:
> >
> > s/Note that the life-cycle management of VNFs are out of scope for
> > I2NSF./ Note that the life-cycle management of VNFs is out of scope
> > for I2NSF./
> >
> > > If the Security Controller monitors/controls the VNFs, is it using
> > > [nsf- monitoring-dm] and [nsf-facing-inf-dm]?
> >
> > Thanks for the additional references.  An editorial nit in the revised text:
> >
> > s/via NSF-Facing Interface along with NSF monitoring capability
> > [nsf-facing- inf-dm][nsf-monitoring-dm]./ via the NSF-Facing Interface
> > along with the NSF monitoring capability [nsf-
> > facing-inf-dm][nsf-monitoring-dm]./

Thanks for the update.

> > Regards,
> > Roman
> >
> > > Roman
> > >
> > > _______________________________________________
> > > I2nsf mailing list
> > > [e-mail]<mailto:[e-mail]>
> > > https://www.ietf.org/mailman/listinfo/i2nsf
> > >
> > >
> > >
> > > --
> > > ===========================
> > > Mr. Jaehoon (Paul) Jeong, Ph.D.
> > > Associate Professor
> > > Department of Software
> > > Sungkyunkwan University
> > > Office: [phone]
> > > Email: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]> Personal
> > Homepage:
> > > http://iotlab.skku.edu/people-jaehoon-jeong.php
> > _______________________________________________
> > I2nsf mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/i2nsf


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