69
The Pouzin Society © John Day, 2013 All Rights Reserved 1 Welcome to the RINAissance! An Introduction to the RINA Architecture Part 2 3 rd Annual International RINA Workshop John Day Ghent 2015 In a network of devices why would we route between processes? - Toni Stoey, RRG 2009

RINA Introduction, part II

Embed Size (px)

Citation preview

Page 1: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

1

Welcome to the RINAissance! ������

An Introduction���to the RINA Architecture���

Part 2

3rd Annual InternationalRINA Workshop

John DayGhent 2015

In a network of devices why wouldwe route between processes?

- Toni Stoey, RRG 2009

Page 2: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

22

What a Layer Looks Like

•  Processing at 3 timescales, decoupled by either a State Vector or a Resource Information Base

–  IPC Transfer actually moves the data ( ≈ IP + UDP)–  IPC Control (optional) for retransmission (ack) and flow control, etc.–  IPC Layer Management for routing, resource allocation, locating applications, access

control, monitoring lower layer, etc.•  Remember that within a scope if there is a partitioning of functions, it will be

orthogonal? Well, here it is.

IPC Transfer

IPC Control IPC Management

Delimiting Transfer

Relaying/ Muxing PDU Protection Common Application

Protocol

Applications, e.g., routing, resource allocation, access control, etc.

Application-entities Application Process

Page 3: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

3

What are the Protocols?

•  Only two–  A data transfer protocol, EFCP, based on delta-t with mechanism and

policy separated. This provides both unreliable and reliable flows.–  The common application protocol based on CDAP.

IPC Management CDAP

Resource Allocation

RIB Daemon

IRM RMT

EFCP

Flow Allocator

Page 4: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

4

Error and Flow Control Protocol*���(EFCP)

•  There is one DTP (and possibly one DTCP) per flow•  One Relaying and Multiplexing Task per IPC Process•  At most, one SDU Protection per (N-1)-flow/DIF.•  Delimiting is a function with an inverse that converts SDUs to User-Data

Fields for PDUs.•  DTP is a bit like IP/UDP (if you don’t look too close)

•  See the EFCP Specification

Delimiting, Fragmentation/

Reassembly

Relaying and Multiplexing Task

SDU Protection

State Vector

DTP- Sequencing/PDU Identification, Data Transfer DTCP - Retransmission

and Flow Control

Page 5: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

5

*A Bit More to Say About���

Error and Flow Control Protocols•  This has been a subject of intense research since the early 70s. You would

think we had pretty much exhausted the subject. Not so. First there was:–  Separating mechanism and policy revealed that the protocol naturally cleaved into

data and control and –  that there was no distinct relaying protocol and–  SDU Protection wasn’t really part of the protocol and–  Heavy weight solutions like IPsec were unnecessary

•  Recently we have also found that:–  Fragmentation/Reassembly is part of Delimiting–  The A-Timer has a role in DTP.–  Finer grained flow control across connections is possible external to EFCP.–  Can one dynamically shift from using DTCP without affecting a connection?

•  Very likely. Set DRF and just do it.

•  Why are we finding these new results?–  Because we are acting scientifically: we are trying to understand the nature of the

problem.

Page 6: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

6

Common Distributed Application Protocol

•  Common Application Connection Establishment (CACE) is the common procedure for establishing application connections. It ensures that there is a known first exchange.

–  Based on the OSI ACSE which was defined to be used recursively and has hooks for. . .•  An authentication module, which is a policy of whatever strength required.•  CACE and an authentication module can be wrapped around any existing application

protocol, e.g. HTTP. (See the CACE specification.)•  CDAP provides the minimal six operations and a basic object-oriented functionality

scope and filter. (See the CDAP specification.)–  Would other programming paradigms lead to different functions?

CACE Authentication CDAP

Page 7: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

7

Only Three Kinds of Systems

•  Middleboxes? We don’t need no stinking middleboxes! •  NATs: either no where or everywhere,

•  NATs only break broken architectures

•  The Architecture may have more layers, but no box need have more than the usual complement.–  Hosts may have more layers, depending on what they do.

Hosts

InteriorRouters

BorderRouters

Page 8: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

8

���All Communication goes through Three Phases

•  Enrollment–  Operations to create sufficient state within the network to allow an instance

of communication to be created.•  Allocation (also known as Establishment)

–  Operations required to allocate an instance of communication creating sufficient shared state among instances to support the functions of the data transfer phase.

•  Data Transfer–  Operations to provide the actual transfer of data and functions which

support it.•  Most of our attention has been on the last two. The first has often been ignored

and is usually seen as necessarily ad-hoc. But enrollment turns out to be key.

Page 9: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

9

