Why is Internet security so brittle? Shortcomings in the structure of the current Internet protocol suite make networks built to the TCP/IP architecture very complex and difficult to secure. The lack of a structured approach towards design causes a proliferation of protocols, each of which has to be individually protected. Unexpected interactions between the ever-increasing protocol-base, inefficiency in the number of repeated security mechanisms, a flat network layer and exposing addresses to applications make the Internet virtually impossible to secure at an affordable cost.

  • Most protocols come with their own security model. The TCP/IP protocol suite security model is usually based on building security functions for each protocol. For example, DNSSEC provides data integrity and authentication to security-aware resolvers. IPsec is a general framework for secure IP communications, supporting confidentiality, integrity, authentication or protection against replay attacks. However since IPsec works end-to-end within a layer, it either only protects the IP payload (transport mode) or makes IP connection-oriented (tunnel mode), encapsulating a protected IP packet into an unprotected IP packet. This makes IPsec a partial solution, not addressing the requirements of IP control plane protocols, which need to define their own security functions, such as OSPF or BGP. TLS, the Transport Layer Security Protocol, specifies a set of related security functions to enable secure communications over the transport layer. All in all, this approach results in a high overhead and unbounded complexity, since new protocols will in many cases require its companion security protocols.
  • Coupled port allocation and synchronizations functions. Use of well-known ports. Transport layer protocols overloads the port-id to be both a local handle (socket) and the connection-endpoint-id (cep-id). Furthermore the lack of application names overloads port-ids with application semantics: application endpoints are identified by a combination of IP address and a well-known port-id that is assigned when the application binds to an IP layer. Static destination port-id values have to be known by the source application when requesting a transport connection. Therefore an attacker wanting to intercept a particular transport connection only needs to guess/spoof the source port-id.
  • No application names: network addresses exposed to applications. Since the TCP/IP protocol suite does not have application names (DNS is an external directory), IP layers expose addresses to applications. This disclosure of information facilitates spoofing of IP addresses, and in combination with the use of common monitoring tools such as traceroute or ping allows attackers on end hosts to learn about the addresses of potential targets in a layer as well as the network connectivity graph. Attackers can use this information to setup DDoS attacks by automating the discovery and infection of vulnerable machines, or to attack the network infrastructure by gaining control over routers.

What about RINA networks? RINA provides an architectural framework with a well-defined building block – the DIF – that recurses as many times as required. Security functions belong to the DIF, not to individual protocols within the DIF. Interactions and the trust model between DIFs are well understood, allowing network architects to reason about the security of a network, understand the threads it is exposed to and design the policies that are more adequate to protect its DIFs.

  • Secure layers instead of individual protocols. RINA provides a consistent security model across layers, DIFs are securable containers, they can be not subject to thread providing the appropriate authentication, access control and SDU protection policies are put in place. In RINA, the unit of protection is the DIF and not its individual protocols. The functional decomposition of a DIF naturally defines the placement of security functions and places the trust boundaries between and within DIF. IPC Processes authenticate each other when joining a DIF, negotiating any keying material and other information required to configure SDU protection policies for a particular N-1 flow (encryption, message integrity verification). Access control is also performed when joining a DIF and when operating on the RIB of a remote IPCP. If the N-1 DIF is not trusted, data will be protected with the aforementioned SDU protection policies before being sent through it. Authentication, access control and SDU protection are policies that can be plugged into any layer – regardless of its ranking and requirements – thus minimising the cost of specifying and implementing security policies compared to the per-protocol security model of the current Internet.
  • Decouple port allocation from synchronisation. Each DIF allocates flows based on a destination application name, which is internally resolved to an IPC Process address. When the flow is allocated, the requesting application gets a (OS) local identifier as a local handle to the flow: the port-id. As opposed to the current Internet, port-ids are dynamically generated and of local significance only, `thus well-known port scanning is not an effective attack for a DIF. Moreover, the transport state associated to the flow is managed by instances of the EFCP protocol, which have their own separate identifiers (connection-endpoint ids or CEP-ids) locally mapped to port-ids. CEP-ids are also dynamically generated at flow allocation time.
  • Addresses are internal to each layer. IPC Process addresses are internal to a DIF and never divulged outside of it. All a user application knows about a DIF is its name and the QoS classes it supports. Therefore an application using a DIF cannot address any member of the DIF unless it joins it. If this risk/thread exists, the DIF designer will have configured the DIF to use authentication and access control, therefore a potential attacker needs to circumvent these security controls before being able to communicate to any IPC Process in that DIF. RINA provides a more controlled environment in which association control and the degree of network openness is a matter of design and not open to everyone by default. Strong layering prevents the DIF from leaking information which is not essential for providing its service and that may be used to attack it.

Do you want to know more?