RINA: Update on research and prototyping activities. Global Future Internet Week 2012

RINA: Update on Research and Prototyping Activities

RINA: Update on Research and Prototyping Activities

Global Future Internet SummitSeptember 14th, 2012

Global Future Internet SummitSeptember 14th, 2012

Eduard GrasaResearch Manager @ DANA

Fundació i2CAT

Eduard GrasaResearch Manager @ DANA

Fundació i2CAT

Before we start… our perspective

What is the “Future Internet”? We don’t know, we’re just interested in building better computer

networks and 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 mistakes of 40+ years of computer networking. If we were starting with “no assumptions” we would not be learning from the past (“Those who don’t know history are destined to repeat it”)

What are the design goals of RINA? No design goals, we just look at solving the problem of computer

networking and try to maximize the invariances and minimize the discontinuities. All the results 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 to join us?

2* Not so new to be honest, initial computer network research (CYCLADES, INWG) was headed in this direction

Outline

Quick Introduction to RINA

Java prototype over IP

Inter DIF Directory

RINA Security Assessment

FP7 IRATI Project: Kernel prototype over Ethernet

3

RINA Architecture

4

• A structure of recursive layers that provide IPC (Inter Process Communication) services to applications on top

• There’s a single type of layer that repeats as many times as required by the network designer

• Separation of mechanism from policy

• All layers have the same functions, with different scope and range.– Not all instances of layers may need all functions, but don’t need more.

• A Layer is a Distributed Application that performs and manages IPC.– A Distributed IPC Facility (DIF)

• This yields a theory and an architecture that scales indefinitely, – i.e. any bounds imposed are not a property of the architecture itself.© John Day, All Rights Reserved, 2011

Naming and addressing in RINA All application processes

(including IPC processes) have a name that uniquely identifies them within the application process namespace.

In order to facilitate its operation within a DIF, each IPC process within a DIF gets a synonym that may have be structured to facilitate 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 a destination 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+1 is an application and the process at the layer N-1 is a Point of Attachment.

1 2 3 4

1 2 1 2 3 1 2

1 21 2

DIF A

DIF B

DIF C DIF

D

DIF 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 address space.

Congestion control: Current: Put in TCP, the worst place it could be, since it maximizes the delay and

variance of the control loop (makes the system chaotic: self-similar traffic) RINA: Each layer can perform congestion control, confining the effects of

congestion to that layer. The delay and variance of control loops can be bound.

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 in

