Information Exposure through Named Contents and Implications on

Information Exposure through Named Contents and Implications on Disaster Management 2 nd GAIA Meeting University of Cambridge 20 th October 2014 Ioannis Psaras University College London i. psaras@ucl. ac. uk Lorenzo Saino (UCL), Kostantinos V. Katsaros (UCL), Mayutan Arumaithurai (UGoettingen), K. K. Ramakrishnan (UC Riverside), George Pavlou (UCL)

Information-Centric Networking (in brief) • Basic ICN Conventions: – Request-response at the chunk/packet level • Similar to HTTP-GET but at the network layer – Explicitly named content chunks/packets • Named content enables in-network caching – Name-based routing • Hierarchical naming, or • Flat, self-certifying names • Motivation for the shift to ICN: – Content is not secured – the content’s host is! – Network is content-agnostic and content is locationdependent!

Content Names • Content names are effectively a tool to expose information that can be used by the network. • Information included in names has so far focused on assisting the routing process. – Perhaps that’s the most important and challenging issue • However, information “leaked” through names deserves more attention. • For example, – it might reveal the identity of content providers and therefore, help cancel network neutrality – it can help in the caching process – it can assist with the dissemination process in infrastructureless networks (e. g. , scoping, single- or multi-recipient transmission)

Information Exposure Through Content Names Content Distribution • Permanent names allow for in-network caching and multicast. • Name resolution (based on permanent names) prevents content providers from logging requests for their contents. • Permanent content names allow for name-based routing, traffic characterisation and self-certification, but also expose the identity of the publisher (potentially) cancelling the network neutrality principle. Content names might expose too much information

Information Exposure Through Content Names Mobile, Opportunistic Networks, Smart Cities etc. • Networks might become fragmented or be completely infrastructureless • Local device-to-device communication is important – Spatiotemporal scoping is needed – control of traffic lights based on ambulance sirens should propagate to local traffic lights and should not escape to other parts of the city. • Routing-by-name becomes replication-by-name • Content format should also be considered in case of mobile devices – E. g. , high-resolution format to low-resolution device Messages are routed/forwarded/replicated based on the information included in the message name

Disaster Management through Name-Based Replication Ioannis Psaras, Lorenzo Saino, Mayutan Arumaithurai, K. K. Ramakrishnan and George Pavlou, “Name-Based Replication Priorities in Disaster Cases”, Proc. of the The 2 nd IEEE workshop on Name Oriented Mobility (NOM‘ 14), IEEE INFOCOM, Toronto, Canada, April 2014

• Green. ICN: Architecture and Applications of Green Information Centric Networking • Duration: 3 years (1 Apr 2013 – 31 Mar 2016) • Website: http: //www. greenicn. org

Green. ICN Project Consortium

Green. ICN requirements • Requirement 1: 20% Reduction of Power Consumption of Green. ICN for Normal Days – EU announced that the total energy consumption of all EU countries should be decreased by 20% – Japan announced a reduction of energy consumption of 30% by 2030, compared to that in 2003 • Requirement 2: At Least 40% Reduction of Power Consumption of Green. ICN (including end-user devices) for Disasters – In 2011, people in Tohoku area suffered 3 days of blackout because of the East Japan Earthquake – The 40% reduction aims to make the communication services and related base stations able to operate 3 days in such a scenario 9

Green. ICN requirements • Requirement 3: Seamless Services before and after a Disaster – The lesson learned at the 2011 East Japan Earthquake is that terminals and services specifically designed for disasters were useless, and that people wanted to use the same terminals and services used in their everyday life • Requirement 4: Migration Path – Green. ICN should friendly coexist with the current IP network • Requirement 5: Scalability and size of the served contents and related names – Green. ICN should be able to serve at least current Web contents with off-the-shelf technology 10

Important in Case of Disaster • Trapped people want to communicate with anyone – not necessarily their friends and family only. • First responders want to distribute important information to the general public – not to a specific person only. Multi-recipient transmission is essential. • There are many rescue teams in several different areas, each of which needs to communicate with people within this area – not necessarily elsewhere. • Messages to groups of people within some area are important for some amount of time – not forever. Communication after disasters needs to be bounded in time and space.

Important in Case of Disaster • A SOS message calling for help, or a message from the fire brigade regarding first aid is more important that “chit chatting” or ads Prioritisation of what to transfer/disseminate becomes of vital importance. • Vital parts and devices of the network fail, therefore, the traditional end-to-end, IP-based intrastructure cannot be depended upon. Communication needs to be based on ad hoc, delay - and disruption-tolerant communications.

Communication Resilience vs Network Resilience

