Download to read offline
Uploaded byICT PRISTINE
The hageu rina-workshop-security-peter
RINA provides a framework to securely manage connectivity and network association. It protects layers instead of individual protocols, and addresses are contained within securable Distributed Interface Functions (DIFs). DIFs can replace firewalls and enable centralized policy-based authentication, authorization, and access control. RINA separates security mechanisms from policies, uses a common layer structure across layers, and minimizes complexity to improve security. It also provides a new access control architecture and key management system to securely manage network functions even if systems are compromised.
More Related Content
Similar to The hageu rina-workshop-security-peter
The hageu rina-workshop-security-peter
- 1. ©PredictableNetworkSolutionsLtd2016 RINA and Security Securityand RINA Peter Thompson | CTO | Predictable Network Solutions SDN World Congress 2016, The Hague, October 2016
- 2. ©PredictableNetworkSolutionsLtd2016 RINA and Security 2 Currentnetworks struggle with managing connectivity/association • Implicit association forces ad-hoc solutions • 802.1X • NAT/Firewalls • Managing the configuration of these mechanisms is complex • Errors are easy to make and hard to fix • Typical node attributes are easily spoofed • E.g. MAC address RINA provides a framework to control association • RINA protects layers instead of protocols • Addressing scope is contained within DIFs • DIFs are securable containers, replacing firewalls • Policy-based Authentication and Authorisation models • Enrollment in DIF • Connection between processes • All centrally managed via policies • Allows Capability-based Access Control Managing connectivity/association
- 3. ©PredictableNetworkSolutionsLtd2016 RINA and Security 3Protectinglayers instead of protocols Operating on the IPCP’s RIB Access control Sending/receiving PDUs through N-1 DIF Confidentiality, integrity N DIF N-1 DIF IPC Process IPC Process IPC Process IPC Process Joining a DIF authentication, access control Sending/receiving PDUs through N-1 DIF Confidentiality, integrity Operating on the IPCP’s RIB Access control IPC Process Appl. Process Access control (DIF members) Confidentiality, integrity Authentication Access control Operations on RIB DIF Operation Logging DIF Operation Logging The architecture specifies where security-related functions are placed: All layers have the same mechanisms, programmable via policies.
- 4. ©PredictableNetworkSolutionsLtd2016 RINA and Security 4Separationof mechanism from policy 4 IPC API Data Transfer Data Transfer Control Layer Management SDU Delimiting Data Transfer Relaying and Multiplexing SDU Protection Retransmission Control Flow Control RIB Daemon RIB CDAP Parser/Generator CACEP Enrollment Flow Allocation Resource Allocation Routing Authentication StateVector StateVector StateVector Data TransferData Transfer Retransmission ControlRetransmission Control Flow Control Flow Control Namespace Management Security Management Authentication Access control (layer mgmt operations) Access control (joining the DIF) Coordination of security functionsConfidentiality, Integrity • Don’t specify/implement security protocols, only security policies • Re-use common layer structure, re-use security policies across layers • Only 2 protocols: EFCP for data transfer, CDAP for layer management • This approach greatly simplifies the network structure, minimizing the cost of security and improving the security level • “Complexity is the worst enemy of security” (B. Schneier)
- 5. ©PredictableNetworkSolutionsLtd2016 RINA and Security 5 Combines: •Adaptive and dynamic nature of ABAC model and • Fine-grained authorization provided by the CBAC model. Exploits RINA layer management functions • Generic solution able to secure any management layer function • E.g. routing or flow allocation New access control architecture in PRISTINE
- 6. ©PredictableNetworkSolutionsLtd2016 RINA and Security 6 •Key material kept separate • Secure even if the management system is compromised • Hierarchical structure • Scalability from delegation • Allows multi-tenant operation • Can integrate with existing key- management systems • ‘Key containers’ in the RIB • Contain key state • No private key material • Physical deployment depends on the level of trust of the environment • Reliable time-of-day clocks? • TPMs? Key management architecture
- 7. ©PredictableNetworkSolutionsLtd2016 RINA and Security 10 ResilientRouting • Loop-free Alternate (LFA) fast re-route • Routing table changes driven from RIB events • N-1 flow up • N-1 flow down • Flow State Database changed • Shown that distributed application exchanging messages between nodes is not affected by failure of links. • Whatever-cast • Transparent data replication Load distribution/balancing • No new components required • Server clusters belong to a single DAF • Exchange loading information • DAPs can be (de)provisioned as required • Distribution decisions can be taken in several locations • Choice depends on specifics of the scenario • Based on configurable policies Resiliency in RINA
- 8. ©PredictableNetworkSolutionsLtd2016 RINA and Security 11Demo:Service provider network • Show that rogue customers / peers could only compromise e-mall DIFs • And to do that they would need access to the key material providing authentication and SDU Protection policies are in place • Show asymetric key (RSA) and cryptographic SDU protection policies in action Access router PtP DIF CPE Edge Service Router MAN P.E MAN P. E. MAN Access DIF PtP DIF PtP DIFPtP DIF PtP DIF Host Core Backbone DIF PtP DIF Core router Core router Edge Router Edge Router Customer network ISP 2ISP 1 network Access Aggregation Service Edge Core Internet Edge PtP DIF PtP DIF PtP DIF Service Provider Top Level DIF E-mall 1 DIF PtP DIF E-mall 2 DIF attacker attacker attacker
- 9. ©PredictableNetworkSolutionsLtd2016 RINA and Security 12Demoobservation points Layout of physical systems • Observe behaviour of authentication and SDU Protection policies • Flows over e-mall1 DIF • Flows over e-mall2 DIF
- 10.
Editor's Notes
- #4 Instead of thinking protocol security (BGPsec, DNSsec, IPsec, TLS, etc.), think security of the architecture: no more ‘each protocol has its own security’, ‘add another protocol for security’ or ‘add another box that does security’