between to improve security (firewalls). RINA: Strong design tells you where security functions go in the architecture (see

later 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 for

resource allocation, routing and data transfer

Management: Current: Complex, reflecting the complexity in the architecture and the high number

of protocols. RINA: The commonality in the structure simplifies management by orders of

magnitude,

7

Outline



Inter DIF Directory



8

RINA Adoption strategy

Start as an overlay to IP, validate technology, work on initial concepts, develop DIF machinery. Useful by itself: internetwork layer(s), decouple application from

infrastructure, improved application API, support for multi-homing and mobility.

9

IP

EthernetPhysical Media

Applications

Today

TCP or UDP

IP


Applications

Current Prototype

TCP or UDP

DIF

DIF…


Applications

DIF

DIF…

IP

Physical Media

Applications

TCP or UDP

DIF

DIF…

Physical Media

Applications

DIF

DIF…

End goal

RINA over IP benefits: Internetwork layer(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!

10

Data Link Data Link Data Link Data Link Data Link

IP

IP Layer A (Public Internet)

IP

IP Layer B (Enterprise Network)

TCP

Appl. A Appl. B


IP


IP


Shim DIF

Appl. A Appl. B Appl. C

Shim DIF

DIF

TCP

Appl. C

RINA over IP benefits: Separate applications from infrastructure

There is no separate application namespace, but synonyms that stand 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 for

the application The application name doesn’t contain the semantics of where the

application is in the network (i.e. what is its point of attachment to the layer below) 11

http://pouzinsociety.org

Synonym of an interface of a host

Port (Endpoint of TCP connection)

:80

RINA over IP benefits: Next generation 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 for different levels of QoS), flow control strategy, data transfer/data transfer control, …

Processes (and not systems) are members of the DIFs (different processes can access different DIFs in each system). Processes may not have access to the whole range of DIFs available on their system

DIFs open the door to VPNs optimized for certain applications

12


IP


IP


Shim DIF

Appl. A Appl. B Appl. C

Shim DIF

DIF

Architectural model

DIF

System (Host)

IPC Process

IPC Process

MgmtAgemt

System(Router)

IPC Process

IPC Process

IPC Process

MgmtAgemt

System(Host)

IPC Process

IPC Process

MgmtAgemt

Appl. Process

DIF DIF

Appl. Process

IPC API

Data Transfer Data Transfer Control

Layer Management

SDU Delimiting

Data Transfer

Relaying and Multiplexing

SDU Protection

Transmission Control

Retransmission Control

Flow Control

RIB Daemon

RIBRIBCDAP

Parser/Generator

CACEP Enrollment

Flow Allocation

Resource Allocation

Forwarding Table

Generator

Authentication

Sta

te

Vecto

rS

tate

V

ecto

rS

tate

V

ecto

r

Data Transfer Data Transfer





Flow ControlFlow Control

13

IPC Resource Mgt.Inter DIF

Directory

SDU Protection

Multiplexing

IPC Mgt. Tasks

Other Mgt. Tasks

Application Specific Tasks

Increasing timescale (functions performed less often) and complexity

The Shim DIF

14

Public Internet

Private IP network

“Shim IPC Process”


IPC Process


IPC Process

IPC Process


Shim DIFShim DIF

DIF

Appl. Process

Appl. Process

UDP flow UDP flow

TCP flow(s)

TCP flow(s)

The “shim IPC Process” for IP layers is not a “real IPC Process”. It just presents 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 the IP layer. Creates TCP and/or UDP flows based on the QoS requested by an “allocate request”.

Implementation platform

Implemented as part of the TINOS framework (a network protocol experimentation framework) https://github.com/PouzinSociety/tinos

Implemented in Java, using the OSGi technology (OSGi container provided by Eclipse Virgo) OSGi is a component model that facilitates building modular Java applications

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 to instantiate several “systems” within a single Java process, using XMPP as the underlying “physical substrate”)

15

https://github.com/PouzinSociety/tinos

Java Virtual Machine

Why using TINOS instead of raw Java?To facilitate experimentation: bigger scenarios without adding more

hardware

IP (Jnode)

Data LinkData Link

Data Link

Shim DIF

Data Link

Data Link

IP (Jnode)

Shim DIF

DIF


IP (Jnode)

Data LinkData Link

Data Link

Shim DIF

Data Link

Data Link

IP (Jnode)

Shim DIF

DIF


Data LinkIP (OS stack)Shim DIF


Data Link

IP (JNode)

Shim DIF

Publ

ic

Inte

rnet

Dat

a Li

nk

IP (OS

stac

k)

Shi

m D

IF

DIF

XMPP network

LAN

With TINOS multiple nodes can be created within the same Java JVM, with different network connectivity with each other and other JVMs (TINOS uses adapted IP stack from JNode and XMPP for this)

Current status & some conclusions

Since all the layers have the same mechanisms with different policies, implementation becomes much simpler than today’s protocol suite(therefore more effort can be devoted to making it more robust and efficient) 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, since developing 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

17

IPC API

Data Transfer Data Transfer Control

Layer Management

SDU Delimiting

Data Transfer

Relaying and Multiplexing

SDU Protection



Flow Control

RIB Daemon

RIBRIBCDAP

Parser/Generator

CACE Enrollment

Flow Allocation

Resource Allocation

Forwarding Table

Generator

Authentication

Sta

te

Vecto

rS

tate

V

ecto

rS

tate

V

ecto

r

Data Transfer Data Transfer





Flow ControlFlow Control

Outline



Inter DIF Directory



18

What’s a layer? Although the term “layer” has been extensively used in

networking, 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 using layers in networks is a necessity because of the distributed shared state of different scopes

