pristine rina-security-icc-2016
TRANSCRIPT
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