To develop and deploy a new service that can provide secure guaranteed bandwidth circuits within ESnet, and interoperate with reservation servers in other domains.
OSCARS is an acronym for On-Demand Secure Circuits and Advance Reservation System. The focus of OSCARS is on facilitating bandwidth-intensive large scientific projects.
This document lists the requirements for the reservation manager (RM) component of OSCARS, updated for year 3 of the project. The requirements for the RM include setting up user accounts, setting up and tracking reservations and circuits, handling security and monitoring, and accounting. Items with a (*) after them are scheduled to be done this year. Items with a (?) may or may not be implemented.
Security is absolutely essential. The impact of an abuse could be very large. A DoS attack could prevent reservations from being processed. If the service is compromised, and thus the routers it has access to, the WAN may be disabled. Discussion of the security implications of requirements are postponed until the section on security.
Current requirements are largely taken from Chin Guok's Powerpoint presentations, the OSCARS project Web page, discussions with QoS/MPLS researchers at other DOE labs, Internet2, and GÉANT2, and from lessons learned thus far. If possible, there may be code sharing/reuse between these researchers and ESnet. Additional security requirements have been arrived at through discussion with researchers from the Distributed Systems Department of the Lawrence Berkeley National Laboratory.
This document covers the requirements for the RM and its clients. The requirements for the other major component of OSCARS, which handles the details of setting up the guaranteed bandwidth circuit using MPLS and RSVP, are listed in the OSCARS full proposal.
The RM must interoperate with other autonomous domains, to enable reservations where the end-to-end path may traverse several such domains. Interdomain reservation setup is discussed in the section on the network-to-network interface (NNI).
Specific design decisions are in a companion document, the OSCARS RM design specification.
Installation and use must be easy as possible. A standard, well-known mechanism to implement operations such as transport and server capability, for example Tomcat or SOAP, is to be preferred.
The manager must be able to run in conjunction with current ESnet proprietary network management systems, as well as in a completely open source mode that other organizations can incorporate and use without additional licensing.
The RM must have four subsystems:
The AAA must be used to authenticate and authorize all external requests, whether from the interactive interface, or the API. User account names must be globally unique.
In addition to the authentication and authorization process, which may be handled via library calls or client requests to other entities, the AAA handles a number of requests related to its management. These requests must only be accessible via test methods on the machine where the OSCARS server is running, and via the interactive interface. Parameters to these requests are listed in a section below.
The following requests must be handled from interactive clients that have successfully authenticated themselves, but require no additional authorization:
The following requests require that a user have the proper authorization:
Requests related to the reservation of bandwidth are handled by the BSS, and are detailed in the next section.
The BSS must accept reservations, keep track of reservations, and maintain information necessary for future reservations:
The BSS must maintain policies associated with the scheduling and actual use of the network, detect any out-of-policy usage, and enforce the policies that are not handled by network management tools at the router level. Enforcement at the router level is not in the scope of this document, but information that may be necessary for such enforcement should be communicated to the PSS.
The BSS must handle the following client requests, whether via the API or the interactive interface, after authentication by the AAA:
The following notifications must be made to clients, and must include the status of a reservation, the bandwidth allocated, and the QoS value:
The PSS must set up and tear down the on-demand circuits on the appropriate routers, based on a request by the BSS. To do so, it must change the router configuration on the start and end of the circuit.
Prior to circuit setup, the PSS must validate the route to use, and query routers along the path to check for "illegal" active circuits that could conflict with bandwidth reservation (*).
The user interface must provide means for making all requests listed in the sections on the AAA and BSS. Client requests generated by either interactive or automated means must use the same transport and message encoding (for example, SOAP) to communicate with the RM.
The API for automated reservations by user applications should utilize well-known mechanisms. A service description must be provided that will allow automated use of the API (AAA portion remains to be done).
The interactive interface must be simple and intuitive. It must prompt a user for a credential (username/password) before allowing any requests. It must in general operate within the trusted domain of the reservations manager.
After login, the interactive interface must provide entry forms to gather the information for requests, which may require an additional step of sending the information gathered as a message to the RM. Several requests may be combined on a single entry form.
For each mandatory and optional argument listed below, an entry form must have corresponding input fields and/or interactive controls. The entry form must not include input fields corresponding to arguments requiring special authorizations, if the client does not have the proper authorization. There must be an area on each entry form for status and error messages, which must be updated after each request.
All parameters must be validated on the client side before sending a request to the RM, to avoid unnecessary waiting time for the client if there is an error.
The following sections list the mandatory and optional arguments for each request, and the results returned, if any.
The following requests require additional authorization:
The reservation's source, destination, and requested bandwidth, and the purpose of the reservation are mandatory arguments. The reservation's start time, duration, source and destination ports, the protocol to use, the DSCP bit(s), the ingress and egress loopbacks, and the start time and duration are optional arguments. Default values must be used for the start time and duration if these arguments are empty.
There must be an authorization that can be associated with a user, which is required for use of the following arguments: a traceroute listing, and flags for the setup of a persistent circuit and a bidirectional path.
A disclaimer must be present on the interactive form indicating that if the transit path across ESnet has more than one ingress point, a full traceroute must be provided to ensure that the requested bandwidth along the actual path is available (*).
Upon successful reservation setup, a listing must be returned with the reservation details.
The following requests require additional authorization:
The RM handles mostly intradomain functionality, but the interdomain aspect is crucial. The RM must determine if it is necessary to contact another domain to complete a request. If so, the RM must forward that request to the other domain, and handle the response (partially implemented).
To do so, there must be a standards-based interface for the RM's of different domains to communicate reservation requests. The RM of one domain must be able to interoperate with the RM's of other autonomous domains. High-bandwidth reservations will be needed, for example by LHC users, that traverse multiple domains. This requirement is at a higher level than the OSCARS specification, but it is a requirement of this specification that such an interface, when agreed upon, be implemented (*).
In addition, the AAA must have a mechanism for trusting other domains. It must forward necessary certificates or tokens to the AAA's of other domains to authenticate a client, and assertions to authorize a client to use a domain's RM. The AAA must interoperate with another trusted AAA, even if that system uses a different means of authentication or authorization.
The administration of an end-to-end circuit must conform to security models of all entities along that path. In particular, stages leading towards the rollout of the service must follow the guidelines in the ESnet Security Plan (*).
OSCARS security mechanisms must be as easy to install and use as possible, as long as security is not compromised. A difficult to use system will not be used.
The machine(s) running the AAA, BSS, and PSS must be inside a protected network. The interactive interface must access these components via an identifier (for example a URL) that does not give the location of the server machine(s).
Access to OSCARS must require authentication and authorization. The AAA must authorize and authenticate all OSCARS requests from outside the protected network, and enforce these restrictions.
The AAA must generate usage records for all accesses, for auditing and accounting (?).
OSCARS accounts must be provided for administrators and the appropriate ESnet personnel, and only users with those accounts can have additional OSCARS authorizations. These authorizations, allowing different levels of access, must be maintained and enforced.
Automated messages to OSCARS must be signed and encrypted. Automated access does not necessarily require an OSCARS account, if it does not require the above-mentioned authorizations. A valid server certificate is sufficient if the request is coming from a reservations manager from another, trusted autonomous domain.
A secure means must be provided to store authentication information during login through the interactive client, to avoid that client having to authenticate for each subsequent access to OSCARS.
Request parameters must be validated on the server side, whether the client is the API or the interactive interface.
All components of the service must be monitored to ensure that they are not being abused. Notifications of sensitive operations such as reservation scheduling and LSP setup must be sent to the appropriate ESnet personnel, in addition to the client.