Application name spaces are not tied to any layer or DIF. Recognizing that they may all be members of other DIFs.
An API overlay to isolate applications and develop a DIF, then just push the use of the architecture down further and further up.
Remember, this is the architecture! DAF Support Tasks: The IPC Management (and other management: memory, storage, CPU) tasks are usually implemented as OS functionality. IPC Resource Management: Creation/Deletion of IPC processes Multiplexing (Usually inverse multiplexing, an application flow into multiple DIF flows, for example: 1 for video, 1 for audio, 1 for text, …) SDU Protection (CRCs, encryption, TTL, …) IDD (Inter DIF Directory, find out in what DIF the destination application process is executing)
Stress that with our scientific approach we are trying maximize the invariances, and minimize how much policy is necessary, as opposed to the craft tradition being pursued by others to minimize invariance.
Mention Dijkstra was right, but don’t repeat functions on the same scope.
A simple case that illustrates the problem under research is given in Fig. 1. In the scenario shown the web browser (application A) residing in host H3 requests to communicate with the web page (application C) on host H1. What discovering the requested application does require is finding which layers make it available, and then choosing an existing layer to join or creating a new one to enable the communication.
Each processing system has an instance of the IDD, an application process that enables the system to make available its applications and discover other applications. The application processes that are members of the same DAF are called “peer IDDs” are able to exchange messages for the discovery of applications. As every other DAF the IDD is supported by one DIF or a collection (set) of underlying DIFs that provide to the distributed application IPC services. Communication in RINA implies that the two systems that the communicating applications are residing share a DIF which provides IPC service. When an application wants to communi- cate with another application, first all the DIFs available to the source system are examined to see if the requested application is available through them. If none of the available DIFs returns a positive result, the IDD is responsible to first find the requested application and then attempt to create a supporting DIF between the two systems for the communication. The DAPs that comprise the IDD will forward a request from one to another asking for the requested application. Forwarding begins at the IDD DAP of the source system and will be based on the forwarding policies between the members of the DAF. The forwarding continues until the IDD DAP of the system in which the requested application resides is found or when some other predefined termination condition is met to prevent infinite searching.
In the case that the destination system is reached, the IDD will have first to verify that the requested application is still there and then that the requesting application is allowed to communicate with it. If both checks are positive, the next action for the IDD is to find a DIF that will support the communication between the two applications.
Since a common DIF between the source and the destination systems does not exist, a new one will have to be created by either expanding (joining) an existing DIF or creating a new one from scratch. The creation of the supporting DIF involves choosing a path from the source to the destination and coordination with the intermediate IDD DAPs for authorization control and creation and initialization of the new IPC application processes. Once the supporting DIF is in place, communication between the two applications can start.
Might cite the results of Gotham’s paper that analyzing the attacks that can be mounted on TCP don’t work on delta-t even though delta-t was designed decades before the attacks were known. The same is true of the IPC Model. No consideration given to security. However the model is more secure. Strong design has more to do with security than security does.
RINA: Update on research and prototyping activities. Global Future Internet Week 2012
RINA: Update on Research andPrototyping ActivitiesGlobal Future Internet SummitSeptember 14th, 2012Eduard GrasaResearch Manager @ DANAFundació i2CAT
Before we start… our perspective What is the “Future Internet”? We don’t know, we’re just interested in building better computer networksand finding out the correct ways of doing so. Is RINA “clean slate”? We’re retaking the direction of computer network research in the mid-70s,continuing where INWG left off, and learning from the success and mistakesof 40+ years of computer networking. If we were starting with “noassumptions” we would not be learning from the past (“Those who don’t knowhistory are destined to repeat it”) What are the design goals of RINA? No design goals, we just look at solving the problem of computer networkingand try to maximize the invariances and minimize the discontinuities. All theresults and insights have emerged from listening to the problem. Do you have all the answers? No way! We’re just beginning to explore the properties of a new paradigm*that simplifies computer networking by orders of magnitude. Do you want tojoin us?2* Not so new to be honest, initial computer network research (CYCLADES, INWG) was headed in this
Outline Quick Introduction to RINA Java prototype over IP Inter DIF Directory RINA Security Assessment FP7 IRATI Project: Kernel prototype overEthernet3
Naming and addressing in RINA All application processes(including IPC processes) have aname that uniquely identifiesthem within the applicationprocess namespace. In order to facilitate its operationwithin a DIF, each IPC processwithin a DIF gets a synonym thatmay have be structured tofacilitate its use within the DIF(i.e. an address).5 The scope of an address is the DIF, addresses are not visible outside of the DIF. The Flow Allocator function of the DIF finds the DIF IPC Process through which adestination Application process can be accessed. Because the architecture is recursive, applications, nodes and PoAs are relative For a given DIF of rank N, the IPC Process is a node, the process at the layer N+1is an application and the process at the layer N-1 is a Point of Attachment.1 2 3 41 2 1 2 3 1 21 21 2DIF ADIF BDIF CDIF DDIF E DIF F
RINA vs. the current Internet Architecture: Current: 5/7? layers, layers “2.5”, layer violations, “overlays”, “virtual networks”,“middleboxes” (NATs, firewalls, application-layer gateways) Getting complex!Unforeseen interactions RINA: Repeating structure, DIF (one type of layer, repeat as needed) Naming, addressing and routing: Current: No independent application names, no node names, just PoA names,routing on PoAs (no wonder why multi-homing and mobility is hard to support) RINA: Complete naming & addressing, routing on the node; support for multi-homing and mobility without special protocols. No need for global addressspace. Congestion control: Current: Put in TCP, the worst place it could be, since it maximizes the delay andvariance of the control loop (makes the system chaotic: self-similar traffic) RINA: Each layer can perform congestion control, confining the effects ofcongestion to that layer. The delay and variance of control loops can bebound. 6
RINA vs. the current Internet Scalability: Current: Limited due to the fixed number of layers in the architecture RINA: Recursion provides a divide and conquer approach, the way to scalability Security: Current: No systematic approach to security, secure each protocol or add boxes inbetween to improve security (firewalls). RINA: Strong design tells you where security functions go in the architecture (seelater in the presentation). DIFs are securable containers. Quality of Service: Current: Best effort is the dogma, “network neutrality” RINA: Each DIF is free to provide the QoS classes it wants, using different policies forresource allocation, routing and data transfer Management: Current: Complex, reflecting the complexity in the architecture and the highnumber of protocols. RINA: The commonality in the structure simplifies management by orders ofmagnitude, 7
Outline Quick Introduction to RINA Java prototype over IP Inter DIF Directory RINA Security Assessment FP7 IRATI Project: Kernel prototype overEthernet8
RINA Adoption strategy Start as an overlay to IP, validate technology, work on initialconcepts, develop DIF machinery. Useful by itself: internetwork layer(s), decouple application from infrastructure,improved application API, support for multi-homing and mobility.9IPEthernetPhysical MediaApplicationsTodayTCP or UDPIPEthernetPhysical MediaApplicationsCurrent PrototypeTCP or UDPDIFDIF…EthernetPhysical MediaApplicationsDIFDIF…IPPhysical MediaApplicationsTCP or UDPDIFDIF…Physical MediaApplicationsDIFDIF…End goal
RINA over IP benefits: Internetworklayer(s) What if application A wants to communicate with Application C? It cannot do it, unless you start deploying middleboxes like NATs, application-layer gateways,… The architecture doesn’t accommodate internetworking!10Data Link Data Link Data Link Data Link Data LinkIPIP Layer A (Public Internet)IPIP Layer B (EnterpriseNetwork)TCPAppl. A Appl. BData Link Data Link Data Link Data Link Data LinkIPIP Layer A (Public Internet)IPIP Layer B (EnterpriseNetwork)Shim DIFAppl. A Appl. B Appl. CShim DIFDIFTCPAppl. C
RINA over IP benefits: Separateapplications from infrastructure There is no separate application namespace, but synonyms thatstand for an IP address and a TCP/UDP port number: A path to an application. This makes anything but client/server hard to achieve, e.g. mobility In RINA application names are independent of the layers below(DIFs) Application names can be structured in a way that makes sense forthe application The application name doesn’t contain the semantics of where theapplication is in the network (i.e. what is its point of attachment to thelayer below) 11 http://pouzinsociety.orgSynonym of aninterface of a hostPort (Endpoint of TCPconnection):80
RINA over IP benefits: Nextgeneration VPN DIFs are customizable VPNs that can span multiple IP layers. Each DIF has its own addressing scheme, security mechanisms (authentication,authorization), routing strategy, resource allocation strategy (support fordifferent levels of QoS), flow control strategy, data transfer/data transfercontrol, … Processes (and not systems) are members of the DIFs (different processes canaccess different DIFs in each system). Processes may not have access to thewhole range of DIFs available on their system DIFs open the door to VPNs optimized for certain applications12Data Link Data Link Data Link Data Link Data LinkIPIP Layer A (Public Internet)IPIP Layer B (EnterpriseNetwork)Shim DIFAppl. A Appl. B Appl. CShim DIFDIF
Architectural modelDIFSystem (Host)IPCProcessIPCProcessMgmtAgemtSystem(Router)IPCProcessIPCProcessIPCProcessMgmtAgemtSystem(Host)IPCProcessIPCProcessMgmtAgemtAppl.ProcessDIF DIFAppl.ProcessIPC APIData Transfer Data Transfer Control Layer ManagementSDU DelimitingData TransferRelaying andMultiplexingSDU ProtectionTransmissionControlRetransmissionControlFlow ControlRIBDaemonRIBRIB CDAPParser/GeneratorCACEP EnrollmentFlow AllocationResourceAllocationForwarding TableGeneratorAuthenticationStateVectorStateVectorStateVectorData TransferData TransferTransmissionControlTransmissionControlRetransmissionControlRetransmissionControlFlow ControlFlow Control13IPCResourceMgt.Inter DIFDirectorySDUProtectionMultiplexingIPC Mgt. TasksOther Mgt. TasksApplication SpecificTasksIncreasing timescale (functions performed less often) and complexity
The Shim DIF14Public Internet Private IPnetwork“Shim IPCProcess”“Shim IPCProcess”IPCProcess“Shim IPCProcess”IPCProcessIPCProcess“Shim IPCProcess”Shim DIFShim DIFDIFAppl.ProcessAppl.ProcessUDP flow UDP flowTCPflow(s)TCPflow(s) The “shim IPC Process” for IP layers is not a “real IPC Process”. It justpresents an IP layer as if it was a regular DIF. Wraps the IP layer with the DIF interface. Maps the names of the IPC Processes of the layer above to IP addresses in theIP layer. Creates TCP and/or UDP flows based on the QoS requested by an “allocaterequest”.
Implementation platform Implemented as part of the TINOS framework (a networkprotocol experimentation framework) https://github.com/PouzinSociety/tinos Implemented in Java, using the OSGi technology (OSGicontainer provided by Eclipse Virgo) OSGi is a component model that facilitates building modular Javaapplications Developed on Mac OS X and Linux Debian, but should be multi-platform (support all the platforms that Eclipse Virgo supports) Found some OS resource allocation issues with Mac OS X Not yet fully integrated with TINOS (once it is, it will be possible toinstantiate several “systems” within a single Java process, usingXMPP as the underlying “physical substrate”)15
Java Virtual MachineWhy using TINOS instead of raw Java?To facilitate experimentation: bigger scenarios without adding more hardwareIP (Jnode)Data Link Data Link Data LinkShim DIFData Link Data LinkIP (Jnode)Shim DIFDIFJava Virtual MachineIP (Jnode)Data Link Data Link Data LinkShim DIFData Link Data LinkIP (Jnode)Shim DIFDIFJava Virtual MachineData LinkIP (OS stack)Shim DIFJava VirtualMachineData LinkIP (JNode)Shim DIFPublicInternetDataLinkIP(OSstack)ShimDIFDIFXMPP networkLAN With TINOS multiple nodes can be created withinthe same Java JVM, with different networkconnectivity with each other and other JVMs(TINOS uses adapted IP stack from JNode andXMPP for this)
Current status & some conclusions Since all the layers have the same mechanisms with different policies,implementation becomes much simpler than today’s protocolsuite(therefore more effort can be devoted to making it more robust andefficient) Also no need to distinguish between ‘physical’ or ‘virtual’ networking protocols: it’s all IPC. Customization & innovation in networking becomes much easier Just focus on the area you’re interested in and change the relevant policies for yours (NOTE:Today “changing the policies” in the prototype means modifying the code, sincedeveloping a pluggable policy framework is out of the scope of the initial prototype) Interoperability with existing networking technologies is not an issue Just wrap the XX layer as a shim DIF, and there you go 17IPC APIData Transfer Data Transfer Control Layer ManagementSDU DelimitingData TransferRelaying andMultiplexingSDU ProtectionTransmissionControlRetransmissionControlFlow ControlRIBDaemonRIBRIB CDAPParser/GeneratorCACE EnrollmentFlow AllocationResourceAllocationForwarding TableGeneratorAuthenticationStateVectorStateVectorStateVectorData TransferData TransferTransmissionControlTransmissionControlRetransmissionControlRetransmissionControlFlow ControlFlow Control
Outline Quick Introduction to RINA Java prototype over IP Inter DIF Directory RINA Security Assessment FP7 IRATI Project: Kernel prototype overEthernet18
What’s a layer? Although the term “layer” has been extensively used innetworking, the concept itself has not been clearly defined. In its origin layers were adopted from its use in operating systems.But in operating systems, using layers is a choice, whereas usinglayers in networks is a necessity because of the distributedshared state of different scopes The necessary and sufficient condition for a layer is distributedshared state of different scope. Therefore we can describe a layer as the collection ofapplication processes that share state.PhysicalData LinkNetworkTransportApplicationHost or End SystemRouterLessScopeMoreScope19
The InterDIF Directory (IDD) A distributed application, Distributed Application Facility (DAF) asit’s called in RINA, which is a collection of two or morecooperating application processes in one or more processingsystems, which exchange information using IPC and maintainshared state The IDD DAF maintains a distributed database that keepsmappings of application names to list of supporting layers The IDD is responsible for two main distinct functions:a) Discovery of the applicationb) Creation of the supporting DIF21
A) Discovery of the application (I) IDD-Request Destination IDD Name, Source IDD Name, Requested ApplicationProcess Name, Access Control Information, Quality of Service,Termination Condition Forwarding of the request between the peer IDDs until thedestination application is found or the pre-defined terminationcondition is methost H2router R2 router R3host H1web serverapplicationBwebbrowserapplicationArouter R4router R1host H4Layer 6router R5host H3...Layer 1Layer 3Layer 2Layer 4Layer 5IDD DAFweb serverapplicationC22
A) Discovery of the application (II) Confirmation that the requested application is executing inthe destination system and authorization check that therequesting application has the rights to access ithost H2router R2 router R3host H1web serverapplicationBwebbrowserapplicationArouter R4router R1host H4Layer 6router R5host H3...Layer 1Layer 3Layer 2Layer 4Layer 5IDD DAFweb serverapplicationC23
B) Creation of the supporting DIF A DIF supporting the communication between the two userapplications has to be found This either involves creating a new DIF from scratch orexpanding (joining) an existing one so that it spans from thesource to the destination systemhost H2router R2 router R3host H1web serverapplicationBwebbrowserapplicationArouter R4router R1host H4Layer 6router R5host H3...Layer 1Layer 3Layer 2Layer 4Layer 5IDD DAFweb serverapplicationC24
Current status Ph.D. thesis ongoing Defined the IDD Framework. Current research is focused inapplication discovery; looking at different policies to performthe IDD search, the replication of the directory information,and compare them in terms of: Time to discover the requested application Average number of messages generated on the IDD DAF per search Average number of hops needed to locate the destination application Time to distribute directory updates, and average number of messagesgenerated by directory update Java simulator of the IDD is being implemented. After resultshave been tested in the simulator, the IDD framework andsome selected policies will be ported to the prototypes25
Outline Quick Introduction to RINA Java prototype over IP Inter DIF Directory RINA Security Assessment FP7 IRATI Project: Kernel prototype overEthernet26
Benefits of having an architecture instead of a protocol suite: thearchitecture tells you where security related functions are placed. Instead of thinking protocol security, think security of the architecture: nomore ‘each protocol has its own security’, ‘add another protocol forsecurity’ or ‘add another box that does security’Allocating a flow todestination applicationAccess controlSending/receiving PDUsthrough N-1 DIFConfidentiality, integrityPlacement of security related functions27N DIFN-1 DIFIPCProcessIPCProcessIPCProcessIPCProcess Joining a DIFauthentication,access controlSending/receiving PDUsthrough N-1 DIFConfidentiality, integrityAllocating a flow todestination applicationAccess controlIPCProcessAppl.ProcessAccess control(DIF members)Confidentiality, integrityAuthenticationAccess control(Flow allocations to apps)DIF OperationLoggingDIF OperationLogging
DIFs are securable containers Master thesis on RINA security assessment (results to bepublished) Possible attacks to a DIF Information required to perform these attacks Mitigation measures against these attacks Comparison to the current Internet Concludes that DIFs are securable containers if properstandard security tools are used (authentication, accesscontrol, confidentiality, integrity and strong auditing) Securable = A structure used to hold or transport something that can bemade to be not subject to threat Again, with a proper structure in place, achieving bettersecurity in networks is much simpler and cost-effective thanin the current situation28
Outline Quick Introduction to RINA Java prototype over IP Inter DIF Directory RINA Security Assessment FP7 IRATI Project: Kernel prototype overEthernet29
What? Main goal To advance the state of the art of RINA towards an architecture reference model andspecifications that are closer to enable implementations deployable in productionscenarios. The design and implementation of a RINA prototype on top of Ethernet willenable the experimentation and evaluation of RINA in comparison to TCP/IP. Who? 4 partners How? Requested 870.000 € funding to the EC to perform 5 activities WP1: Project management WP2: Architecture, Use cases and Requirements WP3: Software Design and Implementation WP4: Deployment into OFELIA testbed, Experimentation and Validation WP5: Dissemination, Standardisation and ExploitationProject at a glanceNextworksInteroutei2CATIBBT
Thanks for your attention!You can contact me firstname.lastname@example.orgMore information about RINA at http://rina.tssg.org,http://pouzinsociety.org, http://csr.bu.edu/rinaMore information about the prototype athttps://github.com/PouzinSociety/tinos/wiki/RINA-PrototypeMore information about IRATI athttp://irati.eu