Role Based Access Control For Software Defined Networking

Role Based Access Control For Software Defined Networking Formal Models and Implementation Dissertation Defense Abdullah Al-Alaj Institute for Cyber Security Department of Computer Science The University of Texas at San Antonio Committee: Prof. Ravi Sandhu, Ph. D. (Advisor) Dr. Ram Krishnan, Ph. D. (Co-advisor) Dr. Palden Lama, Ph. D. Prof. Gregory White, Ph. D. Dr. Weining Zhang, Ph. D. July 20, 2020.

Outline • Introduction • SDN-RBAC Model • Parameterized Permissions and Roles • Para. SDN Model for Fine Grained and Scalable Authorization in SDN • SDN-RBACa Administrative Model • Proxy Operations and Custom Permissions • Conclusion and Future Work @ Abdullah Al-Alaj 2

Introduction Traditional Networks Management Layer CLI Control plane Data plane Infrastructure Layer Traditional Network SDN Idea Control plane Decoupling Data plane @ Abdullah Al-Alaj 3

Introduction Software Defined Networks (SDN) Applications Routing Firewall Load Balancing Intrusion Prevention Network Visualization Other . . . Network Programming APIs Virtual Network Resources Network Services Controller (e. g. , Floodlight) Topology Service Entry Pushing Routing Service Device Management Statistics Collection Link Discovery Switch Management Other Topology Flow tables Switches Ports Statistics Traffic payloads Configurations VLANs Hosts Links Devices Other Manage Control plane Decoupling Open. Flow Protocol Flow table Infrastructure Data plane @ Abdullah Al-Alaj 4

Features Provided by SDN Architecture Logically Centralized Control Network Programmability SDN Network-Wide Visibility @ Abdullah Al-Alaj 5 Dynamic Flow Control

Flow Table Structure SDN Controller Open. Flow Table Entry Rule Priority Action Counters Flow tables Open. Flow Switch MAC src. . : 00: 01 MAC dst. . : 00: 04 . . : 00: 01 * * Port-1 IP src * IP dst * TCP port Priority Action Packets src dst * * Port-4 Port-1 * 10. 0. 0. 3 Port-2 * * Port-3 Drop Packet Processing in Open. Flow Switch Packet from network Port-4 Parse header fields Host-A Host-B Host-D MAC: 00: 00: 00: 01 MAC: 00: 00: 00: 02 MAC: 00: 00: 00: 04 Host-C IP: 10. 0. 0. 1 IP: 10. 0. 0. 2 IP: 10. 0. 0. 4 MAC: 00: 00: 00: 03 IP: 10. 0. 0. 3 @ Abdullah Al-Alaj 6 Match Found? Yes Update counters Apply actions No Send to controller

Flow Rule Insertion Example 5 Read topology info. Routing app 4 6 Find shortest path 8 Parse packet 3 Forward packet to network apps 7 Read hosts info. Insert flow rule Controller If a matching rule found in table, apply actions; otherwise, forward packet to controller. Packet Processing in Open. Flow Switch Insert flow rule: Mac-Host-A -> Mac-Host-D: Port-4 9 Switch receives a network packet 1 2 @ Abdullah Al-Alaj Parse header fields Yes Update counters Port- 4 Host-D Host-B Packet from network Match Found? Port-1 rt-2 Port-3 Po Host-A Flow rule: Mac-Host-A -> Mac-Host-D : Port-4 Host-C 7 Apply actions No Send to controller

Access Control in SDN • Control which subjects (network apps) can access which objects (virtual network resources) for performing which actions (SDN operations). @ Abdullah Al-Alaj Network apps (Untrusted) Open interface: needs control 8

Literature of Access Control for SDN • Capability-based approaches • Direct relation between operations and apps. • Well studied and known to have administrative complexities. Capability-based approach Network apps App 1 App 2 App 3 App 4 Role-based approach Permissions P 1 P 2 Network apps P 3 App 1 P 4 App 2 App 3 P 5 P 2 r 1 P 3 P 4 App 4 P 5 P 6 Total associations = 3 + 6 = 9 1 new app requires 1 new associations 1 new permission requires 1 new association Total associations =3 x 6 = 18 1 new app requires 6 new associations 1 new permission requires 3 new associations @ Abdullah Al-Alaj 9