Building Name-Based Replication on DTN Foundations • We associate each message generated in an infrastructureless, disaster scenario with a Name and some attributes. • We exploit the information that can be exposed in a content name and propose Name-Based Replication, where: – Nodes store-carry-and-forward messages: • with specific time and space limits, and • with priorities as to what to replicate • which are then pushed to devices encountered as nodes move. – Time-space limits, as well as priorities are included within the message’s name (or attributes field) • In DTN nodes have to look into the message contents to make decisions on whether to replicate or not – with NREP decisions are made based on the name. • The ultimate target is to deliver a message to some specific destination node, or Internet access point and want to optimise that delivery. • IP-based DTN protocols are destination-focused and content-agnostic.

The Concept of Floating Content* • Messages replicated without network support • Messages stay within some area • Messages live for some specific amount of time • Floating Content used for: • Advertising • Communicating locally with friends *Joerg Ott et al. www. floating-content. net

NREP Design Challenges • Design Challenges – Which parameters differentiate between types of messages? • E. g. , Time bounds? Space bounds? Message type (SOS vs chat)? – What’s the structure of a Name? • Flat or hierarchical? – Which of them should be included in the name and which as attributes? • What is the most important and what is less important? • Naming Design and Parameters that influence message differentiation – Type of message: SOS, First Responders (Disaster Management), chat – The geographical reach of the message: radius/district/ – The lifetime of the content: temporal-validity

NREP Design Choices • Design Choices 1. 2. 3. 4. Hierarchical is working better than flat in this case • Emergency/SOS or Warning/Shelter The name shows the priority • Emergency, Warning, chat Time and space limits are kept as attributes, • borough. X/ttl=2 h, radius=Xkm/ttl=Yhours User-defined priorities kept as attributes too • user-perceived importance, e. g. , from 1 -5 how useful/important was the message • Example Priorities and Namespaces – High Priority • From first responders: Warning/Dangerous. Area – spreads everywhere, does not expire • From civilians: SOS – spreads locally, expires quickly (to avoid spreading after help received) – Medium Priority • From civilians: Info/Shelter, Info/Food – spreads locally, expires if needed after a while (e. g. , food will run out) – Low Priority • From civilians: Chat – spreads locally or everywhere, expires soon

NREP Design Advantages • Hierarchical design: – content can be filtered according to a longest prefix match – Namespace has a globally understood prioritisation value • Namespace cannot be manipulated/hijacked by individual users – This depends on the application, so cannot be individually set – To avoid misuse, important messages are kept short, e. g. , SOS is just a few characters so cannot be used for chat • Attributes are set by sender, but can be modified by individual users/encounters • Low energy devices have the option to only look at the name and make decisions based only on that • More powerful devices (e. g. , base-stations) can look further at the attributes • Users can exchange messages based on their energy levels • Receive only Priority: High/Emergency, Space: Lcl. Borough, Temp-Val: Exp. Soon

Performance Evaluation • We use the ONE Simulator and simulate 12 h of post-disaster case • Two main scenarios: – First scenario shows importance of prioritisation (but is not very realistic) • 16 km 2 area, around 500 nodes – Second scenario shows what happens in reality • 1 km 2 area, around 300 nodes • High Priority messages get generated less frequently - expire later • Low Priority messages get generated more frequently - expire soon • Metrics: – Replication till Expiry: the longer a message lives the higher the potential to inform more users – Replications per message (and per class): indirectly shows the number of nodes that received a message • Replication Algorithms: NREP, FIFO, RND, SAF (Smaller Area First)

Scenario I Focus: Prioritisation w/o time, space limits High Priority (HP) Class Low Priority (LP) Class NREP: Less LP messages NREP: More HP messages You’re equally likely to receive an important warning message or relay a random chat message between two users FIFO, RND: No differentiation

Scenario II Focus: Prioritisation w/ time, space • Area: 1 km 2, 300 nodes • 6 Message Classes: 2 HP, 2 MP, 2 LP • The higher the priority the longer the TTL and the Generation Interval • Target: the higher the priority the more the nodes a message should reach Messages generated in small circles Disaster Area Messages replicate in large circles (where no circles, messages replicate everywhere) NREP reaches ~95% of nodes for HP 1 NREP keeps more HP msgs in the nodes’ buffers and replicates more of these msgs upon encounters. SAF is more efficient when replicating in small areas (MP 1, MP 2, HP 2).

Scenario II Focus: Prioritisation w/ overlapping space • All messages generated within the HP 1 small circle. • Each message class replicates to its corresponding larger circle as shown. • The lower the priority of a message class the further it spreads. Intention: show messages get replicated in space according to their priority. • We capture the x, y co-ordinates, where messages get replicated according to their priority class. Disaster Area

