A framework for Token Based Firewalling in Hybrid GMPLS networks.

Introduction.

Application of the IETF Generalized Multi Protocol Label Switching (GMPLS) architecture is becoming increasingly popular as a control plane solution for optical networks working in parallel with a common routed IP network. Such an approach is called hybrid networking. The Dutch SURFnet-6 is one of the first example of such a networks. GMPLS deploys a separate data forwarding plane and control plane. The control plane uses the ReSerVation Protocol (RSVP), modified to allow Traffic Engineering (TE) as signalling protocol. The EU-IST funded Phosphorus project, the NSF funded DRAGON project, the MCNC enLightened testbed and the Internet2 HOPI project are examples of initiatives that researches and develops deployment of GMPLS. Commercial interest is also emerging. This chapter will describe an innovation that will enhance the secure use of GMPLS based networks by creating a firewall function that can sit between a routed (connection-less) packet based network and the switched (connection-oriented) GMPLS network, which needs protection against unauthorized usage. Tokens will be used to mark the authorization of certain IP steams to make use of resources inside a GMPLS network. The firewall will route non-authorized IP streams to a transit network.

GMPLS

GMPLS RFC3471 is a generalization of the MPLS architecture RFC3031, which is intended to create connections across packet- or cell (ATM) based networks. In MPLS, packets or cells are forwarded using labels carried inside the data. Such an approach requires a minimum amount of processing during the forwarding process as a label already identifies a path, which is pre-established by a separate control plane using a signalling protocol called RSVP RFC2205. GMPLS removes the requirement for switching devices to be able to recognize packets or cells and consequently the requirement to forward data based on label information. As such, GMPLS adds capabilities to forward data based on for example time-slot numbers, wavelengths, physical ports or Virtual LAN number instead. As such GMPLS can support an intermix of various network technologies based on SONET TDM switches, MEMS fiber switches, 802.1Q VLAN switches etc. In order to support signalling for 3 additional classes of switching (based on Time, Wavelengths and Ports) inside the GMPLS control plane, the RSVP protocol been enhanced with Traffic Engineering extentions (RSVP-TE) as defined in RFC3473.

Security and Access Control in GMPLS networks.

Policy based Access Control requirements in GMPLS networks to support Grids.

Within Grid systems, (meta-) schedulers may need to reserve, cancel or (re-)allocate network connections that are co-allocated with other Grid resources to (competing) applications. The scheduler may continually re-evaluate the most optimal resource allocations for a given system and network workload. Given the fact that GMPLS based network resources are available, the scheduler needs to determine that certain applications should access a specific connection across a GMPLS network. However it may not be clear at the time of reservation which application will use a particular connection at what time and for how long. This is question can only be answered by the scheduler, sometimes only a few seconds in advance. Furthermore the scheduler can only determine a correct answer if it assumes guaranteed availability of a number of different resources, including the network. Schedulers may also determine that certain applications should use the best effort Internet in order to achieve the most optimal solution for a given workload.

When considering the concept of a GMPLS domain, RFC4726 recognizes that the ingress point of a GMPLS domain is a natural point for policy control. In order to assist one or more scheduler to ensure that assumptions of network availability are accurate, it helps if the ingress point can enforce access based on a secured reservation-id. As multiple scheduling agents may reserve network resources, the concept of accepting a ticket or secure token at the ingress point of a network has proven to be pragmatic. Many examples such a systems can be found in transportation networks such as airline-, train- and bus networks. In our research case, the RSVP protocol allows ticket or secure token information to be contained in a POLICY_DATA object as described in RFC2750. In this context, we define a secure token as a signed list of attributes, where at least one attribute identifies a particular service instance. In order to recognize the authenticity and integrity of the token, key material must be shared between the authority issuing the right to access the service instance and the network ingress point that enforces the access. The authority may be a complex set of middleware functions, which includes a scheduler. As such the GMPLS Network ingress point can be considered as a firewall, admitting only an Authorized Label Switched Path (ALSP).

GMPLS firewall architecture.

Below figure shows some basic network elements around the concept of a GMPLS firewall.

The GMPLS firewall sits in between a network that connects a GMPLS client. In effect the GMPLS firewall acts a s proxy for the GMPLS Ingress LSR to which it would normally connect. The GMPLS firewall is connected to the GMPLS Ingress LSR and to the Routed Internet, offering transit (i.e. connectivity to the entire Internet). Both the Firewall and GMPLS client are provisioned with the propper key material, such that the content of the POLICY_DATA object can be signed by the client and recognized by the GMPLS firewall. The content of the POLICY_DATA object is dependant on the application, but for scalability reasons it should be minimal. If the content of the POLICY_DATA object, acting as a secure token, only refers to some pre-provisioned behaviour, that is programmed into the firewall, it has the advantage that the GMPLS client does not have to be aware of- or required to handle the associated attributes. The pre-provisioned behavior could identify future time-slots, source/destination contraints, route and bandwidth constraints etc. As a minimum the POLICY_DATA object should carry some ID and signature.

Conclusion.

The above is intended to act as a framework describing an approach to use the RFC2750 POLICY_DATA object as secure token. Further research needs to be performed to identify what attributes should be carried inside the POLICY_DATA object, how key material should be distributed and what policies should govern the issueing of the keys, in particular in multi-domain GMPLS network scenario’s.

Attachments:

token_based_gmpls.png [TokenBasedAndGMPLS/token_based_gmpls.png]