Roman, Thanks for your guidance.:-) Best Regards, Paul
On Sat, Jun 22, 2019 at 5:09 PM Roman Danyliw <[email protected]> wrote: > 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 < > [email protected]> 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 <[email protected]> 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:[email protected]] >> > Sent: Tuesday, June 18, 2019 5:15 AM >> > To: Roman Danyliw <[email protected]> >> > Cc: Linda Dunbar <[email protected]>; Yoav Nir < >> [email protected]>; >> > [email protected]; [email protected]; >> > Mr. Jaehoon Paul Jeong <[email protected]> >> > 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:[email protected]] On Behalf Of Roman >> Danyliw >> > > Sent: Tuesday, June 4, 2019 6:35 PM >> > > To: Mr. Jaehoon Paul Jeong <[email protected]>; Linda Dunbar >> > > <[email protected]>; Yoav Nir <[email protected]> >> > > Cc: [email protected]; [email protected] >> > > 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:[email protected]] On Behalf Of Mr. >> Jaehoon >> > > > Paul Jeong >> > > > Sent: Thursday, May 02, 2019 5:13 AM >> > > > To: Roman Danyliw <[email protected]>; Linda Dunbar >> > > > <[email protected]>; Yoav Nir <[email protected]> >> > > > Cc: [email protected]; [email protected] >> > > > 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 <[email protected]> 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 >> > > > [email protected] >> > > > https://www.ietf.org/mailman/listinfo/i2nsf >> > > > >> > > > >> > > > >> > > > -- >> > > > =========================== >> > > > Mr. Jaehoon (Paul) Jeong, Ph.D. >> > > > Associate Professor >> > > > Department of Software >> > > > Sungkyunkwan University >> > > > Office: +82-31-299-4957 >> > > > Email: [email protected], [email protected] Personal >> > > Homepage: >> > > > http://iotlab.skku.edu/people-jaehoon-jeong.php >> > > _______________________________________________ >> > > I2nsf mailing list >> > > [email protected] >> > > https://www.ietf.org/mailman/listinfo/i2nsf >> > > > -- > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: [email protected], [email protected] > 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: +82-31-299-4957 Email: [email protected], [email protected] Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