How Does It Work?��� Enrollment or Joining a Layer

•  Nothing more than Applications establishing communication (for management)

–  Authenticating that A is a valid member of the (N)-DIF–  Initializing it with the current information on the DIF –  Assigning it a synonym to facilitate finding IPC Processes in the DIF, i.e. an address–  (see the Enrollment specification for an example.)

(N-1)-DIF

(N)-DIF

A

Page 10: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

10

Enrollment���Details: The Naïve Approach

•  First, create a flow with the lower layer. •  Then, create an application connection with a member of the DIF at this

layer, then authenticate each other. If successful, proceed to enroll.

Allocate (N-1)-flow

ConnectConnectResponse

Start EnrollmentWrite New Synonym

Initialize New MemberWith static info and some dynamic info.

Write Responses

•••

Stop Enrollment

Cause RIB Update to update dynamic info.

Authentication Exchange

Page 11: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

11

Enrollment���Resource Allocation Layers

•  If a member fails and reappears (router crash), can’t assume all is well.–  OTOH, the naïve approach would be onerous.

•  Assume that most Enrollment requests are members dropping out and coming back.

•  Assume that state information they have (including addresses assigned to them) has a lifetime. If gone a short amount of time, then assume it is still good; otherwise, upload. (But still has to authenticate)

•  But to save time, let the new member decide what to upload.•  See Enrollment Specification for details

Page 12: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

12

Enrollment���A Pragmatic Approach for Resource Sharing Layers

•  First part is the same.

Allocate (N-1)-flow

ConnectConnectResponse

Start EnrollmentWrite New Synonym

Initialize New MemberWrite Responses

Authentication Exchange

Page 13: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

13

Enrollment Procedure I

•  When the New Member receives the M_Connect Response, the New Member copies Current_Address to Saved_Address, it sends

–  ! M_Start Enrollment(address, Address_expiration_time, other data about New Member) •  /* The New Member is telling the Existing Member what it knows. Primarily this is

derived from the address (NULL or not), and the expiration life-time of the address if non-NULL. Since addresses are generally assigned for hours or minutes, tight time synchronization is not required. (Even for DIFs with fast turnover, fairly long assignment times are still prudent.)*/

•  The Member sends –  ! M_Start_R Enrollment(address (potentially different), Application Process Name,

Current_Address, Address_Expiration).

Page 14: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

14

Enrollment Procedure II

•  Using the information, provided by the New Member, the Existing Member sends –  ! M_Create (zero or more) to initialize the Static and Near Static information required. When

finished and the New Member has sent all necessary –  " M_Create_Rs

•  The Existing Member sends a –  ! M_Stop Enrollment (Immediate:Boolean)

•  The New Member may Read any additional information not provided by the Existing Member.

–  " M_Read (zero or more) –  " M_Stop_R Enrollment

•  If the Immediate Boolean is True, the New Member is free to transition to the Operational state.

•  If the Boolean Immediate is False, then the New Member can not transition to the Operational state until an M_Start Operation is received.

Page 15: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

15

Enrollment Procedure III

•  The New Member is free to Read any information not provided by the Existing Member. Once these are completed, the Existing Member sends:

–  ! M_Start Operation •  The New Member sends

–  " M_Start_R Operation •  Invoke RIB Update of dynamic information which will cause others to send data to the

New Member.

Page 16: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

16

How Does It Work?���Establishing Communication

•  Simple: do what IPC tells us to do.–  A asks IPC to allocate comm resources to B–  Determine that B is not local to A use search rules to find B–  Keep looking until we find an entry for it.–  Then go see if it is really there and whether we have access.–  Then tell A the result.–  (See Flow Allocator specification)

•  This has multiple advantages.–  We know it is really there.–  We can enforce access control–  We can return B’s policy and port-id choices–  If B has moved, we find out and keep searching

A BAhh, look there!

Page 17: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

17

Flow Allocator

•  The Flow Allocator contains a Name Space Management function which registers applications, allocates new addresses within the DIF, and allocates flows.

•  Most IPC Processes will maintain a cache of recent name to address mappings from flow allocate requests. Larger DIFs may dedicate IPC Processes to repositories (partially replicated databases) to facilitate flow allocation.

Repositories Flow  Allocator Flow  Allocation  

Requestors Enrollment Request

Page 18: RINA Introduction, part II

© John Day, All Rights Reserved, 20099 February 2015 . 18

What about IPC Naming?•  An IPC Process has an Application Process Name, but give it a synonym of

scope limited to the layer.•  Commonly called an address

•  There are three local identifiers:–  A Flow Allocator Instance Identifier,

•  Commonly called a port-id–  A Data Transfer Instance Identifier, and