The necessary and sufficient condition for a layer is distributed shared state of different scope.

Therefore we can describe a layer as the collection of application processes that share state.

Physical

Data Link

Network

Transport

Application

Host or End System

Router

LessScope

MoreScope

19

Application discovery involves also layer discovery

host H2

router R2 router R3

host H1

Layer 1

web serverapplication

B

web browser

application A

router R4

router R1

host H4

Layer 3

Layer 2

Layer 4

Layer 6

Layer 5

router R5

host H3


C

20

The InterDIF Directory (IDD)

A distributed application, Distributed Application Facility (DAF) as it’s called in RINA, which is a collection of two or more cooperating application processes in one or more processing systems, which exchange information using IPC and maintain shared state

The IDD DAF maintains a distributed database that keeps mappings 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 DIF

21

A)

Discovery of the application (I)

IDD-Request Destination IDD Name, Source IDD Name, Requested Application

Process Name, Access Control Information, Quality of Service, Termination Condition

Forwarding of the request between the peer IDDs until the destination application is found or the pre-defined termination condition is met

host H2

router R2 router R3

host H1


B

web browser

application A

router R4

router R1

host H4

Layer 6

router R5

host H3

...

Layer 1

Layer 3

Layer 2

Layer 4Layer 5

IDD DAF


C

22

A)

Discovery of the application (II)

Confirmation that the requested application is executing in the destination system and authorization check that the requesting application has the rights to access it

host H2

router R2 router R3

host H1


B

web browser

application A

router R4

router R1

host H4

Layer 6

router R5

host H3

...

Layer 1

Layer 3

Layer 2

Layer 4Layer 5

IDD DAF


C

23

B) Creation of the supporting DIF

A DIF supporting the communication between the two user applications has to be found

This either involves creating a new DIF from scratch or expanding (joining) an existing one so that it spans from the source to the destination system

host H2

router R2 router R3

host H1


B

web browser

application A

router R4

router R1

host H4

Layer 6

router R5

host H3

...

Layer 1

Layer 3

Layer 2

Layer 4Layer 5

IDD DAF


C

24

Current status

Ph.D. thesis ongoing

Defined the IDD Framework. Current research is focused in application discovery; looking at different policies to perform the 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

messages generated by directory update

Java simulator of the IDD is being implemented. After results have been tested in the simulator, the IDD framework and some selected policies will be ported to the prototypes

25

Outline



Inter DIF Directory



26

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, 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’

Allocating a flow to destination application

Access control

Sending/receiving PDUs

through N-1 DIFConfidentiality,

integrity

Placement of security related functions

27

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 DIFConfidentiality,

integrity

Allocating a flow to destination application

Access control

IPC Process

Appl. Process

Access control(DIF members)

Confidentiality, integrity

Authentication

Access control(Flow allocations to

apps)

DIF OperationLogging

DIF OperationLogging

DIFs are securable containers

Master thesis on RINA security assessment (results to be published) 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 proper standard security tools are used (authentication, access control, confidentiality, integrity and strong auditing) Securable = A structure used to hold or transport something that can

be made to be not subject to threat

Again, with a proper structure in place, achieving better security in networks is much simpler and cost-effective than in the current situation

28

Outline



Inter DIF Directory



29

What? Main goal To advance the state of the art of RINA towards an architecture reference

model and specifications that are closer to enable implementations deployable in production scenarios. The design and implementation of a RINA prototype on top of Ethernet will enable 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 Exploitation

Project at a glance

Nextworks

Interoute

i2CAT

IBBT

Thanks for your attention!

You can contact me [email protected]

More information about RINA at http://rina.tssg.org, http://pouzinsociety.org, http://csr.bu.edu/rina

More information about the prototype at https://github.com/PouzinSociety/tinos/wiki/RINA-Prototype

More information about IRATI at http://irati.eu

http://rina.tssg.org/

http://pouzinsociety.org/

http://csr.bu.edu/rina

https://github.com/PouzinSociety/tinos/wiki/RINA-Prototype

http://irati.eu/

Technology

RINA: Update on research and prototyping activities. Global Future Internet Week 2012