TY - RPRT T1 - Demonstration Plan Y1 - 2015 A1 - Pedro Casas A1 - Edion Tego A1 - Francesco Matera A1 - Maurizio Dusi A1 - A. Bakay A1 - Balazs Szabo A1 - G. Rozsa A1 - Stefano Traverso A1 - Ilias Leontiadis A1 - L. Baltrunas A1 - Yan Grunenberger A1 - Andrea Fregosi A1 - A. Kahveci A1 - Eike Kowallik A1 - G. Mattellini A1 - C. Meregalli A1 - Stefano Raffaglio A1 - M. Russo A1 - Andrea Sannino A1 - M. Scarpino JO - D6.1 ER - TY - CONF T1 - multi-context TLS (mcTLS): Enabling Secure In-Network Functionality in TLS T2 - 2015 ACM SIGCOMM Conference (SIGCOMM ’15) Y1 - 2015 A1 - David Naylor A1 - Kyle Schomp A1 - Matteo Varvello A1 - Ilias Leontiadis A1 - Jeremy Blackburn A1 - Diego Lopez A1 - Konstantina Papagiannaki A1 - Pablo Rodriguez A1 - Peter Steenkiste AB -
Transport Layer Security (TLS), is the de facto protocol supporting secure HTTP (HTTPS), and is being discussed as the default transport protocol for HTTP2.0. It has seen wide adoption and is currently carrying a significant fraction of the overall HTTP traffic (Facebook, Google and Twitter use it by default). However, TLS makes the fundamental assumption that all functionality resides solely at the endpoints, and is thus unable to utilize the many in-network services that optimize network resource usage, improve user experience, and protect clients and servers from security threats. Re-introducing such in-network functionality into secure TLS sessions today is done through hacks, in many cases weakening overall security.
In this paper we introduce multi-context TLS (mcTLS) which enhances TLS by allowing middleboxes to be fully supported participants in TLS sessions. mcTLS breaks the "all-or-nothing" security model by allowing endpoints and content providers to explicitly introduce middleboxes in secure end-to-end sessions, while deciding whether they should have read or write access, and to which specific parts of the content. mcTLS enables transparency and control for both clients and servers.
We evaluate a prototype mcTLS implementation in both controlled and "live" experiments, showing that the benefits offered have minimal overhead.More importantly, we show that mcTLS can be incrementally deployed and requires small changes to clients, servers, and middleboxes, for a large number of use cases.
JF - 2015 ACM SIGCOMM Conference (SIGCOMM ’15) PB - ACM CY - London ER - TY - RPRT T1 - Algorithm and Scheduler Design and Implementation Y1 - 2014 A1 - Maurizio Dusi A1 - Saverio Niccolini A1 - Sofia Nikitaki A1 - Daniele Apiletti A1 - Elena Baralis A1 - Alessandro Finamore A1 - Luigi Grimaudo A1 - Stefano Traverso A1 - Francesco Matera A1 - Edion Tego A1 - V, Guchev A1 - Zied Ben Houidi A1 - Pietro Michiardi A1 - Marco Milanesio A1 - YiXi Gong A1 - Dario Rossi A1 - Ilias Leontiadis A1 - G, Dimopoulos A1 - Tivadar Szemethy A1 - A, Bakay A1 - Arian Bär A1 - Pedro Casas A1 - Alessandro D'Alconzo A1 - Pierdomenico Fiadino KW - algorithm design KW - job scheduler KW - mPlane software KW - repository tools SN - D3.3 JO - D3.3 ER - TY - CONF T1 - The Cost of the “S” in HTTPS T2 - ACM Conference on emerging Networking EXperiments and Technologies (CoNEXT) Y1 - 2014 A1 - David Naylor A1 - Alessandro Finamore A1 - Ilias Leontiadis A1 - Yan Grunenberger A1 - Marco Mellia A1 - Kostantina Papagiannaki A1 - Peter Steenkiste JF - ACM Conference on emerging Networking EXperiments and Technologies (CoNEXT) ER - TY - RPRT T1 - Cross-check of Analysis Modules and Reasoner Interactions Y1 - 2014 A1 - Umberto Manferdini A1 - Stefano Traverso A1 - Marco Mellia A1 - Edion Tego A1 - Francesco Matera A1 - Zied Ben Houidi A1 - Marco Milanesio A1 - Pietro Michiardi A1 - Dario Rossi A1 - D. Cicalese A1 - D. Joumblatt A1 - Jordan Augé A1 - Maurizio Dusi A1 - Sofia Nikitaki A1 - Mohamed Ahmed A1 - Ilias Leontiadis A1 - L. Baltrunas A1 - M. Varvello A1 - Pedro Casas A1 - Alessandro D'Alconzo A1 - Benoit Donnet A1 - W. Du A1 - Guy Leduc A1 - Y. Liao A1 - Alessandro Capello A1 - Fabrizio Invernizzi KW - reasoner KW - WP4 ER - TY - RPRT T1 - Design of the Reasoner Y1 - 2014 A1 - Pedro Casas A1 - Alessandro D'Alconzo A1 - Maurizio Dusi A1 - Sofia Nikitaki A1 - Mohamed Ahmed A1 - Stefano Traverso A1 - Marco Mellia A1 - Daniele Apiletti A1 - Luigi Grimaudo A1 - Elena Baralis A1 - Dario Rossi A1 - D. Joumblatt A1 - Alessandro Capello A1 - M. D'Ambrosio A1 - Fabrizio Invernizzi A1 - M. Ullio A1 - Andrea Fregosi A1 - Eike Kowallik A1 - Stefano Raffaglio A1 - Andrea Sannino A1 - Marco Milanesio A1 - Edion Tego A1 - Francesco Matera A1 - Tivadar Szemethy A1 - Balazs Szabo A1 - L. Németh A1 - Zied Ben Houidi A1 - G. Dimopoulos A1 - Ilias Leontiadis A1 - Yan Grunenberger A1 - L. Baltrunas A1 - Michael Faath A1 - Rolf Winter A1 - Dimitri Papadimitriou KW - design KW - private deliverable KW - reasoner KW - WP4 JO - D4.2 ER - TY - CONF T1 - From Cells to Streets: Estimating Mobile Paths with Cellular-Side Data T2 - CoNEXT Y1 - 2014 A1 - Ilias Leontiadis A1 - Antonio Lima A1 - Haewoon Kwak A1 - Rade Stanojevic A1 - David Wetherall A1 - Konstantina Papagiannaki JF - CoNEXT PB - ACM CY - Sydney, Australia ER - TY - JOUR T1 - mPlane: an Intelligent Measurement Plane for the Internet JF - IEEE Communications Magazine, Special Issue on Monitoring and Troubleshooting Multi-domain Networks using Measurement Federations Y1 - 2014 A1 - Brian Trammell A1 - Pedro Casas A1 - Dario Rossi A1 - Arian Bär A1 - Zied Ben-Houidi A1 - Ilias Leontiadis A1 - Tivadar Szemethy A1 - Marco Mellia VL - 42 IS - 5 ER - TY - RPRT T1 - Basic Network Data Analysis Y1 - 2013 A1 - Pietro Michiardi A1 - Antonio Barbuzzi A1 - Alessandro Finamore A1 - Stefano Traverso A1 - Daniele Apiletti A1 - Elena Baralis A1 - Tania Cerquitelli A1 - Silvia Chiusano A1 - Luigi Grimaudo A1 - A. Rufini A1 - Francesco Matera A1 - A. Valentii A1 - Maurizio Dusi A1 - Mohamed Ahmed A1 - Tivadar Szemethy A1 - L. Németh A1 - R. Szalay A1 - Ilias Leontiadis A1 - Yan Grunenberger A1 - P. Casas A1 - Alessandro D’Alconzo A1 - A Bär A1 - D Rossi A1 - YiXi Gong KW - algorithms KW - big data KW - storage AB -This document describes the requirements, input, output for the algorithms needed to perform analytic tasks on a large amount of data, in the context of WP3. Starting from the use cases defined in WP1, we identify the algorithms needed to address the various scenario requirements. Operating on a large amount of data, these algorithms strive for parallel and scalable approaches; the designing and implementation of the algorithm itself can be a challenging research task since today very little is known concerning how to develop efficient and scalable algorithms that runs on parallel processing frameworks.
The algorithm in the storage layer are characterized by the fact that they operate on a large amount of data, and produce a concise representation of it, extracting features and aggregating it, so that the produced output is easier to handle and understand. Depending on the amount of data produced, on the scenario characteristics and on the time constraints, algorithms can require a real time (or near real time) or a batch processing.
For each algorithm and use case, the input data and the initial state, the computation to run and the output produced are described.
The document defines the requirements for the mPlane architecture on the background of a set of scenarios explored by the consortium, a survey of existing comparable measurement systems and platforms and applicable standards therefore, and a set of architectural first principles drawn from the description of work and the consortium's experience. As mPlane is intended to be a fully flexible measurement platform, freely integrating existing probes and repositories with ones to be developed in the project, this document is primarily concerned with the definition of interfaces among mPlane components. While it does enumerate capabilities to be provided by these components, these are primarily intended to ensure the platform has the flexibility required to meet all the scenarios envisioned; the enumerations of measurements, metrics, data types, and other component capabilities are therefore not to be construed to limit the scope of work on components within the project to just those scenarios treated in this document; nor do the scenarios enumerated here define the capabilities to be demonstrated in the project's integrated trial.
PB - mPlane Consortium CY - Torino ER -