NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 18-Mar-98
Chair(s):
T. O'Malley <timo@bbn.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion:ipc@iphighway.com
To Subscribe: majordomo@iphighway.com
In Body: subscribe ipc
Archive: ftp://ftp.iphighway.com/pub/IETF/ipc
Description of Working Group:
Recent work in the IETF has led to the development of standards for a QoS-enabled Internet. Through the efforts of the Integrated Services working group, data flows can describe their desired or required service to the network. RSVP carries the service requests into the network, where the acceptance of these QoS requests results in better network service to some flows, possibly at the expense of service to traditional best-effort flows.
In an open and public Internet (as well as large intranets), maintaining such service differentiation inherently depends on mechanisms capable of enforcing (or reporting) operational policy constraints. Towards this end, RSVP message formats contain a place-holder for policy data0 elements, which may contain information relevant to the network's decision to grant a reservation request.
Certain network elements may require assistance in the processing of these policy-data elements and, therefore, may communicate with one or more policy servers, entities which specialize in the making of policy decisions.
The purpose of the IPC working group is to establish a scalable policy control model for RSVP. The working group will specify a protocol for use among RSVP-capable network nodes and policy servers. This work will also require documentation of any extensions to RSVP which may be necessary in support of this policy control.
Documents produced by the working group must fully address all the security aspects of this type of protocol. In particular, theft and denial of service threats must be minimized.
In pursuit of these goals, the working group must expressly avoid specifying policy behavior. The judgment of specific policies is similarly beyond the scope of the working group. The working group will, however, specify mechanisms that allow for a wide variety of possible policies to be carried out.
Goals and Milestones:
Jul 98 |
|
Submit I-D framework document for policy control for RSVP to IESG for publication as a RFC. |
Aug 98 |
|
Submit I-D defining any necessary extensions to RSVP to support policy control to IESG for publication as a RFC |
Jan 99 |
|
Submit I-D defining a standard protocol for the exchange of policy information between RSVP-capable network nodes and policy servers to IESG for publication as a RFC. |
Internet-Drafts:
· A Framework for Policy-based Admission Control
· The COPS (Common Open Policy Service) Protocol
· RSVP Extensions for Policy Control
· User Identity Representation for RSVP
No Request For Comments
Minutes of the RSVP Admission Policy (rap) Working Group
Recorded by: Ron Cohen, Class Data Systems
Edited by: Timothy O'Malley, GTE Internetworking
Timothy O'Malley, chair of the WG, started off with a brief welcome to the audience. He reminded everyone of the goals of the WG, which are to produce three drafts, and the associated time frame, the last of the drafts is scheduled for submittal in January of 1999. For more information regarding these milestones see the WG web page, located at http://www.ietf.org/html.charters/rap-charter.html.
The first two presentations discussed work related to RSVP Policy Admission, but not within the charter of the group. Thus, the represent related-work and not imminent standards.
Raju Rajan of IBM presented a directory schema for the representation of policy rules, outlined in draft-ellesson-sla-schema-00.txt. Widely deployed and well-understood, LDAP makes a natural choice for the mechanism to retrieve policy rules. These rules should work for both RSVP and DiffServ policy description. The codification of rules, and in this case policy rules, leads to the problem of what to do when multiple policy rules apply. Raju presented three alternatives:
1) An ordered policy representation removes any ambiguity but also makes the insertion of new rules difficult because the "right" place in the rule ordering must be found.
2) An order-independent representation would improve the efficiency of the searches but requires a more sophisticated algorithm to insert new rules.
3) The draft advocates an approach combining the above two features.
A person from the floor mentioned that the RTFM WG has already done some work into the representation of policy-like rules in a directory schema. Raju mentioned he would look into that work.
The floor was then handed to Ramesh Pabbati, of Microsoft, who discussed the draft-ietf-rap-user-identity-00.txt draft. The goal of this work is to identify to the first RSVP hop, which must be policy-aware, the identity of the user requesting the RSVP service. Of course, the issue here is to do this in a secure manner. As Ramesh described, this work suggests tying the functionality of the RSVP MD5 Integrity object, which provides hop-by-hop integrity, with user keys. This is done by taking the key contained in the user-id policy element and doing authentication with it on the whole message. The side advantage of that is that you don't need to configure all host for MD-5 secrets with the first host router, to achieve usual MD-5 authentication. Replay attacks are handled by the sequence number in the RSVP-AUTH object.
Next at the microphone, David Durham of Intel and Shai Herzog of IPHighway discussed COPS version 01, draft-ietf-rap-cops-01.txt. David began by explaining the changes in COPS since the first draft. If a policy server wishes to terminate a connection with a client, it can now optionally include a 'redirect' parameter, which indicates to the client the location of a new server. This could be used for a backup policy server to return its clients to the main policy server, when it comes back on line. Other changes include the addition of several error codes, the removal of ref-handles for RSVP clients (a change which simplifies the state kept at both the client and the server), and a few minor clarifications to the wording.
James Binder stepped up with a quick question regarding the security of flow statistics in the periodic report messages. Dave noted that IPSEC could be used to provide a secure channel.
Following David's presentation, Shai gave a brief tour through a typical example of COPS in action. This example can be found in Appendix A of the draft. A brief summary of the example: The network node asks and the policy server, who responds with an affirmative. Later, the policy server changes its mind and responds with a negative.
Continuing the tag team presentation, David returned to the front with a list of open issues. First, should COPS support bi-directional connection establishment, which would allow the policy server to initiate the connection? Secondly, should COPS support the replacement of RSVP FlowSpec objects? What is the format of a Priority element. Can or should the policy server instruct the network element to install state, akin to saying "Create this flow"?
Bob Braden noted that the capability to install state approaches the functionality typically provided by SNMP. Where is the boundary, he asked, between COPS and SNMP. Shai (or was it David) expressed that this functionality might have been misplaced in SNMP. The framework document should contain an answer to that question offered Tim O'Malley, the WG chair.
Further discussion on these open issues was then deferred to the mailing list.
A presentation of priority and preemption policy elements and rules followed. Shai Herzog reminded the group of the issues raised at the December meeting, where the merging of heterogeneous flows results in complicated problems when priority is added. If a low-priority, high-bandwidth flow merges with a high-bandwidth, low-priority flow, then what is the characteristics of the resulting merged flow. Using the higher priority creates a large bandwidth flow with high priority, effectively giving the low-bandwidth requester more bandwidth than desirable. Choosing the lower priority allows for a denial of service attack. Perhaps WG should only allow the merging of homogeneous flows? Shai offered a compromise solutions, where the priority element contained a pair of percentages. The first percentage was a lower bound, the second an upper. Flows within that range could merge, and the higher priority was chosen.
This proposal prompted several questions. Tim O'Malley wanted to know if it was possible to take a percentage of a Tspec. Shai answered that the calculation could be inexact, and therefore an approximation would suffice. Bob Braden explained that by ignoring some of the components of the FlowSpec/Rspec this proposal was still allowing a denial of service attack. He also noted that taking a ratio of FlowSpec to Rspec, as the proposal called for, didn't make sense because the units were different. Shai agreed that some more work was needed to solve these issues. Finally, Tim asked what would happen if the merged flow was outside the range of the higher priority reservation. Shai's answer compared it to a blockade state calculation, where the flows are compared to the merge state and excluded if appropriate. Again, there seemed agreement that more work was needed here.
Batting cleanup for the RAP agenda, Ken Pierce presented an introduction to DIAMETER, draft-calhoun-diameter-02.txt. DIAMETER, a significant extension to RADIUS, broadens the scope of RADIUS to support other schemes which require an authorization server. As such, it appears to be a natural fit for RAP, and such a fit is described in draft-calhoun-diameter-res-mgmt-00.txt. The RAP framework draft outlines several faults with RADIUS, each of which DIAMETER has already addressed and fixed. Specifically, DIAMETER has self-identifying objects, supports asynchronous messages from the server, reduces the restriction on message types, and allows any attribute for indexing. Ken also hinted that several industry vendors rally behind the DIAMETER protocol and that a public implementation may be out in near future.
Even before the Ken finished, a lively discussion broke out comparing DIAMETER to COPS. Raj Yavatkar noted that DIAMETER is composed of two layers, the first carrying attributes and the second defining operations, and he therefore wanted to know whether to compare COPS to DIAMETER or to the resource management extension for DIAMETER. Ken suggested trying to think of DIAMETER as a whole. As a follow-up comment, someone (unknown) asked if we were arguing about functionality or bit placements. If we're arguing about the latter, perhaps we should refocus on the former. This question remained unanswered.
Wrapping things up, Timothy O'Malley of GTE Internetworking returned to center stage to point out direction for the next nine months. In order to meet the aggressive schedule, he noted that there would have to be significant discussion on the mailing list. Scott Bradner briefly commandeered the microphone to reiterate the WG's narrow charter, which demands a single, simple policy protocol tailored to the RSVP problem. Timothy O'Malley ended by thanking the presenters and suggesting that further discussion happen on the mailing list.
None Received