Towards a Declarative Language and System for Secure NetworkingMartín Abadi1,2, Boon Thau Loo3
1Microsoft Research Silicon Valley, 2UC Santa Cruz, 3University of Pennsylvania
Motivation
Designing secure network protocols is hard Imperative languages makes process tedious
and error-prone
Explore the use of declarative languages for secure networking: “Ask for what you want, not how to
implement it” Success of database research
70’s – today: Database research has revolutionized data management
Approach
Examine two classes of declarative languages: Database query language for declarative
networking Logic-based access control languages in
distributed systems
Contribution: Compare these two classes of languages Propose a unifying declarative language and
system
Why might this be useful?
Intellectually interesting to compare two languagesSingle declarative language and system
Ease of management Many useful examples: authenticated routing
protocols, secure overlays, DNSSEC, trust management in shared testbeds, P2P information sharing, etc.
Fine-grained control over interaction between security and network protocol
Potential for cross-layer analysis and optimizations
Distributed query engines to process security policies
Outline
Background: Declarative networking Access control & related languages
Introduction to DatalogNetwork Datalog and Binder languagesSecure Network Datalog Language design Examples
Future Directions
Declarative Networking
A declarative framework for networks: Declarative specifications of networks,
compiled to distributed dataflows Distributed query engine to execute
distributed dataflows to implement protocols
Observation: Recursive queries are a natural fit for
routing Network Datalog (NDlog) language
A Declarative Network
Distributed recursive query
Traditional Networks Declarative NetworksNetwork State Distributed
databaseNetwork protocol Recursive Query Execution
Network messages Distributed Dataflow
DataflowDataflow
messages
Dataflow
Dataflow
Dataflow
Dataflow messagesmessages
Declarative Networking
Declarative Routing [SIGCOMM ’05]: Extensible Routers (balance of flexibility,
efficiency and safety). Textbook routing protocols (3-8 lines)
Declarative Overlays [SOSP ’05]: Rapid prototyping of new overlay networks Chord DHT overlay routing (47 lines) Narada Mesh (16 lines)
Database Fundamentals [SIGMOD ‘06] Languge, execution and optimizations
System available: http://p2.cs.berkeley.edu
Access Control
Central to security, pervasive in computer systemsModel:
objects, resources requests for operations on objects sources for requests, called principals a reference monitor to decide on requests
PrincipalReferenc
e Monitor
ObjectDo
operation
guard
Logics in Access Control
Logical tools and ideas have been used to explain and improve access controlLogic-based languages: Binder, SD3, D1LP, SecPAL, etc. Trust managementWe focus on Binder: Simple design, Most similar to NDlog Promises relatively straightforward
unification with NDlog
Key Insight
Binder and NDlog are based on logic and DatalogExtends Datalog in surprisingly similar ways
Notion of context (location) to identify components (nodes) in a distributed system
Suggests possibility to unify both languages
Similar observation: Martín Abadi. “On Access Control, Data Integration, and
Their Languages.” Comparing Tsimmis and Binder
Outline
Background: Declarative networking Access control & related languages
Introduction to DatalogNDlog and Binder languagesSeNDlog Language design Examples
Future Directions
Review of Datalog
<result> <condition1>, <condition2>, … , <conditionN>.
Datalog rule syntax:
Types of conditions in body: Input tables: link(src,dst) predicate Arithmetic and list operations
Head is an output table Recursive rules: result of head in rule body
BodyHead
All-Pairs Reachability
R2: reachable(S,D) link(S,Z), reachable(Z,D)
R1: reachable(S,D) link(S,D)
Input: link(source, destination)Output: reachable(source, destination)
“For all nodes S,D, If there is a link from S to D, then S can reach D”.
link(a,b) – “there is a link from node a to node b”
reachable(a,b) – “node a can reach node b”
All-Pairs Reachability
R2: reachable(S,D) link(S,Z), reachable(Z,D)
R1: reachable(S,D) link(S,D)
Input: link(source, destination)Output: reachable(source, destination)
“For all nodes S,D and Z, If there is a link from S to Z, AND Z can reach D, then S can reach D”.
All-Pairs Reachability
R1: reachable(@S,D) link(@S,D)
R2: reachable(@S,D) link(@S,Z), reachable(@Z,D)
Network Datalog
Query: reachable(@M,N)
@S
D
@a
b
@a
c
@a
d
reachableOutput
table:
Input table:
Query: reachable(@a,N)
@S
D
@c b
@c d
link@
SD
@b
c
@b
a
link@
SD
@a
b
link @
SD
@d
c
link
b dca
@S
D
@b
a
@b
c
@b
d
reachable @
SD
@c a
@c b
@c d
reachable @
SD
@d
a
@d
b
@d
c
reachable
Location Specifier “@S”
Query: reachable(@a,N)
Implicit Communication
A networking language with no explicit communication: R2: reachable(@S,D) link(@S,Z), reachable(@Z,D)
Data placement induces communication
Path Vector in NDlog
Input: link(@source, destination)Query output: path(@source, destination, pathVector)
R1: path(@S,D,P) link(@S,D), P=(S,D).
R2: link(@S,Z), path(@S,D,P)
P=SP2. path(@Z,D,P2),
Query: path(@S,D,P)
Add S to front of P2
Previous work:
- Communication patterns are the same as the actual path vector protocol
- Easy to compose new protocols (distance-vector, link-state, multicast, etc)
lookup
lookup
Dem
ux
link
Local Tables
path ...
UD
P
Tx
Round
Robin
Queue
CC
T
x
Queue
UD
P
Rx
CC
R
x
Execution Plan
Nodes in execution plan (“operators”): Network operators (send/recv, cc, retry, rate limitation) Relational operators (selects, projects, joins, aggregates) Flow operators (mux, demux, queues)
Messages
Network In
Messages
Network Out
Single P2 Node
BinderLogic-based language for access controlSimilar to Datalog, with the special construct “says”Rules in different context
Alice’s contextA1: may-access(P,O,read) :- good(P).A2: may-access(P,O,read) :- bob says may-access(P,O,read).
Bob’s contextmay-access(charlie,o,read).
Export: bob says may-access(charlie,o,read)
Import: bob says may-access(charlie,o,read).
Export: Alice says may-access(charlie,o,read).
Notion of “Says”
“says” abstracts the details of authenticationWhen “p says s”, p may transmit s in a variety of ways:
on a local channel via a trusted operating system within
a computer, on a physically secure channel between two machines,
on a channel secured with shared-key cryptography, or,
in a certificate with a public-key digital signature.
Comparing Binder and NDlog
Trusted vs untrusted networks NDlog:
Location relates to data placement. E.g. link(@X,Y). Global rules:
r(@X,Y) :- l(@X,Z), r(@Z,Y). Binder:
Communication happens via “says” Import and export of facts into context
may-access(P,O,read) :- bob says may-access(P,O,read).
Bottom-up vs Top-down evaluationExport of derived tuples:
Binder: no integration of security policy with export of data
NDlog: location specifier in rule head
Secure Network Datalog (SeNDlog)
Unifies Binder and NDlogGoals of the language: Expressive as Binder and NDlog Supports authenticated communication and
enables differentiation of roles Supports both trusted and untrusted
environments Amenable to execution and optimizations in
distributed query engines Bottom-up evaluation strategy Incremental continuous execution model
SeNDlog
At N, E1: p(X,Y) :- p1(X), p2(Y). E2: p(X,Y,W) :- Y says p1(X), Z says p2(W). E3: p(Y,Z)@X :- p1(X), Y says p2(Z). E4: Z says p(Y)@X :- Z says p(Y), p1(X).
Important features:- Local principle (address, address/key, address/key/username)
- “Localized” rule bodies within context
- Import predicates. “says” construct – different levels of “says”
- Export predicates with location specifiers
- Honesty constraint
Example 1: Authenticated Path Vector Protocol
At Z, Z1: path(Z,X,P) :- neighbor(Z,X), P=(Z,X). Z2: path(Z,Y,P) :- X says advertise(Y,P). Z3: advertise(Y,P1)@X :- neighbor(Z,X), path(Z,Y,P), P1=XP.
p(@c,d,[c,d])
c says advertise(d,[b,c,d])
b says advertise(d,[a,b,c,d])
b dcap(@b,d,[b,c,d])p(@a,d,[a,b,c,d])
Example 2:Secure DHT Identifiers
Security weakness in DHT – malicious nodes occupy a high part of key spaceSolution: certified node identifiers from CA5 additional rules to P2-ChordDetails in the paper. Nodes have different roles: CA, landmark,
joining node, etc. Certificates can be forwarded from one node
to another: Use of honesty constraint.
Another example: DNSSEC
Ongoing Work
Implementation in P2 system: “says” construct Communication via signed certificates Rule bodies within context Implement variety of secure networks. E.g. DNSSEC,
secure routing, secure DHTs, trust management in extensible testbeds, P2P information sharing, your suggestions!
Cross-layer analysis and optimizations Exploit fine-grained control over security and
networks. Authenticity of routing table entries
Logic proof why it is there. Trusted but not trustworthy? Optimize protocols to favor trusted nodes
Future Work
Query language issues: Logic-based trust management: SD3, SecPAL, D1LP Distributed Datalog: ubQL, d3log Data integration: Tsimmis
Different approach: We started from Binder and NDlog Lots of domain knowledge but biased What if we design from scratch?
Sending / receiving & Distributed computations Notion of context Trust relationships Continuous incremental evaluations