Problem and Thesis Statement Problem Statement: Current Software Defined Networking technology is lacking access control models and enforcement for protecting network resources residing in the SDN controller from unauthorized access by Open. Flow applications. Thesis Statement: Role-based access control model and its extensions is an effective approach for the specification and administration of dynamic access control for Software Defined Networking. @ Abdullah Al-Alaj 10

Summary of Contributions • Enabling Role Based Authorization for SDN. • SDN-RBAC Model and Authorization Framework with Implementation & Enforcement in SDN Controller. • Fine-Grained and Scalable Access Control for SDN. • Access Control Enhanced with Role and Permission Parameters with Authorization Framework Extended with Parameter Engine and Enforcement in SDN Controller. • Administration of Access Control in SDN. • SDN-RBACa Administrative Model for Managing roles, Permissions and Network App Authorizations in SDN. • Proxy Operations and Custom Permissions for Enhanced Engineering of Administrative Units in SDN. @ Abdullah Al-Alaj 11

Summary of Contributions • Enabling Role Based Authorization for SDN. • SDN-RBAC Model and Authorization Framework with Implementation & Enforcement in SDN Controller. • Fine-Grained and Scalable Access Control for SDN. • Access Control Enhanced with Role and Permission Parameters with Authorization Framework Extended with Parameter Engine and Enforcement in SDN Controller. • Administration of Access Control in SDN. • SDN-RBACa Administrative Model for Managing roles, Permissions and Network App Authorizations in SDN. • Proxy Operations and Custom Permissions for Enhanced Engineering of Administrative Units in SDN. @ Abdullah Al-Alaj 12

SDN-RBAC: Conceptual Model • • Design goal: conformance with the standard NIST-RBAC Reference Model. SDN-RBAC adopts standard RBAC model with evolutionary changes, rather than revolutionary. Sample Apps: - Load Balancer - Firewall - Intrusion Prevention - Routing app - etc. APPS Sample Roles: - Flow Mod - Device Handler - Bandwidth Monitoring - Link Handler - etc. AR session_ roles session_ app SESSIONS Sample Sessions: - deep packet inspection session - transmission rate monitoring session - web-traffic filtering session - shortest path recomputation session - traffic redirection session - etc @ Abdullah Al-Alaj PR ROLES one-to-many-to-many 13 Sample Operations: - add. Flow - get. All. Devices - get. Bandwidth. Consumption - etc. OPERATIONS (OPS) PRMS OBJECT TYPES (OBTS) OT OBJECTS (OBS) Sample Object Types: - FLOW-RULE - DEVICE - PORT-STATS - PORT - LINK - etc.

SDN-RBAC Formal Model Definition @ Abdullah Al-Alaj 14

Use-case in SDN-RBAC Multi session app: Data Usage Cap Manager @ Abdullah Al-Alaj 15

Use-Case Security Configuration in SDN-RBAC 3 roles 2 sessions permission to insert flow rules role assigned to app very important role & permission role activated in session permission available to session @ Abdullah Al-Alaj 16

SDN-RBAC Framework Implementation in Floodlight @ Abdullah Al-Alaj 17

SDN-RBAC Average Authorization Time • • • Test app with 50 ops covered by 10 different roles. Report authorization time for all 50 requests. Different security policies. Test repeated 100 times for each security policy. Average authorization time is calculated. floodlight’s boot-up time is ignored. Timer Started Timer Ended On average: 0. 0245 ms overhead for 50 operations. @ Abdullah Al-Alaj 18

Summary of Contributions • Enabling Role Based Authorization for SDN. • SDN-RBAC Model and Authorization Framework with Implementation & Enforcement in SDN Controller. • Fine-Grained and Scalable Access Control for SDN. • Access Control Enhanced with Role and Permission Parameters with Authorization Framework Extended with Parameter Engine and Enforcement in SDN Controller. • Administration of Access Control in SDN. • SDN-RBACa Administrative Model for Managing roles, Permissions and Network App Authorizations in SDN. • Proxy Operations and Custom Permissions for Enhanced Engineering of Administrative Units in SDN. @ Abdullah Al-Alaj 19

