Recursive Internetwork Architecture: Difference between revisions

Revision as of 20:48, 30 March 2016

Revision as of 23:38, 18 May 2016

Line 29:

'''1992. Second opportunity to fix addressing missed'''. In 1992 the [[Internet Architecture Board]] (IAB) produced a series of recommendations to resolve the scaling problems of the [[IPv4]]-based Internet: address space consumption and routing information explosion. Three types of solutions were proposed: introduce [[Classless Inter-Domain Routing]] (CIDR) to mitigate the problem, design the next version of IP (IPv7) based on [[CLNP]] (ConnectionLess Network Protocol) and continue the research into naming, addressing and routing.<ref>Internet Architecture Board. IP Version 7 ** DRAFT 8 **. Draft IAB IPversion7, july 1992</ref> CNLP was an OSI-based protocol that addressed nodes instead of interfaces, solving the old multi-homing problem introduced by the [[ARPANET]], and allowing for better routing information aggregation. CIDR was introduced but the [[IETF]] didn't accept an IPv7 based on CLNP. IAB reconsidered its decision and the IPng process started, culminating with [[IPv6]]. One of the rules for IPng was not to change the semantics of the IP address, which continues to name the interface, perpetuating the multi-homing problem.<ref name="IPv6"/>

There are still more wrong decisions{{SaysAccording whoto whom|date=October 2015}} that have resulted in long-term problems for the current Internet, such as:

* In 1988 IAB recommended using the [[Simple Network Management Protocol]] (SNMP) as the initial network management protocol for the Internet to later transition to the object-oriented approach of the [[Common Management Information Protocol]] (CMIP).<ref>Internet Architecture Board. IAB Recommendations for the Development of Internet Network Management Standards. RFC 1052, April 1988</ref> SNMP was a step backwards in network management, justified as a temporal measure while the required more sophisticated approaches were implemented, but the transition never happened.

Line 63:

* It builds on a very basic premise, yet fresh perspective that networking is not a layered set of different functions but rather a single layer of distributed Inter-Process Communication (IPC) that repeats over different scopes. Each instance of this repeating IPC layer implements the same functions/mechanisms but policies are tuned to operate over different ranges of the performance space (e.g. capacity, delay, loss).

* It is based on a comprehensive theory of networking; it does not represent another patch, or point-solution to a piece of the problem. RINA does not propose to simply add a new “session layer” to perform some extra functionality for bridging ISP networks. Instead it takes a clean slate approach and begins with a comprehensive general theory of IPC where the number of IPC layers (DIFs) may vary at different parts of the Internet depending on the range of the resource allocation problem that must be addressed. The greater the operating ranges in a network, the more IPC layers it may have. Thus configuring the appropriate number of IPC layers allows for more predictable services to be delivered to users.

* This repeating structure scales indefinitely, thus it avoids current problems of growing routing tables, and supports features such as multi-homing and mobility, with little or no cost. By indefinitely we mean that the nature of RINA does not impose any limits. There may be physical limits and other constraints.

* An application process using a DIF only knows the name of the destination application process. It has no knowledge of addresses and there are no so-called “well-known ports”. Joining a DIF requires that the new member must be authenticated according to the policies of this particular facility. This yields a far more secure architecture.

* Stacking DIFs on top of each other allows networks to be built from smaller and more manageable layers of limited scope. This divide-and-conquer strategy gives providers more resource management options than just over-provisioning. It also provides the basis for operating subnetworks at much higher utilization than in the current Internet.

* RINA leverages the well-known concept of separating mechanism from policy in operating systems.<ref name="policy">P. Brinch Hansen. The nucleous of a multiprogramming system. Communications of the ACM, 13(4): 238-241, 1970</ref> Applying this separation to network protocols allows a DIF to provide a common minimal set of mechanisms that once instantiated with the appropriate policies allows any transport solution to be realised.<ref>I. Matta, J. Day, V. Ishakian, K. Mattar and G. Gursun. Declarative transport: No more transport protocols to design, only policies to specify. Technical Report BUCS-TR-2008-014, CS Dept, Boston. U., July 2008</ref> Not only the transport functions of a DIF benefit from this approach, but also other ones such as management, authentication or access control; making the DIF a fully configurable container capable of effectively operating on top of heterogeneous physical medias and to provide differentiated levels of QoS to different types of applications.

* DIFs can be configured to not only provide the fundamental services of the traditional networking lower layers but also the services of application relaying (e.g. mail distribution and similar services), [[transaction processing]], [[content distribution]] and [[peer-to-peer]]. This removes the barrier created by the Transport Layer in the current Internet, opening potential new markets for ISPs to provide IPC services directly to their customers leveraging their expertise in resource management of lower layers.