•  Commonly called a connection-endpoint-identifier

AddressCEP-ids

Connections

Port-ids

bindingsApplication Process Name

Page 19: RINA Introduction, part II

© John Day, All Rights Reserved, 20099 February 2015 . 19

To Summarize

•  All identifiers except address and connection-id are local to the IPC Process.–  Scope of the address is the Layer.–  Scope of the connection-id is the participants in the connection.

•  None has more scope than it needs.

Common Term Scope Application Term

Application Process Name Global (unambiguous) Application Process Name

Address Layer (unambiguous) Synonym for IPC Process’ Application Process Name

Port-id IPC Process (unique) Flow-Allocator-Instance-Identifier

Connection-endpoint-identifier IPC Process (unique) Data Transfer Instance-Identifier

Connection-id Src/Dest Data Transfer (unique) Concatentation of data-transfer-instance-identifiers

DIF Management Updates IPC Process (unambiguous) AE-identifier

Page 20: RINA Introduction, part II

© John Day, 2013 20Rights Reserved

The Pouzin Society

Names & Implications of the Model���(Basics)

•  We have made a big deal of node and point of attachment, but they are relative, not absolutes.

–  An (N)-IPC-Process is a node in the (N)-DIF.•  An (N-1)-IPC-Process is a node in the (N-1)-DIF

–  An (N-1)-IPC-Process is a point of attachment to an (N)-IPC-Process.–  An (N)-address is a synonym for an (N)-IPC-Process.

•  So as long as we keep that straight, there is no point to making the distinction.

•  Note that it is the port-id that creates layer independence. With a port-id, No Protocol-Id Field is Necessary, or if there is such a field something is wrong.

Address

Port -id

(N)-IPC-Process

(N-1)-IPC-Process

Page 21: RINA Introduction, part II

This Bounds Router Table Size

•  There will be Natural Subnets within a layer around the Central Hole.•  Each can be a routing domain; Each Subnet is one hop across the Hole.

–  The hole is crossed in the layer below.•  A Topological Space is imposed on the Address Space of Each Layer

Backbone

Regionals

Metros

(N)-Routing Domains

(N-1)-Routing Domains

Page 22: RINA Introduction, part II

Example of Topological Address Assignment

Regionals

Metros

WN

S

E

•  

•   E3920  

S4729  

Possible Address SpaceFor Regional Networks

N and S would be similar

Possible Address SpaceFor Metro Networks

•  ESE8399  

WN

SE

WW NW SW NE SE EE

•WWW7428

Note that strictly speaking the address spaces are independent

Similarity in the upper part of the address hierarchy can be leveraged to simplify router calculations.

Page 23: RINA Introduction, part II

© John Day, 2013 23Rights Reserved

The Pouzin SocietyNames & Implications of the Model���(Multihoming)

•  Yea, so? What is the big deal?–  It just works

•  PDU arrives at the (N-1)-IPC Process. If the address designates this IPC Process, the CEP-id is bound to the port-id, so after stripping off (N-1)-PCI, it passes it up.

•  The process repeats. If the address in the (N)-PCI is this IPC-Process, it looks at the CEP-id and pass it up as appropriate.

•  Normal operation. Yes, the (N-1)-bindings may fail from time to time.•  Not a big deal.

Address

Port -id

(N)-IPC-Process

(N-1)-IPC-Process

Page 24: RINA Introduction, part II

© John Day, 2013 24Rights Reserved

The Pouzin Society

Names & Implications of the Model���(Mobility)

•  Yea, so? What is the big deal?–  It just works just like multihoming only the (N-1)-port-ids come and go a

bit more frequently.•  O, worried about having to change address if it moves too far? Easy.

•  Assign a new synonym to it. Put it in the source address field on all outgoing traffic. Stop advertising the old address as a route to this IPC-Process.

•  Want to renumber the DIF for some reason? Same procedure.

•  Again, no special cases. No special protocols. No concept of a home router. Okay, policies in the DIF may be a bit different to accommodate faster changing points of attachment, but that is it.

Address

Port -id

(N)-IPC-Process

(N-1)-IPC-Process

New Address

Page 25: RINA Introduction, part II

© John Day, 2013 25Rights Reserved

The Pouzin SocietyThe Skewed Necklace���(DIF view)

•  Clearly more layers could be used to ensure the scope allows sufficient time for updating relative to the time to cross the scope of the layer.

–  Space does not permit drawing networks.•  It appears that one could make the mobile host appear stationary to the top

layer, i.e. the top layer addresses don’t change because all the routing is handled in the lower layers.

BaseStation

MetroSubnet

Regional Subnet

Mobile Infrastructure Network Traditional ISP ProviderNetwork with normal necklace with

