1. Towards a Declarative Language and System for Secure Networking Martín Abadi 1,2, Boon Thau Loo 3 1 Microsoft Research Silicon Valley, 2 UC Santa Cruz, 3 University of Pennsylvania

2. 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

3. 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

4. Why might this be useful? 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

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

6. 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

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

8. 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

9. Access Control 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 Reference Monitor Object Do operatio n guard

10. Logics in Access Control 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

11. Key Insight 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

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

13. Review of Datalog ,, …,. 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 Body Head

14. 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”

15. 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”.

16. 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) @SD @ab c d reachable Output table: Input table: Query: reachable(@a,N) @SD @cb d link @SD @bc a link @SD @ab link @SD @dc link bdc a @SD @ba c d reachable @SD @ca b d reachable @SD @da b c reachable Location Specifier “@S” Query: reachable(@a,N)

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

18. 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=S  P 2. path(@Z,D,P 2 ),  Query: path(@S,D,P) Add S to front of P 2 Previous work: - Communication patterns are the same as the actual path vector protocol - Easy to compose new protocols (distance-vector, link-state, multicast, etc)

19. 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

20. Binder Logic-based language for access control Similar to Datalog, with the special construct “says” Rules in different context Alice’s context A1: may-access(P,O,read) :- good(P). A2: may-access(P,O,read) :- bob says may-access(P,O,read). Bob’s context may-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).

21. Notion of “Says” “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.

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

23. Secure Network Datalog (SeNDlog) 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

24. 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

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

26. Example 2: Secure DHT Identifiers 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

27. 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

28. 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

29. Thank You