Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Pristine glif 2015

RINA talk given at the GLIF technical meeting in Prague, September 2015.

  • Login to see the comments

  • Be the first to like this

Pristine glif 2015

  1. 1. #ict-pristine RINA: Recursive InterNetwork Architecture Last advances from the PRISTINE project Leonardo Bergesio on behalf of The PRISTINE consortium
  2. 2. RINA INTRODUCTION 2 1 #ict-pristine
  3. 3. RINA higlights • 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: a communication instance (flow) 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 3 1 2 3 4 #ict-pristine 5 6
  4. 4. From here … 4 Host Enterprise router IEEE 802.3 (Ethernet) Enterprise router TCP/UDP Host App A App B Application A Sockets API OS Sockets Layer 1. Bind/Listen to interface and port 2. Accept incoming connections 3. Connect to a remote address/port 4. Send datagram 5. Write data (bytes) to socket 6. Read data (bytes) from socket 7. Destroy socket IP IEEE 802.11 (WiFi) Carrier Ethernet Switch IEEE 802.1q (VLAN) IEEE 802.1ah (PBB) Each tech has a different API, and all are different from the application API Carrier Ethernet Switch #ict-pristine
  5. 5. To here! 5 Host Border router Interior Router DIF DIF DIF Border router DIF DIF DIF Host App A App B Consistent API through layers App A Layer (DIF) API IPC Process 1. Register/Unregister App 2. Allocate/Deallocate flows 3. Write data (SDUs) to flows 4. Read data (SDUs) from flows 5. Get layer information #ict-pristine
  6. 6. Internal layer organization 6#ict-pristine
  8. 8. • … but can also be the basis of RINA-based products – Tightly integrated with the Operating System – Capable of being optimized for high performance – Enables future hardware offload of some functions – Capable of seamlessly supporting existing applications – IP over RINA RINA implementation goals • Build a platform that enables RINA experimentation … – Flexible, adaptable (host, interior router, border router) – Modular design – Programmable – RINA over X (Ethernet, TCP, UDP, USB, shared memory, etc.) – Support for native RINA applications 8 1 2 3 4 5 1 2 3 4 5 #ict-pristine
  9. 9. Some decisions and tradeoffs 9 Decision Pros Cons Linux/OS vs other Operating systems Adoption, Community, Stability, Documentation, Support Monolithic kernel (RINA/ IPC Model may be better suited to micro-kernels) User/kernel split vs user-space only IPC as a fundamental OS service, access device drivers, hardware offload, IP over RINA, performance More complex implementation and debugging C/C++ vs Java, Python, … Native implementation Portability, Skills to master language (users) Multiple user-space daemons vs single one Reliability, Isolation between IPCPs and IPC Manager Communication overhead, more complex impl. Soft-irqs/tasklets vs. workqueues (kernel) Minimize latency and context switches of data going through the “stack” More complex kernel locking and debugging
  10. 10. High-level software arch. 10
  11. 11. PRISTINE contributions: SDK, policies, NMS 11 Normal IPC Process (Layer Management) User space IRATI stack Kernel Kernel IPC Manager Normal IPC Process (Data Transfer/Control) Shim IPCP over 802.1Q Shim IPCP for HV Shim IPCP TCP/UDP IPC Process Daemon (Layer Management) IPC Manager Daemon Normal IPC Process (Data Transfer/Control) Shim IPCP TCP/UDP Shim IPCP for HV Shim IPCP over 802.1Q Application zoom in zoom in zoom in Normal IPC Process (Data Transfer/Control) Error and Flow Control Protocol Relaying and Multiplexing Task SDU Protection SDK support RTT policy Txctrl policy ECN policy . . . SDK support Forwar policy Schedu policy MaxQ policy Monit policy SDK support TTL policy CRC policy Encryp policy Normal IPC Process (Layer Management) RIB & RIB Daemon librina Resource allocation Flow allocation Enrollment Namespace Management Security Management Routing SDK support Auth. policy Acc.ctrl policy Coord policy SDK support Address assign Directory replica Address validat SDK support New flow policy SDK support PFTgen policy Pushbak notify SDK support Enroll. sequenc e SDK support Routing policyIPC Manager RIB & RIB Daemon librina Manageme nt agent (NMS DAF) IPCM logic Network Manager (NMS DAF) #ict-pristine
  12. 12. Implementation status (I) IPCP components IRATI objectives, outcomes and lessons learned 12 IPCP component SDK Available policies / comments CACEP Y No authentication, password-based, cryptographic (RSA keys) SDU Protection N On/off hardcoded default policies, no SDK support yet: CRC32 (Error Check), hopcount (TTL enforcement), AES encryption CDAP N Google Protocol Buffers (GPB) encoding, no support for filter op Enrollment Y Default enrollment policy based on enrollment spec Flow Allocation Y Simple QoS-cube selection policy (just reliable or unreliable) Namespace Mgr. Y Static addressing, fully replicated Directory Forwarding Table Routing Y Link-state routing policy based on IS-IS Res. Allocator Y PDU Fwding table generator policy with input from routing EFCP Y Retx. Control policies, window-based flow control, ECN receiver RMT Y Multiplexing: simple FIFO, cherish/urgency. Forwarding: longest match on dest. address, multi-path forwarding, LFA. ECN marking
  13. 13. Open source IRATI 13 • IRATI github side • • Hosts code, docs, issues • Installation guide • Experimenters (tutorials) • Developers (software arch) • Mailing list for users and developers • • Procedures to contribute under discussion, doc ongoing #ict-pristine
  15. 15. RINASim ● RINASim is independent framework implemented for OMNeT++ ● Source code is publicly available on github ( ● Easy issue submitting ● Fast integration of partners contribution ● Documentation is automatically generated using Doxygen ● Partners contribute via dedicated branch (fork/merge procedure) ● New release ~every month ● Available also as an virtual-machine OVF appliance for VmWare or VirtualBox 15#ict-pristine
  16. 16. RINA Simulator Model Main building blocks @ictpristine 16 Main RINA Simulator model (systems and physical links) Border Router Interior Router Hosts ● 1 N-level IPC Process ● X > 2 N-1 level IPC Processes ● 1 N-level IPC Process ● X >= 2 N-1 level IPC Processes ● X >= 1 N-2 level IPC Processes ● A flexible number of IPCPs, but not for relaying ● X >= 1 Application Processes ● 1 DIF Allocator #ict-pristine
  18. 18. Simplifying VM Networking with RINA 21 • No need to perform TCP/UDP checksumming since shared memory communication is protected from corruption – Checksumming is not actually performed by modern paravirtualized NICs (e.g. virtio-net, xen-netfront) • No need to implement complex and expensive NIC emulation. • No need to generate and assign MAC addresses, • No need to create and configure software L2 bridges to connect VMs and hypervisor physical NICs together. • Users of the shim DIF are not restricted to the Ethernet MTU (1500/9000 bytes) – Commonly bypassed using the TCP Segmentation Offloading (TSO). #ict-pristine
  19. 19. Experimental results (prototype) IRATI objectives, outcomes and lessons learned 22Experimental scenario Host to VM communication VM to VM communication
  20. 20. Congestion control (I) • In RINA CC is a generalization of how it is done in the Internet • Benefits: – “Naturally” gaining from properties of various previous improvements in the Internet, without inheriting their problems (PEPs), flow aggregation – Customization of CC policies to each layer needs (not one size fits all) – With explicit detection, congestion effects can be confined to a single layer (faster and more local response to congestion) 23 … 2-DIF 1-DIF … Some DIFs RM T RA EFC P Some DIFs N-DIF Sender Receiver RM T RA RM T RA EFC P RM T RA EFC P RM T RA RM T RA EFC P RM T RA EFC P R M T RA EFC P…… #ict-pristine
  21. 21. Congestion control (II): simulations • Horizontal: consecutive DIFs • Vertical: stacked DIFs 24 S 1 R 1 Router 1 TCP Contro l Loop Split- TCP Control Loops S1 Sn R1 Rn Router1 Router2 … … n = 5, 10, 15 n = 1 #ict-pristine
  22. 22. • TCP (iperf) vs. RINA with two different cc policy sets deployed in the red DIF. 4 flows, Throughput vs. Experiment time Congestion control (III): prototype #ict-pristine TCP RINA with RED PS RINA with Jain PS Experiment setup
  23. 23. Security overview: placement of security functions in RINA 26 Allocating a flow to destination application Access control Sending/receiving SDUs 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 SDUs through N-1 DIF Confidentiality, integrity Allocating a flow to destination application Access control IPC Process Appl. Process DIF Operation Logging/Auditing DIF Operation Logging/Auditing • IPC Process components involved in security • CACEP: Authentication policies • Security Coordination: Credential Management, Access Control Decisions (allow new IPC Processes in the DIF, accept flows to applications), Intrusion Detection/Prevention?, other? • SDU Protection: Confidentiality mechanisms (encryption) • RIB Daemon: Logging of operations in the DIF #ict-pristine
  24. 24. Security: DIFs are securable containers • Different security policies depending on who can join the DIF and trust on N-1 DIFs • Recursion provides isolation: internal provider layers are not visible to other customer or provider networks (unless the provider’s systems are physically compromised) IRATI objectives, outcomes and lessons learned 27 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 Customer network Provider 1 network Provider 2 network IPCP A IPCP B IPCP C P2P DIF P2P DIF IPCP D
  25. 25. Example: AuthPassword policy (implemented in prototype) 28 IPCP A IPCP B Target of application connection Initiator of application connection 1 M_CONNECT = PSOC_authentication- password AuthPolicy.version = 1 AuthPolicy.options = cipher 2 Generate random challenge string CHALLENGE REQUEST random challenge string 3 XOR challenge string with password, hash result and return reply CHALLENGE REPLY XORed result 4 XOR random challenge with password, hash and compare with response M_CONNECT_R @ictpristine
  26. 26. IPCP A IPCP B Target of application connection Initiator of application connection 1 M_CONNECT = PSOC_authentication-ssh2 AuthPolicy.version = 1 AuthPolicy.options = <proposed algorithms, DH pubKey> 2 Select algorithms. Generate key pair for DH. Combine with peer’s pubKey to generate shared secret. Hash to generate encryption keys. Enable decryption. Send message. Enable encryption DH Exchange DH pubKey, selected algorithms 3 Select algorithms. Combine peer’s pubKey with DH key pair to generate shared secret. Hash to generate encryption key, enable encryption and decryption. Client Challenge Client random challenge encrypted with RSA pub key 4 <Now communication is encrypted> Client Challenge response and Server Challenge Hashed, decrypted client random challenge Server random challenge encrypted with RSA public key Generate key pair for DH. Load RSA key pair for authentication. Generate random challenge. Encrypt with RSA public key Generate random challenge. Encrypt with RSA public key Decrypt challenge with RSA private key. XOR with shared secret and hash. 5 Server Challenge Response Hashed, decrypted server random challenge Decrypt server challenge with RSA private key. XOR with shared secret and hash. Combine client challenge with shared secrete and hash. Compare with received value Combine server challenge with shared secrete and hash. Compare with received value 6 M_CONNECT_R Example: AuthSSH2 policy (implemented in prototype)
  27. 27. FINAL REMARKS 30 5
  28. 28. Final remarks • Progress on improvement of core protocols (EFCP, CDAP). Started working on policy specifications for authentication, access control, SDU Protection, routing, congestion control and resource allocation. • Prototype (programmable via SDK) and Simulator maturing as they are used in experiments. Getting ready to become usable to newcomers (experiment tutorials under development). • Started quantifying RINA benefits on particular areas and specific scenarios/use cases (more to come during the following year). Current focus is congestion control, resource allocation, routing, security and network management. • Started working with SDOs to educate them on RINA and consider possible standardisation activities (ISO, ETSI). 5G and IoT are areas of potential interest. 31 1 2 3 4 #ict-pristine
  29. 29. Further information can be found here. Twitter @ictpristine www <Thank you!>