MIDCOM Working Group C.Aoun Internet Draft K.Chan Category: Informational L-N.Hamer Expires on March 2002 R.Penno S.Sen Nortel Networks September 2001 COPS applicability as the MIDCOM protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This draft discusses the applicability of the COPS protocol as the MIDCOM protocol. It discusses the architectural similarities between COPS and Midcom and how COPS meets most of the key requirements for the Midcom protocol. The COPS client for the MIDCOM protocol will be specified in separate internet drafts. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1 Introduction.....................................................2 Aoun et all [Page 1] Internet Draft COPS applicability September 2001 as the MIDCOM protocol 2 Conventions used in this document................................2 3 Midcom Terminologies and Concepts................................2 4 COPS protocol architecture.......................................3 5 SIMILARITIES and DISSIMILARITIES between COPS and the Midcom Architectural Framework............................................4 5.1 Key Midcom Requirements MET by COPS............................4 5.2 Key Midcom Requirements NOT met by COPS........................5 6 Summary..........................................................6 7 References.......................................................6 8 Authors'Addresses................................................7 9 Intellectual Property Statement..................................7 10 Full Copyright Statement........................................8 1 Introduction This draft discusses the applicability of the COPS protocol [1] as the Middle Box Communication protocol ([MDCMFRWK]). It discusses the architectural similarities between COPS ([COPS]) and Midcom and how COPS meets most of the key requirements for the Midcom protocol. Extensions in the form of a specific COPS client definition (without impacting the base protocol) are sought for Midcom. The charter of the MIDCOM WG indicates that reuse of existing protocols is preferred if deemed possible. The objective of this draft is to promote discussion and hopefully lead to the selection of the best existing protocol for MIDCOM purposes. 2 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 3 Midcom Terminologies and Concepts The Middle Box, Midcom Agent and the following terminologies are aligned with the terminology of the Midcom WG and may evolve in time. The draft will be updated upon modification of the terminology. Aoun et all Informational - Expires March 2001 [Page 2] Internet Draft COPS applicability September 2001 as the MIDCOM protocol Ruleset: A logical Middle Box resource comprising of a matching expression for packet flows and the action specified on the specified packets (e.g., drop, modify certain fields of the IP header etc.) Midcom protocol: The protocol between a MIDCOM agent and a Middle Box that allows the MIDCOM agent to gain access to Middle Box resources and allows the Middle Box to delegate application specific processing to MIDCOM agent. 4 COPS protocol architecture COPS is a simple query and response protocol that can be used to exchange policy information between a policy server (Policy Decision Point or PDP) and its clients (Policy Enforcement Points or PEPs). A chief objective of this policy control protocol is to begin with a simple but extensible design. The main characteristics of the COPS protocol include: 1. The protocol employs a client/server model where the PEP sends requests, updates, and deletes to the remote PDP and the PDP returns decisions back to the PEP. 2. The protocol uses TCP as its 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. 3. The protocol is extensible in that it is designed to leverage off self-identifying objects and can support diverse client specific information without requiring modifications to the COPS protocol itself. The protocol was created for the general administration, configuration, and enforcement of policies. 4. COPS provides message level security for authentication, replay protection, and message integrity. COPS can also reuse existing protocols for security such as IPSEC [IPSEC] or TLS to authenticate and secure the channel between the PEP and the PDP. 5. The protocol is stateful in two main aspects: (1) Request/Decision state is shared between client and server and (2) State from various events (Request/Decision pairs) may be inter-associated. By (1) we mean that requests from the client PEP are installed or remembered by the remote PDP until they are explicitly deleted by the PEP. At the same time, Decisions Aoun et all Informational - Expires March 2001 [Page 3] Internet Draft COPS applicability September 2001 as the MIDCOM protocol from the remote PDP can be generated asynchronously at any time for a currently installed request state. By (2) we mean that the server may respond to new queries differently because of previously installed Request/Decision state(s) that are related. 6. Additionally, the protocol is stateful in that it allows the server to push configuration information to the client, and then allows the server to remove such state from the client when it is no longer applicable. 5 SIMILARITIES and DISSIMILARITIES between COPS and the Midcom Architectural Framework In the Midcom architecture, the Middle Box plays the role of a Policy Enforcement Point being controlled by an application-aware Agent. The Midcom Agent and the Middle Box perform similar roles as the Policy Decision Point and the Policy Enforcement Point, respectively, in the COPS architecture. The following sections present an analysis on the capabilities of the protocol to meet the Midcom requirements that are being defined by the MIDCOM Working Group. A consolidated set of requirements based on the ongoing work is used. 5.1 Key Midcom Requirements MET by COPS 1. The Midcom protocol must be transaction-oriented and should allow command aggregation. (R39, R43) COPS is transaction-oriented and will allow aggregation of client specific objects 2. Actions on failed commands must be clearly specified (proceed or reject) and the protocol should include failure reason codes. (R61, R63) COPS uses an error object that is used to identify a particular COPS protocol error. The error sub-code field contains additional detailed client (i.e. the MIDCOM COPS client) specific error codes. 3. The protocol will allow atomic operation on a ruleset or an aggregate of rulesets. (R47, R46) COPS Client Specific objects could have a hierarchical structure. Aoun et all Informational - Expires March 2001 [Page 4] Internet Draft COPS applicability September 2001 as the MIDCOM protocol 4. Two levels of security association are required (R1a, R69, R70, R73, R65, R38, R35): (A) A registration session must exist between the Agent and the Middle Box. Either the Agent or the Middle Box should be able to terminate the registration session. The protocol will allow either the Agent or the Middle Box to terminate an association by using the Client-Close message. (B) The protocol messages must be securely transported. COPS could use transport layer security, thus reusing existing security mechanisms that proved to be interoperable. 5. The protocol must allow the Middle Box and the Agent to synchronize state information, perform resource audit and notify the Agent of certain events in the Middle Box. (R23, R74, R32, R10) COPS supports state synchronization, keep-alives and report messages to provide event notifications. 6. The protocol must be extensible and provide version interworking capabilities. (R2, R41) The COPS protocol has a version number field, and there is a capability negotiation mechanism between the COPS client and the COPS server. 5.2 Key Midcom Requirements NOT met by COPS 1. The protocol must allow specification of a flow identifier or pinhole by at least five tuple (R40, R45, R44). A ruleset comprises of a flow identifier and action. This requirement is easily met by the current Classifier specification of existing COPS PIBs.If necessary, existing COPS Classifiers can be extended (object inheritance) to add the new MIDCOM specific filtering parameters, or new Classifier objects can easily be defined. 2. The protocol should allow multiple Agents to interact simultaneously with a Middle Box and vice-versa. (R3a1, R3a2) Aoun et all Informational - Expires March 2001 [Page 5] Internet Draft COPS applicability September 2001 as the MIDCOM protocol The COPS protocol does not allow several COPS servers to control the same COPS client; this is a COPS architectural issue. One possible way to meet this requirement is to have several Midcom clients on a Middle Box. 3. The protocol must allow multiple Agents manipulating the same or overlapping ruleset(s). It should support hand-off of a ruleset between the Agents, proper deletion of overlapping rulesets, creation of a ruleset by an agent and deletion by another. (R20, R22, R59, R3B) COPS meet the requirement of resource usage accountability by assigning management responsibility to a single MA/PDP/server. COPS have failover and load balancing methods across multiple MAs/PDPs/servers, with resource controlled by one and only one MA/PDP/server AT A TIME 4. The MIDCOM protocol is a client/server protocol where the Middle Box is the server. This implicitly requires that the Midcom agent establish contact with the Middle Box. In COPS, the COPS client initiates contact, which goes against the current MIDCOM principles. 5. The Agent must be authenticated by the Middlebox as part of the registration process. (R33) COPS uses transport security mechanisms (TLS or IPSEC), therfore the requirement is met but not within the protocol. 6 Summary The COPS protocol could meet the MIDCOM protocol requirements to some extent. The extensions will be in the form of a specific Midcom COPS client. The MIDCOM COPS client will be documented in a separate draft. 7 References [COPS] D.Durham et all, "The COPS (Common Open Policy Service) Protocol" RFC 2748, January 2000 [MDCMFRWK]P.Srisuresh et all," MIDCOM Architecture & Framework", Internet draft, draft-ietf-midcom-framework-03.txt [MDCMREQ] R.Swale, P.Mart, P.Sijben, " Middlebox Control (MIDCOM) Protocol Architecture and Requirements", Internet draft, draft-ietf-midcom- requirements-02.txt Aoun et all Informational - Expires March 2001 [Page 6] Internet Draft COPS applicability September 2001 as the MIDCOM protocol 8 Authors' Addresses Cedric Aoun Nortel Networks 33 Quai Paul Doumer 92415 Courbevoie Cedex FRANCE Email: cedric.aoun@nortelnetworks.com Kwok Ho Chan Nortel Networks 600 Technology Park Drive Billerica, MA 01821 EMail: khchan@nortelnetworks.com Louis-Nicolas Hamer Nortel Networks Ottawa, Canada Email: nhamer@nortelnetworks.com Reinaldo Penno Nortel Networks 2305 Mission College Boulevard Building SC9 Santa Clara, CA 95054 Email: rpenno@nortelnetworks.com Sanjoy Sen Nortel Networks 2375 N. Glenville Drive, Building B, Richardson, TX-75082 USA E-mail: sanjoy@nortelnetworks.com 9 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of Aoun et all Informational - Expires March 2001 [Page 7] Internet Draft COPS applicability September 2001 as the MIDCOM protocol claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Aoun et all Informational - Expires March 2001 [Page 8]