Just for you: FREE 60-day trial to the world’s largest digital library.
The SlideShare family just got bigger. Enjoy access to millions of ebooks, audiobooks, magazines, and more from Scribd.
Cancel anytime.
- 1. From protecting protocols to layers: security policies in RINA From protecting protocols to layers: designing, implementing and experimenting with security policies in RINA Eduard Grasa (presenter), Ondrej Lichtner, Ondrej Rysavy, Hamid Asgari, John Day, Lou Chitkushev FP7 PRISTINE ICC 2016, Kuala Lumpur, May 24th 2016
- 2. WHAT IS RINA?1 2
- 3. RINA highlights • Network architecture resulting from a fundamental theory of computer networking • Networking is InterProcess Communication (IPC) and only IPC. Unifies networking and distributed computing: the network is a distributed application that provides IPC • There is a single type of layer with programmable functions, that repeats as many times as needed by the network designers • All layers provide the same service: instances or communication (flows) to two or more application instances, with certain characteristics (delay, loss, in-order-delivery, etc) • There are only 3 types of systems: hosts, interior and border routers. No middleboxes (firewalls, NATs, etc) are needed • Deploy it over, under and next to current networking technologies 1 2 3 4 5 6 3
- 4. From the “TCP/IP” protocol suite … • Functional layers organized for modularity, each layer provides a different service to each other – As the RM is applied to the real world, it proofs to be incomplete. As a consequence, new layers are patched into the reference model as needed (layers 2.5, VLANs, VPNs, virtual network overlays, tunnels, MAC-in-MAC, etc.) (Theory) (Practice) 4
- 5. … to the RINA architecture Single type of layer, consistent API, programmable policies Host Border router Interior Router DIF DIF DIF Border router DIF DIF DIF (Distributed IPC Facility) Host App A App B Consistent API through layers 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 Control Retransmission Control Flow Control Flow Control Increasing timescale (functions performed less often) and complexity Namespace Management Security Management 5
- 6. Deployment Clean-slate concepts but incremental deployment Large-scale RINA Experimentation on FIRE+ 6 • IPv6 brings very small improvements to IPv4, but requires a clean slate deployment (not compatible to IPv4) • RINA can be deployed incrementally where it has the right incentives, and interoperate with current technologies (IP, Ethernet, MPLS, etc.) – Over IP (just like any overlay such as VXLAN, NVGRE, GTP-U, etc.) – Below IP (just like any underlay such as MPLS or MAC-in-MAC) – Next to IP (gateways/protocol translation such as IPv6) IP Network RINA Provider RINA Network Sockets ApplicationsRINA supported Applications IP or Ethernet or MPLS, etc
- 7. PROPERTIES OF RINA DESIGN CONTRIBUTING TO SECURITY 2 7
- 8. Protecting layers instead of protocols All layers have the same consistent, security model 8 • Benefits of having an architecture instead of a protocol suite: the architecture tells you where security related functions are placed. – 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’ 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
- 9. Separation of mechanism from policy 9 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 Control Retransmission Control Flow Control Flow Control Namespace Management Security Management • All layers have the same mechanisms and 2 protocols (EFCP for data transfer, CDAP for layer management), programmable via policies. • Don’t specify/implement security protocols, only security policies – Re-use common layer structure, re-use security policies across layers • 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) Authentication Access control (layer mgmt operations) Access control (joining the DIF) Coordination of security functions Confidentiality, Integrity
- 10. Separation of mechanism from policy 10 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 Control Retransmission Control Flow Control Flow Control Namespace Management Security Management • All layers have the same mechanisms and 2 protocols (EFCP for data transfer, CDAP for layer management), programmable via policies. • Don’t specify/implement security protocols, only security policies – Re-use common layer structure, re-use security policies across layers • 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) Authentication Access control (layer mgmt operations) Access control (joining the DIF) Coordination of security functions Confidentiality, Integrity Source: J. Small master thesis
- 11. Scope as a native construct Recursion provides isolation • Size each DIF to the scope supported applications need – Only allow those that really need to connect to the apps • No need for extra tools to do that: scope is built-in – DIFs are securable containers, no need for firewalls 11 Internet (TCP/IP) RINA Default model Global connectivity Controlled connectivity Control scope via Firewalls, ACLs, VLANs, Virtual Private Networks, etc.. Scope native concept in architecture (DIF) Example: Provider’s network internal layers hidden from customers and other providers
- 12. Separating port allocation from sync. Complete application naming • With app-names no need for well- known ports. Port-ids of local scope (not in protocol headers) • CEP-ids (in protocol headers) dynamically generated for each flow 12 IPCPP A App A Port-id read/ write 1 EFCP instance, cep-id 8736 IPCPP A App B Port-id read/ write 4 EFCP instance, cep-id 9123 Synchronization • Well-known ports used to identify app endpoints; statically assigned. @s exposed to apps. • Ports used also to identify TCP instances (in protocol headers). Attacker only needs to guess source port-id RINA TCP/IP IP@: 12 Port read/ write 12 TCP instance, port 12 IP @: 78 Port read/ write 78 TCP instance, port 78 TCP PM A TCP PM A
- 13. DESIGN AND EXPERIMENTATION WITH SECURITY POLICIES3 13
- 14. Customer network Interior Router Customer Border Router Interior Router Border Router P2P DIF Interior Router P2P DIF Border Router P2P DIF P2P DIF Interior Router Border Router Provider 1 Backbone DIF P2P DIF Border Router Provider 1 Regional DIF Multi-provider DIF P2P DIF Access DIF P2P DIFP2P DIF Provider 1 network Provider 2 network IPCP A IPCP B IPCP C P2P DIF P2P DIF IPCP D • DIFs are securable containers, strength of authentication and SDU Protection policies depends on its operational environment • DIFs shared between provider/customer (blue DIF) may require strong authentication and encryption, specially if operating over wireless (red DIF) • DIFs internal to a provider may do with no auth.: accessing the DIF requires physically compromising the provider’s assets (green and orange DIFs). Border Router Authentication and SDU protection policies
- 15. Authentication policy: SSH2-based (I) • Once applications (including IPCPs) have a flow allocated, go through application connection establishment phase – Negotiate app protocol (CDAP) version, RIB version, authenticate • Specified authentication policy based on SSH2 authentication (uses per IPCP public/private RSA key pairs), adapted to the RINA environment 15
- 16. Authentication policy: SSH2-based (II) 16
- 17. Crypto SDU protection policy • Crypto policy that encrypts/decrypts PCI and payload of EFCP PDUs – In general SDU protection is used by a DIF to protect its own data (PCIs of data transfer PDUs and full layer management PDUs) • Not assuming N-1 DIF will provide reliable and in-order-delivery -> using counter mode (as in IPsec) – AES128 and AES256 as supported encryption algorithms • HMAC code to protect integrity of PDU – SHA256 chosen as hash algorithm 17 12 IPCPP A IPCPP A N-1 flow SDU Protection SDU Protectioncounter Encrypted data HMAC
- 18. Experimentation with IRATI 18 Provider Border Router 1 Provider Border Router 2 Customer Border Router Shim DIF over Eth Shim DIF over Eth IPCP A IPCP B access.DIF IPCP C IPCP D regional.DIF IPCP E IPCP F IPCP G multi-provider.DIF Customer network Provider network Experimental scenario • IRATI is an open source, programmable implementation of RINA for Linux, written in C/C++ • Implemented plugins with authSSH2 auth. and SDU protection policies
- 19. ONGOING RINA INITIATIVES 4 19
- 20. Research, open source, standards • Current research projects – FP7 PRISTINE (2014-2016) http://ict-pristine-eu – H2020 ARCFIRE (2016-2017) http://ict-arcfire.eu – Norwegian project OCARINA(2016-2021) – BU RINA team http://csr.bu.edu/rina • Open source implementations – IRATI (Linux OS, C/C++, kernel components, policy framework, RINA over X) http://github.com/irati/stack – RINASim (RINA simulator, OMNeT++) – ProtoRINA (Java, RINA over UDP, quick prototyping) • Key RINA standardization activities – Pouzin Society (experimental specs) http://pouzinsociety.org – ISO SC6 WG7 (2 new projects: Future Network – Architectures, Future Network- Protocols) – ETSI Next Generation Protocols ISG 1 2 3 4 1 2 3 1 2 3 20
Editor's Notes
Recommended
More Related Content
Related Books
Free with a 30 day trial from Scribd