Internet Draft Jim Boyle Expiration: January 25, 1998 MCI File: draft-ietf-rsvp-pepci-00.txt Ron Cohen Class Data Systems Laura Cunningham MCI David Durham Intel Arun Sastry Cisco Raj Yavatkar Intel Protocol for Exchange of PoliCy Information (PEPCI) July 25, 1997 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Boyle et. al. Expires January 25, 1998 [Page 1]
Internet Draft PEPCI July 25, 1997 Abstract This document describes a simple client/server model for supporting policy for RSVP, and is designed to be extensible so that other kinds of client types may be supported in the future. The model does not make any assumptions about the algorithm of the policy server, but is based on the server returning a single priority value in response to a policy request. The objective is to use this very basic model to begin policy experimentation. 1. Introduction This document describes Protocol for Exchange of PoliCy Information (PEPCI) which can be used to exchange policy information between a policy server and its clients. The policy clients are expected to be RSVP routers, that must exercise policy-based admission control over RSVP usage. We assume that at least one policy server exists in each routing domain. The basic model of interaction between a policy server and its clients is compatible with the RSVP extensions for policy control [EXT]. A chief objective of our proposal is to begin with a simple design for easy/quick deployment, testing, and experimentation. The main characteristics of the proposed protocol include: 1. The protocol uses TCP as the transport protocol for reliable exchange of messages between policy clients and a server. Therefore, no additional mechanisms are necessary for reliable communication between a server and its clients. 2. The protocol is designed to leverage off existing RSVP implementations and makes extensive use of RSVP-like self- identifying objects. 3. Even though the protocol is mainly intended for administration and enforcement of policies in conjunction with RSVP, the protocol may be extended for administration of other policies such as multicast group access and network security. 4. The protocol relies on existing protocols for message authentication. Namely IPSEC [IPSEC] can be used to authenticate and secure the channel between the LPM and the server and RSVP MD5 message authentication [MD5] can be used for inter-node authentication. Boyle et. al. Expires January 25, 1998 [Page 2]
Internet Draft PEPCI July 25, 1997 5. Messages are exchanged asynchronously and there is no need for error control or specific sequencing of messages. 1.1. Basic Model We assume that each participating router has a Local Policy Module (LPM) [LPM] and may communicate with a policy server for policy decisions. It is assumed that most communication with a policy server will be done by border routers upon entry of an RSVP message into a routing domain, although this protocol is not restricted to such a model. A policy client establishes a TCP connection to the policy server to begin communication and uses the connection to send requests to and receive responses from the server. Communication between client and server is mainly in the form of a request/response exchange, though the server may occasionally send an unsolicited response to the client to force a change to a previously approved state. The response from the server is in the form of Accept(Priority). The priority returned by the policy server is a non-negative integer indicating priority. Higher numbers indicate higher priority, and the LPM interprets 0 as an indicator to completely deny the request. A single policy value indicating priority enables the routers to sort and kill sessions without requiring server intervention. For example, suppose a router has already successfully admitted and installed a reservation with priority 5. Later, if a new reservation request comes in and is approved by the policy server at priority 10, but cannot be admitted due to local admission control at the client, the client can remove the previously admitted reservation (with priority 5) to make room for the newer, higher priority reservation. The LPM keeps state of known RSVP messages and processes policy as part of admission control. In particular, the LPM keeps track of the priority associated with each reservation message received. When a new PATH or RESV message is received, the LPM sends a new request message to the server. The client includes RSVP objects from the message in question and establishes a request identification handle (RIH) for future reference to this message. It should be noted that this is done rather early in RSVP processing [RSVPPROC]. The server responds with ACCEPT/REJECT indication and may optionally include objects that provide for modification of the original message. If the message is accepted, it is further processed by RSVP including RESV merging with other messages if necessary. If RESV messages are merged, the client may end up with several policy objects to merge. Boyle et. al. Expires January 25, 1998 [Page 3]
Internet Draft PEPCI July 25, 1997 This is resolved by attaching the Policy Object of the "largest" downstream RESV to the forwarded RESV message. In the event of a "tie" (i.e. there are multiple reservations that can be considered the "largest" reservation), we will include the policy objects from all the reservations. Boyle et. al. Expires January 25, 1998 [Page 4]
Internet Draft PEPCI July 25, 1997 For example, if a router receives two RESV messages for the same session, it will check with the policy server separately for each message and then keep track of the priority received as part of the RSB for each message. When the two RESVs are successfully merged, the merged RESV is forwarded with the policy object of the "larger" original message. If the higher priority reservation is later torn down, the existing reservation would then revert to the next "largest" reservation. The RSVP implementation must keep track of the associated priority. This could result in the lower priority reservation "riding" the priority of a higher reservation and then being torn down once the higher priority reservation is gone and other reservations pre-empt the lower priority one. This is considered acceptable as a side effect of merging benefits. Under this model, both the policy server and its client maintain state associated with a particular request. Failure of a client or the server is detected by the loss of a TCP connection. Upon failure, a client connects to a new server and the new server syncs up with the client. Boyle et. al. Expires January 25, 1998 [Page 5]
Internet Draft PEPCI July 25, 1997 2. The Protocol This section describes the message formats and objects used by the LPM and Policy Server. 2.1 Common Header Each PEPCI message consists of the PEPCI header followed by a number of client-specific objects. 0 1 2 3 +--------------+--------------+--------------+--------------+ |Version|Flags | Client Type | Op Code | +--------------+--------------+--------------+--------------+ | RIH | +--------------+--------------+--------------+--------------+ | Message Length | +--------------+--------------+--------------+--------------+ The fields in the header are: Version: 4 bits PEPCI version number. Current version is 1. Flags: 4 bits Flag bits Client Type: 16 bits The type identification for the policy client Interpretation of all encapsulated objects is relative to the client type. The client type of 1 indicates an RSVP client using RSVP V1 objects. In the future, further types may be defined to accommodate types of policies other than bandwidth and to accommodate new versions of RSVP. Boyle et. al. Expires January 25, 1998 [Page 6]
Internet Draft PEPCI July 25, 1997 Op Code: 8 bits The PEPCI operations: 1 = Request Query (RQ) 2 = Request Response (RR) 3 = Request Allowed (RA) 4 = Delete Request (DRQ) 5 = Synchronize State Req (SSQ) 6 = Synchronize State Resp (SSR) 7 = Unsolicited Response (USR) RIH (Request Identification Handle): 32 bits Client side value to uniquely identify message/association. For example, an RSVP client will provide a handle to identify a reservation request so that subsequent operations that apply to the same message can be easily identified. Similarly, if PATH control is desired, an RSVP client would send the RSVP objects associated with the PATH to the server and supply a RIH handle for future references to this PATH state. Message Length: 32 bits Size of message in bytes. This includes all encapsulated objects, but not including the standard PEPCI header. Boyle et. al. Expires January 25, 1998 [Page 7]
Internet Draft PEPCI July 25, 1997 2.2 Object Formats All the objects follow the RSVP object format; each object consists of one or more 32-bit words with a one-word header, with the following format: 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | | // (Object contents) // | | +-------------+-------------+-------------+-------------+ The Class Numbers are chosen to start with high values so as not to conflict with Class Number values already defined for RSVP objects. The choice of PEPCI specific class numbers ensures that PEPCI- specific objects are never forwarded beyond the policy client. 2.2.1 RSVP Objects RSVP Objects can be copied as is into PEPCI messages. The first Request Query which initializes the RIH for the message includes a large portion of the RSVP message. In a PATH message, for instance, there is no relevant information in the Integrity object and the relevant information in the RSVP common header is included with the PEPCI context object. So, the initial PEPCI request query from the LPM to the server about an RSVP PATH message includes all the remaining RSVP objects starting with the session object. These are not encapsulated into PEPCI objects. RESV RSVP messages will contain the Session, Flowspec, Style, and, if applicable, the Filter objects. The server can return a Policy Object within a Request Response which the LPM must substitute for the Policy Object(s) that the router received within that RSVP message. Boyle et. al. Expires January 25, 1998 [Page 8]
Internet Draft PEPCI July 25, 1997 2.2.2 Priority Object As stated earlier, the priority object is used to specify the relative priorities among different reservation requests. A priority of zero indicates a DENY. A priority value is encoded as an unsigned, 16-bit integer value. Class-Num = 128, C-Type = 1 0 1 2 3 +--------------+--------------+--------------+--------------+ | Priority | //// Reserved //// | +--------------+--------------+--------------+--------------+ 2.2.3 Handle Object The handle object is designed to carry a handle that identifies a particular association (such as a complete reservation request or parts such as a particular PATH state). The handle is a 32-bit number chosen by a policy client at the time of sending a new request to the policy server. Handles are optional for both the client and server, and there is no special negotiation needed (between the client and server) to determine the usage of the handle. Class-Num = 129, C-Type = 1 +--------------+--------------+--------------+--------------+ | Request Identification Handle | +--------------+--------------+--------------+--------------+ Boyle et. al. Expires January 25, 1998 [Page 9]
Internet Draft PEPCI July 25, 1997 2.2.4 Reason Code Object A one octet, integer value used to provide additional reasons for a particular response or a particular delete state notification. Class-Num = 130, C-Type = 1 +--------------+--------------+--------------+--------------+ | Reason code | /////// RESERVED /////// | +--------------+--------------+--------------+--------------+ 2.2.5 Hold Off Timer Object The Hold Off Timer is used to specify the length of time for which a given policy is valid, or the length of time the LPM should wait before asking the policy server for a new policy value for a given RIH. This timer acts as a simple mechanism to prevent denial of service attacks on a policy server. It also works to ensure that policy information must be renewed periodically. Times are encoded as 32-bit integer values and are in units of seconds. The time value is treated as a delta from the point at which the LPM receives the message containing the Hold Off Timer. LPM implementation of this object is mandatory for clients, but its use by servers is optional. Class-Num = 131, C-Type = 1 +--------------+--------------+--------------+--------------+ | Hold Off Timer | +--------------+--------------+--------------+--------------+ Boyle et. al. Expires January 25, 1998 [Page 10]
Internet Draft PEPCI July 25, 1997 2.2.6 Interface Object The interface object is used to identify particular interfaces on a router. It is a 32-bit integer field whose value is the same as the SNMP ifIndex value for that interface. There are two types of interfaces : incoming interfaces and outgoing interfaces. An incoming interface is the interface on which the RSVP message was received, and an outgoing interface is one on which the RSVP message is being forwarded. in-interface: Class-Num = 132, C-Type = 1 out-interface Class-Num = 133, C-Type = 1 0 1 2 3 +--------------+--------------+--------------+--------------+ | ifIndex | +--------------+--------------+--------------+--------------+ 2.2.7 Context Object The context object carries the RSVP message type (PATH, RESV, etc.) of the RSVP message that triggered the query. Class-Num = 134, C-Type = 1 0 1 2 3 +--------------+--------------+--------------+--------------+ | RSVP MsgType | //// Reserved //// | +--------------+--------------+--------------+--------------+ Boyle et. al. Expires January 25, 1998 [Page 11]
Internet Draft PEPCI July 25, 1997 2.3 Request Query (RQ) LPM -> Policy Server The client establishes a Request Identification Handle (RIH) which the server maintains a state for, and uses to refer to this RSVP message. It also sends portions of the RSVP message so Policy Servers of varying complexity can use any information from the message without requiring that the LPM make a determination of what to parse out and send to the server. Once a RIH is established with a new request, any subsequent modifications of the request can be made using the RQ message with a previously established RIH. For example, when a change in a reservation happens on a refresh (or some other means such as SNMP- based state change on a router), the router will simply supply the new information in a RQ message with the existing RIH associated with the reservation state. The format of the Request Query message is as follows: <Request Query> ::= <Common Header> <Context><in-interface> <RSVP Objects> [<Additional objects>] The additional objects are optional and can give more information on the RSVP state. For example, in queries with Path context, the additional objects may be a list of out-interface objects which specify the outgoing interfaces on which this Path message is going to be forwarded. Similarly, we can have a Reservation query with multiple objects for the associated PATH states, e.g. <Request Query> ::= <Common Header> <Context=RESV><in-interface> <RSVP RESV Objects> <associated path handle #1> <associated path handle #2> <associated path handle #3> Boyle et. al. Expires January 25, 1998 [Page 12]
Internet Draft PEPCI July 25, 1997 2.4. Request Response (RR) Policy Server -> LPM The server responds to the RQ with a RR message that includes the associated RIH and the response. The priority value included in the response indicates the result such as Deny (priority = 0 means Reject) or Accept. In addition, the response may optionally include policy objects (OUT_POLICY), whose structure is defined in [EXT], to replace the incoming policy object(s). This assumes wholesale replacement of a previously received policy object(s) with appropriate modifications. In order to avoid the issue of keeping track of which Request Query a particular response belongs to, it is important that, for a given RIH, there be at most one outstanding response per query. This essentially means that the client should not issue more than one RQ (for a given RIH) before it receives a corresponding RR. The format of the Request Response message is as follows: <Request Response> ::= <Common Header> <Priority> [ <Hold Off Timer> ] [ <OUT_POLICY> ] [ <Additional objects> ] The additional objects are optional and can give more information on replacement of policy objects, and can permit the extension of policy enforcement capabilities. For example, the additional objects may carry <out-interface><OUT_POLICY> pairs, indicating that when forwarding the message out that particular interface, the policy object associated with this interface should supersede the policy object received. This may be useful in multicast cases where different policy objects should be forwarded out different interfaces. The exact format of additional objects is left for future work. A router that does not support these additional objects should ignore them. Boyle et. al. Expires January 25, 1998 [Page 13]
Internet Draft PEPCI July 25, 1997 2.5. Request Allowed (RA) LPM -> Policy Server This message serves as an acknowledgment to the server that a particular request response has been acted upon. <Request Allowed> ::== <Common Header> <Priority> 2.6. Delete Request (DRQ) LPM -> Policy Server This message indicates to the server that the PATH or RESV state has been deleted. This will be used by the server to initiate appropriate clean up actions. Reasons may include: PATH_ or RESV_TEAR, pre- emption, SNMP, loss of soft state. The format of the Delete Request message is as follows: <Delete Request> ::= <Common Header> <Reason Code Object> Reason Code: 16 bits Reason Code = 0 Unknown 1 Priority Changed 2 Pre-empted 3 TEAR 4 SNMP request 5 Loss of Soft State Boyle et. al. Expires January 25, 1998 [Page 14]
Internet Draft PEPCI July 25, 1997 2.7. Synchronize State Request (SSQ) Policy Server -> LPM; The server uses this message to request a list of state that has been approved and not yet deleted. A case where this would be used is in server connection startup time. A long or short response may be provided, and is indicated by a bit in the flag value. A short answer provides just a list of RIH values with their current priority and their context and incoming interface. A long answer additionally provides the original RSVP message along with the OUT_POLICY object. Flag: LONG_ANSWER 0x1 Each RSVP message is sent in a separate policy message. The format of the Synchronize State Query message is as follows: <Synchronize State> ::= <Common Header> If the RIH is specified (a nonzero value), the server queries about the state of a particular request. RIH=0 indicates that server wishes to synchronize all the state. 2.8. Synchronize State Response (SSR) LPM -> Policy Server The format of the Synchronize State Response message is as follows: <Synchronize State> ::= <Common Header> <Priority #1><Handle #1> <Context><in-Interface> If Long: <RSVP Object><OUT-POLICY> endIf Long: <Priority #2><Handle #2> <Context><in-Interface> If Long: <RSVP Object><OUT-POLICY> endIf Long: Boyle et. al. Expires January 25, 1998 [Page 15]
Internet Draft PEPCI July 25, 1997 2.9 Unsolicited Response (USR) Policy Server -> LPM The server can also send an unsolicited response to a client. One example where this can happen is when a policy change is made at the server, and a corresponding change needs to be effected at the client (e.g. change a policy for a particular reservation to DENY, so that reservation needs to be deleted.) The format for an USR is the same as that for a RR. 2.10 ResvErr and PathErr control Policy control over RSVP Error messages is left as an option. RSVP error messages carry policy objects which may add information to the RSVP nodes along the way. Policy error messages generated by the router after the server has denied a query request should carry the policy objects returned in the query response. Error messages received from other routers are handled much like Path and Resv messages. Since policy error messages do not create states, the only PEPCI messages used are Request Query and Request Response. The router should use a temporary handle that will allow it to match reply to response, but otherwise has no significance. Boyle et. al. Expires January 25, 1998 [Page 16]
Internet Draft PEPCI July 25, 1997 3. Operation This section lists some sample exchanges between policy servers and LPM clients. 3.1. Client receives a new RSVP message, gets permission from Policy server, and, later, deletes the state when RESV is torn down. Client -> Server: RQ "RIH=4, RSVP objects incl. policy data" Server -> Client: RR "RIH=4, Priority=5, OUT-POLICY" Client -> Server: RA "RIH=4, Priority=5" Client -> Server: DRQ "RIH=4, Reason Code = TEAR" Client gets another RESV for the same session. We assume that the client first checks with the policy server and then does local merging, before forwarding the resulting policy objects within the merged RESV towards PHOP(s). Client -> Server: RQ "RIH=11, objects in new incoming RESV inc' policy data" Server -> Client: RR "RIH=11, Priority=6, OUT-POLICY" Client -> Server: RA "RIH=11, Priority=6" 3.2. Server changes priority of an existing request. Server -> Client: USR "RIH=4, NewPriority = 10, Reason Code = 1, OUT-POLICY" Client -> Server: RA "RIH=4, Priority=10" or, Server decides to pre-empt or abort a request accepted earlier by sending an USR with priority zero Server -> Client: USR "RIH=4, NewPriority = 0, Reason Code = 1, OUT-POLICY" Client -> Server: DRQ "RIH=4, Reason Code = Preempt" Boyle et. al. Expires January 25, 1998 [Page 17]
Internet Draft PEPCI July 25, 1997 3.3. Example of use of handle objects Client receives a PATH message, first contact the server for PATH control Client -> Server: RQ "RIH = 100, RSVP objects in the PATH message, policy data" Server -> Client: RR "RIH = 100, OUT_POLICY" Later, the client receives a RESV for the same session and wishes to include the PATH state info in its request. It uses RIH=100 (previously established handle) to associate the relevant PATH state with its NEW request as in: Client -> Server: RQ "RIH=7, RSVP objects, Policy data, Handle = 100" Server examines the information in the Query and the information about the Path state stored from previous query on Path and reaches a policy decision: Server -> Client: RR "RIH=7, priority = 1, OUT-Policy" Boyle et. al. Expires January 25, 1998 [Page 18]
Internet Draft PEPCI July 25, 1997 3.4. Server inquires about RIH 4. Server -> Client: SSQ (Long) "RIH=4" Client -> Server: SSR (Long) "RIH=4, Priority=10, OUT-POLICY, RSVP Objects " 3.5 Server requests a list of state. Server -> Client: SSQ(Long, RIH=0) Client -> Server: SSR(Long) "RIH=2, Context, In-Interface, Priority=1, OUT-POLICY, RSVP_MESSAGE RIH=4, Context, In-Interface, Priority=10, OUT-POLICY, RSVP_MESSAGE RIH=5, Context, In-Interface, Priority=10, OUT-POLICY, RSVP_MESSAGE RIH=8, Context, In-Interface, Priority=100, OUT-POLICY, RSVP_MESSAGE" 3.6 State Torn Down Client -> Server: DRQ "RIH=4, Reason=Tear" 3.7 Admission error handling The client receives a RESV message and determines that this reservation was previously admitted using handle 100. Assuming that the flowspec of the new reservation is different, we might have something like: Client -> Server: RQ "RIH=100 NewFlowSpec, Policy data" Server -> Client: RR "RIH=100, Priority=4" The client tries to admit the reservation. If it fails, it tries to preempt installed reservations with lower priority. If it is still unable to admit the reservation, it does not send a RA indication, and performs the admission error operations as defined in [RSVP], including sending a ResvErr frame. According to [RSVP] the client should still keep the old active installed reservation. The client Boyle et. al. Expires January 25, 1998 [Page 19]
Internet Draft PEPCI July 25, 1997 will send a DRQ to the server only if it deletes an active (RESV/PATH) state. In order to keep the server in sync, the client will reissue a query to approve its active state: Client -> Server: RQ "RIH=100 ActiveFlowSpec, Policy data" Server -> Client: RR "RIH=100, Priority=4" Client -> Server: RA "RIH=100, Priority=4" 3.8 ADSPEC control The following example describes a possible use of PEPCI to control ADSPEC values. The receiver uses the ADSPEC values received in the PATH message to decide on what QoS parameters are sent in the RESV message. The server may want to update the parameter AVAILABLE-PATH BANDWIDTH [INSCH] in the ADSPEC. This value carries information about the maximum bandwidth the receiver can successfully reserve due to physical resources limitations and bandwidth policy limitations. Client -> Server: RQ "RIH=12, Path objects including Adspec, out-intfc 2 " Server pulls the ADSPEC from the request, and updates the Available path bandwidth parameter. Server -> Client: RR "RIH=12, Priority=2, out-intfc=2, newAdspec " Client updates the values in newAdspec, if necessary, and sends it in the PATH message sent via interface 2. Boyle et. al. Expires January 25, 1998 [Page 20]
Internet Draft PEPCI July 25, 1997 4. Security As mentioned in Section 2, security of RSVP messages is provided by inter-router MD5 authentication. This assumes a chain-of-trust model for inter LPM authentication. Security between LPM and server is provided by IPSEC. To ensure an LPM is talking to the correct policy server involves two issues: authentication of the policy client and server using a shared secret, and consistent proof that the connection remains valid. The shared secret requires manual configuration of keys, which is a maintenance issue. For validation of the connection, IPSEC AH will be used. 5. Open issues 6. References [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - Functional Specification." Internet-Draft, draft-ietf-rsvp-spec-16.txt, June 1997. [EXT] Herzog, S., "RSVP Extensions for Policy Control." Internet- Draft, draft-ietf-rsvp-policy-ext-02.txt, April 1997 [INSCH] Shenker, S., Wroclawski, J., "General Characterization Parameters for Integrated Service Network Elements" Internet-Draft, draft-ietf-intserv-charac-02.txt, October 1996 [IPSEC] Atkinson, R., "Security Architecture for the Internet Protocol." RFC1825, August 1995. [MD5] Baker, F., "RSVP Cryptographic Authentication." Internet-Draft, draft-ietf-rsvp-md5-03.txt, May 1997. [LPM] Herzog, S., "Local Policy Modules (LPM): Policy Control for RSVP." Internet-Draft, draft-ietf-rsvp-policy-lpm-01.ps, November 1996. [RSVPPROC] Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing Rules." Internet-Draft, draft-ietf- rsvp-procrules-00.txt, November 1996. Boyle et. al. Expires January 25, 1998 [Page 21]
Internet Draft PEPCI July 25, 1997 6. Author Information and Acknowledgments Thanks Fred! Jim Boyle Ron Cohen MCI Class Data Systems 2100 Reston Parkway 13 Hasadna St. Reston, VA 20191 Ra'anana 43650 Israel 703.715.7006 972.9.7462020 jboyle@mci.net ronc@classdata.com Laura Cunningham David Durham MCI Intel 2100 Reston Parkway 2111 NE 25th Avenue Reston, VA 20191 Hillsboro, OR 97124 703.715.7085 503.264.6232 lcunning@mci.net David_Durham@ccm.jf.intel.com Arun Sastry Raj Yavatkar Cisco Systems Intel 210 W Tasman Drive 2111 NE 25th Avenue San Jose, CA 95134 Hillsboro, OR 97124 408.526.7685 503.264.9077 asastry@cisco.com yavatkar@ibeam.intel.com Boyle et. al. Expires January 25, 1998 [Page 22]
