idnits 2.17.1 draft-kutscher-icnrg-rice-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 01, 2018) is 2033 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG M. Krol 3 Internet-Draft University College London 4 Intended status: Experimental K. Habak 5 Expires: April 4, 2019 Georgia Institute of Technology 6 D. Oran 7 Network Systems Research & Design 8 D. Kutscher 9 Huawei 10 I. Psaras 11 University College London 12 October 01, 2018 14 Remote Method Invocation in ICN 15 draft-kutscher-icnrg-rice-00 17 Abstract 19 Information Centric Networking has been proposed as a new network 20 layer for the Internet, capable of encompassing the full range of 21 networking facilities provided by the current IP architecture. In 22 addition to the obvious content-fetching use cases which have been 23 the subject of a large body of work, ICN has also shown promise as a 24 substrate to effectively support remote computation, both pure 25 functional programming (as exemplified by Named Function Networking) 26 and more general remote invocation models such as RPC and web 27 transactions. Providing a unified remote computation capability in 28 ICN presents some unique challenges, among which are timer 29 management, client authorization, and binding to state held by 30 servers, while maintaining the advantages of ICN protocol designs 31 like CCN and NDN. This document specifies a unified approach to 32 remote method invocation in ICN that exploits the attractive ICN 33 properties of name-based routing, receiver-driven flow and congestion 34 control, flow balance, and object-oriented security while presenting 35 a natural programming model to the application developer. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 4, 2019. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Terminology and Design Overview . . . . . . . . . . . . . . . 5 73 2.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.1. Thunks . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.3. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 9 78 3.4. Shared Secret Derivation . . . . . . . . . . . . . . . . 9 79 3.5. Client Authentication . . . . . . . . . . . . . . . . . . 10 80 3.6. Input Parameters . . . . . . . . . . . . . . . . . . . . 10 81 3.7. Dynamic Content Retrieval Using Thunks . . . . . . . . . 11 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 5.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 5.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 Much of today's network traffic consists of data sent for processing 91 to the cloud and web-servers exchanging high volumes of dynamically 92 generated content. While today's ICN networks can deal efficiently 93 with static data delivery, they have difficulty handling service/ 94 function invocation [MOISEENKO2014]. In view of these limitations, 95 multiple works have recently tried to extend ICN's capabilities to 96 deal with dynamic content. 98 Notable among these efforts, Named Function Networking (NFN) 99 [TSCHUDIN2014NAMED] and Named Function as a Service (NFaaS) [NFAAS] 100 extend ICN's named data access model to a remote function invocation 101 capability, enabling consumers to request the network to execute 102 functions remotely. In NFN \cite{tschudin2014named}, for instance, 103 function invocation corresponds to independent computational 104 processes, evaluated as expressions in a functional programming 105 model. 107 ICN provides several attractive benefits compared to remote 108 invocation over current network protocol stacks (e.g. CORBA, RESTful 109 HTTP [REST]. Name-based routing allows the network to optimise the 110 placement of computations with automatic load distribution and 111 failure resiliency. The built-in object-based security of ICN frees 112 application designers from the need to craft custom solutions in the 113 common cases where channel security alone is insufficient. Short- 114 term caching brings latency benefits under transient error conditions 115 and mobility events, while long-term caching can substantially reduce 116 server load for referentially transparent computations. 118 There have been several approaches for integrating computation with 119 ICN. However, when using them to realize real-world applications 120 like web-style interactions, several additional aspects beyond the 121 fundamental Named Function invocation concept need to be addressed: 123 o Consumer authentication and authorization: a producer should not 124 blindly answer any consumer request. In basic ICN, this 125 protection is provided by cryptographic data object integrity and 126 encryption, i.e., only authorized consumers are able to decrypt a 127 received data object. In a Named Function Networking environment, 128 the computation may be an expensive operation, so just relying on 129 encryption and performing computations without validating consumer 130 authorization may critically impede scalability of the whole 131 approach. 133 o Parameter passing: Remote function execution typically requires a 134 set of input parameters/arguments. In dynamic web content 135 creation for example, the volume of such parameters (in bytes) can 136 easily surpass the volume of the actual returned data objects 137 {{MOISEENKO2014}. Adding larger sets of parameters to Interest 138 messages can introduce additional unsolicited traffic in ICN 139 networks that could interfere with congestion control. 141 o Accommodating non-trivial computations: Unlike responding to an 142 Interest message with a (possibly pre-generated) static Data 143 message, constructing responses by performing general computations 144 (that could in turn invoke further remote computations) may take 145 relatively long. In CCN/NDN, forwarders keep Interest state for 146 matching received Data messages. The design and dimensioning of 147 Pending Interest Tables (PITs) is typically based on the 148 assumption that corresponding Data messages are received in a time 149 frame that is based on typical network RTTs (e.g., order of 10s or 150 100s of milliseconds for wide-area networks). PIT state is, 151 therefore, short-lived by design. As a result, Application 152 Timescales can differ significantly from Network Timescales, which 153 must be considered by a general purpose function invocation 154 scheme. 156 RICE aims to overcome these three limitations by enhancing the ICN 157 model with function-oriented capabilities while preserving the core 158 architectural and protocol design elements of ICN networks. RICE is 159 a general-purpose network-layer framework and can be applied to any 160 named-function networking context. Its main features are: 162 o a secure, 4-way handshake for ICN networks in order to achieve 163 shared secret derivation, consumer authentication and parameter 164 passing. 166 o the concept of thunks [THUNKS] from the programming language 167 literature to decouple method invocation from the return of 168 results to enable long-running computations. The thunk is used to 169 name the results for retrieval purposes. 171 The ultimate goal of the RICE framework is to enable in-network 172 function execution with client authentication and non-trivial 173 parameter passing, to support cases where computation takes longer 174 than PIT expiry time. RICE achieves this goal by decoupling 175 application processing time from PIT timers and network RTT. We 176 argue that this is a necessary feature of any name-based remote 177 function invocation scheme, where computation is accommodated in 178 distributed compute spots in local or wide area networks at the core 179 or edge of the network. The mechanisms we propose follow ICN 180 principles and require minimal and short-lived additional network 181 state. 183 More rationale, a comparison with related work, and an evaluation of 184 the RICE approach is provided in [RICE2018]. 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119, BCP 14 189 [RFC2119] and indicate requirement levels for compliant RICE 190 implementations. 192 2. Terminology and Design Overview 194 RICE is as a general Remote Method Invocation (RMI) service - 195 providing a robust and secure basis for a wide range of applications 196 and in-network computation scenarios, including scenarios where 197 method invocation requires a significant amount of input data and 198 involves computations that take significantly longer than a network 199 RTT to complete. 201 RICE is independent of any particular function execution environment. 202 RICE provides all the required ICN protocol mechanisms and 203 conventions for clients and servers and can serve as an underlying 204 platform to support frameworks such as NFN and NFaaS (as well as any 205 other in-network compute framework that utilises core ICN 206 principles). In the description of RICE we use the following 207 terminology: 209 Consumer: ICN protocol entity that is sending an Interest message 211 Producer: ICN protocol entity that is sending a Data message, 212 replying to a received Interest message 214 Client: RICE protocol user that wants to request a remote method 215 invocation 217 Server: RICE protocol user that is processing and answering the 218 remote method invocation request (this may be a logical entity 219 that is represented by more than one ICN protocol entity) 221 2.1. Design Goals 223 The RICE protocol is based on the following design goals: 225 Decouple application time scale from network time scale: RICE does 226 not map remote method invocation directly to one Interest/Data 227 exchange for the reasons discussed above. We want clients to 228 request remote method invocation from a server without changing 229 the network behavior with respect to Pending Interest management. 231 Support client authorization: A RICE server should be able to 232 authorize clients before committing resources such as state, 233 processing power etc. A server that blindly accepts any RMI 234 request opens itself to computational and/or memory overload 235 attacks. This also implies that the authorization mechanisms must 236 be designed so that performing authorization itself does not 237 overload servers and open a vulnerability to computational 238 attacks. 240 Support non-trivial method invocation with arbitrarily complex 241 parameter sets 243 Be robust and ICN-friendly to a mix of RICE and non-RICE traffic: we 244 want RICE to coexist seamlessly in existing ICN networks, e.g., it 245 should adhere to the same flow balance principles. The main 246 consequence is that we do not transmit RMI parameters in Interest 247 messages. 249 Support non-trivial, long-running computations with large amounts of 250 result data 252 Support session-like interactions, where a client and a server use a 253 sequence of exchanges: 254 RICE result data should be chunkable, and it should also be 255 possible to retrieve result data that is generated over time, for 256 example in multiple invocations in the same "session". 258 Allow ICN caching for referentially transparent method invocations: 259 ICN generally supports location-independent data access and 260 opportunistic caching. In RICE, we want to support referentially 261 transparent functions efficiently, i.e., function expressions that 262 can be replaced with the result of the actual function execution. 263 In other words, RICE is able to cache the result from such 264 function invocations and enables the network to answer subsequent 265 Interest messages from caches. Since not all functions are 266 referentially transparent (some functions may depend on other data 267 from the environment that is not specified in arguments), our 268 framework distinguishes between functions that are referentially 269 transparent and those that are not. 271 Adhere to ICN principles: RICE should not give up important ICN 272 principles, such as flow balance, implicit support for consumer 273 mobility, consumer anonymity (no source addresses). This last 274 property is worth mentioning, because some ICN extensions/ 275 applications rely on the fact that one end of an interaction would 276 provide a globally routable "source" address to the other end to 277 achieve "callback" behavior or generally enable bidirectional 278 communication. Since such schemes would expose client identity 279 information to the network (and to peers), we deem this approach 280 an unacceptable deviation from ICN principles. Client identities 281 should be exposed only to the application layer. Other forms of 282 identifiers that help the network for maintaining reverse 283 forwarding state to clients should be designed so that they do not 284 expose clients' identities. 286 Be compatible with ICN extension mechanisms: Some recent proposed 287 extensions make benign changes to ICN forwarding behavior (without 288 compromising general interoperability). One example would be fast 289 forwarding information updates using technique such as Map-ME 290 [MAPME]. RICE should be designed to work with such extensions. 291 In this particular case, this means that RICE should support 292 client and server mobility in a Map-ME-enhanced network. 294 Make minimal changes to ICN protocols and forwarder behavior: We 295 want to allow for some changes to ICN forwarder behavior, but 296 these should be limited and designed so that they do not 297 complicate forwarder implementations or impair their performance. 299 The general guideline for achieving these goals is to prioritize 300 robustness, security and scalability over absolute efficiency (with 301 respect to number of handshakes and message exchanges), while still 302 arriving at a design with reasonable efficiency. 304 3. Protocol 306 Remote Method Invocation (RMI) operations in RICE are split in two 307 ICN interaction phases: 1) RMI Initiation (eventually triggering the 308 remote method execution), and 2) the Result Retrieval. The RMI 309 Initiation phase is designed to complete in Network Timescale (on the 310 order of a few RTTs), whereas the remote method execution is 311 decoupled from that and can take as long as required. The Result 312 Retrieval phase can consist of several ICN Interest-Data exchanges 313 (for chunked results or for computations that generate results 314 iteratively). 316 3.1. Thunks 318 RMI Initiation and Result Retrieval are somehow decoupled from each 319 other. The RMI Initiation generates a 'Thunk' name, i.e., a handler 320 that the client can use later to retrieve the RMI result (or status) 321 from the server. 'Thunk' thus represents the computation process at 322 the server. 324 The RMI Initiation and the actual RMI invocation (and results) 325 delivery do not necessarily have to take place on the same ICN node. 326 For example, a RICE server could accept an RMI request, perform the 327 Initiation and then delegate the actual computation to a backend 328 server. For that, it would generate a Thunk name that the client can 329 use to reach that backend server (or to obtain the corresponding 330 result, generally speaking). 332 3.2. Naming 334 RICE relies on a generic naming scheme for remote method invocation. 335 We distinguish between 'Method Names' and 'Thunk Names'. A function 336 name identifies a method requested by a client that can be executed 337 by any server able to perform the computations. In contrast, a thunk 338 name identifies a specific method instance already being run on a 339 specific node. 341 When a client initially requests the invocation of a referentially 342 transparent method, the name in the Interest MUST unambiguously 343 specify both the invoked method and the set of input parameters. The 344 method part can be system-specific (\e.g., lambda-expressions in 345 [TSCHUDIN2014NAMED] or expressed as a hierarchical name structure as 346 in [NFAAS]}), but MUST unambiguously identify the method to invoke. 348 The input parameters can be represented directly when very small in 349 size (e.g., username, number of iterations to perform), or as a hash 350 when larger. (The choice of the actual hashing method can be left to 351 the application.) 353 For referentially opaque methods, the result can be different even 354 when using the same input parameters. Every invocation (either from 355 the same client or from other clients) MUST lead to a new computation 356 instance. Therefore, Interests for triggering referentially opaque 357 method invocations MUST use a unique name for each invocation, while 358 Interest retransmissions from the same client MUST use the same name. 360 This prevents the network from aggregating the corresponding 361 Interests and limits cached responses to only answer retransmitted 362 interests from a individual consumer. To achieve this, the client 363 MUST include a name component that distinguishes its request from 364 those generated by other clients. This component MUST be chosen by 365 the client such that other nodes cannot predict the value. (Using 366 predictable information (e.g., a MAC address) opens an additional 367 attack surface and can leak client's sensitive information.) 369 The thunk name MUST unambiguously identify the server's forwarder, 370 the instantiated method and the method's internal state (i.e., input 371 parameters, chunk number). In that way, when the client uses the 372 thunk name in consecutive requests, the Interest can be forwarded to 373 the correct server and dispatched to the application possessing the 374 associated result data. With thunk names, we do not need to 375 distinguish between names for referentially transparent and opaque 376 methods. They unambiguously identify a handler to a method execution 377 instance, and it is up to the server to return the same or different 378 handlers to multiple clients. 380 3.3. Handshake 382 RICE uses a 4-way handshake which serves the purposes of 1) deriving 383 a shared secret, 2) authenticating and authorizing clients, and 3) 384 providing input parameters to methods. 386 A client starts a 4-way handshake by sending an Interest message I1 387 towards a server. Similarly to the TCP SYN flag, the message 388 contains an additional TLV Handshake field (this description assumes 389 NDN [NDN] implementation of ICN). 391 The field contains an identifier that is chosen by the client and 392 distinguishes among different handshakes. Upon receipt of the 393 Interest, each forwarder creates a corresponding PIT entry as with 394 regular Interests. Forwarders also inject a new temporary entry in 395 the FIB formed from the identifier and pointing to the face on which 396 the Interest was received. This FIB entry has a short expiry time 397 after which it is deleted. 399 TODO: specify the timeout 401 When the server receives the Interest, it MUST respond with an I2 402 Interest message and forms the name from the received identifier. 403 The Interest thus follows the previously established FIB entries 404 towards the client. The forwarder also increases the expiry timer of 405 I1's PIT entry. 407 At this point, the client MUST be ready to respond and send a D2 Data 408 message. (Authorization information and parameters may be larger 409 than what can be carried in a single D2 message. Therefore, multiple 410 I2/D2 exchanges using the built-in chunking capabilities of the 411 underlying ICN protocols can be employed.) When the server receives 412 D2 it allocates resources for the computation for the client and 413 sends back a confirmation in D1 Data message. 415 Interest I1 of the first handshake contains a method name that is 416 delivered to a server advertising the corresponding prefix. At the 417 end of the first handshake, in D1, the server returns its thunk name. 418 This name can be then used by the client in I1 message of consecutive 419 handshakes to assure future invocations reach the same method 420 instance. 422 3.4. Shared Secret Derivation 424 *Dirk: Not sure we need the following:* 426 Common secret derivation plays an important role in many security 427 protocols. Once a common secret is established, both parties can 428 encrypt the communication using symmetric cryptography. Common 429 secret derivation (e.g., via Diffie-Hellman Key Exchange) requires 430 sending data in both directions between the involved parties and is 431 clumsy to implement in vanilla ICN networks where not all nodes have 432 globally routable prefixes. Using one or multiple handshakes as 433 described above allows use of any symmetric key scheme to secure the 434 communication over arbitrary paths. 436 3.5. Client Authentication 438 Reliable and secure authentication requires multiple messages to be 439 exchanged between the server and the client. Utilizing the handshake 440 for client authentication, specially the exchanged I2/D2 messages, we 441 achieve this goal and we decouple it from function invocation and 442 input parameter passing. 444 In addition, by using the I2/D2 messages for client authentication 445 and avoiding adding authentication information in the original 446 interest (I2/D2), the RICE handshake mechanism becomes protected 447 against any record-and-replay attack by a malicious party which can 448 intercept the traffic. Once authenticated, the client creates a 449 security token that can be included as a last component of the thunk 450 name. In further communication such as commands (i.e., pause, stop) 451 or referentially opaque methods, the token can be changed for each 452 consecutive Interest message (i.e., based on the last received Data 453 message). 455 It should be noted that RICE can rely on idiomatic ICN mechanisms for 456 server authentication, i.e., validate the signatures on Data or 457 signed Interest messages. The client could also encrypt input 458 parameters using the public key of the server. A detailed 459 specification will be provided by a future version of this document. 461 Following ICN principles, clients SHOULD NOT authenticate the server 462 performing computations, but rather authenticate the returned result. 463 If submitted input contains confidential data, it can be encrypted 464 and shared using existing ICN access control techniques 465 [ION2013TOWARD]. 467 3.6. Input Parameters 469 RICE passes input parameters to remote methods "by reference". Since 470 the server cannot access memory in the client, we use the I2/D2 471 Interest/Data Exchange as a "callback" from the server to the client 472 to fetch the input parameters. This preserves the ICN principle that 473 data is never pushed to the server if not requested. The server 474 piggybacks on the PIT entry established by I1 to reach the client and 475 pull the required data. If the input contains sensitive information, 476 the client can encrypt it using a common secret derived in previous 477 handshakes as described above. 479 3.7. Dynamic Content Retrieval Using Thunks 481 In dynamic content generation or method invocation, the server may 482 require a significant amount of time to create the requested data. 483 In this section, we describe our use of thunks to allow clients to 484 retrieve computation results. 486 The client starts by sending an Interest with a function name. 487 Thunks allow multiple clients calling the same referentially 488 transparent method with identical parameter sets to share one PIT 489 entry and efficiently retrieve the data, while keeping entries 490 separate for referentially opaque computations. 492 Upon receipt of the Interest, the server starts the requested 493 computation and immediately responds with a thunk Data message. For 494 the network, the thunk does not differ from a regular Data message 495 that consumes the pending PIT entry. The payload of the message 496 contains a 'thunk name' and an estimated completion time. The client 497 waits for the time indicated in the server's response and issues a 498 new Interest with the received thunk name. 500 Once the computation has finished, the function responds with a Data 501 message containing the result. If the server mis-estimated the 502 completion time and the data is not ready, it returns the same thunk 503 target with an updated completion time estimate. 505 4. Security Considerations 507 By building on a well-studied ICN protocol framework, RICE shares the 508 fundamental security advantages and difficulties of those protocols 509 [MISRA2013], [CHOI2013THREAT], [ALSHEIKH2015FLOODING]. RICE employs 510 native CCN/NDN machinery for cryptographic data integrity, origin 511 authentication, confidentiality, and key management [MAHADEVAN2014]. 512 Similarly, RICE shares the privacy problems and limitations of extant 513 ICN protocols [GHALI2016]. In general, the additional threat that 514 needs to be addressed is a computational or state-creation attack 515 against a server by un-authorized clients. These threats request 516 long-running computations, or flood the server with remote invocation 517 requests that start useless computations [AIRTNT], [SPOC]. 519 For the security consideration, we concentrate on the vulnerabilities 520 associated with RICE, and provide a brief security analysis of the 521 RICE machinery. The proposed 4-way handshake provides secure input 522 parameter passing. It does so by fetching the parameters via the 523 Interest-Data exchange "callback" from the server to the client. 525 Such callbacks could open a reflection attack via interest flooding 526 [CHOI2013THREAT] if a globally routable name were used for the 527 callback operation. However, the reverse-path mechanism and non- 528 routable name RICE uses confines knowledge of the client's input 529 parameter set to the server and on-path forwarders. The remaining 530 vulnerability is the need to maintain forwarding state for the entire 531 duration of the four-way handshake, rather than just a two-way 532 exchange. 534 When a client sends I1 towards a producer, it creates additional 535 state in FIB tables on all the intermediary forwarders. However, 536 similarly to PIT entries, the created state is purged when its timer 537 expires. If the timer is set to the same value as the PIT entries 538 divided by 2, it does not expand the attack surface and existing 539 Interest flood prevention techniques can be applied 540 [ALSHEIKH2015FLOODING]. 542 Upon reception of I1, the producer does not create any local state or 543 allocate resources for the client. This protects our system from DoS 544 attacks similar to the TCP SYN flood attack [RFC4987]. When the 545 producer responds with the I2 message, that follows the trail created 546 by I1. Such an approach assures that I2 is delivered only to the 547 client initiating the session and eliminates the threat of using the 548 producer as a spam bot. Following ICN principles, the data is 549 effectively pulled by the producer from the consumer assuring that 550 the producer does not receive large volume data that it did not 551 request. 553 5. References 555 5.1. Normative References 557 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 558 Requirement Levels", BCP 14, RFC 2119, 559 DOI 10.17487/RFC2119, March 1997, 560 . 562 5.2. Informative References 564 [AIRTNT] Mustafa Al-Bassam et al, ., "Airtnt -- Fair Exchange 565 Payment for Outsourced Secure Enclave Computations", 2018, 566 . 569 [ALSHEIKH2015FLOODING] 570 Al-Sheikh, S., WA[currency units]hlisch, M., and T. 571 Schmidt, "Revisiting Countermeasures Against NDN Interest 572 Flooding", Proceedings of the 2nd International Conference 573 on Information-Centric Networking - ICN '15, 574 DOI 10.1145/2810156.2812604, 2015. 576 [CHOI2013THREAT] 577 and , "Threat of DoS by interest flooding attack in 578 content-centric networking", The International Conference 579 on Information Networking 2013 (ICOIN), 580 DOI 10.1109/icoin.2013.6496396, January 2013. 582 [GHALI2016] 583 Ghali, C., Tsudik, G., and C. Wood, "(The Futility of) 584 Data Privacy in Content-Centric Networking", Proceedings 585 of the 2016 ACM on Workshop on Privacy in the Electronic 586 Society - WPES'16, DOI 10.1145/2994620.2994639, 2016. 588 [ION2013TOWARD] 589 Ion, M., Zhang, J., and E. Schooler, "Toward content- 590 centric privacy in ICN", Proceedings of the 3rd ACM 591 SIGCOMM workshop on Information-centric networking - 592 ICN '13, DOI 10.1145/2491224.2491237, 2013. 594 [MAHADEVAN2014] 595 Mahadevan, P., Uzun, E., Sevilla, S., and J. Garcia-Luna- 596 Aceves, "CCN-KRS", Proceedings of the 1st international 597 conference on Information-centric networking - INC '14, 598 DOI 10.1145/2660129.2660154, 2014. 600 [MAPME] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L., 601 Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less 602 Producer Mobility in Content-Centric Networks", IEEE 603 Transactions on Network and Service Management Vol. 15, 604 pp. 596-610, DOI 10.1109/tnsm.2018.2796720, June 2018. 606 [MISRA2013] 607 Misra, S., Tourani, R., and N. Majd, "Secure content 608 delivery in information-centric networks", Proceedings of 609 the 3rd ACM SIGCOMM workshop on Information-centric 610 networking - ICN '13, DOI 10.1145/2491224.2491228, 2013. 612 [MOISEENKO2014] 613 Moiseenko, I., Stapp, M., and D. Oran, "Communication 614 patterns for web interaction in named data networking", 615 Proceedings of the 1st international conference on 616 Information-centric networking - INC '14, 617 DOI 10.1145/2660129.2660152, 2014. 619 [NDN] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., claffy, 620 k., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, 621 "Named data networking", ACM SIGCOMM Computer 622 Communication Review Vol. 44, pp. 66-73, 623 DOI 10.1145/2656877.2656887, July 2014. 625 [NFAAS] KrA^3l, M. and I. Psaras, "NFaaS", Proceedings of the 4th 626 ACM Conference on Information-Centric Networking - 627 ICN '17, DOI 10.1145/3125719.3125727, 2017. 629 [REST] Fielding, R., "Architectural Styles and the Design of 630 Network-based Software Architectures", 2000. 632 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 633 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 634 . 636 [RICE2018] 637 Michael Krol, ., Karim Habak, ., Dave Oran, ., Dirk 638 Kutscher, ., and . Ioannis Psaras, "RICE -- Remote Method 639 Invocation in ICN", September 2018. 641 [SPOC] Michael Krol, . and . Ioannis Psaras, "SPOC -- Secure 642 Payments for Outsourced Computations", 2018, 643 . 646 [THUNKS] Ingerman, P., "Thunks: a way of compiling procedure 647 statements with some comments on procedure declarations", 648 Communications of the ACM Vol. 4, pp. 55-58, 649 DOI 10.1145/366062.366084, January 1961. 651 [TSCHUDIN2014NAMED] 652 Tschudin, C. and M. Sifalakis, "Named functions and cached 653 computations", 2014 IEEE 11th Consumer Communications and 654 Networking Conference (CCNC), 655 DOI 10.1109/ccnc.2014.6940518, January 2014. 657 Authors' Addresses 659 Michal Krol 660 University College London 661 Gower Street 662 London 663 United Kingdom 665 Email: m.krol@ucl.ac.uk 667 Karim Habak 668 Georgia Institute of Technology 669 North Ave NW 670 Atlanta GA 30332 671 USA 673 Email: karim.habak@gatech.edu 675 Dave Oran 676 Network Systems Research & Design 677 TBD 678 Cambridge 679 USA 681 Email: daveoran@orandom.net 683 Dirk Kutscher 684 Huawei 685 Riesstrasse 25 686 Muenchen D-80992 687 Germany 689 Email: ietf@dkutscher.net 691 Ioannis Psaras 692 University College London 693 Gower Street 694 London 695 United Kingdom 697 Email: i.psaras@ucl.ac.uk