PRISTINE RINA security presentation for IEEE ICC 2016

1. 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

2. WHAT IS RINA?1
2

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
3

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

5. … to the RINA architecture
Single type of layer, consistent API, programmable policies
Host
Border router Interior Router
DIF
DIF DIF
Border router
DIF
DIF
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
StateVector
StateVector
StateVector
Data TransferData Transfer
Retransmission
Control
Retransmission
Control
Flow Control
Flow Control
Increasing timescale (functions performed less often) and complexity
Namespace
Management
Security
Management
5

6. 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

7. PROPERTIES OF RINA DESIGN
CONTRIBUTING TO SECURITY
2
7

8. 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’
Operating on the
IPCP’s RIB
Access control
Sending/receiving PDUs
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 PDUs
through 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 control
Operations on RIB
DIF Operation
Logging
DIF Operation
Logging

9. Separation of mechanism from policy
9
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
StateVector
StateVector
StateVector
Data TransferData Transfer
Retransmission
Control
Retransmission
Control
Flow Control
Flow 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 policy
10
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
StateVector
StateVector
StateVector
Data TransferData Transfer
Retransmission
Control
Retransmission
Control
Flow Control
Flow 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 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
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
12
IPCPP
A
App
A
Port-id
read/
write
1
EFCP instance,
cep-id
8736
IPCPP
A
App
B
Port-id
read/
write
4
EFCP instance,
cep-id
9123
Synchronization
• 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/IP
IP@:
12
Port
read/
write 12
TCP instance,
port
12
IP @:
78
Port
read/
write
78
TCP instance,
port
78
TCP PM
A
TCP PM
A

13. DESIGN AND EXPERIMENTATION
WITH SECURITY POLICIES3
13

14. Customer network
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 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).
Border
Router
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
15

16. Authentication policy: SSH2-based (II)
16

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
17
12
IPCPP
A
IPCPP
A
N-1 flow
SDU
Protection
SDU
Protectioncounter Encrypted data HMAC

18. Experimentation with IRATI
18
Provider Border
Router 1
Provider Border
Router 2
Customer Border
Router
Shim DIF over Eth Shim DIF over Eth
IPCP
A
IPCP
B
access.DIF IPCP
C
IPCP
D
regional.DIF
IPCP
E
IPCP
F
IPCP
G
multi-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 INITIATIVES
4
19

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
20