an e-mall top layer.

Page 26: RINA Introduction, part II

© John Day, 2013 26Rights Reserved

The Pouzin SocietyWhat New Is Needed?

•  Nothing–  Enrollment in a new DIF follows normal procedures–  Allocation of a flow follows normal procedures–  Changing the address of an IPC Process with in a DIF follows the

normal procedure.–  New points of attachments, i.e. new lower layer DIFs, are acquired

in the normal way.•  There are specific cases to work out here. In general, expect that a

wireless device will be probing for new PoAs. But then a system with a down wireline interface should be doing the same thing.

–  Current points of attachment are discarded when they can no longer provide an acceptable QoS (criteria and measurement is policy as it is in the wireline case).

Page 27: RINA Introduction, part II

© John Day, 2013 27Rights Reserved

The Pouzin SocietyEven the Shim DIF was Enlightening

•  A Shim DIF creates the thinnest possible veneer to make a legacy layer service look like a DIF.

•  Both IP and Ethernet (without LLC) have a ‘protocol-id’ field–  Historically (1982) a problem: (N+1)-protocol identified in an (N)-protocol

•  Without port-ids, there is no isolation and this implies that for each protocol type, there can only be one “user” of the “flow.”

–  There can be only one QoS-cube.•  Conclusion: Port-ids are necessary to a well-formed layer/DIF. These are ill-

formed layers.–  Ethernet with LLC is well-formed.–  Port-ids provide isolation.

Dest Src Protocol-id Stuff User-Data

DIF Boundary

Page 28: RINA Introduction, part II

Why Can WiFi Have 4 MAC Addresses?

BSS-id

Laptop Access Point

Router/Cable Modem

Sndr/Rcvr

“Ethernet” btwn SRC/DEST

IP

Laptop Access Point

Access Point

Router/Cable Modem

Sndr/Rcvr Sndr/Rcvr

“Ethernet” btwn SRC/DEST

IP

•  Because it is really two layers!•  In general, there is forwarding across access points. First two addresses would be

SNDR/RCVR addresses and would change at every hop, while . . .•  Over the top is a logical Ethernet with Src/Dest addresses constant, continuous

with the Wired Ethernet connecting the last Access Point to the Router.•  The most common configuration is a Star Network connected to a Router/Cable

Modem. In this case, the SRC and SNDR addresses are the same, so only 3 addresses are necessary.

•  VLANs are doing the same thing: Multiple Layers of the Same Rank over a Common Media

Page 29: RINA Introduction, part II

WiLAN Model

•  The Wired Media DIF is point-to-point between a station or bridge and another bridge. –  Hence, this DIF does not need addresses, but does need CEP-ids and

port-ids.•  OTOH, the wireless-media DIF is also point-to-point but needs both

addresses and CEP-ids.–  Because multiple wireless networks may exist in the same physical

space.•  Over the top is any ordinary DIF.

Station

BridgesAccessPoint

Wired Media DIFsWireless Media DIF

Station

Page 30: RINA Introduction, part II

© John Day, 2013 30Rights Reserved

The Pouzin Society

Implications of the Model & Names ���(Choosing a Layer)

•  In building the IPC Model, the first time there were multiple DIFs (data link layers in that case), to maintain the API a task was needed to determine which DIF to use.

IAP Dir

MuxFlowMgr

– User didn’t have to see all of the wires–  But the User shouldn’t have to see all of the “Nets” either.

•  This not only generalizes but has major implications.

Page 31: RINA Introduction, part II

© John Day, 2013 31Rights Reserved

The Pouzin SocietyImplications of the Model & Names ���(A DIF Allocator)

•  A DIF-Allocator incorporating a Name Space Management function determines via what DIFs applications are available.–  If this system is a not member, it either joins the DIF as before–  or creates a new one.

•  Which Implies that the largest address space has to be only large enough for the largest e-mall.•  Given the structure, 32 or 48 bits is probably more than enough.

•  You mean?•  Right. IPv6 was a waste of time . . .•  Twice.

DIF-Allocator

Page 32: RINA Introduction, part II

© John Day, 2013 32Rights Reserved

The Pouzin SocietySo a Global Address Space is Not Required but���Neither is a Global Application Name Space

Inter-DIFDirectory

To PeersIn Oher DIFs

Actually one could still have distinct names spaces within a DIFs (synonyms) with its own directory database.

•  Not all names need be in one Global Directory.•  Coexisting application name spaces and directory of distributed

databases are not only possible, but useful.•  Needless to say, a global name space can be useful, but not a

requirement imposed by the architecture.•  The scope of the name space is defined by the chain of databases that

point to each other.

Page 33: RINA Introduction, part II