Prioritisation w/ overlapping space FIFO es g a s es te m LP mina do P area on H ti the rentia ffe i d No HP NREP opp. Moore repl ic itie ation s fo r HP rtun HP LP m die essag e out fast s er LP LP

Conclusions • NREP looks promising for the management of emergency situations – It seems it can also be very useful for community networks • Communication Resilience is important in conjunction with (and not in contrast to) Network Resilience • Ad hoc communication is essential to achieve Communication Resilience and realise NREP • ICN should work together with DTN: these are two complementary areas – not conflicting ones

Thanks! Questions? We have openings @ UCL! Dr Ioannis Psaras University College London i. psaras@ucl. ac. uk http: //www. ee. ucl. ac. uk/~uceeips Slide 25

Information Exposure • K. Katsaros, L. Saino, I. Psaras, G. Pavlou, “Information Exposure through Named Content”, Workshop on Quality, Reliability and Security in Information-Centric Networking (Q-ICN), Q-SHINE, August 2014. Name-Based Replication • Ioannis Psaras, Lorenzo Saino, Mayutan Arumaithurai, K. K. Ramakrishnan and George Pavlou, “Name-Based Replication Priorities in Disaster Cases”, Proc. of the The 2 nd IEEE workshop on Name Oriented Mobility (NOM‘ 14), IEEE INFOCOM, Toronto, Canada, April 2014

EU FP 7 COMET Architectural Papers • G. Pavlou, N. Wang, W. K. Chai and I. Psaras, "Internet-scale Content Mediation in Information-centric Networks", Annals of Telecommunications, Special Issue on Networked Digital Media, Springer 2012 • W. K. Chai, N. Wang, I. Psaras, G. Pavlou, C. Wang, G. G. de Blas, F. J. Salguero, L. Liang, S. Spirou, A. Bęben and E. Hadjioannou, "CURLING: Content-Ubiquitous Resolution and Delivery Infrastructure for Next Generation Services", IEEE Communications Magazine, Special Issue on Future Media Internet, pp. 112 -120, March 2011 • G. Garcia, A. Beben, F. J. Ramon, A. Maeso, I. Psaras, G. Pavlou, N. Wang, J. Sliwinski, S. Spirou, S. Soursos, E. Hadjioannou, "COMET: Content Mediator Architecture for Content-aware Networks", in Future Network and Mobile Summit 2011, Warsaw, Poland, 15 -17 June 2011

Modelling Work • I. Psaras, R. G. Clegg, R. Landa, W. K. Chai, G. Pavlou, "Modelling and Evaluation of CCN-Caching Trees", Proceedings of the 10 th IFIP Networking, Valencia, Spain, 9 -13 May 2011 • I. Psaras, R. G. Clegg, R. Landa, W. K. Chai, G. Pavlou, ”In-Cache Time Estimations for Information-Centric Networks”, under submission

In-Network Caching Work I • W. K. Chai, D. He, I. Psaras, G. Pavlou, "Cache "Less for More" in Informationcentric Networks", Proceedings of the 11 th IFIP Networking, Prague, Czech Republic, 21 -25 May 2012 Best Paper Award • W. K. Chai, D. He, I. Psaras, G. Pavlou, "Cache "Less for More" in Informationcentric Networks", Elsevier Computer Communications Special Issue on ICN 2013

In-Network Caching Work II • I. Psaras, W. K. Chai, G. Pavlou, "Probabilistic In-Network Caching for Information-Centric Networks", Proc. of the 2 nd ACM SIGCOMM Workshop on ICN 2012, Helsinki, Finland, August 2012 • I. Psaras, W. K. Chai, G. Pavlou, ”In-Network Cache Management and Resource Allocation for Information-Centric Networks", in press IEEE TPDS Prob. Cache: Probabilistic In-Network Caching Capability of a Path Weight-based Caching

In-Network Caching Work III • L. Saino, I. Psaras, G. Pavlou, ”Hash-routing schemes for Information-Centric Networks", Proc. of the 3 rd ACM SIGCOMM Workshop on ICN 2013, Hong Kong, August 2013 • L. Saino, I. Psaras, G. Pavlou, ”Icarus: a Caching Simulator for Information. Centric Networking", Proc. of the 7 th ICST SIMUTOOLS, Lisbon, Portugal, March 2014

Ongoing Projects • Green. ICN, EU-Japan collaborative project – EU: U Gottingen (DE), NEC (DE, UK), CEDEO (IT), OLP (PL), UCL (UK), CNIT (IT) – Japan: KDDI, NEC, Panasonic, U Tokyo, U Waseda, U Osaka – http: //www. greenicn. org/ • COMIT: Content Management at Internet Scale, EPSRC UK, UCL