Limitations of SDN-RBAC • Apps are authorized on object types (e. g. , (add. Flow, FLOW RULE)) Fine grained access control is required. a 1 a 2 a 3 Requires restriction a 4 a 5 a 6 a 7 a 8 a 9 … Controller (Floodlight) CS 0 x 1 0 x 2 0 x 3 • • 0 x 4 CIS 0 x 7 CE 0 x 8 0 x 5 0 x 9 0 x 6 Role: Flow Mod 1 Role: Flow Mod 2 Role: Flow Mod 3 Assigned Perms: (add. Flow, flow_rulesw 0 x 1) (add. Flow, flow_rulesw 0 x 4) (add. Flow, flow_rulesw 0 x 7) sw 0 x 2 sw 0 x 5 (add. Flow, flow_rule ) (add. Flow, flow_rulesw 0 x 8) sw 0 x 3 sw 0 x 6 (add. Flow, flow_rule ) (add. Flow, flow_rulesw 0 x 9) continue for: Multiple very closely related roles are defined to achieve fine-grained access control. delete. Flow x 3 Roles read. Flow are limited x 3 in membership. read. Flow x 3 update. Flow x 3 @ Abdullah Al-Alaj … Role explosion 20 … Permission explosion

Introducing Parameterized Roles and Permissions in SDN a 1 a 2 a 3 Requires restriction a 4 a 5 a 6 a 7 a 8 a 9 Controller (Floodlight) CS 0 x 1 0 x 2 0 x 3 dept = CS CIS 0 x 4 0 x 7 0 x 8 0 x 5 0 x 9 0 x 6 dept = CIS Role: Flow Mod Assigned Perms: (add. Flow, FLOW RULE) (delete. Flow, FLOW RULE) (update. Flow, FLOW RULE) (read. Flow, FLOW RULE) @ Abdullah Al-Alaj CE 21 dept = CE

Parameterized Permissions and Roles • Parameters • name: value pairs. • Add restrictions on access to network resources. • Parameterized Roles: (ri , {(par 1 , val 1 ), (par 2 , val 2 ), . . . }) Example: (Flow Mod, {(dept, ⊥), (traffic, ⊥)}) • Parameterized Permissions: ((opi, oti), {(par 1 , val 1 ), (par 2 , val 2 ), . . . }) Example: ((add. Flow, FLOW-RULE), {(dept, ⊥), (traffic, ⊥)}) ⊥ = Unknown. @ Abdullah Al-Alaj 22

Para. SDN Conceptual Model many-to-many PARAMETERS (PAR) one-to-many PVPAIRS PARAMETERS (PAR) VALUES (VAL) PVPAIRS APPS AA PPA VALUES (VAL) OPERATIONS (OPS) app_ sessions session_ roles PRMS ROLES OBJECT TYPES (OBTS) PROLES PPRMS. . . @ Abdullah Al-Alaj 23 OT OBJECTS (OBS)

Para. SDN Formal Model Definition @ Abdullah Al-Alaj 24

Use-Case Security Configuration in SDN-RBAC @ Abdullah Al-Alaj 25

Para. SDN Framework Implementation in Floodlight . @ Abdullah Al-Alaj 26

Para. SDN Implementation & Evaluation Timer Started Timer Ended @ Abdullah Al-Alaj 27

Para. SDN Evaluation - 1 • • • Test app with 50 ops covered by 10 different roles. Report authorization time for all 50 requests. Different security policies (parameters and roles). Test repeated 100 times for each security policy. Average authorization time is calculated. Floodlight’s boot-up time is ignored. On average: Para. SDN adds 0. 031 ms overhead compared to 0. 025 for SDN-RBAC. • 1 st parameter in all roles is: active. Period = “ 08: 00 -17: 00”. • Any request submitted outside active period, will be denied. • Test 8 is conducted outside active period. . @ Abdullah Al-Alaj 28

Para. SDN Evaluation - 2 @ Abdullah Al-Alaj 29