* It turns out that private networks (with private addresses) are the norm. IPC processes are identified by addresses internal to the DIF and public networks are simply a degenerate case of a private network. This lays the foundation for major competition and innovation and avoids the rigidness of the current Internet structure. There's not just a single network where everybody has to be attached to; with RINA network operators, service providers and users have a choice of which networks to provide and which networks to join.

Line 124 ⟶ 117:

'''Resiliency to data transport attacks'''. IPCP (node) addresses are internal to a DIF and not exposed to applications, data connections are dynamically assigned connection-endpoint ids (CEP-ids) that are bound to dynamically assigned ports. Bodappati et al.<ref>G. Boddapati, J. Day, I. Matta, L. Chitkushev, "Assessing the security of a clean-slate Internet architecture," Network Protocols (ICNP), 2012 20th IEEE International Conference on , vol., no., pp.1,6, Oct. 30 2012-Nov. 2 2012</ref> showed that due to this decoupling of transport port allocation and access control from data synchronization and transfer RINA was much more resilient than TCP/IP to transport-level attacks such as port-scanning, connection opening or data-transfer.

'''DIFs are securable containers, no firewalls are necessary'''. Small et al. <ref>J. Small, J. Day, L. Chitkushev, “Threat analysis of Recursive Inter-Network Architecture Distributed Inter-Process Communication Facilities”. Boston University Technical Note.</ref> performed a threat analysis at the RINA architecture level, concluding that DIFs are securable containers. That is, if proper authentication, authorization, confidentiality, integrity protection and auditing policies are put in place (as identified in section 2.1) a DIF is a structure used to transport data that can be made to be not subject to threat. No external tools such as firewalls are required.

'''Complexity of RINA security is lower than that of the current Internet security'''. This is a consequence of the different approach to each of the architectures: the system design approach adopted by the RINA architecture, is based on identifying the proper placement of all the functions within the architecture - in contrast to the disorganized evolution of the Internet “protocol-suite” which leads to unnecessary redundancy and complexity. This is particularly evident in comparing the number of protocols and mechanisms required to add security to both RINA and the Internet: Small<ref>J. Small. “Patterns in Network Security: An analysis of architectural complexity in securing Recrusive Inter-Network Architecture Networks”. Master thesis, 2012. Boston University Library</ref> showed that the current Internet security had for 4-5 times the overhead of RINA security. Less overhead means not only less cost but also more effective security, since complexity is the worst enemy of security <ref>B. Schneier, “Complexity the worst enemy of Security”. Computer World, December 2012.</ref>

Line 143 ⟶ 136:

===BU Research Team===

The RINA research team at Boston University <ref>Boston University’s RINA research team website: http://csr.bu.edu/rina</ref> is led by Prof. Abraham Matta and Prof. John Day. BU has been awarded a number of grants from the [[National Science Foundation]] in order to continue investigating the fundamentals of RINA, develop an open source prototype implementation over UDP/IP for Java <ref>Flavio Esposito, Yuefeng Wang, Ibrahim Matta and John Day. Dynamic Layer Instantiation as a Service. Demo at USENIX Symposium on Networked Systems Design and Implementation (NSDI ’13), Lombard, IL, 2-52–5 April, 2013.</ref> <ref>Yuefeng Wang, Ibrahim Matta, Flavio Esposito and John Day. Introducing ProtoRINA: A Prototype for Programming Recursive-Networking Policies. ACM SIGCOMM Computer Communication Review. Volume 44 Issue 3, July 2014.</ref><ref>ProtoRINA github site: https://github.com/ProtoRINA/users/wiki</ref> and experiment with it on top of the GENI infrastructure.<ref>Yuefeng Wang, Flavio Esposito, and Ibrahim Matta. "Demonstrating RINA using the GENI Testbed". The Second GENI Research and Educational Experiment Workshop (GREE 2013), Salt Lake City, UT, March 2013.</ref><ref>Yuefeng Wang, Ibrahim Matta and Nabeel Akhtar. "Experimenting with Routing Policies Using ProtoRINA over GENI". The Third GENI Research and Educational Experiment Workshop (GREE2014), March 19–20, 2014, Atlanta, Georgia</ref> BU is also a member of the Pouzin Society and an active contributor to the FP7 IRATI and PRISTINE projects. In addition to this, BU has incorporated the RINA concepts and theory in their computer networking courses.

===FP7 IRATI===

Line 155 ⟶ 148:

==References==

{{reflistReflist|colwidth=30em}}

==External links==

Line 162 ⟶ 155:

* RINA tutorial at the IEEE Globecom 2014 conference, available online at http://www.slideshare.net/irati-project/rina-tutorial-ieee-globecom-2014

[[Category:Network_architectureNetwork architecture]]