#ict-pristine

RINA: Recursive InterNetwork Architecture Last advances from the PRISTINE project

Leonardo Bergesio <leonardo.bergesio@i2cat.net> on behalf of The PRISTINE consortium

RINA INTRODUCTION

2

1

#ict-pristine

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

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

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

Internal layer organization

6 #ict-pristine

IRATI: OPEN SOURCE RINA IMPLEMENTATION

7

2

• … 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

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

High-level software arch.

10

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

po

lic

y

Tx

ctr

l

po

lic

y

EC

N

po

lic

y

. . .

SDK support

Fo

rwa

r p

oli

cy

Sc

he

du

p

oli

cy

Ma

x Q

p

oli

cy

Mo

nit

p

oli

cy

SDK support

TTL

p

oli

cy

CR

C

po

lic

y

En

cry

p

po

lic

y

Normal IPC Process (Layer Management)

RIB & RIB Daemon

librina

Resource allocation

Flow allocation

Enrollment

Namespace

Management

Security Management

Routing

SDK support

Au

th.

po

lic

y

Ac

c. c

trl

po

lic

y

Co

ord

p

oli

cy

SDK support

Ad

dre

ss

a

ss

ign

Dir

ec

tory

re

pli

ca

Ad

dre

ss

v

ali

da

t

SDK support

New flow policy

SDK support

PF

T g

en

p

oli

cy

Pu

sh

ba

k

no

tify

SDK support

Enroll. sequenc

e SDK support

Routing policy IPC Manager

RIB & RIB Daemon

librina

Management agent

(NMS DAF) IPCM logic

Network Manager

(NMS DAF)

#ict-pristine

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

Open source IRATI

13

• IRATI github side • http://irati.github.io/stack

• Hosts code, docs, issues • Installation guide

• Experimenters (tutorials)

• Developers (software arch)

• Mailing list for users and developers • irati@freelists.org

• Procedures to contribute under discussion, doc ongoing

#ict-pristine

RINASIM: RINA SIMULATOR

14

3

RINASim

● RINASim is independent framework implemented for OMNeT++

● Source code is publicly available on github (https://github.com/kvetak/RINA)

● 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

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

SOME ONGOING WORK AND RESULTS

17

4

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

Experimental results (prototype)

IRATI objectives, outcomes and lessons learned 22 Experimental scenario

Host to VM communication

VM to VM communication

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

RMT

RA

EFCP

Some DIFs

N-DIF

Sender Receiver

RMT

RA

RMT

RA

EFCP

RMT

RA

EFCP

RMT

RA

RMT

RA

EFCP

RMT

RA

EFCP

RMT

RA

EFCP … …

#ict-pristine

Congestion control (II): simulations

• Horizontal: consecutive DIFs

• Vertical: stacked DIFs

24

S1

R1

Router1

TCP Contro

l Loop

Split-TCP

Control Loops

S1

Sn

R1

Rn

Router1 Router2

…

…

n = 5, 10, 15 n = 1

File transmission start/finish times for File 1: 20MB, File 2: 500KB

#ict-pristine

• 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

File transmission start/finish times for File 1: 20MB, File 2: 500KB

#ict-pristine

TCP

RINA with RED PS

RINA with Jain PS

Experiment setup

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

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 DIF P2P DIF

Customer network Provider 1 network Provider 2 network

IPCP A

IPCP B

IPCP C

P2P DIF P2P DIF

IPCP D

Example: AuthPassword policy (implemented in prototype)

28

IPCP A

IPCP B

Target of application connection

Initiator of application connection

1

M_CONNECT AuthPolicy.name = 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

IPCP A

IPCP B

Target of application connection

Initiator of application connection

1

M_CONNECT AuthPolicy.name = 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)

FINAL REMARKS

30

5

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

Further information can be found here. Twitter @ictpristine www www.ict-pristine.eu

<Thank you!>