Summary of Contributions • Enabling Role Based Authorization for SDN. • SDN-RBAC Model and Authorization Framework with Implementation & Enforcement in SDN Controller. • Fine-Grained and Scalable Access Control for SDN. • Access Control Enhanced with Role and Permission Parameters with Authorization Framework Extended with Parameter Engine and Enforcement in SDN Controller. • Administration of Access Control in SDN. • SDN-RBACa Administrative Model for Managing roles, Permissions and Network App Authorizations in SDN. • Proxy Operations and Custom Permissions for Enhanced Engineering of Administrative Units in SDN. @ Abdullah Al-Alaj 30

Access Control Administration in SDN • App-role and permission-role relations need management. • In SDN-RBACa administrative model (inspired by Uni-ARBAC): • Indirect permission-role assignment. • Permissions are grouped into permission-pools (tasks). • Tasks: units of network functions. • Apps are grouped into app-pools. • Administrative Units for administering app-role and task-role relations. ed to Assign Admin User an @ Abdullah Al-Alaj ed to Manages Portion of Ca n. M Apps Assign Admin Unit ag e App-role assignment Roles Admin User e ag n Ma n Ca Task-role assignment 31 Tasks

SDN-RBACa Administrative Model . @ Abdullah Al-Alaj 32

SDN-RBACa Administrative Model Defenition @ Abdullah Al-Alaj 33

Use Case using SDN-RBACa Introduction • In large SDNs, specialized apps control/analyze and monitor/inspect specific network traffic type. • These apps should be authorized to access only traffic type they handle and not other type (via roles). Apps Web-specific apps: • Web Load Balancers • Web Firewalls • etc. Vo. IP-specific apps: • Vo. IP Load Balancers • Vo. IP Firewalls • etc. FTP-specific apps: • FTP Load Balancers • FTP Firewalls • etc. Email-specific apps: @ Abdullah Al-Alaj • Email Load Balancers • Email Firewalls • etc. Roles Authorized via 34 Web-specific roles: • Web Flow Mod • Web Load Balancing • etc. Vo. IP-specific roles: • Vo. IP Flow Mod • Vo. IP Load Balancing • etc. FTP-specific roles: • Ftp Flow Mod • Ftp Load Balancing • etc. Email-specific roles: • Email Flow Mod • Email Load Balancing • etc.

Use Case using SDN-RBACa Introduction • In large SDNs, specialized apps control/analyze and monitor/inspect specific network traffic type. • These apps should be authorized to access only traffic type they handle and not other type (via roles). Apps Web-specific apps: • Web Load Balancers • Web Firewalls • etc. Vo. IP-specific apps: • Vo. IP Load Balancers • Vo. IP Firewalls • etc. Roles Authorized via Roles: FTP-specific apps: Email-specific apps: @ Abdullah Al-Alaj • FTP Load Balancers • FTP Firewalls • etc. • Email Load Balancers • Email Firewalls • etc. Authorized via 35 • Flow Mod • Load Balancing • etc.

Functional Administrative Units for SDN • Relations between apps and roles should be managed by different administrative units. Administrative Units @ Abdullah Al-Alaj Web Admin Unit • Roles: {Web Flow Mod, Web Load Balancing, etc. } • App-Pools: {Web Security, Web Load Balance, etc. } Email Admin Unit • Roles: {Email Flow Mod, Email Load Balancing, , etc. } • App-Pools: {Email Security, Email Load Balance} Vo. IP Admin Unit • Roles: {Email Flow Mod, Vo. IP Load Balancing, etc. }} • App-Pools: {Vo. IP Security, Vo. IP Load Balance} FTP Admin Unit • Roles: {FTP Mod Email, FTP Load Balancing, etc. } • App-Pools: {FTP Security, FTP Load Balance} 36

Custom and Proxy Operations OPProxy 1 OPProxy 2 OPProxy 3 (verify access to appropriate content) provides restrictive access to specific traffic type. (ensure that flow rule handles correct traffic type) @ Abdullah Al-Alaj 37