© John Day, 2013 33Rights Reserved

The Pouzin SocietyScope is Determined by the���Chain of Places to Look

•  The chain of databases to look for names determines the scope of the name space.–  Here there are 2 non-intersecting chains of systems, that could be

using the same wires, but would be entirely oblivious to the other.

Page 34: RINA Introduction, part II

© John Day, 2013 34Rights Reserved

The Pouzin SocietyName Space Management

•  There is a common functional required to manage name spaces. It handles registration, query, and delegation of names and is incorporated found in both DIFs and DAFs.

•  There are two major uses: the DIF-Allocator and the Flow Allocator, as well as in many distributed database applications, etc.

Repositories

Registration  Server Query  Servers

Registration  Client Query  Client

Page 35: RINA Introduction, part II

© John Day, 2013 35Rights Reserved

The Pouzin SocietyDIF Allocator

•  A DIF Allocator is very similar to the Flow Allocator, both contain a NSM function for application names and addresses, respectively and operate at different granularities creating either DIFs or connections.

Registration Server Query Servers

Registration Client Query IRM DA-DAP

NSM Repositories DIF Creation

and Relay NSM- DAP

DA-DAF

Page 36: RINA Introduction, part II

How It Works

•  There is a repeating structure of name mappings.•  The DIF Allocator has an NSM of Application-Names with scope greater than any one DIF. Associated with each name is the

name of the processing system on which it resides, and a list of supporting DIFs. From this information, the DA is able to project the application-names into the Flow Allocator of supporting DIFs and the IPC Processes of that DIF.

•  The Flow Allocator keeps the mapping of each application-name to the synonym of the IPC Process in the same processing system.

•  The Resource Allocator contains an NSM for the synonyms for each IPC Process, i.e. addresses, in this DIF and the (N-1)-DIFs supporting the synonym. The Resource Allocator is consulted during Enrollment to get appropriate synonyms assigned. The Resource Allocator also injects information for the (N-1)-Flow Allocator, serving the analogous service as the DIF Allocator.

•  Needless to say, that this mapping information may be acquired from bottom up as well as top down.•  Supporting DIF-name and access control information might only be stored “near” the object named for security reasons, to

keep databases small, or accommodate frequent changes.•  There may be a topological relation between synonym spaces of (N)- and (N-1)-DIFs.•  It is highly unlikely that there will be a topological relation between the Application Name Space and the Synonyms of a DIF.

–  A topological relation between Name Spaces of DAFs is a different matter.

DIF Allocator

Flow AllocRes-Alloc

DA-NSM: Application-names -> DIF/DAF names, Processing Systems

FA: (N+1)-names -> (N)-names

RA: (N)-names-> (N-1)-names, (N-1)-DIFs

Page 37: RINA Introduction, part II

© John Day, 2013 37Rights Reserved

The Pouzin SocietyMulticast and Anycast are Simpler Too

•  Generalized to Whatevercast:–  A set and a rule that returns as many members of the set that satisfy the

rule.•  Unicast becomes a degenerate case of whatevercast.

–  Forwarding table entry maps Destination Address to a list of next hops. For unicast, the list has one element.

•  Primarily handled by hosts or border routers, where all whatevercast traffic is either:

•  On this subnet (only do spanning tree within subnet if there is a lot) or•  Transit to another subnet, (both cases degenerate to point-to-point).

•  So we see Whatevercast devolves into Unicast.

Page 38: RINA Introduction, part II

© John Day, 2013 38Rights Reserved

The Pouzin SocietyMulticast and Anycast are Simpler Too

•  Information in topological addresses imply an approximate spanning tree, which can be used to identify the border routers. Thus, in most cases obviating the need for a separate spanning tree (multicast) routing algorithm.

•  And also making it straightforward to multiplex whatevercasts with common sub-trees which will allow even greater efficiency.–  Note that the common sub-trees do not have to be strict sub-trees but

simply have a reasonable degree of commonality to be worthwhile.

Page 39: RINA Introduction, part II

© John Day, 2013 39Rights Reserved

The Pouzin SocietyBut Another Surprise���(Allocating a Group)

•  Start with a set of Application Names (or something similar)•  Need to Allocate a Group•  Now we need to find the addresses and create a spanning tree.•  Shall we just do what the model says?•  Doesn’t sound promising, send out Create Flows for all of the

addresses in the set? Okay lets try it.

Flow Allocator

Allocate (. . . .)

Page 40: RINA Introduction, part II

© John Day, 2013 40Rights Reserved

The Pouzin SocietyBut Another Surprise���(Allocating a Group)

•  We found the addresses, and then the Responses get forwarded back through the Border Routers.

•  Wow! It generates the spanning tree!–  There is much to explore here.

