idnits 2.17.1 draft-pouwelse-perpass-shadow-internet-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3714 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ATTACK' is mentioned on line 802, but not defined == Missing Reference: 'CATALOG' is mentioned on line 806, but not defined == Missing Reference: 'SCHNEIER' is mentioned on line 811, but not defined == Missing Reference: 'YOUTH' is mentioned on line 816, but not defined == Missing Reference: 'FORCEDLOGIN' is mentioned on line 819, but not defined == Missing Reference: 'OPENMICRO' is mentioned on line 832, but not defined == Missing Reference: 'DATING' is mentioned on line 835, but not defined == Missing Reference: 'TREND' is mentioned on line 839, but not defined == Missing Reference: 'BOOTSTRAP' is mentioned on line 842, but not defined == Missing Reference: 'BUBBLE' is mentioned on line 866, but not defined == Missing Reference: 'BRIAR' is mentioned on line 863, but not defined == Missing Reference: 'NKOREA' is mentioned on line 823, but not defined == Missing Reference: 'ZEROKNOW' is mentioned on line 845, but not defined == Missing Reference: 'EGYPTSTUDY' is mentioned on line 828, but not defined == Missing Reference: 'TOR' is mentioned on line 857, but not defined == Missing Reference: 'CAPLIMIT' is mentioned on line 849, but not defined == Missing Reference: 'LEVELS' is mentioned on line 852, but not defined == Missing Reference: 'DIASPORA' is mentioned on line 860, but not defined == Missing Reference: 'TWIMIGHT' is mentioned on line 869, but not defined == Missing Reference: 'MUSUBI' is mentioned on line 873, but not defined == Missing Reference: 'TRIBLER' is mentioned on line 877, but not defined == Missing Reference: 'REBELLIONTV' is mentioned on line 880, but not defined == Missing Reference: 'DISPERSY' is mentioned on line 883, but not defined == Missing Reference: 'LIBSWIFT' is mentioned on line 887, but not defined Summary: 0 errors (**), 0 flaws (~~), 27 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Pouwelse, Ed. 3 Internet-Draft Delft University of Technology 4 Intended status: Standards Track February 14, 2014 5 Expires: August 18, 2014 7 The Shadow Internet: liberation from Surveillance, Censorship and 8 Servers 9 draft-pouwelse-perpass-shadow-internet-00 11 Abstract 13 This document describes some scenarios and requirements for Internet 14 hardening by creating what we term a shadow Internet, defined as an 15 infrastructure in which the ability of governments to conduct 16 indiscriminate eavesdropping or censor media dissemination is 17 reduced. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 18, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Real world scenario: Arab Spring context . . . . . . . . . . . 4 56 4. Microblogging . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Onion routing and bandwidth accounting . . . . . . . . . . . . 7 58 6. Driving scenarios . . . . . . . . . . . . . . . . . . . . . . 7 59 6.1. 20sec scenario . . . . . . . . . . . . . . . . . . . . . . 8 60 6.1.1. Adversary model: A simplistic attacker . . . . . . . . 8 61 6.1.2. Scenario details and architectural requirements . . . 8 62 6.2. Kill-switch scenario . . . . . . . . . . . . . . . . . . . 10 63 6.2.1. Adversary model: An advanced attacker . . . . . . . . 10 64 6.2.2. Scenario details and architectural requirements . . . 10 65 6.3. Friend-to-friend scenario . . . . . . . . . . . . . . . . 11 66 6.3.1. Adversary model: A powerful attacker . . . . . . . . . 11 67 6.3.2. Scenario details and architectural requirements . . . 12 68 6.4. Transmorph ability . . . . . . . . . . . . . . . . . . . . 13 69 6.5. A single global conversation . . . . . . . . . . . . . . . 13 70 6.6. Spammers and hoaxes . . . . . . . . . . . . . . . . . . . 14 71 7. Design principles: simplicity and prior success . . . . . . . 14 72 8. Background rant: lack of coordination and fragmentation . . . 14 73 9. Current running code and related work . . . . . . . . . . . . 15 74 10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 10.1. Use cases and threat model . . . . . . . . . . . . . . . . 17 76 10.2. System components, definitions and system architecture . . 17 77 10.3. Current technology and gap . . . . . . . . . . . . . . . . 17 78 10.4. Detailed system design and protocol specification . . . . 17 79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 13.2. Informative References . . . . . . . . . . . . . . . . . . 17 84 13.3. URL References . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2. Introduction 94 The shadow Internet is an alternative communication infrastructure 95 specifically crafted to be resiliant to sniffing, blocking, filtering 96 and shutdown. We discuss usage scenarios, architectural requirements 97 and how it could be used to combat global surveillance and 98 censorship. 100 Pervasive monitoring is a widespread attack on privacy [ATTACK]. It 101 is defined as widespread (and often covert) surveillance through 102 intrusive gathering of protocol artefacts, including application 103 content, or protocol meta-data such as headers. Bits moving across 104 the Internet are under surveillance at an unprecedented scale. 105 Today, both Internet providers and governments possess the ability to 106 monitor the moves of their digital citizens from central 107 infrastructure points. The leaks by Edward Snowden show the 108 capabilities of the NSA through their ANT product catalog [CATALOG]. 109 Internet routers from various vendors are easily compromised in their 110 entirety and "taps" may be inserted. Furthermore, some packets may 111 be re-routed to modify them, called man-in-the-middle Internet route 112 hijacking. The challenge is to make global pervasive surveillance 113 expensive again. We need to figure out how to re-engineer the 114 internet to prevent this kind of wholesale spying, see [SCHNEIER]. 116 Censorship is another key threat to The Internet. We focus on media 117 censorship and anonymity. The largest source of Internet traffic is 118 video traffic. Video is a powerful medium for reaching and 119 mobilizing mass audiences, with unique potential to bring about 120 social change. Anonymous video distribution is needed to prevent 121 repressive governments from stifling the free exchange of information 122 that enables citizens to organize effective political opposition. As 123 such, it constitutes a key tool for allowing populations to establish 124 self-governance, and for safeguarding human rights around the world. 125 Yet current methods of video distribution are controlled by a small 126 number of gatekeepers, and are difficult to access privately or 127 anonymously. Anonymous video distribution depends on technical 128 structures to support the building of trust, community, and 129 cooperative relationships between users. Until now, the difficulty 130 of confronting this challenge has prevented any system from offering 131 an effective solution. 133 Servers also cause problems. Email provider Lavabit is in court 134 appealing against a government order to hand over its encryption 135 keys. Owners of servers can be forced to cooperate to install a "pen 136 register", which tracks communication patterns. In the case of 137 Lavabit, authorities demanded he hand over the encryption keys for 138 its entire service and expose all customers. Essentially, a company 139 director can be forced to choose between committing sabotage on their 140 own security or goto jail. Therefore, servers are a key risk factor 141 in the shadow Internet architecture. Servers often keep extensive 142 logs, another risk factor. No privacy exists for the one billion 143 regular users of online video. Rather, their watching patterns are 144 meticulously recorded, including what they watched, when they watched 145 it, and with whom they shared it. 147 We outline scenarios for the shadow Internet and several 148 requirements. A key principle of the shadow Internet is that it 149 offers usable encryption without infrastructure. The shadow Internet 150 is required to protect the privacy of its users, allowing them to 151 remain anonymous if they wish, or to create digital personas for 152 sharing and commenting on videos. Privacy will be achieved by having 153 participants work together, each relaying the encrypted traffic of 154 others. For sustainability, participants will need to relay several 155 hours of traffic for each hour of video that they watch, so 156 encouraging cooperation is a key part of our scenario. The presented 157 scenarios strongly rely on a sense of community and mutual trust. 158 The potential user-base of our system is large: over 6 billion hours 159 of video are watched each month on YouTube alone. Our use-case and 160 scenarios are focused on large-scale penetration and uptake. 162 3. Real world scenario: Arab Spring context 164 Video footage of human rights violations can be a powerful catalyst 165 for change. Graphic depiction of atrocities for a world-wide 166 television audience can influence outcomes. However, global news 167 networks need to be able to obtain video footage from a hot zone. 169 Governments have demonstrated their ability to disable communications 170 networks in times of crisis. During the 2011 Arab Spring, Egyptian 171 authorities demanded that telecommunication companies sever their 172 broadband connections and mobile networks--both local and European 173 operators were forced to comply, and, as a result, digital Egypt 174 vanished. Despite the country's decentralized infrastructure, an 175 Internet blackout was relatively easy to carry out. The roles and 176 consequences of social media (e.g., Facebook and Twitter) during that 177 same period further illustrate the capacity governments have for 178 Internet censorship and the challenges activists face in combating 179 it. The April 6 Youth Movement from Egypt committed digital dissent 180 in full public view. According to The New York Times[YOUTH], the 181 movement "provided a structure for a new generation of Egyptians, who 182 aren't part of the nation's small coterie of activists and opinion 183 makers, to assemble virtually and communicate freely about their 184 grievances." But moving protest organizations to social media 185 accessible to the public-at-large can hold surprising risks. On the 186 ground, the movement's organization of labor strikes and protests in 187 Facebook groups, many with thousands of followers, triggered arrest 188 and imprisonment. Protesters in other countries quickly took note of 189 Egypt's lesson and disabled their public Facebook profiles. In 190 response, one government initiated social media searches on incoming, 191 young, plane travelers by forcing them to login to Facebook upon 192 arrival, thereby revealing online activities and any anti-government 193 sympathies.[FORCEDLOGIN] 195 A glimmer of hope exists. The Arab Spring shows that a new 196 generation is claiming their right to express themselves. 197 Microblogging, social media in general and traditional satellite news 198 broadcast networks are perceived as critical catalysts for political 199 change. Generic computational fabric is soon getting in the hands of 200 two billion people with the growth of smartphones and increasingly 201 affordable communication. These smartphones are increasingly used to 202 record and spread disruptive audiovisual material, even in regions 203 without media freedom. 205 Democratic countries also face a dilemma. Restrictions on the free 206 information flow is the topic of several proposed laws by elected 207 representatives. The strength of copyright law impacts digital 208 information flow. Politicians must decide between weak copyright 209 law, as championed by civil rights activists versus strong copyright 210 enforcement, as promoted by numerous players in the creative 211 industries. Recent furor around SOPA, PIPA, etc. in the US plus the 212 European Parliament vote on ACTA is highly relevant in this context. 214 The uniqueness of The Internet lies in the IETF standards. Moving 215 certain bits to certain locations or offering a service requires no 216 prior official approval. However, Internet-deployed mechanisms now 217 exist which filter news and media in general for both surveillance 218 and censorship. The Internet has ceased to provide reliable 219 transport service for all users. The IETF can repeat its historical 220 inter-networking role again by setting the standard for reliable flow 221 of media packets. 223 4. Microblogging 225 Microblogging is an increasingly popular technology for lightweight 226 interaction over the Internet. It differs from traditional blogging 227 in that [OPENMICRO]: 229 o Posts are short (typically less than 140 characters, which is the 230 limit in SMS). 232 o Posts are in plain text, but may contain links to photos or 233 videos, often taken and uploaded with a mobile device. 235 o People can reply to your posts, but not directly comment on them. 237 o People learn about your posts only if they have permission to view 238 them. 240 o Your microblogging feed is discovered based on your identity at a 241 domain or with a service. 243 The goal is creating a microblogging standard and facilitating a 244 reference implementation for portable devices which is capable of 245 operating in a hostile environment. This standard should be 246 resilient against all known forms of censorship. This proposed draft 247 standard SHALL provide: "information dissemination from a single 248 smartphone to an audience of millions in the form of microblogging, 249 enriched with pictures or streaming video which is guarded against 250 all known forms of censorship such as: cyberspace sabotage, digital 251 eavesdropping, infiltration, fraud, Internet kill switches, physical 252 checkpoints and lawyer-based attacks with the best known protective 253 methods". 255 The focus on microblogging is driven by feasibility. Creating a 256 standard for overcoming censorship for social networks, search 257 engines or web browsing in general is extremely challenging. 258 Mitigating the threats posed by Internet kill switches requires focus 259 on the most feasible viable standard. The related work listed in 260 this document shows existing operational systems. Existing systems 261 cover all functionality we desire, however none of them cover all 262 aspects and little interoperability exists. 264 As early as 2006, long before Arab spring events, it was reported 265 that individuals in wide swathes of the Arab world were using 266 Bluetooth technology to bypass police restrictions. According to 267 news reports[DATING], communication between men and women in this 268 region had been made possible by cellphone technology. When 269 Bluetooth-capable phones are in close proximity, they can engage 270 directly in digital and social chatter--no other infrastructure is 271 needed. Moreover, when sharing photos or bandwidth-hungry videos 272 with friends it also pays to be close. Government provided cellphone 273 networks might not be filtering you, but can still be dreadfully 274 slow. It therefore pays to use cell phones' Bluetooth-based, direct 275 file-transfer features--and it comes as no surprise that wireless- 276 transfer apps have seen millions of installs. A query of Google 277 Trends for the phrase "Bluetooth transfer" reveals a geographical 278 spread of this interesting social phenomenon[TREND]. It seems 279 millions of mobile phone owners are already employing the social 280 practice of wireless data exchange. Viability is increased by 281 building upon this practice. 283 5. Onion routing and bandwidth accounting 285 Tor pioneered the technique of relaying traffic to improve privacy 286 and security. We extend their valuable work in our scenarios. 287 However, our attacker model differs significantly and our goal is 288 robust video streaming, instead of browsing. Another key difference 289 is our focus on communities and utilizing trust between participants. 291 Onion routing consumes a lot of bandwidth and processing capacity. 292 Within Tor there is no direct rational incentive to operate a relay 293 node or exit node. In our outlined scenario and mechanisms we reward 294 cooperating (bandwidth donating) individuals with priority over 295 freeriders. This is an old idea, yet never realized. Large-scale 296 uptake is a key challenge. 298 We believe bandwidth accounting is essential for anonymous streaming, 299 as it creates an incentive mechanism motivating people to participate 300 in a collective system and thus contributing to its sustenance. 301 This, in turn, makes pervasive surveillance harder. Within the 302 scenarios we strive to leave out design and implementation details. 303 However, incentive compatibility is a MUST HAVE requirement and 304 explicitly included. 306 In our scenario we assume that it is possible to create and 307 distribute proof-of-work certificates. Such certificates are the 308 technological basis for the incentives. Helping others with becoming 309 anonymous through onion routing yields a cryptographically signed 310 proof-of-work certificate. Such proof-of-work certificates somehow 311 provide cooperating individuals with priority or faster service. 313 6. Driving scenarios 315 Recent Arab spring events have shown the power of ubiquitous camera- 316 phones, new media and microblogging. This document proposes to uses 317 smartphones, wifi and USB sticks for multimedia transport and 318 playback. The architecture, features and driving scenarios are 319 specifically crafted to enable compliant implementations as a single 320 smartphone app without any additional server infrastructure. 322 Each scenario is focused on certain threats in a hostile environment. 323 The adversary becomes stronger in several of the following scenarios 324 and we also focus on the social media context. 326 6.1. 20sec scenario 328 First scenario, called "20sec", defines an open microblogging 329 standard. This first scenario duplicates existing microblogging 330 practices with an open standard in a fully decentralized setting. 331 The scenario requirements are performance equal to central-server 332 based approach (e.g. the ability to reach 20 million people in 20 333 seconds). 335 6.1.1. Adversary model: A simplistic attacker 337 Eavesdropping is a common and easy passive attack in a hostile 338 environment. In this scenario we assume the attacker has full access 339 to the network between the user and any Internet server. 340 Specifically, the adversary can observe, block, delay, replay and 341 modify all traffic coming from any server. Furthermore, all servers 342 such as DNS servers, web servers, swarm trackers, CDN cloud servers 343 and access portals are assumed to be under direct or indirect control 344 of the adversary. 346 The adversary cannot compromise traffic between smartphones or other 347 participating devices. The adversary cannot compromise smartphones 348 or other participating devices. The adversary cannot break standard 349 cryptographic primitives, such as block ciphers and message- 350 authentication codes. 352 6.1.2. Scenario details and architectural requirements 354 Smartphone owner Alice with wifi-based Internet access records an 355 eye-witness video. She attaches this video to a microblog entry and 356 shares the story and the video content automatically with friends Bob 357 and Charlie, who are subscribers of her news feed. Alice does not 358 need to trust any central server with her credentials, nor has to 359 prove her identity to a central (web) server. Bob and Charlie are 360 both behind a NAT middlebox compliant to the BEHAVE recommendations 361 [RFC4787]. No assistance of a coordinating server (e.g. STUN or 362 TURN) is required to traverse this NAT box using UDP messages. This 363 scenario assumes direct or NAT-based Internet access (the next 364 scenario deals with packet forwarding). 366 Performance should be equal to a central-server based approach, 367 providing the ability to reach 20 million people in 20 seconds. This 368 first scenario duplicates existing microblogging practices with an 369 open standard in a fully decentralized setting. The 20sec scenario 370 requires that solutions provide seamless backwards compatibility with 371 existing leading solutions (e.g. Twitter, Sina Weibo, chyrp, heello) 372 by using content import tools. Proposed open solutions MUST permit 373 easy bulk transcoding and ingest of existing news feeds into this 374 open standard. 376 An essential feature of the 20sec scenario is all central gatekeepers 377 or communication to them is possibly compromised. Ownership of data 378 is fundamental to autonomy. To meet the anti-censorship goal, 20sec 379 assumes an infrastructure which is not dependent and completely 380 decoupled from potentially hostile servers such as DNS servers and 381 web servers. 20sec MUST be based on full self-organization. The 382 infrastructure consists purely of devices running compliant 383 implementations. No central server requires installation or 384 maintenance, making this infrastructure independent on any type of 385 funding or business model. 20sec requires an overlay which is highly 386 resilient. Smartphones, tablets and PCs are able to utilize this P2P 387 overlay for microblogging. Existing solutions such as [OPENMICRO] 388 require a central webserver and OAuth-like authentication primitives. 389 This prior work is not suitable for our 20sec scenario, as we aim to 390 remove all server, ultrapeer or superpeer reliance and equality of 391 all participants in the overlay. 393 When Alice downloads the smartphone app and runs it for the first 394 time, the application performs a bootstrap phase. On this initial 395 startup, the microblogging software looks for at least one other peer 396 in the overlay. The simplest method of bootstrapping is to use a 397 list of peers currently online, together with their port number. See 398 the example below. 400 # file: Central-Bootstrap-Servers.txt 401 # default bootstrap peers 402 server1.always-online.org 6420 403 host1.never-offline.ro 6420 404 sealand.routed.org 6420 405 168.0.0.13 6420 407 A file sharing program needs a fresh list of peers to bootstrap. 408 Thus a pre-defined list of peers is included in the software 409 installer. As peers can go offline it is important that at least one 410 peer out of possibly thousands on the list is still online. This 411 pre-existing address list of possibly working peers must therefore 412 remain valid for as long as possible. Bootstrapping is done by 413 contacting peers in the list, possibly in parallel. If a single 414 peers replies, the smartphone app of Alice is connected. Once 415 connected, a fresh list of working peer Internet addresses COULD be 416 requested. Several ideas have been proposed on bootstrapping systems 417 without an "online bootstrap server" list. For instance, simply by 418 smart brute force pinging, as described by the University of Denver 419 [BOOTSTRAP]. 421 It is RECOMMENDED compliant implementations explore and implement 422 efficient alternatives for decentralized initial bootstrapping. 424 6.2. Kill-switch scenario 426 This scenario describes a situation without any Internet access. We 427 assume the government has essentially "killed" the Internet, in an 428 Arab spring like scenario. It is focused on ad-hoc packet forwarding 429 between smartphones. 431 6.2.1. Adversary model: An advanced attacker 433 The adversary has disabled all Internet-based communication. 435 We assume the adversary cannot eavesdrop, jam, delay, replay, modify 436 or spoof wireless communication between smartphones. The adversary 437 cannot compromise smartphones or other participating devices. The 438 adversary cannot break standard cryptographic primitives, such as 439 block ciphers and message-authentication codes. 441 6.2.2. Scenario details and architectural requirements 443 Smartphone owner Alice has no Internet access. She records a video, 444 attaches this video to a microblog entry in her phone app. Friends 445 Bob and Charlie are subscribed to her news feed. Bob and Charlie are 446 at some point within range of the wifi, bluetooth or other wireless 447 capability of Alice. This fresh microblog entry plus video is shared 448 automatically. Bob obtained the message from Alice using a 449 smartphone app which is periodically scanning if other devices are 450 around and if they possibly have fresh news. This periodic 451 synchronization SHOULD be energy-efficient. Bob sees no noticeable 452 decrease in battery lifetime after he obtained unconstrained news 453 access. Charlie later goes to a square where numerous people have 454 gathered, most of which are highly interested in the latest videos. 455 The fresh messages automatically spreads in this crowd. 457 Note that this scenario differs from Delay-Tolerant Networking (DTN), 458 as being investigated by a Working Group within the Internet Research 459 Task Force [RFC4838] and scientists[BUBBLE]. The DTN focus is on 460 finding routes to an explicitly given destination, usually by 461 maintaining routing tables. Their system model and terminology 462 cannot be applied in our context, for instance, "Endpoint 463 Identifiers" which identify the original sender and final 464 destination. In our Internet-Free scenario sender Alice does NOT 465 explicitly send a message with destination Bob. 467 A wealth of related work exists in this area. General solutions are 468 found in mobile ad hoc networks (MANET), which provide self-organized 469 IP routing among wireless devices, and delay-tolerant networks (DTN), 470 which use a simple store-and-forward primitive to communicate over 471 heterogeneous links. Mobile ad hoc networks have been studied within 472 the Internet Research Task Force (IRTF) since 1997, leading to 473 several standards published by the IETF's MANET Working Group, while 474 delay-tolerant networks are currently the focus of the IRTF's DTN 475 Research Group. We hope that much of that knowledge can be reused, 476 despite our scenario differing slightly from DTN (as being 477 investigated by the IRTF [RFC4838]) 479 6.3. Friend-to-friend scenario 481 This third scenario uses friend-to-friend networking to remove the 482 requirement for active networking and wifi sensing. The smartphones 483 of Alice and Bob need to be synced manually. This scenario SHOULD 484 deliver a privacy-by-design type of microblogging service. 486 6.3.1. Adversary model: A powerful attacker 488 We must assume from the Arab Spring scenario the existence of a 489 powerful adversary. For instance, the adversary has disabled all 490 Internet-based communication. The adversary even actively monitors 491 wireless communication. Protocol designers have identified the 492 following threats [BRIAR] for similar circumstances: 494 o The adversary can observe, block, delay, replay, and modify 495 traffic on the underlying network. Thus, the microblogging 496 service must ensure end-to-end security without relying on the 497 security of the underlying network. 499 o Wireless communication is regularly monitored. Responding to any 500 wireless requests from a stranger is a direct threat to the user 501 and extremely harmful. 503 o Possession of encrypted electronic messages or encryption 504 technology in general is extremely harmful to the smartphone 505 owner. 507 o The adversary has a limited ability to compromise smartphones or 508 other participating devices. If a device is compromised, the 509 adversary can access any information held in the device's volatile 510 memory or persistent storage. 512 o The adversary can choose the data written to the microblogging 513 layer by higher protocol layers. 515 o The adversary cannot break standard cryptographic primitives, such 516 as block ciphers and message-authentication codes. 518 Encryption is not a sufficient requirement of the friend-to-friend 519 scenario, everything MUST be hidden. Possession of smartphones apps 520 with encryption is already dangerous for the owner. 522 6.3.2. Scenario details and architectural requirements 524 Reports from repressive regions indicate that USB sticks are commonly 525 used to transport sensitive information. See for instance this 526 extensive report on North-Korea [NKOREA]. In the friend-to-friend 527 scenario a network of friends is trusted to transport news manually, 528 by simply carrying it around. Smartphones with NFC capability or 529 manual USB transfer are used to duplicate and move messages. Thus 530 Alice delivers her fresh news message to Bob, which is later given 531 manually to Charlie. 533 As direct social connections are sparse and proximity of friends is 534 not continuous, this scenario SHOULD facilitate usage of friends-of- 535 friends or further removed social ties to relay news messages. This 536 requires the development of a decentralized social network, for 537 instance, with digital signatures of friendship certificates. In 538 effect this would create a "decentralized social network", completely 539 autonomous and owned by all participants. We assume Alice only has 540 Bob in her friendlist and Bob only has Charlie in his friendlist. An 541 OPTIONAL feature is that the smartphone apps running on the 542 smartphone Alice and Charlie detect that they have friendship path 543 through Bob. Fresh news is thus exchanged. 545 The interception of a single smartphone MUST NOT expose the app 546 itself, any friend list or worse: the entire social network. We 547 assume Alice is placing herself in danger with electronic tools for 548 "subversive activities against the democratic republic". Information 549 hiding techniques are essential or even life-critical. Possibly 550 based on Zero-Knowledge Proof (ZKP) protocols [ZEROKNOW]. The 551 smartphone app MUST pose as a harmless entertainment feature of a 552 smartphone or use another mechanism to become a "stealth app". The 553 requirement of such a stealth app is that a somewhat knowledgeable 554 person will not detect the presence of the app and will not discover 555 any video content, hence making the app checkpoint-proof. The app 556 itself should be hidden, i.e., it should not be visible in the app 557 list of the phone but, for example, be activated by dialing a secret 558 telephone number. In addition, the app should be able to virally 559 spread and be able to bypass any governmental restrictions on the 560 official app store. 562 This scenario requires modification and enhancement based on real- 563 world experience from human rights activist [EGYPTSTUDY]. 565 6.4. Transmorph ability 567 Prior scenarios expanded the threat model. This and the following 568 scenarios are focused on the social media context. News is created 569 in a region without freedom and then needs to travel to the outside 570 world. We refer to this simply as the freedom/non-freedom border. 571 Different transport protocols, dynamics and different solutions are 572 needed on the two sides of this border. 574 We now expand the friend-to-friend scenario with a transmorph 575 ability, the ability of news to cross the freedom/non-freedom border. 577 Alice is a well known blogger in an region with extreme censorship. 578 Her identity on Twitter has millions of followers. However, she has 579 no direct ability to reach a Twitter.com server or Internet in 580 general. We assume Alice only has Bob in her friendlist and Bob only 581 has Charlie in his friendlist. Charlie is able to smuggle a 582 collection of messages out of the country. The messages originating 583 from Alice should be transmorphed into a series of Twitter post 584 belonging to her. 586 The identities used in Twitter are highly identifiable labels, with a 587 certain trust level. This hard identity with millions of followers 588 is a stark contrasts with anonymity. Current anti-censorship 589 technology lacks the ability to first have stealth encrypted 590 transport of news, cross the freedom/non-freedom border and then 591 transmorph this news into a public accessible form with a highly 592 identifiable label. 594 6.5. A single global conversation 596 Existing technologies, such as [TOR] in combination with XMPP or the 597 Orbot smartphone app facilitate protected point-to-point 598 communication. However, a desired scenario is to facilitate more 599 current the Twitter-like social media practices, best typified as a 600 "global conversation". 602 Furthermore, current social media revolves around video-rich, real- 603 time interaction with groups, hashtag-based discovery and social 604 networking. All of these aspects are not offered or are incompatible 605 with current-generation of privacy enhancing technology. More 606 knowledge is needed about reputation models in news reporting and 607 information flows. In the current microblogging age, can the number 608 of real-person followers be seen as your reputation? Do several news 609 sources of moderate reputation which report the same news story yield 610 together an increased reputation score? 612 This work should combine privacy enhancement with microblogging. 614 6.6. Spammers and hoaxes 616 This final scenario is focused on spam. All technology addressing 617 one of the above scenarios MUST also have the capability to deal with 618 spam. Unfortunately, this ability to deal with spam is in conflict 619 with simplicity. 621 Alice and Bob are exchanging the fresh messages from their social 622 network (similar to Internet-free or Friends-only). Eve is actively 623 trying to disrupt the system by injecting news channels with a mix of 624 genuine news, obviously fake messages (consuming valuable system 625 resources and user attention) and hoaxes. These falsehoods made to 626 masquerade as truth result in erosion of overall trust in the system. 628 Systems SHOULD offer capabilities to report spam, mechanisms for fact 629 validation and reputations of (pseudo) identities. 631 7. Design principles: simplicity and prior success 633 Designing and crafting software which is completely self-organizing 634 has clear limits [CAPLIMIT] and requires a certain level of expertise 635 [LEVELS]. In order to avoid repeating mistakes from the past, this 636 document aims to base its design principles on existing new media 637 successes. For microblogging this means following market leading 638 solutions and enhance them with censorship resilience. We recognize 639 the following success factors: Simplicity, Real-time responsiveness, 640 Near-effortless news creation, News items are bundled in channels, 641 combine public broadcasting and person-to-person private messaging, 642 following a channel is single direction, more followers yields more 643 visibility, keyword search with push of updates and ability to deal 644 with spam. 646 8. Background rant: lack of coordination and fragmentation 648 Computers communicating on equal footing has been part of the IETF 649 standards for many decades. Recently several loosely connected 650 standard initiated around explicitly driven by the P2P paradigm for 651 applications such as Internet telephony video streaming. An 652 essential problem in this domain is the lack of coordination and 653 standard setting for P2P technology. A large part of the innovation 654 around P2P seems to happen in single-person Open Source projects and 655 small groups which lack the engineering capacity to make generic, re- 656 usable and documented components. Given their running code-driven 657 nature, money and time is not available for attending standards- 658 setting meetings, writing formal specifications and defining quality 659 control testing suites. Profit-driven organizations should have the 660 resources to overcome these resource shortage issues. However, due 661 to the dynamic, disruptive and litigious nature of P2P few examples 662 exist of companies which are capable of supporting an IETF standard 663 setting activity for several years. 665 As presented during IETF 81 area directorate, there is "not a clear 666 long-term architecture yet for you to build actual classes of P2P 667 applications using IETF technologies". Forming an overlay is hard 668 and scalable privacy-preserving unstructured search solutions are 669 only barely out of the scientific research community. 671 From the above we conclude that a key obstacle to the success of this 672 proposal is implementation and uptake. A draft document, active 673 community and reference implementation ideally evolve together over 674 time. To overcome this issue a continuous incremental improvement 675 approach is advised. The preferred way is incremental development of 676 single a reference implementation, based on free software. 678 9. Current running code and related work 680 DISCLAIMER: this section needs significant expansion and listing of 681 projects with running code and self-organization. 683 Several Open Source projects have running code and partially 684 implemented the above four scenarios. We will briefly list them 685 here. 687 [TOR] A free software implementation of second-generation onion 688 routing, a mechanism enabling users to communicate anonymously over 689 the Internet. This flagship project has boosted online anonymity for 690 over a decade and is the key example for the cat and mouse dynamics 691 of privacy/surveillance technologies. The Orbot project provides an 692 Android implementation of Tor. Due to the usage of the client server/ 693 model, exit node principle plus lack of reputations this architecture 694 is not compatible with our scenarios. 696 [DIASPORA] A free personal web platform implementing a distributed 697 social networking service. This partially operational system is 698 based on a client/server model and thus not compatible with our ad- 699 hoc scenarios. 701 [BRIAR] Briar is a secure news and discussion system designed to be 702 used by journalists, activists and civil society groups in 703 authoritarian countries. Briar differs from existing circumvention 704 tools and mesh networks in three significant ways: needs no external 705 infrastructure, can operate over any mixture of available media and 706 builds on social relationships. The aims of this project are similar 707 to our scenarios, but this project lacks running code and has few 708 active developers. 710 [BUBBLE] DTN researchers have simulated closely related scenarios. 711 Dissemination in the Arab Spring scenario is likely to involve an 712 explicit copy between people who trust each other, referred to as 713 social-based forwarding in this study. 715 [TWIMIGHT] The Twimight project by ETH-Zurich university shows that 716 decentralized microblogging already exists. Researchers developed an 717 Android application that uses Twitter servers in normal conditions, 718 but switches to a Bluetooth-based disaster mode when Internet 719 connectivity is lost. 721 [MUSUBI] The Musubi smartphone app represents another key, 722 censorship-free, technology advancement. Developed by Stanford 723 University, it offers instant messaging service and media sharing 724 capabilities similar to WhatsApp, Ping, and Blackberry Messenger. 725 What makes it unique is that all data and processing resides on the 726 smartphones, not in the cloud. This decentralization removes the 727 need for central processing and provides significant decoupling from 728 the underlying infrastructure. Exchange of cryptographic keys is 729 integrated in the friending process--Musubi essentially builds a 730 decentralized social graph. Unfortunately, Musubi is also limited-- 731 all data transfers go through central servers, as it lacks NAT- 732 traversal capability. 734 [TRIBLER] DISCLAIMER2: this project is coordinated by the author. 735 This project has created Open Source firmware for a Samsung Internet- 736 connected television which gives it the ability to find, share and 737 stream news videos within a fully self-organizing overlay; operated 738 only by remote control [REBELLIONTV]. It is also available as 739 generic zero-server file sharing software for the PC which has been 740 installed by 1.2 million users. It uses the Dispersy elastic 741 database for providing: keyword search, content discovery, content 742 voting and spam prevention using crowd sourcing [DISPERSY]. For 743 swarm-based streaming and generic message transport it uses the IETF 744 protocol developed within the PPSP working group, called Libswift 745 [LIBSWIFT]. All this code is created by a single team and 746 specifically designed to facilitate evolution into the prior 747 described scenarios. An Libswift demo streaming app is available on 748 the Android market. 750 10. Open issues 752 Deliverables planned and issues which need to be addressed. 754 TODO: ADD REF Privacy definition: 755 http://tools.ietf.org/html/draft-iab-privacy-terminology-01 757 TODO: REF 758 http://www.ietf.org/id/draft-iab-privacy-considerations-03.txt 760 TODO: http://datatracker.ietf.org/doc/search/ P2P 762 TODO: http://datatracker.ietf.org/doc/rfc4981/ SEARCH survey 764 TODO: https://datatracker.ietf.org/doc/draft-ietf-p2psip-reload/ 766 10.1. Use cases and threat model 768 10.2. System components, definitions and system architecture 770 10.3. Current technology and gap 772 10.4. Detailed system design and protocol specification 774 11. Security Considerations 776 tbd. 778 12. IANA Considerations 780 tbd. 782 13. References 784 13.1. Normative References 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, March 1997. 789 13.2. Informative References 791 [RFC4787] Audet, F. and C. Jennings, "Network Address 792 Translation (NAT) Behavioral Requirements for Unicast 793 UDP", BCP 127, RFC 4787, January 2007. 795 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., 796 Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay- 797 Tolerant Networking Architecture", RFC 4838, 798 April 2007. 800 13.3. URL References 802 [ATTACK] https://datatracker.ietf.org/doc/ 803 draft-farrell-perpass-attack, "Pervasive Monitoring is 804 an Attack". 806 [CATALOG] http://www.spiegel.de/international/world/ 807 catalog-reveals-nsa-has-back-doors-for-numerous- 808 devices-a-940994.html, "Shopping for Spy Gear: Catalog 809 Advertises NSA Toolbox". 811 [SCHNEIER] http://www.theguardian.com/commentisfree/2013/sep/05/ 812 government-betrayed-internet-nsa-spying, "The US 813 government has betrayed the internet. We need to take 814 it back". 816 [YOUTH] http://www.nytimes.com/2009/01/25/magazine/ 817 25bloggers-t.html, "Revolution, Facebook-Style". 819 [FORCEDLOGIN] http://online.wsj.com/article/ 820 SB125978649644673331.html, "Iranian Crackdown Goes 821 Global". 823 [NKOREA] http://audiencescapes.org/sites/default/files/ 824 Report_Summary_Quiet_Opening_North% 825 20Korea_InterMedia.pdf, "A QUIET OPENING: NORTH 826 KOREANS IN A CHANGING MEDIA ENVIRONMENT". 828 [EGYPTSTUDY] http://conferences.sigcomm.org/imc/2011/docs/p1.pdf, 829 "Analysis of country-wide internet outages caused by 830 censorship". 832 [OPENMICRO] http://xmpp.org/extensions/xep-0277.html, "XEP-0277: 833 Microblogging over XMPP". 835 [DATING] http://www.washingtonpost.com/wp-dyn/content/article/ 836 2006/08/05/AR2006080500930.html, "Saudi Youth Use 837 Cellphone Savvy To Outwit the Sentries of Romance". 839 [TREND] http://www.google.com/trends/?q=bluetooth+transfer, 840 "Google Trends query". 842 [BOOTSTRAP] http://grothoff.org/christian/dasp2p.pdf, 843 "Bootstrapping Peer-to-Peer Networks". 845 [ZEROKNOW] http://www.cse.ust.hk/~liu/luli/PT_Trans_final.pdf, 846 "Pseudo trust: Zero-knowledge based authentication in 847 anonymous peer-to-peer protocols". 849 [CAPLIMIT] http://doi.ieeecomputersociety.org/10.1109/MC.2012.54, 850 "The CAP Theorem's Growing Impact". 852 [LEVELS] http://blog.incubaid.com/2012/03/28/ 853 the-game-of-distributed-systems-programming-which- 854 level-are-you/, "The Game of Distributed Systems 855 Programming. Which Level Are You?". 857 [TOR] http://www.torproject.org, "Tor Project: Anonymity 858 Online". 860 [DIASPORA] http://diasporaproject.org/, "Diaspora is a fun and 861 creative community that puts you in control.". 863 [BRIAR] https://fulpool.org/btp.pdf, "Secure communication 864 over diverse transports". 866 [BUBBLE] http://dx.doi.org/10.1109/TMC.2010.246, "BUBBLE Rap: 867 Social-Based Forwarding in Delay-Tolerant Networks". 869 [TWIMIGHT] http://dl.acm.org/citation.cfm?id=2159576.2159601, 870 "Twitter in disaster mode: smart probing for 871 opportunistic peers". 873 [MUSUBI] http://dl.acm.org/citation.cfm?id=2187866, "Musubi: 874 disintermediated interactive social feeds for mobile 875 devices". 877 [TRIBLER] http://dl.acm.org/citation.cfm?id=2206767, "Tribler: 878 P2P search, share and stream". 880 [REBELLIONTV] http://www.tribler.org/trac/wiki/SwiftTV, "RebellionTV 881 a.k.a. Libswift on a television project". 883 [DISPERSY] www.frayja.com/pub/ 884 dispersypaper2012.pdf:donotdistribute, "Dispersy 885 elastic database". 887 [LIBSWIFT] http://www.libswift.org, "IETF PPSP streaming protocol 888 implementation". 890 Author's Address 892 Johan Pouwelse (editor) 893 Delft University of Technology 894 Mekelweg 4 895 Delft 896 The Netherlands 898 Phone: +31 15 278 2539 899 EMail: J.A.pouwelse@tudelft.nl