Custom Permissions • Custom permissions are those permissions that are created using proxy operations. (OPProxy_1, ot) (OPProxy_2, ot) (OPProxy_3, ot) … Examples: (add. Web. Flow, FLOW-RULE) (add. Vo. IPFlow, FLOW-RULE) (add. Ftp. Flow, FLOW-RULE) (create. Web. Member, LB-POOL-MEMBER) (create. Vo. IPMember, LB-POOLMEMBER) (create. Ftp. Member, LB-POOL-MEMBER) (read. Web. Packet. In. Payload, PI-PAYLOAD) (read. Vo. IPPacket. In. Payload, PI-PAYLOAD) … @ Abdullah Al-Alaj 38

Task and Role Engineering Custom Permissions SDN Apps App 1 App 2 App 3 Roles r 1 r 2 r 3 Tasks Custom Permissions OPProxy p 1 x 11 p 2 x 12 t 1 OPTarget val 1 val 2 c 1 clone op 1 val 3 t 2 p 3 x 13 p 4 x 21 p 5 x 22 Actual value passed to custom operation val 1 val 2 clone op 2 val 3 t 3 p 6 x 23 p 7 x 31 p 8 x 32 val 1 val 2 val 3 p 9 @ Abdullah Al-Alaj OPCustom 39 x 33 c 3 clone op 3

Task and Role Engineering using Custom Permissions - Example SDN Apps Web Intrusion Prevention Roles Web Flow Mod Tasks Web Traffic Forwarding Task Web Flow Viewing Task Vo. IP Load Balancer Vo. IP Flow Mod Vo. IP Traffic Forwarding Task Voip Flow Viewing FTP Application Firewall @ Abdullah Al-Alaj FTP Flow Mod FTP Traffic Forwarding Task FTP Flow Viewing Task Custom Permissions OPProxy (add. Web. Flow, Fl. OW-RULE) add. Web. Flow (add. Voip. Flow, Fl. OW-RULE) add. Voip. Flow (add. Ftp. Flow, Fl. OW-RULE) add. Ftp. Flow (delete. Web. Flow, Fl. OW-RULE) delete. Web. Flow (delete. Voip. Flow, Fl. OW-RULE) delete. Voip. Flow (delete. Ftp. Flow, Fl. OW-RULE) delete. Ftp. Flow (read. Web. Flow, Fl. OW-RULE) read. Web. Flow (read. Voip. Flow, Fl. OW-RULE) read. Voip. Flow (read. Ftp. Flow, Fl. OW-RULE) read. Ftp. Flow 40 OPCustom OPTarget web voip add. Flow(traffic) clone add. Flow ftp passed to custom operation web voip clone delete. Flow(traffic) delete. Flow ftp web voip ftp read. Flow(traffic) clone read. Flow

Use-Case and Administrative Actions Tasks, roles, and app-pools in white are exclusively managed by: Web Admin Unit Tasks, roles, and app-pools in gray are exclusively managed by: Vo. IP Admin Unit Administrative User Assignment: TA_admin = { (web_functions_admin_user, Web Admin Unit), (voip_functions_admin_user, Vo. IP Admin Unit)}. Example: 1. Administrative Action to assign task to a role: assign_task_to_role(web_functions_admin_user, Web Traffic Forwarding Task, Web Flow Mod) is allowed. Authorization Function: can_manage_task_role(web_functions_admin_user, Web Traffic Forwarding Task, Web Flow Mod) = True. Reason: ∃Web Admin Unit ∈ AU : ((web_functions_admin_user, Web Admin Unit) ∈ TA_admin) ∧ Web Flow Mod ∈ roles(Web Admin Unit) ∧ Web Traffic Forwarding Task ∈ tasks(Web Admin Unit). @ Abdullah Al-Alaj 41

Evaluation and Comparison • Evaluation of SDN-RBACa operational model with tasks and proxy permissions. • Test app with 50 proxy operations ops covered by 10 different roles. • Report authorization time for all 50 requests. • Different security policies. • Test repeated 100 times for each security policy. • Average authorization time is calculated. • Operational model of SDN-RBACa adds an average of 0. 0252 ms overhead on the floodlight controller while SDN-RBAC adds 0. 0245 ms on average. • Using tasks in SDN-RBACa operational model introduces additional variance in the authorization check time. • The operational model of SDN-RBACa introduces acceptable overhead to the controller for the sake of access control administration. @ Abdullah Al-Alaj 42

