From protecting protocols to layers: security policies in RINA

From protecting protocols to layers: designing,

implementing and experimenting with security

policies in RINAEduard Grasa (presenter), Ondrej Lichtner, Ondrej Rysavy,

Hamid Asgari, John Day, Lou ChitkushevFP7 PRISTINE

ICC 2016, Kuala Lumpur, May 24th 2016

2

WHAT IS RINA?1

3

RINA highlights• 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: instances or communication (flows) 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

1

2

3

4

5

6

4

From the “TCP/IP” protocol suite …

• Functional layers organized for modularity, each layer provides a different service to each other– As the RM is applied to the real world, it proofs to be

incomplete. As a consequence, new layers are patched into the reference model as needed (layers 2.5, VLANs, VPNs, virtual network overlays, tunnels, MAC-in-MAC, etc.)

(Theory) (Practice)

5

… to the RINA architectureSingle type of layer, consistent API, programmable policies

Host

Border router Interior Router

DIF

DIF DIF

Border router

DIFDIF

DIF (Distributed IPC Facility)

Host

App A

App B

Consistent API through

layers

IPC API

Data Transfer Data Transfer Control Layer Management

SDU Delimiting

Data Transfer

Relaying and Multiplexing

SDU Protection

Retransmission Control

Flow Control

RIB Daemon

RIB

CDAP Parser/Generator

CACEP

Enrollment

Flow Allocation

Resource Allocation

Routing

Authentication

State VectorState VectorState Vector

Data Transfer Data Transfer

Retransmission Control

Retransmission Control

Flow ControlFlow Control

Increasing timescale (functions performed less often) and complexity

Namespace Management

Security Management

Large-scale RINA Experimentation on FIRE+ 6

DeploymentClean-slate concepts but incremental deployment

• IPv6 brings very small improvements to IPv4, but requires a clean slate deployment (not compatible to IPv4)

• RINA can be deployed incrementally where it has the right incentives, and interoperate with current technologies (IP, Ethernet, MPLS, etc.)– Over IP (just like any overlay such as VXLAN, NVGRE, GTP-U, etc.)– Below IP (just like any underlay such as MPLS or MAC-in-MAC)– Next to IP (gateways/protocol translation such as IPv6)

IP Network

RINA Provider

RINA Network

Sockets ApplicationsRINA supported Applications

IP or Ethernet or MPLS, etc

7

PROPERTIES OF RINA DESIGN CONTRIBUTING TO SECURITY2

8

Protecting layers instead of protocolsAll layers have the same consistent, security model• 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 (BGPsec, DNSsec, IPsec, TLS, etc.),

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’

Operating on the IPCP’s RIB

Access control

Sending/receiving PDUsthrough 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 PDUsthrough N-1 DIF

Confidentiality, integrity

Operating on the IPCP’s RIB

Access control

IPC Process

Appl. Process

Access control(DIF members)

Confidentiality, integrity

Authentication

Access controlOperations on RIB

DIF OperationLogging

DIF OperationLogging

9

Separation of mechanism from policyIPC API

Data Transfer Data Transfer Control Layer Management

SDU Delimiting

Data Transfer

Relaying and Multiplexing

SDU Protection

Retransmission Control

Flow Control

RIB Daemon

RIB

CDAP Parser/Generator

CACEP

Enrollment

Flow Allocation

Resource Allocation

Routing

Authentication

State VectorState VectorState Vector

Data Transfer Data Transfer

Retransmission Control

Retransmission Control

Flow ControlFlow Control

Namespace Management

Security Management

• All layers have the same mechanisms and 2 protocols (EFCP for data transfer, CDAP for layer management), programmable via policies.

• Don’t specify/implement security protocols, only security policies– Re-use common layer structure, re-use security policies across layers

• This approach greatly simplifies the network structure, minimizing the cost of security and improving the security level– Complexity is the worst enemy of security (B. Schneier)

Authentication

Access control (layer mgmt operations)

Access control (joining the DIF)

Coordination of security functions

Confidentiality, Integrity

10

Separation of mechanism from policyIPC API

Data Transfer Data Transfer Control Layer Management

SDU Delimiting

Data Transfer

Relaying and Multiplexing

SDU Protection

Retransmission Control

Flow Control

RIB Daemon

RIB

CDAP Parser/Generator

CACEP

Enrollment

Flow Allocation

Resource Allocation

Routing

Authentication

State VectorState VectorState Vector

Data Transfer Data Transfer

Retransmission Control

Retransmission Control

Flow ControlFlow Control

Namespace Management

Security Management

• All layers have the same mechanisms and 2 protocols (EFCP for data transfer, CDAP for layer management), programmable via policies.

• Don’t specify/implement security protocols, only security policies– Re-use common layer structure, re-use security policies across layers

• This approach greatly simplifies the network structure, minimizing the cost of security and improving the security level– Complexity is the worst enemy of security (B. Schneier)

