Re: [icnrg] I-D Action: draft-irtf-icnrg-deployment-guidelines-01.txt

[Guillaume Doyen <[e-mail]>]

Hi Akbar,

Thanks for all your work. We are fine with the last version.

Best regards,

Guillaume

> Le 25 juin 2018 à 16:14, Rahman, Akbar <[e-mail]> a écrit :
> 
> Hi Guillaume,
> 
> 
> I have captured your final suggestions (as per our off line discussions) in the latest draft:
> 
> https://tools.ietf.org/html/draft-irtf-icnrg-deployment-guidelines-03
> 
> 
> or please see the -diff
> 
> https://tools.ietf.org/rfcdiff?url2=draft-irtf-icnrg-deployment-guidelines-03.txt
> 
> 
> 
> Thank you very much for your interest and suggestions on the draft.
> 
> 
> Best Regards,
> 
> 
> Akbar
> 
> 
> -----Original Message-----
> From: Guillaume Doyen [mailto:[e-mail]]
> Sent: Thursday, June 21, 2018 12:41 PM
> To: Rahman, Akbar <[e-mail]>
> Cc: Luca Muscariello <[e-mail]>; Michael Kowal (mikowal) <[e-mail]>; Luca Muscariello (lumuscar) <[e-mail]>; icnrg <[e-mail]>
> Subject: Re: [icnrg] I-D Action: draft-irtf-icnrg-deployment-guidelines-01.txt
> 
> Dear Akbar,
> 
> First of all, our warm thanks for carefully integrating all the elements provided by our consortium in the last version of the draft.
> 
> We are roughly inline with this last version and there are only some minor suggestions/corrections we have:
> - In section 5.2.6, regarding the sentence « The testbed carries live web traffic of users from the most popular (1000) Web sites. », we would prefer the document to explicitly mention that the tested is designed to carry real web traffic, and that it has been currently evaluated with the top-1000 of the most popular web sites.
> - In section 9, related to security considerations, we suggest to re-cite here the four publications [Mai-1] [Mai-2] [Nguyen-1] [Nguyen-2] since they are at the core of the section topic.
> 
> FYI, a very last paper summarizing all our contributions in security has just been accepted this week in IEEE Comm. Mag (special topic on ICN Security). We will forward the reference to you once known.
> 
> For the rest, we are ok with the current version.
> 
> Thanks again and best regards,
> 
> Guillaume
> 
>> Le 12 juin 2018 à 22:40, Rahman, Akbar <[e-mail]> a écrit :
>> 
>> Hi Guillaume,
>> 
>> 
>> Sorry for the delayed response.  We agree with all your suggestions below and have updated the draft to cover them (with some editorial license).
>> 
>> Can  you please review the diff:
>> 
>> https://tools.ietf.org/rfcdiff?url2=draft-irtf-icnrg-deployment-guidelines-02.txt
>> 
>> or the overall draft:
>> 
>> https://tools.ietf.org/html/draft-irtf-icnrg-deployment-guidelines-02
>> 
>> 
>> Please confirm that we have addressed your questions sufficiently by writing back to the list.
>> 
>> 
>> Best Regards,
>> 
>> 
>> Akbar
>> 
>> 
>> -----Original Message-----
>> From: icnrg [mailto:[e-mail]] On Behalf Of Guillaume Doyen
>> Sent: Wednesday, May 23, 2018 11:29 AM
>> To: Rahman, Akbar <[e-mail]>
>> Cc: Luca Muscariello <[e-mail]>; Michael Kowal (mikowal) <[e-mail]>; Luca Muscariello (lumuscar) <[e-mail]>; icnrg <[e-mail]>
>> Subject: Re: [icnrg] I-D Action: draft-irtf-icnrg-deployment-guidelines-01.txt
>> 
>> Hi Akbar,
>> 
>> Thanks for integrating the Doctor project in the scope of the draft. Please find subsequently our feedback (as discussed in an out-of-band email, I waited for a project meeting last Friday before getting back to you).
>> 
>> 1. Section 3
>> 
>> Is is unclear for us how to classify our approach given the three main criteria you provide in section 3 (you propose « underlay » due to the use of gateways). Since in our case, by leveraging NFV, (1) an NDN stack can be deployed directly over a virtual L2 offered by network virtualization and the cohabitation with standard traffic is done through gateways (thus matching the « underlay » criterion), (2) at the underlying infrastructure level, data are still encapsulated in GRE/VXLAN tunnels (thus matching the « overlay » criterion), and finally (3), as highlighted in section 3, NFV/SDN is at the core of network slicing, which is also applicable in our case (e.g. forwarding HTTP trafic in NDN islands, while some other traffic can be still forwarded in other virtual IP networks in the same infrastructure). Consequently, it is unclear to us where our approach can be integrated. On that basis, perhaps:
>> - It would be necessary to explicitly provide a section related to « hybrid » approaches or mention somewhere that some solutions result from a mix of the above-mentioned categories?
>> - The paragraph on « slicing » should not only cover 5G approaches but more generally deal with NFV/SDN solutions (5G or not)?
>> 
>> 2. Section 4.1
>> 
>> In this section, we suggest to integrate a sentence on our project contribution to HTTP/NDN gateways which brings some elements on protocol mapping issues and caching.
>> 
>> « The underlay deployment configuration options presented in Section 3.3.2 and Section 3.3.1 aim at providing some level of backward compatibility to this existing ecosystem through a proxy based message flow mapping mechanism (e.g., mapping of existing HTTP/TCP/IP message flows to HTTP/TCP/IP/ICN message flows). A related approach of mapping TCP/IP to TCP/ICN message flows is described in [Moiseenko]. Another approach described in [Marchal] uses HTTP/NDN gateways and focuses in particular on the right strategy to map HTTP over NDN to guarantee a high level of compatibility with HTTP while enabling an efficient caching of Data in the ICN island. »
>> 
>> 3. Section 5
>> 
>> One of the major scopes of the Doctor project is to address security issues in ICN in realistic deployment situations. As such, an important amount of work in our testbed has been conducted to (1) feature IFA (Interest Flooding Attack) and CPA (Content Poisoning Attack) with real attack patterns and (2) evaluate the detection solutions we propose. As such, from our perspective, it is worth citing these publication works in the draft:
>> 
>> [1] T. Nguyen, X. Marchal, G. Doyen, T. Cholez and R. Cogranne. "Content Poisoning in Named Data Networking: Comprehensive Characterization of real Deployment". To appear in Proceedings of the 15th IFIP/IEEE International Symposium on Integrated Network Management – IM 2017. 8p. IEEE, 2017.
>> 
>> [2] T. Nguyen, R. Cogranne and G. Doyen, "An optimal statistical test for robust detection against interest flooding attacks in CCN". In S. Ata, R. Badonnel and J. Xiao (Eds) Proceedings of the 14th IFIP/IEEE International Symposium on Integrated Network Management – IM 2015, pages 252-260. IEEE 2015.
>> 
>> [3] H. L. Mai, T. N. Nguyen, G. Doyen, R. Cogranne, W. Mallouli, E. Montes de Oca, and O. Festor. “Towards a Security Monitoring Plane for Named Data Networking: Application to Content Poisoning Attack.” To appear in 2018 IEEE/IFIP Symposium on Network Operations and Management (NOMS). IEEE, 2018.
>> 
>> and we also suggest the related changes in the Doctor paragraph:
>> 
>> « The Doctor project is a French research project meaning "Deployment and Securisation of new Functionalities in Virtualized Networking Environments". The project aims to run NDN over virtualized NFV infrastructure [Doctor] (based on Docker) and focuses on the MANO aspects to build an operational NDN network regarding essential criteria such as security, performance and interoperability.
>> 
>> The data-plane relies on a HTTP/NDN gateway [Marchal] that processes HTTP traffic and transports it in an optimized way over NDN to benefit from the properties of the NDN-island. The testbed carries real web traffic of users who only needs to set the gateway as a web proxy. The control-plane relies on a central manager which uses Machine Learning based detection methods  [Mai] from the data gathered by distributed probes and applies orchestrated counter-measures against NDN attacks (IFA, CPA) [1, 2, 3] or performance issues. A remediation can be, for example, the scale-up of a bottleneck component, or the deployment of a security function like a firewall or a signature verification module. »
>> 
>> 4. Section 11
>> 
>> It seems the two references [Mai] and [Marchal] are not complete. I do propose to reference them as follows:
>> 
>> [Marchal] X. Marchal, M. El Aoun, B. Mathieu, T. Cholez, G. Doyen, W. Mallouli and O. Festor. “Leveraging NFV for the Deployment of NDN: Application to HTTP Traffic Transport”. In Proceedings of the 2018 IEEE/IFIP Symposium on Network Operations and Management (NOMS). Copyright IEEE, 2018.
>> 
>> [Mai] H. L. Mai, M. Aouadj, G. Doyen, D. Kondo, X. Marchal, T. Cholez, E. Montes de Oca, W. Mallouli. “Implementation of Content Poisoning Attack Detection and Reaction in Virtualized NDN Networks”. In the 21st Conference on Innovation in Clouds, Internet and Networks - ICIN 2018 (demo paper) IEEE, 2018.
>> 
>> 
>> Thanks Akbar; we can discuss that further on the mailing-list of with an audio-conf is needed.
>> 
>> Best regards,
>> 
>> Guillaume
>> 
>> 
>>> Le 9 mai 2018 à 09:58, Luca Muscariello <[e-mail]> a écrit :
>>> 
>>> Hi Akbar,
>>> 
>>> so far so good to me.
>>> 
>>> Luca
>>> 
>>> On Wed, May 9, 2018 at 7:02 AM, Rahman, Akbar <[e-mail]> wrote:
>>> Hi Guillaume/Michael/Luca,
>>> 
>>> 
>>> Thank you very much for your input into the Deployment Trial Experiences (Section 5) of the Draft.  We have taken a stab at incorporating your comments.  Can you please review and write back if you have any more suggestions or comments?
>>> 
>>> 
>>> 
>>> Best Regards,
>>> 
>>> 
>>> Akbar
>>> 
>>> -----Original Message-----
>>> From: icnrg [mailto:[e-mail]] On Behalf Of [e-mail]
>>> Sent: Wednesday, May 9, 2018 12:53 AM
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> Subject: [icnrg] I-D Action: draft-irtf-icnrg-deployment-guidelines-01.txt
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the Information-Centric Networking RG of the IRTF.
>>> 
>>>       Title           : Deployment Considerations for Information-Centric Networking (ICN)
>>>       Authors         : Akbar Rahman
>>>                         Dirk Trossen
>>>                         Dirk Kutscher
>>>                         Ravi Ravindran
>>> Filename        : draft-irtf-icnrg-deployment-guidelines-01.txt
>>> Pages           : 28
>>> Date            : 2018-05-08
>>> 
>>> Abstract:
>>>  Information-Centric Networking (ICN) is now reaching technological
>>>  maturity after many years of fundamental research and
>>>  experimentation.  This document provides a number of deployment
>>>  considerations in the interest of helping the ICN community move
>>>  forward to the next step of live deployments.  First, the major
>>>  deployment configurations for ICN are described including the key
>>>  overlay and underlay approaches.  Then proposed deployment migration
>>>  paths are outlined to address major practical issues such as network
>>>  and application migration.  Next, selected ICN trial experiences are
>>>  summarized.  Finally, protocol areas that require further
>>>  standardization are identified to facilitate future interoperable ICN
>>>  deployments.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-irtf-icnrg-deployment-guidelines/
>>> 
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-irtf-icnrg-deployment-guidelines-01
>>> https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-deployment-guidelines-01
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-irtf-icnrg-deployment-guidelines-01
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> _______________________________________________
>>> icnrg mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/icnrg
>>> [Banner]
>>> This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.
>>> 
>>> _______________________________________________
>>> icnrg mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/icnrg
>>> 
>> 
>> _______________________________________________
>> icnrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/icnrg
>> [Banner]
>> This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.
>> 
> 
> [Banner]
> This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.
>