Thursday 9 February 2017

Fast, Flexible and Secure Onloading of Edge Functions using AirBox

Summary: Having seen a couple of client-driven cyber foraging methods in the earlier papers, this paper presents a backend driven approach for onloading benefits and functionalities near end usr to minimize user perceived latency and utilize the available bandwidth. Airbox is a dynamic just-in-time deployment platform for fast and secure onloading of Edge Functions.
Few Definitions:

  • Edge Function (EF): Any third party service deployed on edge infrastructure that interacts with end client requests on behalf of a backend service deployed in remote clouds.
  • • Edge function platform (EFP): Software platform that enables Edge functions to be deployed at the edge
The AirBox consists of AirBox Console which is a web front end and a Airbox Provisioner built as an extension of the Docker interface. The Provisioner accepts provisioning requests from the Console. The security and privacy of the end users and the EF state confidentiality is maintained using a two phase process using OpenSGX interface. This ensures that the content served to end clients is always encrypted and the anything stored on disk is encrypted using sealing key before writing to the disk.


Strength:

  • The paper is very well laid out and the author takes time to introduce the new terms and terminologies used in the paper one at a time. 
  • It goes into explaining theoretical details about the background concepts used throughout the paper like dockers, Intel SGX and OpenSGX.
  • The comparison presented before deciding on using Docker and Intel SGX for Airbox is reasonable.
  • Security and privacy of the onloading the services to the edge clouds is considered non trivial and a good secure system of handling the traffic has been suggested.

Weakness:

  • The Airbox platform has an extra hardware functionality of the SGX which requires developers to be familiarized with the OpenSGX interface.
  • The maximum buffer size available for host enclave communication is only 5 MB. There may be many many applications which might be larger than this. 
  • The evaluation has been done on a very simple application. Real time applications may pose several other problems like memory requirement etc which have not been covered.
  • In order to lay emphasis on the importance of maintaining a secure platform, the paper talks about the EPF  "situated into the wild" at so many places which seems repetitive and unnecessary.
  • It requires an extra book-keeping of the hashing the sessions key. The data is encrypted before it enters the user enclave and decrypted here and then re-encrypted to send it back to the host. This logic appeared complex and can have many points of failure in case of an edge cloud system.


Discussion:

  • How will the platform work on real applications which may have memory requirement much larger than 5MB?
  • How will this affect the cost and performance with the increased computation of slicing and reassembly of data in order to maintain state confidentiality.
  • The security and confidentiality mechanism has an overhead of sending encrypted data and key and decrypting it. Is this overhead required for all applications? Are all mobile applications so sensitive?


1 comment:

  1. Good blog. Nice point about whether security should be configurable for applications that are less sensitive (though perhaps this is handled by the split architecture?). You criticized the 5 MB limit -- do you have specific examples or evidence that this is too small? (i.e. one can always complain about limits, but this is a generic comment unless you can justify it more fully).

    ReplyDelete

Note: only a member of this blog may post a comment.