ICNRG M. Krol Internet-Draft University College London Intended status: Experimental K. Habak Expires: April 4, 2019 Georgia Institute of Technology D. Oran Network Systems Research & Design D. Kutscher Huawei I. Psaras University College London October 01, 2018 Remote Method Invocation in ICN draft-kutscher-icnrg-rice-00 Abstract Information Centric Networking has been proposed as a new network layer for the Internet, capable of encompassing the full range of networking facilities provided by the current IP architecture. In addition to the obvious content-fetching use cases which have been the subject of a large body of work, ICN has also shown promise as a substrate to effectively support remote computation, both pure functional programming (as exemplified by Named Function Networking) and more general remote invocation models such as RPC and web transactions. Providing a unified remote computation capability in ICN presents some unique challenges, among which are timer management, client authorization, and binding to state held by servers, while maintaining the advantages of ICN protocol designs like CCN and NDN. This document specifies a unified approach to remote method invocation in ICN that exploits the attractive ICN properties of name-based routing, receiver-driven flow and congestion control, flow balance, and object-oriented security while presenting a natural programming model to the application developer. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Krol, et al. Expires April 4, 2019 [Page 1] Internet-Draft Remote Method Invocation in ICN October 2018 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 4, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Design Overview . . . . . . . . . . . . . . . 5 2.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Thunks . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Shared Secret Derivation . . . . . . . . . . . . . . . . 9 3.5. Client Authentication . . . . . . . . . . . . . . . . . . 10 3.6. Input Parameters . . . . . . . . . . . . . . . . . . . . 10 3.7. Dynamic Content Retrieval Using Thunks . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Normative References . . . . . . . . . . . . . . . . . . 12 5.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction Much of today's network traffic consists of data sent for processing to the cloud and web-servers exchanging high volumes of dynamically generated content. While today's ICN networks can deal efficiently with static data delivery, they have difficulty handling service/ function invocation [MOISEENKO2014]. In view of these limitations, multiple works have recently tried to extend ICN's capabilities to deal with dynamic content. Krol, et al. Expires April 4, 2019 [Page 2] Internet-Draft Remote Method Invocation in ICN October 2018 Notable among these efforts, Named Function Networking (NFN) [TSCHUDIN2014NAMED] and Named Function as a Service (NFaaS) [NFAAS] extend ICN's named data access model to a remote function invocation capability, enabling consumers to request the network to execute functions remotely. In NFN \cite{tschudin2014named}, for instance, function invocation corresponds to independent computational processes, evaluated as expressions in a functional programming model. ICN provides several attractive benefits compared to remote invocation over current network protocol stacks (e.g. CORBA, RESTful HTTP [REST]. Name-based routing allows the network to optimise the placement of computations with automatic load distribution and failure resiliency. The built-in object-based security of ICN frees application designers from the need to craft custom solutions in the common cases where channel security alone is insufficient. Short- term caching brings latency benefits under transient error conditions and mobility events, while long-term caching can substantially reduce server load for referentially transparent computations. There have been several approaches for integrating computation with ICN. However, when using them to realize real-world applications like web-style interactions, several additional aspects beyond the fundamental Named Function invocation concept need to be addressed: o Consumer authentication and authorization: a producer should not blindly answer any consumer request. In basic ICN, this protection is provided by cryptographic data object integrity and encryption, i.e., only authorized consumers are able to decrypt a received data object. In a Named Function Networking environment, the computation may be an expensive operation, so just relying on encryption and performing computations without validating consumer authorization may critically impede scalability of the whole approach. o Parameter passing: Remote function execution typically requires a set of input parameters/arguments. In dynamic web content creation for example, the volume of such parameters (in bytes) can easily surpass the volume of the actual returned data objects {{MOISEENKO2014}. Adding larger sets of parameters to Interest messages can introduce additional unsolicited traffic in ICN networks that could interfere with congestion control. o Accommodating non-trivial computations: Unlike responding to an Interest message with a (possibly pre-generated) static Data message, constructing responses by performing general computations (that could in turn invoke further remote computations) may take relatively long. In CCN/NDN, forwarders keep Interest state for Krol, et al. Expires April 4, 2019 [Page 3] Internet-Draft Remote Method Invocation in ICN October 2018 matching received Data messages. The design and dimensioning of Pending Interest Tables (PITs) is typically based on the assumption that corresponding Data messages are received in a time frame that is based on typical network RTTs (e.g., order of 10s or 100s of milliseconds for wide-area networks). PIT state is, therefore, short-lived by design. As a result, Application Timescales can differ significantly from Network Timescales, which must be considered by a general purpose function invocation scheme. RICE aims to overcome these three limitations by enhancing the ICN model with function-oriented capabilities while preserving the core architectural and protocol design elements of ICN networks. RICE is a general-purpose network-layer framework and can be applied to any named-function networking context. Its main features are: o a secure, 4-way handshake for ICN networks in order to achieve shared secret derivation, consumer authentication and parameter passing. o the concept of thunks [THUNKS] from the programming language literature to decouple method invocation from the return of results to enable long-running computations. The thunk is used to name the results for retrieval purposes. The ultimate goal of the RICE framework is to enable in-network function execution with client authentication and non-trivial parameter passing, to support cases where computation takes longer than PIT expiry time. RICE achieves this goal by decoupling application processing time from PIT timers and network RTT. We argue that this is a necessary feature of any name-based remote function invocation scheme, where computation is accommodated in distributed compute spots in local or wide area networks at the core or edge of the network. The mechanisms we propose follow ICN principles and require minimal and short-lived additional network state. More rationale, a comparison with related work, and an evaluation of the RICE approach is provided in [RICE2018]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, BCP 14 [RFC2119] and indicate requirement levels for compliant RICE implementations. Krol, et al. Expires April 4, 2019 [Page 4] Internet-Draft Remote Method Invocation in ICN October 2018 2. Terminology and Design Overview RICE is as a general Remote Method Invocation (RMI) service - providing a robust and secure basis for a wide range of applications and in-network computation scenarios, including scenarios where method invocation requires a significant amount of input data and involves computations that take significantly longer than a network RTT to complete. RICE is independent of any particular function execution environment. RICE provides all the required ICN protocol mechanisms and conventions for clients and servers and can serve as an underlying platform to support frameworks such as NFN and NFaaS (as well as any other in-network compute framework that utilises core ICN principles). In the description of RICE we use the following terminology: Consumer: ICN protocol entity that is sending an Interest message Producer: ICN protocol entity that is sending a Data message, replying to a received Interest message Client: RICE protocol user that wants to request a remote method invocation Server: RICE protocol user that is processing and answering the remote method invocation request (this may be a logical entity that is represented by more than one ICN protocol entity) 2.1. Design Goals The RICE protocol is based on the following design goals: Decouple application time scale from network time scale: RICE does not map remote method invocation directly to one Interest/Data exchange for the reasons discussed above. We want clients to request remote method invocation from a server without changing the network behavior with respect to Pending Interest management. Support client authorization: A RICE server should be able to authorize clients before committing resources such as state, processing power etc. A server that blindly accepts any RMI request opens itself to computational and/or memory overload attacks. This also implies that the authorization mechanisms must be designed so that performing authorization itself does not overload servers and open a vulnerability to computational attacks. Krol, et al. Expires April 4, 2019 [Page 5] Internet-Draft Remote Method Invocation in ICN October 2018 Support non-trivial method invocation with arbitrarily complex parameter sets Be robust and ICN-friendly to a mix of RICE and non-RICE traffic: we want RICE to coexist seamlessly in existing ICN networks, e.g., it should adhere to the same flow balance principles. The main consequence is that we do not transmit RMI parameters in Interest messages. Support non-trivial, long-running computations with large amounts of result data Support session-like interactions, where a client and a server use a sequence of exchanges: RICE result data should be chunkable, and it should also be possible to retrieve result data that is generated over time, for example in multiple invocations in the same "session". Allow ICN caching for referentially transparent method invocations: ICN generally supports location-independent data access and opportunistic caching. In RICE, we want to support referentially transparent functions efficiently, i.e., function expressions that can be replaced with the result of the actual function execution. In other words, RICE is able to cache the result from such function invocations and enables the network to answer subsequent Interest messages from caches. Since not all functions are referentially transparent (some functions may depend on other data from the environment that is not specified in arguments), our framework distinguishes between functions that are referentially transparent and those that are not. Adhere to ICN principles: RICE should not give up important ICN principles, such as flow balance, implicit support for consumer mobility, consumer anonymity (no source addresses). This last property is worth mentioning, because some ICN extensions/ applications rely on the fact that one end of an interaction would provide a globally routable "source" address to the other end to achieve "callback" behavior or generally enable bidirectional communication. Since such schemes would expose client identity information to the network (and to peers), we deem this approach an unacceptable deviation from ICN principles. Client identities should be exposed only to the application layer. Other forms of identifiers that help the network for maintaining reverse forwarding state to clients should be designed so that they do not expose clients' identities. Be compatible with ICN extension mechanisms: Some recent proposed extensions make benign changes to ICN forwarding behavior (without Krol, et al. Expires April 4, 2019 [Page 6] Internet-Draft Remote Method Invocation in ICN October 2018 compromising general interoperability). One example would be fast forwarding information updates using technique such as Map-ME [MAPME]. RICE should be designed to work with such extensions. In this particular case, this means that RICE should support client and server mobility in a Map-ME-enhanced network. Make minimal changes to ICN protocols and forwarder behavior: We want to allow for some changes to ICN forwarder behavior, but these should be limited and designed so that they do not complicate forwarder implementations or impair their performance. The general guideline for achieving these goals is to prioritize robustness, security and scalability over absolute efficiency (with respect to number of handshakes and message exchanges), while still arriving at a design with reasonable efficiency. 3. Protocol Remote Method Invocation (RMI) operations in RICE are split in two ICN interaction phases: 1) RMI Initiation (eventually triggering the remote method execution), and 2) the Result Retrieval. The RMI Initiation phase is designed to complete in Network Timescale (on the order of a few RTTs), whereas the remote method execution is decoupled from that and can take as long as required. The Result Retrieval phase can consist of several ICN Interest-Data exchanges (for chunked results or for computations that generate results iteratively). 3.1. Thunks RMI Initiation and Result Retrieval are somehow decoupled from each other. The RMI Initiation generates a 'Thunk' name, i.e., a handler that the client can use later to retrieve the RMI result (or status) from the server. 'Thunk' thus represents the computation process at the server. The RMI Initiation and the actual RMI invocation (and results) delivery do not necessarily have to take place on the same ICN node. For example, a RICE server could accept an RMI request, perform the Initiation and then delegate the actual computation to a backend server. For that, it would generate a Thunk name that the client can use to reach that backend server (or to obtain the corresponding result, generally speaking). Krol, et al. Expires April 4, 2019 [Page 7] Internet-Draft Remote Method Invocation in ICN October 2018 3.2. Naming RICE relies on a generic naming scheme for remote method invocation. We distinguish between 'Method Names' and 'Thunk Names'. A function name identifies a method requested by a client that can be executed by any server able to perform the computations. In contrast, a thunk name identifies a specific method instance already being run on a specific node. When a client initially requests the invocation of a referentially transparent method, the name in the Interest MUST unambiguously specify both the invoked method and the set of input parameters. The method part can be system-specific (\e.g., lambda-expressions in [TSCHUDIN2014NAMED] or expressed as a hierarchical name structure as in [NFAAS]}), but MUST unambiguously identify the method to invoke. The input parameters can be represented directly when very small in size (e.g., username, number of iterations to perform), or as a hash when larger. (The choice of the actual hashing method can be left to the application.) For referentially opaque methods, the result can be different even when using the same input parameters. Every invocation (either from the same client or from other clients) MUST lead to a new computation instance. Therefore, Interests for triggering referentially opaque method invocations MUST use a unique name for each invocation, while Interest retransmissions from the same client MUST use the same name. This prevents the network from aggregating the corresponding Interests and limits cached responses to only answer retransmitted interests from a individual consumer. To achieve this, the client MUST include a name component that distinguishes its request from those generated by other clients. This component MUST be chosen by the client such that other nodes cannot predict the value. (Using predictable information (e.g., a MAC address) opens an additional attack surface and can leak client's sensitive information.) The thunk name MUST unambiguously identify the server's forwarder, the instantiated method and the method's internal state (i.e., input parameters, chunk number). In that way, when the client uses the thunk name in consecutive requests, the Interest can be forwarded to the correct server and dispatched to the application possessing the associated result data. With thunk names, we do not need to distinguish between names for referentially transparent and opaque methods. They unambiguously identify a handler to a method execution instance, and it is up to the server to return the same or different handlers to multiple clients. Krol, et al. Expires April 4, 2019 [Page 8] Internet-Draft Remote Method Invocation in ICN October 2018 3.3. Handshake RICE uses a 4-way handshake which serves the purposes of 1) deriving a shared secret, 2) authenticating and authorizing clients, and 3) providing input parameters to methods. A client starts a 4-way handshake by sending an Interest message I1 towards a server. Similarly to the TCP SYN flag, the message contains an additional TLV Handshake field (this description assumes NDN [NDN] implementation of ICN). The field contains an identifier that is chosen by the client and distinguishes among different handshakes. Upon receipt of the Interest, each forwarder creates a corresponding PIT entry as with regular Interests. Forwarders also inject a new temporary entry in the FIB formed from the identifier and pointing to the face on which the Interest was received. This FIB entry has a short expiry time after which it is deleted. TODO: specify the timeout When the server receives the Interest, it MUST respond with an I2 Interest message and forms the name from the received identifier. The Interest thus follows the previously established FIB entries towards the client. The forwarder also increases the expiry timer of I1's PIT entry. At this point, the client MUST be ready to respond and send a D2 Data message. (Authorization information and parameters may be larger than what can be carried in a single D2 message. Therefore, multiple I2/D2 exchanges using the built-in chunking capabilities of the underlying ICN protocols can be employed.) When the server receives D2 it allocates resources for the computation for the client and sends back a confirmation in D1 Data message. Interest I1 of the first handshake contains a method name that is delivered to a server advertising the corresponding prefix. At the end of the first handshake, in D1, the server returns its thunk name. This name can be then used by the client in I1 message of consecutive handshakes to assure future invocations reach the same method instance. 3.4. Shared Secret Derivation *Dirk: Not sure we need the following:* Common secret derivation plays an important role in many security protocols. Once a common secret is established, both parties can Krol, et al. Expires April 4, 2019 [Page 9] Internet-Draft Remote Method Invocation in ICN October 2018 encrypt the communication using symmetric cryptography. Common secret derivation (e.g., via Diffie-Hellman Key Exchange) requires sending data in both directions between the involved parties and is clumsy to implement in vanilla ICN networks where not all nodes have globally routable prefixes. Using one or multiple handshakes as described above allows use of any symmetric key scheme to secure the communication over arbitrary paths. 3.5. Client Authentication Reliable and secure authentication requires multiple messages to be exchanged between the server and the client. Utilizing the handshake for client authentication, specially the exchanged I2/D2 messages, we achieve this goal and we decouple it from function invocation and input parameter passing. In addition, by using the I2/D2 messages for client authentication and avoiding adding authentication information in the original interest (I2/D2), the RICE handshake mechanism becomes protected against any record-and-replay attack by a malicious party which can intercept the traffic. Once authenticated, the client creates a security token that can be included as a last component of the thunk name. In further communication such as commands (i.e., pause, stop) or referentially opaque methods, the token can be changed for each consecutive Interest message (i.e., based on the last received Data message). It should be noted that RICE can rely on idiomatic ICN mechanisms for server authentication, i.e., validate the signatures on Data or signed Interest messages. The client could also encrypt input parameters using the public key of the server. A detailed specification will be provided by a future version of this document. Following ICN principles, clients SHOULD NOT authenticate the server performing computations, but rather authenticate the returned result. If submitted input contains confidential data, it can be encrypted and shared using existing ICN access control techniques [ION2013TOWARD]. 3.6. Input Parameters RICE passes input parameters to remote methods "by reference". Since the server cannot access memory in the client, we use the I2/D2 Interest/Data Exchange as a "callback" from the server to the client to fetch the input parameters. This preserves the ICN principle that data is never pushed to the server if not requested. The server piggybacks on the PIT entry established by I1 to reach the client and pull the required data. If the input contains sensitive information, Krol, et al. Expires April 4, 2019 [Page 10] Internet-Draft Remote Method Invocation in ICN October 2018 the client can encrypt it using a common secret derived in previous handshakes as described above. 3.7. Dynamic Content Retrieval Using Thunks In dynamic content generation or method invocation, the server may require a significant amount of time to create the requested data. In this section, we describe our use of thunks to allow clients to retrieve computation results. The client starts by sending an Interest with a function name. Thunks allow multiple clients calling the same referentially transparent method with identical parameter sets to share one PIT entry and efficiently retrieve the data, while keeping entries separate for referentially opaque computations. Upon receipt of the Interest, the server starts the requested computation and immediately responds with a thunk Data message. For the network, the thunk does not differ from a regular Data message that consumes the pending PIT entry. The payload of the message contains a 'thunk name' and an estimated completion time. The client waits for the time indicated in the server's response and issues a new Interest with the received thunk name. Once the computation has finished, the function responds with a Data message containing the result. If the server mis-estimated the completion time and the data is not ready, it returns the same thunk target with an updated completion time estimate. 4. Security Considerations By building on a well-studied ICN protocol framework, RICE shares the fundamental security advantages and difficulties of those protocols [MISRA2013], [CHOI2013THREAT], [ALSHEIKH2015FLOODING]. RICE employs native CCN/NDN machinery for cryptographic data integrity, origin authentication, confidentiality, and key management [MAHADEVAN2014]. Similarly, RICE shares the privacy problems and limitations of extant ICN protocols [GHALI2016]. In general, the additional threat that needs to be addressed is a computational or state-creation attack against a server by un-authorized clients. These threats request long-running computations, or flood the server with remote invocation requests that start useless computations [AIRTNT], [SPOC]. For the security consideration, we concentrate on the vulnerabilities associated with RICE, and provide a brief security analysis of the RICE machinery. The proposed 4-way handshake provides secure input parameter passing. It does so by fetching the parameters via the Interest-Data exchange "callback" from the server to the client. Krol, et al. Expires April 4, 2019 [Page 11] Internet-Draft Remote Method Invocation in ICN October 2018 Such callbacks could open a reflection attack via interest flooding [CHOI2013THREAT] if a globally routable name were used for the callback operation. However, the reverse-path mechanism and non- routable name RICE uses confines knowledge of the client's input parameter set to the server and on-path forwarders. The remaining vulnerability is the need to maintain forwarding state for the entire duration of the four-way handshake, rather than just a two-way exchange. When a client sends I1 towards a producer, it creates additional state in FIB tables on all the intermediary forwarders. However, similarly to PIT entries, the created state is purged when its timer expires. If the timer is set to the same value as the PIT entries divided by 2, it does not expand the attack surface and existing Interest flood prevention techniques can be applied [ALSHEIKH2015FLOODING]. Upon reception of I1, the producer does not create any local state or allocate resources for the client. This protects our system from DoS attacks similar to the TCP SYN flood attack [RFC4987]. When the producer responds with the I2 message, that follows the trail created by I1. Such an approach assures that I2 is delivered only to the client initiating the session and eliminates the threat of using the producer as a spam bot. Following ICN principles, the data is effectively pulled by the producer from the consumer assuring that the producer does not receive large volume data that it did not request. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 5.2. Informative References [AIRTNT] Mustafa Al-Bassam et al, ., "Airtnt -- Fair Exchange Payment for Outsourced Secure Enclave Computations", 2018, . Krol, et al. Expires April 4, 2019 [Page 12] Internet-Draft Remote Method Invocation in ICN October 2018 [ALSHEIKH2015FLOODING] Al-Sheikh, S., WA[currency units]hlisch, M., and T. Schmidt, "Revisiting Countermeasures Against NDN Interest Flooding", Proceedings of the 2nd International Conference on Information-Centric Networking - ICN '15, DOI 10.1145/2810156.2812604, 2015. [CHOI2013THREAT] and , "Threat of DoS by interest flooding attack in content-centric networking", The International Conference on Information Networking 2013 (ICOIN), DOI 10.1109/icoin.2013.6496396, January 2013. [GHALI2016] Ghali, C., Tsudik, G., and C. Wood, "(The Futility of) Data Privacy in Content-Centric Networking", Proceedings of the 2016 ACM on Workshop on Privacy in the Electronic Society - WPES'16, DOI 10.1145/2994620.2994639, 2016. [ION2013TOWARD] Ion, M., Zhang, J., and E. Schooler, "Toward content- centric privacy in ICN", Proceedings of the 3rd ACM SIGCOMM workshop on Information-centric networking - ICN '13, DOI 10.1145/2491224.2491237, 2013. [MAHADEVAN2014] Mahadevan, P., Uzun, E., Sevilla, S., and J. Garcia-Luna- Aceves, "CCN-KRS", Proceedings of the 1st international conference on Information-centric networking - INC '14, DOI 10.1145/2660129.2660154, 2014. [MAPME] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L., Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less Producer Mobility in Content-Centric Networks", IEEE Transactions on Network and Service Management Vol. 15, pp. 596-610, DOI 10.1109/tnsm.2018.2796720, June 2018. [MISRA2013] Misra, S., Tourani, R., and N. Majd, "Secure content delivery in information-centric networks", Proceedings of the 3rd ACM SIGCOMM workshop on Information-centric networking - ICN '13, DOI 10.1145/2491224.2491228, 2013. Krol, et al. Expires April 4, 2019 [Page 13] Internet-Draft Remote Method Invocation in ICN October 2018 [MOISEENKO2014] Moiseenko, I., Stapp, M., and D. Oran, "Communication patterns for web interaction in named data networking", Proceedings of the 1st international conference on Information-centric networking - INC '14, DOI 10.1145/2660129.2660152, 2014. [NDN] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., claffy, k., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, "Named data networking", ACM SIGCOMM Computer Communication Review Vol. 44, pp. 66-73, DOI 10.1145/2656877.2656887, July 2014. [NFAAS] KrA^3l, M. and I. Psaras, "NFaaS", Proceedings of the 4th ACM Conference on Information-Centric Networking - ICN '17, DOI 10.1145/3125719.3125727, 2017. [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", 2000. [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, . [RICE2018] Michael Krol, ., Karim Habak, ., Dave Oran, ., Dirk Kutscher, ., and . Ioannis Psaras, "RICE -- Remote Method Invocation in ICN", September 2018. [SPOC] Michael Krol, . and . Ioannis Psaras, "SPOC -- Secure Payments for Outsourced Computations", 2018, . [THUNKS] Ingerman, P., "Thunks: a way of compiling procedure statements with some comments on procedure declarations", Communications of the ACM Vol. 4, pp. 55-58, DOI 10.1145/366062.366084, January 1961. [TSCHUDIN2014NAMED] Tschudin, C. and M. Sifalakis, "Named functions and cached computations", 2014 IEEE 11th Consumer Communications and Networking Conference (CCNC), DOI 10.1109/ccnc.2014.6940518, January 2014. Krol, et al. Expires April 4, 2019 [Page 14] Internet-Draft Remote Method Invocation in ICN October 2018 Authors' Addresses Michal Krol University College London Gower Street London United Kingdom Email: m.krol@ucl.ac.uk Karim Habak Georgia Institute of Technology North Ave NW Atlanta GA 30332 USA Email: karim.habak@gatech.edu Dave Oran Network Systems Research & Design TBD Cambridge USA Email: daveoran@orandom.net Dirk Kutscher Huawei Riesstrasse 25 Muenchen D-80992 Germany Email: ietf@dkutscher.net Ioannis Psaras University College London Gower Street London United Kingdom Email: i.psaras@ucl.ac.uk Krol, et al. Expires April 4, 2019 [Page 15]