Conclusion and Future Work • We presented SDN-RBAC, a model for enabling role based authorization for SDN-RBAC is implemented and enforced in Floodlight controller. • We presented Para. SDN, a fine-Grained and Scalable Access Control for SDN Enhanced with Role and Permission Parameters. The Authorization Framework includes Parameter Engine and Enforcement in SDN Controller. • We presented SDN-RBACa, an administrative model for SND enhanced with Proxy Operations and Custom Permissions. Future Work: • Access Control for SDN-Enabled technologies. • Risk-Aware Access Control for SDN Apps. 43

Dissertation Publications Published: 1. Abdullah Al-Alaj, Ram Krishnan, and Ravi Sandhu. "SDN-RBAC: An Access Control Model for SDN Controller Applications. " 2019 4 th International Conference on Computing, Communications and Security (ICCCS). IEEE, 2019. 2. Abdullah Al-Alaj, Ravi Sandhu, and Ram Krishnan. "A Formal Access Control Model for SE-Floodlight Controller. " Proceedings of the ACM International Workshop on Security in Software Defined Networks & Network Function Virtualization. ACM, 2019. Submitted for review: 3. Abdullah Al-Alaj, Ram Krishnan, and Ravi Sandhu. Para. SDN: An Access Control Model for SDN Applications based on Parameterized Roles and Permissions. In 2020 IEEE 6 th International Conference on Collaboration and Internet Computing (CIC ). Atlanta, Georgia, USA, IEEE, 2020. 4. Abdullah Al-Alaj, Ravi Sandhu, and Ram Krishnan. A Model for the Administration of Access Control in Software Defined Networking using Custom Permissions. In 2020 Second IEEE International Conference on Trust, Privacy and Security in Intelligent Systems and Applications (TPS-ISA). Atlanta, Georgia, USA, IEEE, 2020. 44

Thank you! Questions? 45

Backup Slides 46

Selected roles in SDN-RBAC © Abdullah Al-Alaj 47

SDN-RBAC - Check Access avail_session_ perms SDN-RBAC check. Access session_ roles request from session (se) se se session_roles(se) loop ri ∈ session_roles(se) assigned_perms(ri) loop pi ∈ assigned_perms(ri) perm pi matches request? true/false 48 assigned_ perms

SDN-RBAC App Authorization- Example - dces = Data. Cap. Enforcing. Session avail_session_ perms SDN-RBAC check. Access request from session (dces) add. Flow, fri session_ roles dces {Flow Mod} loop Flow Mod {(add. Flow, FLOW-RULE), …} loop (add. Flow, FLOW-RULE) matches request? true 49 assigned_ perms

SDN-RBAC: Specifications of System Functions Session Creation/Deletion Adding/Dropping Active Role Access Check Apps are authorized based on object type. © Abdullah Al-Alaj 50

Methods for Inter-session Interaction for SDN-RBAC Atomic sessions © Abdullah Al-Alaj Two sessions access shared data Conditional session creation 51 Interaction via inter-session interaction APIs Active role set sent from master to slave sessions

Session Handling Approaches • Who is responsible of specifying: - (T) the tasks and corresponding sessions. (C) the condition for session creation/deletion. (A) the active role set. (R) role to be added/dropped during execution. Session Handling Approaches Developer-driven Approach System-driven Approach (T) DD (C) DD (A) DD (R) DD (T) CR (C) CR (A) CR (R) CR DD = determined by Developer at Design-time. CR = determined by Controller at Run-time. SR = determined by Session at Run-time. © Abdullah Al-Alaj 52 Session-driven Approach (T) DD (C) SR (A) SR (R) SR

Developer-driven Session Handling (1) • Developer has full and prior knowledge of • all possible sessions • active role set required for each session to achieve its task. • This information is provided to the controller before app execution. • The controller knows in advance: • what session instances will be created. • the tasks that will execute in each session. • active role set required for each session. © Abdullah Al-Alaj 53 (T) DD (C) DD (A) DD (R) DD

Usability demonstration (1) Access Denies • To show that SDN-RBAC authorization system can identify and reject any unauthorized operations: • We forced Data. Usage. Analysis. Session to read link information via operation get. All. Links. • The permission (get. All. Links, LINK) is assigned to the role Link. Handler. • Role Link. Handler is not a member of the active role set of Data. Usage. Analysis. Session. • A snapshot of the execution result is shown below. Unauthorized Snapshot 1 © Abdullah Al-Alaj 54

