Martín Abadi 1,2 , Boon Thau Loo 3
1
Microsoft Research Silicon Valley,
2
UC Santa Cruz,
3
University of Pennsylvania

Designing secure network protocols is hard

Imperative languages makes process tedious and error-prone
Explore the use of declarative languages for secure networking:


Success of database research
 70’s – today: Database research has revolutionized data management

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

Intellectually interesting to compare two languages
Single 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

Background:


Declarative networking
Access control & related languages
Introduction to Datalog
Network Datalog and Binder languages
Secure Network Datalog

Language design

Examples
Future Directions



Declarative specifications of networks, compiled to distributed dataflows
Distributed query engine to execute distributed dataflows to implement protocols

are a natural fit for routing

Network Datalog (NDlog) language

messages
Dataflow Dataflow messages
Dataflow messages
Dataflow
Traditional Networks
Network State
Network protocol
Network messages
Dataflow
Dataflow recursive query
Declarative Networks
Distributed database
Recursive Query Execution
Distributed Dataflow

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

Central to security, pervasive in computer systems
Model:



 objects , resources requests for operations on objects sources for requests, called principals a reference monitor to decide on requests
Principal
Do operatio n
Reference
Monitor guard
Object

Logical tools and ideas have been used to explain and improve access control
Logic-based languages: Binder, SD3, D1LP,
SecPAL, etc.
Trust management
We focus on Binder:

Simple design,


Most similar to NDlog
Promises relatively straightforward unification with NDlog

Binder and NDlog are based on logic and Datalog
Extends 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

Background:


Declarative networking
Access control & related languages
Introduction to Datalog
NDlog and Binder languages
SeNDlog

Language design

Examples
Future Directions

Datalog rule syntax:
<result>  <condition1>, <condition2>, … , <conditionN>.
Head Body
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

R1: reachable(S,D)  link(S,D)
R2: reachable(S,D)  link(S,Z), reachable(Z,D) link(a,b) – “there is a link from node reachable(a,b) – “node a a to node can reach node b ” b ”
If there is a link from S to D , then S can reach D ”.
Input: link(source, destination)
Output: reachable(source, destination)

R1: reachable(S,D)  link(S,D)
R2: reachable(S,D)  link(S,Z), reachable(Z,D)
“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 ”.
Input: link(source, destination)
Output: reachable(source, destination)

Location
Specifier “@S”
R1: reachable(@S,D)  link(@S,D)
R2: reachable(@S,D)  link(@S,Z) , reachable(@Z,D)
Query: reachable(@M,N) All-Pairs Reachability
Input table: link
@S D
@a b
Output table: a reachable
@S D
@a b
@a c
@a d link
@S D
@b c
@b a link
@S D
@c b
@c d b reachable c reachable
@S D
Query: reachable(@a,N)
@S D
@c a
@b c @c b
@b d @c d link
@S D
@d c d reachable
@S D
@d a
@d b
@d c

A networking language with no explicit communication:
R2: reachable( @S ,D)  link( @S ,Z), reachable( @Z ,D)
Data placement induces communication

R1: path(@S,D ,P )  link(@S,D), P=(S,D).
R2: path(@S,D ,P ) 
Query: path(@S,D,P) link(@S,Z), path(@Z,D ,P
2
), P=S  P
2
.
Add S to front of P
2
Input: link(@source, destination)
Query output: path(@source, destination, pathVector )
Previous work:
- Communication patterns are the same as the actual path vector protocol
- Easy to compose new protocols (distance-vector, link-state, multicast, etc)

Network
In
Messages lookup lookup
Network
Out
Messages path ...
link
Local Tables
Nodes in execution plan (“operators”):



Network operators (send/recv, cc, retry, rate limitation)
Relational operators (selects, projects, joins, aggregates)
Flow operators (mux, demux, queues)

Logic-based language for access control
Similar to Datalog, with the special construct “says”
Rules in different context
Export: Alice says may-access(charlie,o,read).
Alice’s context
A1: may-access(P,O,read) :- good(P).
A2: may-access(P,O,read) :- bob says may-access(P,O,read).
Import: bob says may-access(charlie,o,read).
Export : bob says may-access(charlie,o,read)
Bob’s context may-access(charlie,o,read).

“says” abstracts the details of authentication
When “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.

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 evaluation
Export of derived tuples:


Binder: no integration of security policy with export of data
NDlog: location specifier in rule head

Unifies Binder and NDlog
Goals 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

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

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=X  P.
p(@a,d,[a,b,c,d]) a p(@b,d,[b,c,d]) b p(@c,d,[c,d]) c b says advertise(d,[a,b,c,d]) c says advertise(d,[b,c,d]) d

Security weakness in DHT – malicious nodes occupy a high part of key space
Solution: certified node identifiers from CA
5 additional rules to P2-Chord
Details 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

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

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