•  Just follow the Model.

Allocate (. . . .)

FA

Page 41: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

41

“Internet” Congestion Control

•  Congestion Control has been a known issue since 1972.–  Except in the Internet who only discovered it when it crashed around their ears in 86

•  The effectiveness of any congestion control is directly related to the time to effect a change.

–  The longer it takes the less effective the congestion control

•  End-to-end implicit notification is predatory.–  Longest response time. Will work against any attempt to do it at a lower level with

shorter scope and better response time.•  The Internet has network congestion control,

–  not internet congestion control

Page 42: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

42

What is the Difference Between ���Flow Control and Congestion Control?

Data

Control

Control

Data Data

Notify

Flow Control is a feedback mechanism co-located with the resource being controlled.

Congestion Control is a feedback mechanism not co-located with the resource being controlled.

Page 43: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

43

How Does It Work?���“Congestion Control”

•  Congestion Control in TCP was always known to be a stop-gap.•  A DIF always has the potential for the full capability of functions.•  Do flow control (without retransmissions) between intermediate points.

–  Better congestion control, really flow control–  Allocate different resources to different e-malls.–  Allows provider much more effective management of resources.–  Provides means to throttle flows being used for denial of service attacks–  All of these places? Probably not all in the same DIF. Major Area for Research

Page 44: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

44

How Does It Work?���The Internet and ISPs

•  ISPs have as many layers as they need to best manage their resources.

Backbone

Regionals

Metros

Page 45: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

45

How Does It Work?���The Internet and ISPs

•  The Internet floats on top of ISPs, a “e-mall.”–  One in the seedy part of town, but an “e-mall”–  Not the only emall and not one you always have to be connected to.

Public Internet

ISP 1 ISP 2 ISP 3

Page 46: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

46

How Does It Work?���The Internet and ISPs

•  But there does not need to be ONE e-mall.–  You mean!

•  Yes, it is really an INTERnet!

Public Internet

ISP 1 ISP 2 ISP 3

Internet Rodeo Drive

Utility SCADAMy NetFacebook Boutique

Internet Mall of America

Page 47: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

47

How Does It Work?���The User’s Perspective

In this case, one host on the local network chooses to join one of the available e-malls.

e-common DIFs

Provider Network

Local Customer Network

Peering DIF

A Customer Network has a border router that makes several e-malls available. A choice can be made whether the entire local network joins, a single host or a single application.

e-common DIFs

Provider Network

Local Customer Network

Peering DIF

Page 48: RINA Introduction, part II

© John Day, 2013 48

Rights Reserved

The Pouzin SocietyBefore Tackling Security ���A Word on Method���

(hardly news by now)

•  When trying to work out the IPC Model absolutely no thought was given to security. All of the focus was just understanding the structure.

•  People kept asking, What about Security? Is there a security layer?•  Didn’t Know. Hadn’t thought about it.•  There was the obvious:

–  The recursion of the layer provided Isolation.–  That only the Application Name and local port-id were exposed to the

correspondents.•  Interesting, but hardly an answer•  But it wasn’t the time for those questions . . . •  At least not yet . . .

Page 49: RINA Introduction, part II

© John Day, 2013 49

Rights Reserved

The Pouzin SocietyThe Recursion Provided Isolation

•  Security by isolation, (not obscurity)

•  Hosts can not address any element of the ISP.•  No user hacker can compromise ISP assets.

•  Unless ISP is physically compromised.

