Token Authorization Framework
Question: What is the point having a key ?
Situation 1: Consider two endpoints via a switch
Case 1 - Give endsystems X and Y a key - allows IPSec based VPN tunnel to be created.
Network is not involved and can prevail silent - any port can be used for access.
Case 2 - MAC Port locking. No key(s) involved. One (or more) particular MAC address(es) can be locked to a specific port. A MAC locked port will only accept traffic from the locked MAC address and no other Source MAC address(es). Switches can be set to lock out other then locked-in ports.
Case 3 - Give key to a single
port and end system - allows port based access control (802.1X / 802.11 style) and port mapping.
Allows for VPN extentions where VPN attributes go along with key determining access to a particular VLAN/VPN. The end server and the switch are key. It is important to recognize that keys allow dynamic port locking - keys create a dynamic port association for the duration of a port session.
Case 4 - The
network may want to say: A particular port may only connect to a particular other port accross the network creating a path (VPN) accross the switch. A key provides access to this path at both ends of the path and determines which ports interconnect. (see above picture).
Case 5 - Same as Case 4, however the keys at both end systems are different.
-- some issues to discuss --
How do we set it up - who does what ?
1. User X authenticates to Y and Y authorizes X to use a connection to Y. The switch allows control by Y.
2. User X authenticates to a User Authority or user X presents a credential when X asks for a connection thru the network to Y. The question is asked to the network authority. The question is still if Y will accept the connection. The question may therefore also be asked to Y (in either hierarchical fashion using an agent that both talks to the network authority and Y or chained fashion where the network authority contacts Y. Both decisions needs to be combined before a network authority replies to X.
What are the kind of things you can ask for ?
level2 connection between x and y
IP connection between IP X and IP Y
Lambda between X and Y
Port A on X and port B on Y
URL on Y
There could be policy in all places that would check what you have it at each of the places, so that both Ingress and Egress would check what is allowed. The network could make the checks and user Y could make the checks. It is not clear if this all needs to be done.
Who enforces policy and why?
ie what is the value to the network and what is the value to the user.
Users buy/negotiate cabapilities from/with the network. A user wants a guarantee that no one else gets what has been negotiated, so the user marks all belonging traffic. Network wants to provide only what has been negotiated, so it checks what is sent by the user against what has been agreed. The network is acts to marked traffic according to agreed capabilities
What services can the network offer (and may need interaction with user) ?
Resource management
The network and the user may decide to use or rely on a resource manager to control the usage of network resources. Typically we would expect that user and network management are handled in different places, but all three must be coordinated somehow [perhaps a 'super manager or -see later - a Virtual organization manager].
Bandwitdh management
Bandwitdh may be subject to resource management. Bandwidth is allocated by network, but also by client/user. Both users would be able to send/receive a certain amount of bandwitdh. Users don't typically worry as much about bandwidth as it is often controlled by the protocol (TCP or UDP) used for a particular application. However, an end user may want to limit input it will accept. End user may also want to limit the amount of data sent (perhaps to avoid overcharge for non-contracted resource)
The network resource manager must decide how to allocate bandwidth for the network. This seems particularly true IP streams, or perhaps (G)MPLS streams.
For networks of lambda's interconnected at exchange points that switch lambdas, it is fairly straightforward. For layer 2 and above, or for paths concatenating layer 1 segments with layer 2 and higher, it gets more complex.
< picture of resource manager > in picture 2.
Security: Ingress Port Access Control.
The network may offer security policy support such that the network will only allow traffic to enter a specific designated port. Traffic may originate from specific stations, physical ports, users etc. Access may be provided with our without user Authentication. Users may first need to negotiate access.
Security: Egress Port Access Control.
The network may offer security policy support such that the network will only allow traffic to exit on designated ports. Devices or applications that are accessed by the network may set access policies such that it only accepts certain traffic (e.g. from specific sources, applications or (authenticated-) users).
Security: Firewalling
Traffic, flowing thru certain points within the network must have certain features. It must originate and/or be destined for specific MAC addresses, IP addresses, Port numbers, application protocols features, etc. Firewalling can be statefull or stateless.
Security: Path Access control
The network is required to switch the traffic only via a designated (valuable, secure) path. Depending on the position of the access control enforcement point, path access is granted to the entire end-to-end path or to part(s) of an end-to-end path. The path may cross one or more administrative domains. Sources and/or destinations could be required to adhere to certain policies (e.g. security level, type of destination, ownership etc.).
Security: Combinations of ingress-port, egress-port, path and firewall control
Users and network administrator(s) can agree upon a combination of the above mentioned security enforcement elements to be applied for certain applications that travel accross a (multi-domain) network. Tokens inside packets may index into these types of security behaviors.
Distribution control
The network is required to distribute traffic to more then one destination (multicast).
Load balancing
The network is required to balance traffic over multiple paths or destinations
Priority control
The network is required to treat traffic with a certain priority (e.g. in case of malfuntion)
Backup and Reliability
The network is required to guarantee a certain level of service reliability.
(Multi-domain) Application Control
The network is required to adapt its behavoir (path selection, delivery control, priority handling etc.) dependant on application requirements. By allowing applications to mark (using tokens) traffic differently depending on the application, the application is able to control the (predetermined) network behavior of each domain. Within limits set by the network domain resource owner, the application (or user of the application) should be allowed to program the behavior of the domain network. The user/application should be able to say: if I hand the domain traffic marked with tokens belonging to key M you should observe behavior m1 for domain 1, m2 for domain 2 etc. If the same traffic is marked N, domain 1 should observe behavior n1, domain 2 n2 etc.
Value of the key that goes with the token
A key allows the sender to identify/mark the traffic such that it says that it should be part of what is allocated or arranged. The receiver can get anything and must check for marked frames/packets and subsequently expects the network to act according to the pre-arranged or pre-programmed service behavior. Only the user is allowed to mark the traffic. The network may (re-)mark the traffic on behalf of the user. Somebody, who does not have its marked somehow, may not get a specific network behavior.
The key does not give you a right, but identifies the user. The token implements (indexes into) a certain behavior. The key is used to authenticate the token, so that the receiver knows that the token came from the user. The key may also authenticate capabilities send along/inside the data.
Keys may be used or not. If used, keys may be provisioned by some sort of hand configuration of each element, or may be deployed dynamically by some management application, that may involve a resource manager.
Multi-domain cases are harder to provision by hand - takes a lot of administration if changes happen frequently.
Situation 2: A network of switches
∞
Resource management
A resource manager can be present at the user and in the network.
Resources can allocated by a VO, but we need to take a look at the case were users do not belong to VO's
∞
∞
General:
Keys are there to protect against someone stealing/spoofing a token allowing use of resource
Tokens allow variety of resources to be included in a service dynamically
Keys can be obtained by a user from an authority based on authentication of the user.
- authentication might be by cert, by shared key, or simply by asserting an identity
Resource can be allocated to a user by giving a token. Key is used to sign token so resources know token is from user.
Key issueing can be policy dependant
Path represented by keys in multi-switch case can be allocated in INTSERV [inband] or Broker [out of band] fashion
Specific capabilities may be used to create a path, depending on what is available and controllable (e.g. multiplexing, resource management, priviliged path selection)
Additional capablities or restrictions can be assigned based on where you came from (only valid on this port, this subnetwork, eligible for use of Lambda from a to b, etc.).
The value of the capability assigned to a specific flow depends on the token of the flow.
Main thing for the immediate study is to make a case for tokens and describe its value. This should include comparison to existing implementation concept.
How do VOs fit in.
VOs seem to provide a mechanism for controlling a set of resources in a particular way. Without VO one would have to find resources, determine which are appropriate for what is desired, contract for the resources to reserve use, etc. While this might happen in the long run, it seems that VOs allow pooling of resources in a more limited way. They still require much of the same organization, but in a much more controlled environment.
Where does Token Based Networking fit in terms of technology?
Token Based Networking is a technology that fits between
traditional networking where network behavior is provisioned using network management interfaces (CLI, SNMP, COPS-PR etc.) and
active networking, in which network behavior is determined by instructions carried inside packets. With
token based networking, network behavior is programmed into a switch via a network management interface, and represented by tokens, packets carry
an authentic index into this behavior.
There is one comment on this page. [Display comment]