Realizing a Virtual Private Network using Named Data Networking September 28, 2017 Craig Partridge Samuel Nelson Derrick Kong Th This document does not contain technology or te technical data controlled under either the U.S. In Inter ernation onal T Traffic i in A Arms R s Reg egulation ons or s or t the e U. U.S. Export Administration Regulations.
Virtual Private Networks • Goals: Consider the classic security problem of creating virtual private networks (VPNs), but within an NDN infrastructure – Two or more secure red networks wish to communicate over a less secure black network ? ? A user with VPN software is a special case of this more general case 2
NDN Features and VPN Challenges • NDN enables numerous features not inherent to IP- based networks – Disassociation of producers and consumers – Receiver-driven communication – Named-based forwarding – In-network caching – Inherent multicast • NDN applications have access to a rich feature set, and hence can look different than IP applications Though Experiment IP VPNs are highly successful. Can NDN VPNs be modeled after them, or do they have to look completely different? 3
IP-in-IP • IPSec tunnel mode can be used to create IP VPNs • IP packets transitioning from red to black are encrypted and encapsulated as payload within another IP packet containing a separate, black- routable IP address – All content, including the red-side IP address, is cryptographically secured Example IP-based VPN from www.cisco.com 4
An IP-in-IP Analogy for NDN • Goal: Don’t change any NDN offered services – Built completely around names, not IP addresses – Don’t change FIB or PIT behavior – Allow in-network caching on both secure and insecure routers Alice Bob (1) Alice issues red Interest for (3) FIB match for bbn.com, (4) Bob’s gateway translates black /bbn.com/videos/v1.mpg forwards to Bob’s gateway; Interest to red Interest and caches for future requests forwards to Bob (2) Gateway translates to black Interest (name stays for now) (8) Gateway decrypts black (7) PIT match on black data (5) Bob responds with data data packet, revealing packet, forwards to Alice’s /bbn.com/videos/v1.mpg encapsulated red data packet, gateway (6) Gateway encrypts red data with and sends to Alice shared red key , and encapsulates within a black data packet 5
Challenge #1: Interest Security • Black side can DoS red side with malicious Interests, filling the red PIT with random requests or red caches with unsolicited data Alice Bob Data sent to Alice is cached in Alice’s red gateway Bogus black Interest kicks out recently cached data Bob must go all the way back to the source for the data, which may or may not be available Solution Add authentication material to red-side Interest 6
Challenge #2: Name leakage • NDN names likely leak information about the NDN data, so this must be obfuscated on the black side • Clear first step is to encrypt or hash red names to produce black names • Tradeoff between privacy and scalability – Is hierarchy preserved? – Are fields within hierarchy the same size? • Traffic analysis is an open problem Scalability fjkdsal/ysdskxh/qlcuslz Hierarchy preserved Non-sensitive kuyvksh/ciskacq bbn.com/videos/v1.mp3 hierarchy preserved hdshvassjflwelakfd Flat naming structure Privacy Lots of existing work; still ripe for future work and advances in cryptography 7
Challenge #3: Shared Keys / Caching • IP-in-IP generally contains two endpoints, and hence pairwise keys works • NDN-in-NDN may contain multiple end-points, particularly when using black-side caching so a group key is necessary • Red networks often have have centralized administration (e.g., company or university), and can use existing systems, such as direct loading or PKI, to exchange rotating group keys • For added security, intra-domain group-based cryptography can be easily added, which is specifically endorsed by NSA’s Commercial Solutions for Classified – For example, Attribute-Based Encryption (ABE) encrypts based on user attributes, which fits nicely into the content-centric paradigm Shared red group keys, distributed via a centralized, administrative unit for the domain, bolstered by intra- domain group-based cryptography 8
Putting it all Together Red gateways perform (1) Alice issues Interest for authentication and I red = /bbn.com/videos/v1.mpg (2) Gateway signs and encryption, and live in encapsulates Interest, both the red and black producing I black Alice domains Red Gateway (4) Conversion to I red , satisfied by D red (3) FIB match on I black Bob (7) D black unencapsulated to D red Red Black Charlie Gateway Router (5) D black created by (6) D black cached, and encapsulating D red PIT entry match Red Gateway (8) Future requests for I black get A user with VPN software is a special satisfied by black router case, easily handled by the architecture 9
NIST requirements • NIST SP 800-77 VPN Requirements NIST SP 800-77 IP-in-IP NDN-in-NDN Confidentiality Encrypt red IP Encrypt red NDN packet Protection datagram in black in black NDN packet IP datagram Integrity Protection AH header Use NDN built-in integrity checks Replay Protection ESP sequence Authenticated Interests; numbers NDN Data needs no replay protection Security Association Rekey security Rotate domain specific LIfetimes associations keys 10
Other Security Issues • Replay protection – Related to the “Interest Security” challenge previously mentioned, replaying old Interests can cause useful content to be driven out of caches, severely hindering network performance – As before, it’s important to authenticate Interests arriving in red domains – Note that the replay of Data is not harmful , since the PIT will immediately drop unsolicited data • Bypass channels – NDN-in-NDN uses pre-established group keys, hence it does not need a black-to-red bypass channel, which is used in IP-in-IP to set up SAs. – While the red side needs to tell the black side what prefixes to advertise, this can be done following the similar standard NDN- in-NDN procedure for name obfuscation. 11
Traffic Analysis • What can a black-side observer infer about red-side actions or data from passively monitoring (but not decrypting) traffic? • IP-in-IP: Host-centric , so can infer which nodes are talking to each other – Can infer that Alice and Charlie are both speaking to Bob at the same time • NDN-in-NDN: Content-centric , so can infer accesses to the same (unknown) content item – Can infer that Alice and Charlie both accessed the same content, at the same or different times – However, can’t necessarily infer that a consumer accessed content from a specific producer, due to indirection between producers and consumers Specifics are an open question that is ripe for exploration 12
Conclusions and Future Directions • Considering the classic IP VPN security question, applied to NDN, we provide evidence that: – A relatively straightforward NDN-in-NDN analogy provides all of the standard NDN benefits while gaining much of the needed security for VPNs – Most VPN security holes within NDN-in-NDN, resulting from IP and NDN differences, can be solved – Some security concerns are difficult, and often require a tradeoff between privacy and scalability • Future directions: – Name obfuscation, balancing privacy and scalability – Detailed traffic analysis of NDN-in-NDN – Implement an NDN-in-NDN prototype 13
Recommend
More recommend
