Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Information-centric networking and relaton to legal and regulatory issues


Published on

Published in: Technology
  • Be the first to comment

Information-centric networking and relaton to legal and regulatory issues

  1. 1. Information-centric networking– and relation to some legal and regulatory issuesBengt AhlgrenSICS SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  2. 2. Content distribution• CDNs• Peer-to-peer – User driven – Service provider driven• Making use of storage for caching – In one way or another2011-09-02 2 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  3. 3. Evolution of networking Information-centric Today’s Internet network Focuses on Focuses onConversations between Hosts Dissemination of Information objects Host-centric abstraction Evolution Who to communicate with Information-centric abstraction Web CDN P2P What to communicate In today’s Internet, accessing information is the dominating use case! 2011-09-02 3 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  4. 4. Host-centric networking Trusted Connect to Server Server X and get object B Server X B Secure Connection2011-09-02 4 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  5. 5. Information-centric networking A Trustable D copy of object B B C E Get object B D B B B E E A A A A C D Untrusted Untrusted2011-09-02 5 SCALABLE & ADAPTIVE INTERNET SOLUTIONS connection host
  6. 6. ICN main components Name resolution/routing Security Security Name resolution/routing - - tied to the information tied to the information - - scalability main concern scalability main concern - - and the names and the names Naming scheme for objects Naming scheme for objects - - flat or hierarchical flat or hierarchical Forwarding/transport Forwarding/transport - - with in-network caching with in-network caching2011-09-02 6 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  7. 7. ICN naming• Naming today: – Hierarchical (aggregatable) IP addresses – Hierarchical DNS names – URL/URIs name “stuff”, but includes one of the above! • So names are largely tied to hosts, that is, name the container, not the actual content• New: names for information objects themselves – Names for the information independent of the container – Need security directly tied to the name and object – Hierarchical or flat namespace? • I.e., aggregatable or non-aggregatable • Consequences for resolution/routing2011-09-02 7 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  8. 8. NetInf naming scheme Type A = Hash(PKIO) L = {identifier attr.} Structure: – Type: Defines the format • e.g. Hash algorithm used (SHA1, MD5, …) – Authenticator (A): Binds the ID of the IO to a public key PK • Hash function used to compress length of PK – Label (L): Identifying individual object published by Authenticator • contains a number of identifier attributes associated with an IO – (A, L) combination needs to be globally unique Supporting the combination of: – name persistence, self-certification, and owner authentication – for objects that change content, location, or owner – without need to trust the delivering host Internet-draft: draft-farrell-ni2011-09-02 8 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  9. 9. CCN naming scheme• Hierarchical names rooted in publisher prefixes – Includes segmentation (packets!) and versioning• Makes (some) routing aggregation possible• Need to establish trust in signing key to verify integrity• (drawing from “Networking Named Data” paper at CoNEXT 2009 by Van Jacobson et al)2011-09-02 9 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  10. 10. Name resolution / routing –scalability• Main scalability issue: – Number of information objects • bookkeeping needed to keep track of them – Cf. Internet: IP network prefixes in backbone & BGP convergence• How many information objects?• Some numbers to compare with: – One trillion (1,000,000,000,000) unique web URLs (Google 2008) – 26 billion web pages ( – 119 million second-level domain names in the DNS (Dec 2010) • Applicable if we can aggregate information objects on the publisher level – 60.000 AS numbers, of which 34.000 announced in BGP2011-09-02 10 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  11. 11. Name resolution / routing• Two main options: – Name resolution translating into another, routable, namespace • e.g., IP – Routing directly on information object names • sometimes called “name-based routing” – (Possible with hybrid schemes)• Scalability depends on namespace – Flat or hierarchical2011-09-02 11 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  12. 12. ICN application service(“socket API”) sender receiver publish() retrieve(object ID) object• “Publish/subscribe-like”• Most approaches defines a synchronous “retrieve” instead of asynchronous “subscribe”2011-09-02 12 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  13. 13. ICN vs current networks• Caches integrated in the network infrastructure – Combines todays CDNs and user caching (p2p) in the basic network service• Network service in terms of named data objects – No direct host addressing2011-09-02 13 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  14. 14. Legal implications of caching(a layman view)2011-09-02 14 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  15. 15. Copyright• Copyright and distribution agreements currently do not seem to allow for general in-network caching – Distribution agreements need to change? Is this likely?• What exactly differs packet buffering from caching? – Both stores content in a memory• Can some mechanism in the network support the copyright agreements? – I.e., mechanisms that have legal meaning – (I do not believe in enforcing mechanisms – it has to be combined with contracts and/or legislation)• Example mechanisms: – Access counting, distribution constraints, time-to-live• Or, is the only solution to encrypt copyrighted material and replace the problem with key distribution – as is done for satellite TV2011-09-02 15 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  16. 16. Responsibility for illegal content• To what extent is the cache owner responsible for the cached content? – e.g., if it is illegal for some reason?• Dependent on the time in the cache?• (Anonymity and content control later...)2011-09-02 16 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  17. 17. Business issues• Some current ISP business models work against in-network caching – Need to pay for delivering data to someone else – Delivering data from your own cache to others incurs a cost!• Shouldnt there instead be value in providing content that users want?2011-09-02 17 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  18. 18. Discussion!2011-09-02 18 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  19. 19. Problems in host-centricnetworks No common persistent naming scheme for information – URLs and IPs overloaded with locator and identifier functionality • Moving information = changing it‘s name („404 file not found“ errors) => Use flat namespace for persistent and secure identification Information dissemination is inefficient – Can‘t benefit from existing copies (e.g. local copy on client) • Also true for Content Delivery Networks (e.g. Akamai) – No “anycast”: e.g., get “nearest” copy – Problems like Flash-Crowd effect, Denial of Service, … => Add storage for caching as part of the infrastructure Security is host-centric – Mainly based on securing channels (encryption) and trusting servers (authentication) – Can’t trust a copy received from an untrusted server Problems can be solved in a consistent manner via an information-centric architecture2011-09-02 19 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  20. 20. Flat namespace• Name resolution: – Distributed hashtables (DHTs) only known technology that scales – Make use of publisher prefixes to increase scalability• Routing: – Hard! – DHTs can be used here too (?) – “Routing hints” proposed as optimisation • ~ source route or topological address • Can be tied to publisher prefixes • Can be retrieved from a name resolution service2011-09-02 20 SCALABLE & ADAPTIVE INTERNET SOLUTIONS
  21. 21. Hierarchical namespace• Name resolution: – DNS type design scales well (?)• Routing: – Problem similar to BGP, but harder2011-09-02 21 SCALABLE & ADAPTIVE INTERNET SOLUTIONS