Usability demonstration (2) Access Allowed • We forced Data. Usage. Analysis. Session to read device statistics via operation get. Bandwidth. Consumption. • The permission (get. Bandwidth. Consumption, PORT-STATS) is assigned to the role Bandwidth. Monitoring. • Role Bandwidth. Monitoring is a member of the active role set of Data. Usage. Analysis. Session. • A snapshot of the execution result is shown below. • The snapshot below shows how Data. Usage. Analysis. Session was able to pass the authorization. Authorized Snapshot 2 © Abdullah Al-Alaj 55

Parameter Checking Functions 56

App Authorization Function 57

Verifier Example 58

Parameter Value Assignment • Parameter values, assigned via assign. App administrative action, propagate automatically from role parameters to permission parameters. Example: (Flow Mod, {(dept, ⊥), (traffic, ⊥)}) ((add. Flow, FLOW-RULE), {(dept, ⊥), (traffic, ⊥)}) 1. Parameterized permission assigned to parameterized role. Parameter values are unknown. 2. Parameter value assigned to parameterized role via assign. App administrative action. 3. Parameter values propagate from parameterized role to parameterized permission. (Flow Mod, {(dept, {CS}), (traffic, web)}) ((add. Flow, FLOW-RULE), {(dept, {CS}), (traffic, web)}) . 59

Para. SDN : App Authorization Example • check. Access(Data. Cap. Enforcing. Session, add. Flow, fow_rule[switch _ id=0 x 2, tcp _ dst=80, . . . ] ) ≡ ∃(Flow Mod, {(dept, {CS}), (traffc, web)}) ∈ PROLES : (Flow Mod, {(dept, {CS}), (traffic, web)}) ∈ session_roles(Data. Cap. Enforcing. Session), = true ∃((add. Flow, FLOW-RULE), {(dept, {CS}), (traffic, web)}) ∈ PPRMS : (((add. Flow, FLOW-RULE), {(dept, {CS}), (traffic, web)}), (Flow Mod, {(dept, {CS}), (traffic, web)})) ∈ PPA ∧ (add. Flow, type(flow_rule[switch _ id=0 x 2, tcp _ dst=80, . . . ])) = (add. Flow, FLOW-RULE) ∧ = true Param. Check(Data. Cap. Enforcing. Session, add. Flow, flow_rule[switch _ id=0 x 2, tcp _ dst=80, . . . ], {(dept, {CS}), (traffic, web)}) = True. PPA = {. . . , (((add. Flow, FLOW-RULE), {(dept, {CS}), (traffic, web)}), (Flow Mod, {(dept, {CS}), (traffic, web)})), . . . }. 60

Parameter Engine - Use Case Example Request Evaluation & Decision (PDP) Param Check Point (PCP) Verifiers Retrieval Point (VRP) Data. Cap. Enforcing. Session, add. Flow, flow_rule[switch _ id=0 x 2, tcp _ dst=80, . . . ], {(dept, {CS}), (traffic, web)} type(add. Flow, flow_rule[switch _ id=0 x 2, tcp _ dst=80, . . . ]), {(dept, {CS}), (traffic, web)} (FLOW-RULE, dept) VRule. Switch (FLOW-RULE, traffic) VRule. Traffic {VRule. Switch, VRule. Traffic} flow_rule[switch _ id=0 x 2, tcp _ dst=80, . . . ], (dept, {CS}) (∃d ∈ pvpair. val : verifier’s result = false true/false VRule. Switch flow_rule. switch_id ∈ switches(d)); flow_rule[switch _ id=0 x 2, tcp _ dst=80, . . . ], (traffic, web) (flow_rule. tcp_dst ∈ verifier’s result = false true/false VRule. Traffic protocol_ports(pvpair. val)) true 61 … switches: CS= [0 x 1, x 02] CE= [x 03] … protocol_ports: web = [80, 443] voip= [5060, …] ftp= [20, 21] … CONFIG Verifiers Map