RAP WG 45th IETF, Oslo - RAP working group meeting (99/07/12) Minutes recorded by: Walter Weiss. Meeting chair: Andrew Smith Administrative Andrew Smith (WG co-chair) started the meeting 5 minutes late. Agenda: 1. intro and presentation of new charter, timetable 2. Status of current RAP WG documents 3. Security issues in COPS protocol 4. COPS clientMIB 5. COPS Usage for policy provisioning 6. RSVP reservation status policy element for end-to-end accounting New name for WG, 'Resource Allocation Policy' instead of 'RSVP Admission Policy' [See slides.] The charter has been updated: working group will define usage directives for use of the COPS base protocol to support policy information exchange transactions within the framework being standardized in the Policy Framework Working Group. In particular, the WG will address the following work items: 1. COPS usage for policy provisioning transactions ("COPS Usage"): The working group will produce a standards track RFC that specifies usage of COPS for the support of policy information exchange transactions between a PDP and it's PEPs. 2. Object syntax for carrying policy provisioning information. Overlaps DiffServ working group. Later, Scott Bradner indicated that this work would be moved to the DiffServ WG. This work explicitly EXCLUDES the definition of policy provisioning objects. There is a proposal to specify the objects for implementing COPS policy for QoS provisioning (also known as "PIB"). This has been submitted to the DiffServ WG. Andrew presented the new timetable for the next round of RAP work. Then he reviewed the status of various existing WG drafts. To get complete understanding of Policy for QoS activities, DiffServ WG will work on PIBs and MIBs. Scott Bradner (transport AD): as RAP is focusing on general usage cases and focusing less on transports, the plan is to move the RAP WG under the O&M area with monitoring by the Transport AD. This move will happen after the security issues with COPS have been addressed. Question about whether or not this reorg will impact Policy or AAA working groups. The answer is no. There was a question as to whether RSVP working group is closing. The indication was that this WG would close. There are still some RSVP issues, but those will probably be addressed in separate drafts. Abel Weinrib: does RAP WG define the Syntax of RAP objects as opposed to the semantics? The answer was that RAP WG will provide syntax for specifying policies while DiffServ WG will work on the semantics. Security for COPS - Dave Durham Dave Durham presented choices for the Required Security Mechanism for the COPS protocol for . Dave was pleased with himself that he could plug his notebook into the projector for the very first time. [See slides.] COPS needs a mutual authentication protocol between the PEP and PDP. There also needs to be a mechanism to ensure the integrity of the contents of the COPS messages. Privacy and Denial of Service attacks are not requirements at this point COPS could use IPSEC over a TCP/IP stack minimally requiring AH with a NULL ESP and manually configure shared keys. The pros are that IPSEC is available today and meets the requirements. IPSEC can also get. The cons are that IPSEC is not implemented on all routers. IPSEC is transparent to COPS so COPS is not aware of the status of Security problems or when keys are changed. There is also a problem with NAT and firewalls. The original solution was to add an Integrity object in the COPS message that would provide authentication and sequence numbers to prevent replay. It would use the same mechanism used for IPSEC AH and RSVP (HMAC-MD5-96/HMAC-SHA1-96) The pros are that it would be built into COPS so it can be supported by all COPS implementations. It would also work through firewalls and NAT. Also, it does not preclude the use of TLS, IPSEC or other mechanisms in the future. The cons are that it is redundant with IPSEC and it is a minimal solution. Because it does not use the IPSEC infrastructure, there is more configuration overhead. Option 3 is to use Transport Layer Security (TLS) The pros are that it is secure. The cons are that it is not clear whether it is available. Scott (Hahn?): use the most light-weight option to give the least burden to the switch. Shai Herzog: IPSEC is always an option for the future. You could start with the light-weight mechanism is that it can be deployed right away and it is less costly to implement in devices. James Binder: likes light-weight and sees a benefit to being able to removeit. Keith: wants it mandatory to implement and optional to use. Consensus was in favor of the COPS Integrity object. COPS client MIB - Andrew Smith/Dave Partain/John Seligson: Andrew presented the COPS protocol client MIB used to manage the important features of the COPS protocol client module. [See slides] He thought that perhaps he should rename the draft to be the COPS PEP MIB to avoid confusion. He also thought that a COPS PDP MIB was less urgent. The draft does not provide support for COPS-RSVP specific capabilities. There are three groups: ClientCapabilities (Version and security), ClientStatus (table indexed by the IP address and server/client type containing the TCP port, the cops server type, the security being used, and statistics), and Config (decide when to switch over to another device). Bert Wijnen: there is a MIB design team that is solving a problem of using IP addresses as indexes to tables (ed: see draft-ops-endpoint-mib-00.txt for their Auguest 1999 report). Dave Oran: why are DNS names were not being used instead of IP addresses? Bert: there is a limit to OID size particularly when DNS names can be quite long. James Binder: Config objects could have the security-related attributes in them as well. Two open issues: should the IP address be used as an index and whether the client should be configured with a security mode. Andrew asked for comments to the RAP WG list as soon as possible. RSVP Reservation Status Policy Element for End-to-End Accounting - Dave Durham/Shai Herzog: The authors proposed this extension to provide information on the status of an RSVP reservation end-to-end. [See slides] One possible alternative to this approach is to use RSVP RESV confirm message. However, Confirm message is a one time message and is therefore unreliable. Also, it does not provide a reliable indication of the duration of the session. In addition the RESV Confirm message is not Multicast-friendly. The draft proposes using a new RSPE object in the RESV and PATH messages to monitor the reservation. The RSPE would first be sent with the RESV message. When it arrives at the source, the PATH message would include a RSPE object in PATH messages containing information about when the reservation was initiated. RSPEs need to be capable of being merged so that Multicast RESV RSPEs can be integrated upstream at convergence points. It is possible to assign RSPEs hop by hop or Domain by Domain. In the Multicast model, when a new branch is created, the starttime timestamp is reset. Question: What is the impact of RSVP refresh reduction on this proposal. There has been no consideration of this in the current draft. There is a question as to whether this is a core RSVP capability or a policy-specific feature. Walter Weiss: is it appropriate in all cases for the starttime timestamp to be reset in the multicast model? Do you charge for the amount each port on a conference call is active or the duration of the overall call? COPS usage for Policy Provisioning - Fran Reichmeyer/Shai Herzog/Keith McCloghrie [See slides] This draft proposes using COPS to configure network devices based on a network-wide policy model. The idea is to first make the PDP aware of the capabilities of the PEP. Then the PDP configures the device with objects consistent with the devices needs. Changes since the last revision is a name change to reflect a WG change and that the protocol extensions are no longer limited to just DiffServ. Why not use SNMP? The solution needs a transactional model that preserves a stateful relation between the router and the manager. This also provides a fault-tolerance mechanism. The content and encoding of the PIB is opaque to the proposed COPS protocol extension. Bert Wijnen: is COPS really required or is SNMP or SNMP+ sufficient? The advocates need to construct an internet-draft arguing the merits of COPS over SNMP for configuration purposes. This discussion needs to include the perspectives from the SNMP proponent to balance the discussion and also to make the discussions bilateral. Bob Moore: is it a rule being downloaded to the PEP or a decision? There will be a change in a future version of the draft that will clarify this. However, the sense is that this is a set of configuration settings and not a rule or a decision. Shai discussed the semantics of the PIB: PIB is a tree similar to the MIB tree. Presented an example for how a policy is embedded into a PIB table using DiffServ as an example. The example separated ACLs and rules into various tables. The COPS message would send a set of these table entries to the device based on the applicability of the rules to the device. Brian Carpenter: the formats of the PIB for DiffServ will be defined in the DiffServ group, so none of this is cast in concrete. Keith McCloghrie presented the proposed PIB for QoS provisioning , slides at . He pointed out that the PIB is higher level than the MIB because the MIB defines the behavior of a particular router while the PIB can be applied uniformly to a set of devices. Further, he pointed out that a PIB is lower level than the Policy Schema, which describes the high level policies. The main differences between SMI and the PIB are: 1. PIB modules start with PIB-DEFINITIONS, instead of DEFINITIONS, to identify as PIB 2. Policy Rule Classes are tables not scalers. 3. Policy Rule Instances are row instances. There is also a object type for the PIB allowing polices to be downloaded and installed independently. MAX-ACCESS and conformance clauses not used. Keith believes that PIBs can be mapped to MIBs. This could be used to use SNMP to query policies or a means for passing information sent via SNMP to the PDP. However, there is no clear application for this yet. Roles are a means for grouping interfaces, devices or services together to allow a single policy to be applied to a number of devices simultaneously. Filter, Filter Group and Classifier classes are used in the proposed DiffServ MIB. There are also concepts for describing the semantics of the Queues as to whether it is WRR, WFQ, etc. There is also the capability to classify and manipulate the MAC layer header. The draft has three components (Framework, IP, and 802.1). Brian Carpenter: use of the term Queue is somewhat contentious in the DiffServ group. However, using the term Class is overloaded in the context of schemas and PIBs (ie. Classes and Instances).