Authentication

Access control (layer mgmt operations)

Access control (joining the DIF)

Coordination of security functions

Confidentiality, Integrity

Source: J. Small master thesis

11

Scope as a native constructRecursion provides isolation

• Size each DIF to the scope supported applications need– Only allow those that really need to connect to the apps

• No need for extra tools to do that: scope is built-in– DIFs are securable containers, no need for firewalls

Internet (TCP/IP) RINA

Default model Global connectivity Controlled connectivity

Control scope via Firewalls, ACLs, VLANs, Virtual Private Networks, etc..

Scope native concept in architecture (DIF)

Example: Provider’s network internal layers hidden from customers

and other providers

12

Separating port allocation from sync.Complete application naming

• With app-names no need for well-known ports. Port-ids of local scope (not in protocol headers)

• CEP-ids (in protocol headers) dynamically generated for each flow

IPCPP A

App A

Port-idread/write 1

EFCP instance,cep-id

8736

IPCPP A

App B

Port-id

read/write

4

EFCP instance,cep-id

9123Synchronization

• Well-known ports used to identify app endpoints; statically assigned. @s exposed to apps.

• Ports used also to identify TCP instances (in protocol headers). Attacker only needs to guess source port-id

RINA TCP/IPIP@:12

Portread/write 12

TCP instance,port

12

IP @: 78

Portread/write

78

TCP instance,port

78

TCP PMA

TCP PMA

13

DESIGN AND EXPERIMENTATION WITH SECURITY POLICIES3

Customer network

InteriorRouter

CustomerBorderRouter

InteriorRouter Border

Router

P2P DIF

InteriorRouter

P2P DIF

BorderRouter

P2P DIF P2P DIF

InteriorRouter

BorderRouter

Provider 1 Backbone DIF

P2P DIF

BorderRouter

Provider 1 Regional DIF

Multi-provider DIF

P2P DIF

Access DIF

P2P DIFP2P DIF

Provider 1 network

Provider 2 network

IPCP A

IPCP B

IPCP C

P2P DIF P2P DIF

IPCP D

• DIFs are securable containers, strength of authentication and SDU Protection policies depends on its operational environment• DIFs shared between provider/customer (blue DIF) may require strong

authentication and encryption, specially if operating over wireless (red DIF)• DIFs internal to a provider may do with no auth.: accessing the DIF

requires physically compromising the provider’s assets (green and orange DIFs).

BorderRouter

Authentication and SDU protection policies

15

Authentication policy: SSH2-based (I)

• Once applications (including IPCPs) have a flow allocated, go through application connection establishment phase– Negotiate app protocol (CDAP) version, RIB version, authenticate

• Specified authentication policy based on SSH2 authentication (uses per IPCP public/private RSA key pairs), adapted to the RINA environment

16

Authentication policy: SSH2-based (II)

17

Crypto SDU protection policy

• Crypto policy that encrypts/decrypts PCI and payload of EFCP PDUs– In general SDU protection is used by a DIF to protect its own data

(PCIs of data transfer PDUs and full layer management PDUs)

• Not assuming N-1 DIF will provide reliable and in-order-delivery -> using counter mode (as in IPsec)– AES128 and AES256 as supported encryption algorithms

• HMAC code to protect integrity of PDU– SHA256 chosen as hash algorithm

12IPCPP

AIPCPP

AN-1 flow

SDU Protection

SDU Protectioncounter Encrypted data HMAC

18

Experimentation with IRATI

Provider Border Router 1

Provider Border Router 2

Customer Border Router

Shim DIF over Eth Shim DIF over Eth

IPCPA

IPCPB

access.DIF IPCPC

IPCPDregional.DIF

IPCPE

IPCPF

IPCPGmulti-provider.DIF

Customer network

Provider network

Experimental scenario

• IRATI is an open source, programmable implementation of RINA for Linux, written in C/C++

• Implemented plugins with authSSH2 auth. and SDU protection policies

19

ONGOING RINA INITIATIVES4

20

Research, open source, standards• Current research projects

– FP7 PRISTINE (2014-2016) http://ict-pristine-eu – H2020 ARCFIRE (2016-2017) http://ict-arcfire.eu – Norwegian project OCARINA(2016-2021)– BU RINA team http://csr.bu.edu/rina

• Open source implementations– IRATI (Linux OS, C/C++, kernel components, policy framework, RINA over

X) http://github.com/irati/stack – RINASim (RINA simulator, OMNeT++) – ProtoRINA (Java, RINA over UDP, quick prototyping)

• Key RINA standardization activities– Pouzin Society (experimental specs) http://pouzinsociety.org – ISO SC6 WG7 (2 new projects: Future Network – Architectures, Future

Network- Protocols)– ETSI Next Generation Protocols ISG

1

2

3

4

1

2

3

1

2

3