Unreliable inter process communication in Ethernet: Migrating to RINA with the shim DIF Sander Vrijders, Dimitri Staessens, Didier Colle, Mario Pickavet Ghent University – iMinds Eleni Trouva, Eduard Grasa i2CAT John Day, Lou Chitkushev Boston University 17/10/2015 1

Communication between application processes  Not to be confused with communication between interfaces  TCP/IP !!!  Basic premise: All networking is inter process communication and IPC only  All communication goes through three phases:  Enrollment  Flow allocation  Data transfer 17/10/2015 2

Enrollment  Creates/maintains/distributes/deletes the information within a layer that is needed to create instances of communication  Often ignored in the current internet architecture  Addresses, maximum packet size, …  More well-formed enrollment phases in IEEE (WiFi) and IEEE 802.1q (VLAN) 17/10/2015 3

Flow allocation  Creates/maintains/deletes the shared state between connection endpoint-ids necessary to support the functions of the data transfer phase  For unicast: between 2 communication processes  Also often ignored, forgotten  Without a flow allocation phase, all Protocol Data Units (PDUs) are implicitly accepted 17/10/2015 4

Data transfer  The actual sending of data  In the current architecture the other phases are often skipped  Immediately skipping to data transfer causes unreliable inter process communication 17/10/2015 5

Examining the Ethernet Header  Ethernet II: specification released by DEC, Intel, Xerox (hence also called DIX Ethernet) 17/10/ PreambleMAC destMAC src802.1q header (optional) EthertypePayloadFCSInterfram e gap 7 bytes6 bytes 4 bytes2 bytes bytes 4 bytes12 bytes

Examining the Ethernet header  IEEE Frame  Combined with IEEE (LLC) 17/10/ PreambleMAC destMAC src802.1q header (optional) LengthPayloadFCSInterfram e gap 7 bytes6 bytes 4 bytes2 bytes bytes 4 bytes12 bytes DSAPSSAPControlInformation 1 byte 1-2 bytesM bytes (M>=0 )

Ethertype  Identifies the syntax of the encapsulated protocol  Layers below need to know the syntax of the layer above  Layer violation!  Same for the protocol id in the IPv4 header 17/10/2015 8

Consequences of using an Ethertype  Also means only one flow can be distinguished between an address pair  The MAC address doubles as the connection endpoint-id 17/10/2015 9

Same problem with LLC?  Source and Destination Service Access Points (SAPs) are the connection endpoint-ids  Allow for more than one flow to be distinguished between two communicating nodes  Still fixed endpoints  All traffic will still be accepted 17/10/

Recursive InterNet Architecture (RINA)  New internetwork architecture  Unified theory of networking  A layer = a distributed application that provides IPC over a certain scope, called a Distributed IPC Facility (DIF)  Recurse as much as needed  Can be configured to a certain policy 17/10/

Architectural model DIF System (Host) IPC Process Shim IPC Process Mgmt Agemt System (Router) Shim IPC Process IPC Process Mgmt Agemt System (Host) IPC Process Shim IPC Process Mgmt Agemt Appl. Process Shim DIF over TCP/UDP Shim DIF over Ethernet Appl. Process IPC API Data TransferData Transfer Control Layer Management SDU Delimiting Data Transfer Relaying and Multiplexing SDU Protection Transmission Control Retransmission Control Flow Control RIB Daemon RIB CDAP Parser/Generator CACEP Enrollment Flow Allocation Resource Allocation Forwarding Table Generator Authentication State Vector Data Transfer Transmission Control Retransmission Control Flow Control IPC Resource Mgt. Inter DIF Directory SDU Protec tion Multipl exing IPC Mgt. Tasks Other Mgt. Tasks Application Specific Tasks Increasing timescale (functions performed less often) and complexity

Recursive InterNet Architecture  Recognizes the three phases all communication goes through!  Other advantages of RINA:  Inherent support for QoS  Multihoming and mobility  More secure 17/10/

Flow allocation in RINA 17/10/  Application A performs a flow allocation request  Application B responds to this request  Accept  Deny  If positive reply, a flow is created:  Port-id is assigned for further reference  Connection (with CEP-id) is maintained in lower layer while there is active data transfer

After flow allocation 17/10/

Flow allocation in TCP/IP  UDP has the same problem as Ethernet  No flow allocation  “Well-known ports”  security risk  Either manual configuration needed for flow allocation  Or use of other protocols (for instance SIP)  TCP has an incomplete flow allocation phase  But, overloads the uses of the TCP port (port-id and CEP-id)  another security risk  So, no decoupling of the flow allocation (port-id) and data transfer phase (CEP-id) 17/10/

Shim IPC process for 802.1q  Interfaces a new model to a legacy implementation  shim  Allows RINA DIFs to use it unchanged  Only provides the capability of a legacy layer  Simulates flow allocation 17/10/

Shim IPC process over 802.1q  Spans a single Ethernet segment  VLAN id is shim DIF name: joining the VLAN is considered enrolling in the shim DIF  Uses Ethernet II: Only one user of the shim DIF  Reuses the Address Resolution Protocol (ARP)  In RINA knowing which application is available at what address(es) is part of enrollment  For DIFs with small scope it can be part of flow allocation, just broadcast the allocate request 17/10/

Placement of the different PMs 17/10/

State diagram 17/10/

Conclusion  Creating the shim DIF over Ethernet reveals something about the nature of layers  For reliable inter process communication, three phases have to be present  Port-id and CEP-id have to be decoupled!  Port-ids seem to be a necessity for a clean separation of layers 17/10/

Questions ? 17/10/ Sander Vrijders Internet Based Communication Networks and Services (IBCN) Department of Information Technology (INTEC) Ghent University - iMinds