Realizing a Virtual Private Network using Named Data Networking - - PowerPoint PPT Presentation

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

• nal T

Traffic i in A Arms R s Reg egulation

• ns or

s or t the e U. U.S. Export Administration Regulations.

2

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

3

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?

4

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

5

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 /bbn.com/videos/v1.mpg (2) Gateway translates to black Interest (name stays for now) (3) FIB match for bbn.com, forwards to Bob’s gateway; caches for future requests (5) Bob responds with data /bbn.com/videos/v1.mpg (6) Gateway encrypts red data with shared red key, and encapsulates within a black data packet (7) PIT match on black data packet, forwards to Alice’s gateway (8) Gateway decrypts black data packet, revealing encapsulated red data packet, and sends to Alice (4) Bob’s gateway translates black Interest to red Interest and forwards to Bob

6

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

Data sent to Alice is cached in Alice’s red gateway Bob must go all the way back to the source for the data, which may or may not be available Bogus black Interest kicks out recently cached data

Alice Bob Solution Add authentication material to red-side Interest

7

Challenge #2: Name leakage

• NDN names likely leak information about the NDN data, so this must be
• bfuscated 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

bbn.com/videos/v1.mp3 fjkdsal/ysdskxh/qlcuslz Hierarchy preserved Flat naming structure hdshvassjflwelakfd kuyvksh/ciskacq Non-sensitive hierarchy preserved Scalability Privacy Lots of existing work; still ripe for future work and advances in cryptography

8

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

9

Putting it all Together

Red Gateway Red Gateway Red Gateway Bob Alice Charlie Black Router

(1) Alice issues Interest for Ired = /bbn.com/videos/v1.mpg (2) Gateway signs and encapsulates Interest, producing Iblack (3) FIB match on Iblack (4) Conversion to Ired, satisfied by Dred (5) Dblack created by encapsulating Dred (6) Dblack cached, and PIT entry match (7) Dblack unencapsulated to Dred (8) Future requests for Iblack get satisfied by black router

Red gateways perform authentication and encryption, and live in both the red and black domains A user with VPN software is a special case, easily handled by the architecture

10

NIST requirements

• NIST SP 800-77 VPN Requirements

NIST SP 800-77 IP-in-IP NDN-in-NDN Confidentiality Protection Encrypt red IP datagram in black IP datagram Encrypt red NDN packet in black NDN packet Integrity Protection AH header Use NDN built-in integrity checks Replay Protection ESP sequence numbers Authenticated Interests; NDN Data needs no replay protection Security Association LIfetimes Rekey security associations Rotate domain specific keys

11

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.

12

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

13

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