RSVP Working Group Minutes 42nd IETF in Chicago Reported by: Steven Berson Tuesday August 25 0900-1000 RSVP Working Group session I meeting minutes A. WORKING GROUP STATUS ------------------------ Co-chair Bob Braden (USC/ISI) opened the meeting with a summary on progress in the RSVP Working Group. Three basic RSVP documents have been published as Proposed Standards: RFC 2205 (RSVP Version 1 Functional Specification), RFC 2206 (RSVP MIB), and RFC 2207 (RSVP extensions for IPSEC). The WG has also published two Informational RFCs: RFC 2209 (RSVP message processing rules) and RFC 2208 (Version 1 Applicability Statement). Several WG documents have yet not been submitted for Proposed Standard: MD5 Integrity, RSVP Diagnostic Messages, and RSVP tunnels. Braden noted that the WG had been dormant since the Munich meeting, and that several new issues that have come up since then merit discussion. B. RAPI STANDARDIZATION ------------------------ Chris Harding (Open Group) spoke on the work in the effort by the XNET Working group of Open Group to standardize the RAPI application programming interface. The original RAPI interface was designed and documented by ISI and Sun Microsystems, and it is included in ISI's rsvpd distribution. As a target for Open group standardization, the original RAPI specification was too ISI-specific, too Unix-specific, and too socket-specific, and its error handling was weak. The January 1998 draft removed the Unix-specific and socket-specific parts, and the June 1998 draft improved error handling and added a specification of the RAPI and Integrated Services data structures that an application needs to know. In July 1998, the draft spec was sent out for company review. Final editing of the spec is scheduled for the end of September, and the spec will then be published on the Web in html. C. RSVP INTEGRITY OBJECT ------------------------- Bob Lindell (USC/ISI) described the updated draft on RSVP Cryptographic Authentication (draft-ietf-rsvp-md5-06.txt). RSVP provides integrity and authentication (but not confidentiality) on a hop-by-hop basis, as opposed to the end-to-end approach of IPSEC. The earlier draft did not reach Proposed Standard because it did not adequately address replay attacks, in the view of the IESG. This version of the draft provides an approach based on a key-id, a one-time sequence number, and an MD5 digest, carried in an RSVP INTEGRITY object. The key-id defines a key and an algorithm. Implementation of the MD5 algorithm is required, but other optional algorithms may be implemented. Each key is simplex and is distributed out-of-band. Each key has a defined lifetime, after which a new key must be negotiated. Sequence numbers are defined to be monotonically increasing, which requires some form of stable storage. For example, an implementation might choose to construct monotonically increasing sequence numbers using a stable hardware clock, a counter in stable storage, or NTP time synchronization. The sequence number only exists for the life of the key, at which time a new initial sequence number is chosen. To provide complete protection against replays, RSVP requires an initial INTEGRITY handshake when the system initializes. This handshake requires a new RSVP message. The receiver sends a challenge to the sender, which responds to the challenge by returning its current sequence number. Out-of-order sequence numbers are handled by keeping a list of the K most recent sequence numbers that have arrived. Braden commented that replayed messages within a small time window just refresh existing state, so they are not a great security threat. The magnitude of the threat need to be balanced against the complexity of mechanisms to protect against the threat. D. USER IDENTITY ----------------- Tim Moore (Microsoft) spoke about draft-ietf-rap-user-identity-00.txt that has been introduced into the RAP WG. Its primary function is to define a User Identify (sub-)object for use within a POLICY object. However, it also draft proposes an extension to the Cryptographic Authentication draft just discussed, to solve what is seen as a scaling problem for the Cryptographic Authentication (INTEGRITY) mechanism across a large campus LAN. Their idea is to use a key associated with the User Identify object, instead of a per-host key, for the integrity hash in the edge of the network. The intent appeared to be that node-specific keys would still be used for hop-by-hop integrity in the interior of the network. Discussion after the meeting clarified the relationship between the User Identity and the INTEGRITY specifications. It should suffice to made a small addition to the INTEGRITY spec, noting that the receiver may have only a cache of keys and may have to consult some external [policy] server to locate the necessary key when an unknown key-id arrives. This addition will be made shortly. There remains the issue of key management, to which User Identity draft adds an important scaling problem. It is not entirely clear which WG needs to address RSVP key management. There are also a number of unresolved issues in the User Identity work, relating to merging User Identity objects. E. RSVP DIAGNOSTIC MESSAGES ---------------------------- Andreas Terzis (UCLA) talked about draft-ietf-rsvp-diagnostics-04.txt, on RSVP diagnostic messages. The current update has no major changes, although some minor improvements have been made. There are some changes in the order of processing of DREQ messages, and an additional paragraph on security considerations. The draft now deals with the issue of ``black holes', where a node understands RSVP but does not understand diagnostic messages. Their approach is to use a traceroute or mtrace approach using multiple messages with increasing ttls to reach the next RSVP node that handles diagnostic messages. UCLA has produced a graphical diagnostic client, with a Java applet front end and a back end written in C. The question was asked if there is a problem with asymmetric paths, Terzis said yes. Discussions after the meeting led to the following conclusions: - There should be no problem with multicast RSVP sessions. - Asymmetric paths can cause problems in unicast sessions if one runs traceroute starting from receiver direction. A obvious solution is to run traceroute from sender direction. The spec is being revised accordingly. Braden commented that the diagnostics draft is mature and doing a last call soon is reasonable. Braden mentioned that vendors had wanted this earlier and questioned whether they still do. No opinions were offered on this. F. RSVP TUNNELS ---------------- Andreas Terzis also talked about draft-ietf-rsvp-tunnel-01.txt. There was a cleanup and reorganization of the draft for this version. There are three types of tunnels defined: (1) at least one tunnel endpoint does not support RSVP tunnels, (2) configured tunnels, and (3) dynamic tunnels created by end-to-end sessions. There is also some support for multicast tunnels, but such tunnels are for signaling only and not for data traffic. UCLA's implementation of tunnels needs to be upgraded to the ISI 4.2a4 release, and the SESSION_ASSOC object needs to be handled on an end-to-end basis rather than between the tunnel end-points. Braden mentioned that the tunnels work, which is less mature than Diagnostic messages, seems to be part of a larger picture, which seems to include diff-serv tunnels, MPLS, and mobile IP. Lixia and George Swallow stated that MPLS is a separate issue, but Scott Bradner said that the problem set in MPLS is similar to the problem set with RSVP tunnels, so the solutions should be similar. In response to a question from Yoram Bernet, Lixia answered that the current draft does not include diff-serv tunnels. Braden noted that Yoram would be talking about that issue on Wednesday. Bob asked about the relationship to other new tools, such as MPLS, that are being developed to support VPNs. Lixia clarified the issue by emphasizing that: (1) RSVP tunnel support is needed as long as IP tunnels exist, and (2) RSVP tunnel support can be used to implement VPNs, but having alternative ways to implement VPNs does not make RSVP tunnel support less useful. There was no clear way forward from this discussion, but we hope that further discussion on the mailing list will help. G. ROUTER ALERT ---------------- Bob Braden spoke (standing in for Craig Partridge and Alden Jackson (BBN)) about the Router Alert (RA) IP option. The draft RA for IPv6 differs from the Proposed Standard RA for IPv4: IPv4 RA has no parameter (and vendors look at the IP protocol id), while the IPv6 RA has a parameter whose value registered with IANA. Possible actions include adding the same parameter to IPv4 RA, or removing the parameter from IPv6 and using the IP protocol Id. There was insufficient time or motivation to discuss this issue in the meeting, and it was deferred. Lixia asked if this is an RSVP issue. Braden said that he would be happy to turn it over to the proper party. Scott Bradner said that the RSVP WG is as good a place as any for it. Meeting Adjourned. =========================================================================== Wednesday August 26 1530-1730 RSVP Working Group session II meeting minutes A. DOCUMENTS ISSUES -------------------- Bob Braden led a discussion on the future of the RSVP documents. - The processing rules document (RFC 2209) is out of date. Michael Speer said that the document should either be updated or dropped. There was sentiment that the document is highly useful to implementers, implying that it should be updated. - Should we merge documents such as RFC 2207 (IPSEC) into the RSVP Spec (RFC 2205)? - Should the WG make the new IPv6 flow labels document a WG item? There is a strong parallel between the IPSEC extension and the handling of IPv6 flow labels; perhaps these should be somehow treated together. The question was raised whether we should mandate the use of flow labels with RSVP-IPv6. It was not clear whether this issue falls into the RSVP WG domain, and it was tabled. Lixia urged that the "fat" be cut from the spec. Braden reminded people that document form was the current issue, while Lixia was raising an issue about content. Michael Speer suggested that all changes should be postponed until RSVP is advanced to Draft Standard. Braden raised the question of the need for UDP encapsulation, and there was broad support for dropping it from the spec. The attendees indicated by their silence that all important operating systems now support raw mode. Braden will issue a Working Group Last Call for this change. The Working Group will attempt to advance the Cryptographic Authentication, Diagnostic messages, and Tunnels documents to Proposed Standard. It was undecided when to advance the RSVP Version 1 Spec to Draft Standard. The Working Group next turned to presentations on important proposals for RSVP extensions, in particular for MPLS, aggregation, and differentiated services. B. MPLS --------- George Swallow (Cisco) and Tony Li (Juniper) discussed work in the MPLS WG on using RSVP for MPLS traffic engineering (draft-swallow-mpls-rsvp-trafeng-00.txt). This draft suggests adding three new objects to RSVP to exchange label and for explicit routing. It also includes new tunnel CTypes, a new Session Attribute object, and a new RSVP message type for aggregation of label-switched state. Li talked about the issues with Juniper's experience with RSVP. These include relatively high cpu overhead to process RSVP protocol packets, with a design limit of roughly 10,000 sessions. The current solution for this problem, lowering the refresh rate, can interfere with convergence after route changes. Other suggested approaches include concatenating small RSVP messages into larger datagrams, using digests for messages (as in IS-IS), using TCP for RSVP, or using the reliable-update scheme of Pan, Schulzrinne, and Guerin (draft-pan-rsvp-timer-00.txt). Li noted that using state digests implies that sessions are long lived. Li asked for input from the RSVP WG on this work, which is originating in the MPLS Working Group. Scott Bradner urged the RSVP WG to look at Li's talk very seriously. The MPLS work is looking not at hijacking RSVP, but making it more useful. C. AGGREGATION --------------- John Wroclawski (MIT) presented an overview of two different contributions on aggregation of RSVP state in the interior of the network: draft-berson-rsvp-aggregation-00.txt and draft-guerin-aggreg-rsvp-00.txt. The main issues in both drafts were the amount of scheduling state and the amount of RSVP control state. The requirements of both drafts were to (1) limit state, (2) deliver the reserved service, (3) maintain flow isolation, and (4) disaggregate. The Guerin draft is more comprehensive in some ways, including support for both Controlled Load and Guaranteed service; however, it deals only with unicast. The Berson draft is oriented towards Controlled Load and provides multicast support. There was an of whether the measurement-based admission control in the Berson draft could correctly account for new flows. Liang Li asked how the ingress and egress nodes know that they are the ingress and egress; the ingress is known by configuration, but the egress may be dependent on the destination IP address of the packet. This work is closely related to the diff-serv work (see later discussion), although no one has brought them together. D. FRAMEWORK FOR FUTURE RESOURCE MANAGEMENT -------------------------------------------- Lixia Zhang (UCLA) presented a two-tier framework for resource management. Today's Internet is an interconnection of multiple administrative domains, and all protocol designs must take this basic fact into consideration. Analogous to the inter-domain/intra-domain routing distinction, we must move resource managements towards a two-level control hierarchy. Lixia suggested that each domain will have a Bandwidth Broker (BB) to manage SLAs (service level agreements) with neighbor domains, and they can have the flexibility of selecting among different approaches for intra-domain signaling. Other ongoing work seems to all fit into this two-tier model. RSVP makes a good intra-domain signaling protocol (as Yoram described in more detail later), and MPLS can also be viewed as another intra-domain candidate for transit domains (ISP networks). John Wroclawski noted that the ability to make end-to-end allocation for individual remains useful in many ways. Lixia pointed out that the two-tier framework maintains the ability of adjusting resource allocation to meet the needs of individual flows, but performs such function in a scalable way through bilateral agreement between Bandwidth Brokers. Steve Berson asked what is the means to achieve end-to-end resource allocation; it would be achieved through the concatenation of SLAs. E. RSVP AND DIFF-SERV --------------------- Yoram Bernet (Microsoft) and Raj Yavatkar (Intel) discussed drafts draft-ietf-diffserv-rsvp-00.txt and draft-bernet-diffedge-00.txt. Their approach is to use Integrated Service over int-serv clouds and Differentiated Service (with admission control) over diff-serv clouds, with RSVP doing end-to-end signaling. To do this, mappings from int-serv services to diff-serv services would be needed. There would typically be a default mapping, but the host (or network) may be able to request alternate mappings. The diff-serv cloud should not set the RSVP service "Break bit" unless it is unable to provide the requested service. Another issue is how to carry RSVP protocol messages transparently across diff-serv networks. There was a discussion of using the Router Alert (RA) option, turning it "off" in the interior of a diff-serv cloud. There was a discussion of hosts tagging packets for diff-serv. This allows the host itself to implement drop preference, and it makes it easier to use IPSEC (since the transport fields necessary to tag the packet at the first hop router would then be hidden). John Wroclawski noted that the proposed tagging scheme lets the sender, not the receiver, decide on the service. Bernet answered that the sender knows the characteristics of the traffic, but agreed that it was an open issue. Tony Li claimed that in two years, 90 percent of Internet traffic will be either tunneled or label-switched. Andrew Smith asked whether new PHB's are needed, but this is an ISSLL WG problem. No conclusions were reached in this discussion. Meeting Adjourned.