ISP Hosts and ISPs do not share DIFS.(ISP may have more layers

Page 50: RINA Introduction, part II

© John Day, 2013 50

Rights Reserved

The Pouzin SocietyHow Does It Work?���Security

•  A Hacker in the Public Internet cannot connect to an Application in another DIF without either joining the DIF, or creating a new DIF spanning both. Either requires authentication and access control.

–  Non-IPC applications that can access two DIFs are a potential security problem. •  Certainly promising

Public Internet

ISP 1 ISP 2 ISP 3

Internet Rodeo Drive

Utility SCADAMy NetFacebook Boutique

Internet Mall of America

Page 51: RINA Introduction, part II

© John Day, 2013 51

Rights Reserved

The Pouzin SocietyBut When It Was Time

•  The question was not, how to put in security?•  The question was, •  What does the IPC Model tell us about security?

–  Remember, our first task is always understanding.

•  Let the Problem Answer the Question! –  Let the Problem Tell Us What to Do.

Page 52: RINA Introduction, part II

© John Day, 2013 52

Rights Reserved

The Pouzin Society

The Problem Had a Lot to Say

•  We Already Mentioned How Little is Exposed the Layer Above.•  The Original OS Model indicated where Access Control went.•  Creating the Application Connection for Enrollment indicated where

Authentication belonged, and that–  Authentication of Applications must be done by the Applications themselves.–  All members of the layer are authenticated within policy.

•  SDU Protection clearly provided Confidentiality and Integrity.•  That implied that only Minimal trust was necessary:

–  Only that the lower layer will deliver something to someone.

Port:=Allocate(Dest-Appl, params)

Access ControlExercised

Page 53: RINA Introduction, part II

© John Day, 2013 53

Rights Reserved

The Pouzin SocietyA Very Unexpected Result

•  A DIF with no explicit security mechanisms is inherently more secure than the current Internet under the same conditions!

•  It would appear that –  A DIF is a Securable Container.

Page 54: RINA Introduction, part II

© John Day, 2013 54

Rights Reserved

The Pouzin SocietyOther Things Fall Into Place

•  Data Transfer in RINA is based on Delta-t (Watson, 1980)•  Lot has happened in 30 years, many attacks on TCP have been found:

–  Port scanning – Reset Attacks–  SYN attacks – Reassembly Attacks

•  Long after delta-t was designed, what about delta-t?•  Short answer:

–  None of them work (Boddapati, et al., 2012)•  Amazing, totally unexpected

–  Why not? •  Multiple fundamental reasons, but all inherent in the structure:

–  First, have to join the DIF (all members are authenticated)–  Second, No Well-Known Ports

•  Would have to scan all possible application names!–  Third and more importantly, . . .

Page 55: RINA Introduction, part II

© John Day, 2013 55

Rights Reserved

The Pouzin Society

Decoupling Port Allocation and Synchronization

•  No Way to Know What CEP-ids are Being Used, Since There is No Relation Between Port-id and CEP-id.–  SYN-Ack Attack: must guess which of 2^16 CEP-id.–  Data Transfer: must guess CEP-id and seq num within window!–  Reassembly attack: Reassembly only done once.–  No well-known ports to scan.

Synchronization

ConnectionEndpoint

Port Allocation

Port-id

Connection

Page 56: RINA Introduction, part II

© John Day, 2013 56

Rights Reserved

The Pouzin Society

Decoupling Port Allocation and Synchronization: No IPSec

•  IPsec is necessary with TCP/IP because no authentication and Sequence numbers turn over too quickly: don’t repeat sequence number with same CEP-id.

•  With RINA and delta-t, IPC Processes all authenticated, SDU Protection does the encryption, and packet sequence numbers slows rollover, but if it does, then simply allocate a new connection

•  And bind it to the same port-ids, old one disappears after 2MPL.

ConnectionEndpoint

Port Allocation

Port-id

Connection

SDU Protection SDU Protection

Page 57: RINA Introduction, part II

© John Day, 2013 57

Rights Reserved

The Pouzin Society

RINA is Inherently More Secure���and Less Work

•  A DIF is a Securable Container. (Small, 2011)–  What info required to mount an attack, How to get the info–  Small does a threat analysis at the architecture level

•  Implies that Firewalls are Unnecessary, –  The DIF is the Firewall!

•  RINA Security is considerably Less Complex than the Current Internet Security (Small, 2012)–  Only do a rough estimate counting protocols and mechanisms.

•  See paper for details.

Page 58: RINA Introduction, part II

© John Day, 2013 58

Rights Reserved

The Pouzin Society

Internet RINA

Protocols 8 0

Non-Security Mechanisms 59 0

Security Mechanisms 28 7

To AddSecurity

Copyright © 2012, Jeremiah Small. All Rights Reserved.

Page 59: RINA Introduction, part II

© John Day, 2013 59

Rights Reserved

The Pouzin SocietySumming Up Security

•  This is a MAJOR Improvement in Internet Security.–  Not only more secure, but for less cost, with less overhead.

•  So is Internet Security solved?–  Hardly.–  Still need: to develop the plug-in policy modules–  to consider DDoS (we have some ideas)–  As well as protecting against Rogue IPC Processes –  and much more to explore and who knows what general principles will

fall out.•  Most attacks are in the Applications, this does nothing about that.

–  But Much of this applies equally well to DAFs•  Model implies that OS security reduces to Bounds Checking on Memory and

IPC Security.–  May also make it harder, might be able to deflect more DDoS attacks

Page 60: RINA Introduction, part II

The Pouzin Society

© John Day, 2013 60

Rights Reserved

Management DAFs

Page 61: RINA Introduction, part II

The Pouzin Society

© John Day, 2013 61

Rights Reserved

An Important Class of DAFs:���DAF Management Systems

•  There are four major kinds of distributed management systems (DMS):–  Operating System – Network Management–  Distributed Applications – Name Space Management

•  The Most Important Property of Management–  Commonality, Commonality, Commonality. Reduce the Parts Count.

•  Not Necessarily make everything look alike, but–  Effectively separating the like from the unlike

•  Maximizing invariance and minimizing discontinuities

•  This is what the principles we have uncovered do, and have been•  Embodied in RINA.

–  RINA was not designed to do this. We worked out the principles and then did what they said. (There wasn’t that much leeway.)

–  We aren’t done. We have pushed commonality into major parts of the model but there are more principles, invariances to find.

•  It is subtle, greatest generality with least constraint, often requires shift in POV

Page 62: RINA Introduction, part II

The Pouzin Society

© John Day, 2013 62

Rights Reserved

DAF Management Systems

•  There is a commonality to their structure and•  A range in their complexity from distributed to centralized•  Each DAF/DIF has a DAF Management Task. These constitute data

collection and autonomic functions, what IEEE calls layer management.•  The DAF Manager can be considered the nervous system of a DAF.

–  A DAF Manager might manage more than one DAF or –  In a degenerate case, the DAF Management Tasks might constitute the DAF

Manager.DAF Manager

Page 63: RINA Introduction, part II

The Pouzin Society

© John Day, 2013 63

Rights Reserved

The General Model

•  And down the side were the labels•  This became the core of our approach to Network Management

Cerebellum

Cerebrum

Hypothalamus(Ganglia)

PeripheralIncreasing

Aggregation

Sensor

Agent

Manager

Coordinator

Raw Data

Filtered

Processed Data

Planning Data

Increasing“Cycle” Time

Page 64: RINA Introduction, part II

The Pouzin Society

© John Day, 2013 64

Rights Reserved

But More Importantly It was Clear that ���Network Management is

•  The whole point is that events are happening too fast for humans to be in the loop. They can manage, but not control.

•  Control must be autonomic.

Monitor and RepairBut not Control

Page 65: RINA Introduction, part II

The Pouzin Society

© John Day, 2013 65

Rights Reserved

The Management Architecture���Central Nervous System

•  While there might be managers for distinct subnets (domains) and the subnets might be a hierarchy, the managers were peers.

–  Many talked about managers of managers but there is really nothing for second level managers to do. (that generalizes?)

•  Then Realized what was missing: Where’s the Homunculus?

Agent

Event

ConfigPerf

Fault

Agent

Agent

AgentAgent

ReliableReq/Resp

Best EffortTelemetry

Agent

MIB

NetworkManagement

System (NMS)Devices to be Managed

NMS

Agent Agent AgentAgent

autonomic

Page 66: RINA Introduction, part II

The Pouzin Society

© John Day, 2013 66

Rights Reserved

The Relation Among���Management Applications

•  Configuration Management – is the primary “action” a management system should take.–  Security Management is a subset of Configuration Management.

•  Performance Management monitors the autonomic functions, e.g. routing and congestion, and provides input to the Coordination Level for improving policies.–  It should seldom result in direct action. Although some policies might

provide tunable parameters. This is dangerous.•  Accounting Management is a Coordination Level function. It’s data is

a subset of Performance data.•  Fault Management isn’t an app, but a management system with a small

domain for diagnosing, testing, and repairing network elements.

Page 67: RINA Introduction, part II

The Pouzin Society

© John Day, 2013 67

Rights Reserved

Note of Practicality

•  We have identified 4 kinds of management systems: Systems, Applications, Network, and Name Space.

•  While they can all be stand-alone (and there will be cases where they should be), they will often occur as symbiotic, i.e. incorporated into another Management system.

•  Many of the confusions today are because these 4 are not clearly recognized.–  For example, in a corporate environment, it would not be unusual for all

four to be combined. But even here, different groups might have their own application management or even system management systems within that.

–  In a data center, the data center would manage its systems and network resources and allocate them to users who would use their application management systems to manage the applications running on the datacenter.

–  Etc.

Page 68: RINA Introduction, part II

The Pouzin Society

© John Day, 2013 68

Rights Reserved

On Autonomic vs Centralized

•  In nature, a central nervous system appears in fairly primitive organisms, such as Platyhelminthes (flatworms).–  Clearly monitoring and reporting must be centralized.

•  Some actions can be done without a central nervous system, see coelenterate locomotion and tentacles.–  Some rhythmic behaviors as well, where reacting to neighbors suffice.

•  However, complex actions across the organism may require more coordination, as will finding true optima rather than local optima.–  In nature, we find that ganglia suffice for this much of the time with ganglia

often being larger than the “brain.”•  Food for thought for management.

Page 69: RINA Introduction, part II

The Pouzin Society

© John Day, 2013All Rights Reserved

69

Questions?