From protecting protocols to layers: designing ...€¦ · layers: designing, implementing and experimenting with security policies in RINA Eduard Grasa (presenter), Ondrej Lichtner,

From protecting protocols to layers: security policies in RINA

From protecting protocols to layers: designing, implementing and experimenting with security

policies in RINA

Eduard Grasa (presenter), Ondrej Lichtner, Ondrej Rysavy, Hamid Asgari, John Day, Lou Chitkushev

FP7 PRISTINE ICC 2016, Kuala Lumpur, May 24th 2016

WHATISRINA?1

2

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

3

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) (Prac.ce)

4

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

Host

Borderrouter InteriorRouter

DIF

DIF DIF

Borderrouter

DIFDIF

DIF(DistributedIPCFacility)

Host

AppA

AppB

ConsistentAPIthrough

layers

IPCAPI

DataTransfer DataTransferControl LayerManagement

SDUDelimiNng

DataTransfer

RelayingandMulNplexing

SDUProtecNon

RetransmissionControl

FlowControl

RIBDaemon

RIB

CDAPParser/Generator

CACEP

Enrollment

FlowAllocaNon

ResourceAllocaNon

RouNng

AuthenNcaNon

StateVectorStateVectorStateVector

DataTransferDataTransfer



FlowControlFlowControl

IncreasingNmescale(funcNonsperformedlessoUen)andcomplexity

NamespaceManagement

SecurityManagement

5

Deployment Clean-slate concepts but incremental deployment

Large-scale RINA Experimentation on FIRE+ 6

•  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

PROPERTIESOFRINADESIGNCONTRIBUTINGTOSECURITY2

7

Protecting layers instead of protocols All layers have the same consistent, security model

8

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

OperaNngontheIPCP’sRIB

Accesscontrol

Sending/receivingPDUsthroughN-1DIF

Confiden.ality,integrity

NDIF

N-1DIF

IPCProcess

IPCProcess

IPCProcess

IPCProcess JoiningaDIF

authen.ca.on,accesscontrol

Sending/receivingPDUsthroughN-1DIF


OperaNngontheIPCP’sRIB

Accesscontrol

IPCProcess

Appl.Process

Accesscontrol(DIFmembers)


Authen.ca.on

AccesscontrolOpera.onsonRIB

DIFOperaNonLogging

DIFOperaNonLogging

Separation of mechanism from policy

9

IPCAPI


SDUDelimiNng

DataTransfer


SDUProtecNon


FlowControl

RIBDaemon

RIB


CACEP

Enrollment

FlowAllocaNon

ResourceAllocaNon

RouNng

AuthenNcaNon






NamespaceManagement

SecurityManagement

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

Authen.ca.on

Accesscontrol(layermgmtopera.ons)

Accesscontrol(joiningtheDIF)

Coordina.onofsecurityfunc.ons

Confiden.ality,Integrity

Separation of mechanism from policy

10

IPCAPI


SDUDelimiNng

DataTransfer


SDUProtecNon


FlowControl

RIBDaemon

RIB


CACEP

Enrollment

FlowAllocaNon

ResourceAllocaNon

RouNng

AuthenNcaNon






NamespaceManagement

SecurityManagement

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

Authen.ca.on

Accesscontrol(layermgmtopera.ons)

Accesscontrol(joiningtheDIF)

Coordina.onofsecurityfunc.ons

Confiden.ality,Integrity

Source:J.Smallmasterthesis

Scope as a native construct Recursion 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

11

Internet(TCP/IP) RINA

Defaultmodel Globalconnec.vity Controlledconnec.vity

Controlscopevia Firewalls,ACLs,VLANs,VirtualPrivateNetworks,etc..

Scopena.veconceptinarchitecture(DIF)

Example:Provider’snetworkinternallayershiddenfromcustomersandotherproviders

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

12

IPCPPA

AppA

Port-id

read/write 1

EFCPinstance,cep-id

8736

IPCPPA

AppB

Port-id

read/write

4

EFCPinstance,cep-id

9123

SynchronizaBon

•  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

TCPinstance,port

12

IP@:78

Portread/write

78

TCPinstance,port

78

TCPPMA

TCPPMA

DESIGNANDEXPERIMENTATIONWITHSECURITYPOLICIES3

13

Customernetwork

InteriorRouter

CustomerBorderRouter

InteriorRouter Border

Router

P2P DIF

InteriorRouter

P2P DIF

BorderRouter

P2P DIF P2P DIF

InteriorRouter

BorderRouter

Provider1BackboneDIF

P2P DIF

BorderRouter

Provider1RegionalDIF

MulN-providerDIF

P2P DIF

AccessDIF

P2P DIF P2P DIF

Provider1network

Provider2network

IPCPA

IPCPB

IPCPC

P2P DIF P2P DIF

IPCPD

•  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

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

15

Authentication policy: SSH2-based (II)

16

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

17

12

IPCPPA

IPCPPA

N-1flow

SDUProtecBon

SDUProtecBoncounter Encrypteddata HMAC

Experimentation with IRATI

18

ProviderBorderRouter1

ProviderBorderRouter2

CustomerBorderRouter

ShimDIFoverEth ShimDIFoverEth

IPCPA

IPCPB

access.DIF IPCPC

IPCPD

regional.DIF

IPCPE

IPCPF

IPCPG

mulB-provider.DIF

Customernetwork

Providernetwork

Experimentalscenario

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

•  Implemented plugins with authSSH2 auth. and SDU protection policies

ONGOINGRINAINITIATIVES4

19

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

20

Documents

From protecting protocols to layers: designing ...€¦ · layers: designing, implementing and experimenting with security policies in RINA Eduard Grasa (presenter), Ondrej Lichtner,