MIDCOM Working Group C.Aoun Internet Draft K.Chan Category: Informational L-N.Hamer Expires on September 2002 R.Penno S.Sen Nortel Networks April 2002 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, in the context of the current protocol evaluations within the MIDCOM working group. It discusses the architectural similarities between COPS and Midcom and how COPS meets most of the MIDCOM protocol requirements. Aoun et al [Page 1] Internet Draft COPS applicability April 2002 as the MIDCOM protocol 1 Introduction This draft discusses the applicability of the COPS protocol as the MIDCOM protocol, in the context of the current protocol evaluations within the MIDCOM working group. It discusses the architectural similarities between COPS and Midcom and how COPS meets most of the MIDCOM protocol requirements. 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 defined in [MDCMFRWK] and may evolve in time. The draft will be updated upon modification of the terminology. Policy rule: The combination of one or more filters and one or more actions. Packets matching a filter are to be treated as specified by the associated action(s). 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 a 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). The chief objective of this policy control protocol is to begin with a simple but extensible design. The main characteristics of the COPS protocol include: Aoun et al Informational - Expires September 2002 [Page 2] Internet Draft COPS applicability April 2002 as the MIDCOM protocol 1. The protocol employs a client/server model where the PEP sends requests, updates, and deletions to the remote PDP and the PDP returns decisions back to the PEP. 2. The protocol uses TCP as its transport protocol for reliable exchanges 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 and kept synchronized in a transactional manner between client and server (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 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 Requirements & 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. Requirements from section 2 of the MIDCOM requirements document ([MDCMREQ]) are used as the basis for the COPS protocol evaluation. Aoun et al Informational - Expires September 2002 [Page 3] Internet Draft COPS applicability April 2002 as the MIDCOM protocol 5.1 Midcom Requirements MET by COPS "2.1.2: The Midcom protocol must allow a Midcom agent to communicate with more than one middlebox simultaneously. In any but the most simple network, an agent is likely to want to influence the behavior of more than one middlebox. The protocol design must not preclude the ability to do this. " -COPS PDPs are designed to communicate with multiple PEPs. "2.1.3: The Midcom protocol must allow a middlebox to communicate with more than one Midcom agent simultaneously. There may be multiple instances of a single application or multiple applications desiring service from a single middlebox, and different agents may represent them. The protocol design must not preclude the ability to do so. " -The COPS framework specifies that a PEP should have a unique PDP, this was specified in order to achieve effective policy control. A single middlebox may have multiple instances of PEPs, with each instance of PEP communicating to a specific PDP. This can be used when applying COPS to a Midcom scenario. "2.1.4: Where a multiplicity of Midcom Agents are interacting with a given middlebox, the Midcom protocol must provide mechanisms ensuring that the overall behavior is deterministic. This states that the protocol must include mechanisms for avoiding race conditions or other situations in which the requests of one agent may influence the results of the requests of other agents in an unpredictable manner. " -COPS has built-in support for clear state and policy instances. This would allow the creation of well-behaved Midcom state machines. "2.1.5: The Midcom protocol must enable the middlebox and any associated Midcom agents to establish known and stable state. This must include the case of power failure, or other failure, where the protocol must ensure that any resources used by a failed element can be released. This states that the protocol must provide clear identification for requests and results and that protocol operations must be atomic with respect to the midcom protocol. " Aoun et al Informational - Expires September 2002 [Page 4] Internet Draft COPS applicability April 2002 as the MIDCOM protocol -The COPS protocol maintains synchronized states between Middleboxes and MA as hence all the states are known on both sides. "2.1.6: The middlebox must be able to report its status to a Midcom agent with which it is associated. " -The COPS Report message is designed to indicate status change and asynchronous conditions/events. "2.1.7: The protocol must support unsolicited messages from middlebox to agent, for reporting conditions detected asynchronously at the middlebox. It may be the case that exceptional conditions or other events at the middlebox (resource shortages, intrusion mitigation) will cause the middlebox to close pinholes or release resources without consulting the associated Midcom agent. In that event the protocol must allow the middlebox to notify the agent. " -Idem to 2.1.6. "2.1.8: The Midcom protocol must provide for the mutual authentication of Midcom agent and middlebox to one another. In addition for the more obvious need for the Midcom agent to authenticate itself to the middlebox, there are some attacks against the protocol which can be mitigated by having the middlebox authenticate to the agent. " -COPS has built-in message level security for authentication, replay protection, and message integrity. COPS can also use TLS or IPSec, thus reusing existing security mechanisms that have interoperated in the markets. "2.1.9: The Midcom protocol must allow either the Midcom agent or the middlebox to terminate the Midcom session between a Midcom Agent and a middlebox. This allows either entity to close the session for maintenance, security or other reasons. " -COPS allows both the PEP and PDP to terminate a session. "2.1.10: A Midcom agent must be able to determine whether or not a request was successful. Aoun et al Informational - Expires September 2002 [Page 5] Internet Draft COPS applicability April 2002 as the MIDCOM protocol This states that a middlebox must return a success or failure indication to a request made by an agent. " - The COPS Report message directly fulfills this requirement. "2.1.11: The Midcom protocol must contain version interworking capabilities to enable subsequent extensions to support different types of middlebox and future requirements of applications not considered at this stage. We assume that there will be later revisions of this protocol. The initial version will focus on communication with firewalls and NATs, and it is possible that the protocol will need to be modified as support for other middlebox types is added. These version interworking capabilities may include (but not be limited to) a protocol version number. " -The COPS protocol can carry a MIDCOM version number and capability negotiation between the COPS client and the COPS server. This capability negotiation mechanism allows the COPS client and server to communicate to the other which features/capabilities it support. This would allow seamless version interworking. "2.1.12: It must be possible to deterministically predict the behavior of the middlebox in the presence of overlapping rules. The protocol must preclude nondeterministic behavior in the case of overlapping policy rules, e.g. by ensuring that some known precedence is imposed. " -The COPS protocol provides transactional-based communication between the PEP and PDP, hence the behavior is totally deterministic. As long as the middlebox state machine is designed correctly. The COPS protocol features encourage and support good state machine design. "2.2.1: The syntax and semantics of the Midcom protocol must be extensible to allow the requirements of future applications to be adopted. This is related to, but different from, the requirement for versioning support. As support for additional middlebox types is added there may be a need to add new message types. " -The COPS protocol is extensible since it was designed to separate the Protocol from the Policy Control Information. COPS takes the approach of defining a stable, reusable, more widely Applicable protocol. With the applicability/extensibility addressed by the Policy Control Information carried by the COPS protocol. Aoun et al Informational - Expires September 2002 [Page 6] Internet Draft COPS applicability April 2002 as the MIDCOM protocol "2.2.2: The Midcom protocol must support the ability of an agent to install a policy rule that governs multiple types of middlebox actions (e.g. firewall and NAT). This states that the protocol must support filters and actions for a variety of types of middleboxes. A Midcom agent ought to be able to have a single Midcom session with a middlebox and use the Midcom interface on the middlebox to interface with different middlebox functions on the same middlebox interface. " -COPS allows a PDP to provide filters and actions to multiple PEP functions through a single COPS session. "2.2.3: The protocol must support the concept of a policy rule comprising a multiple of individual {filter, action} pairs to be treated as an aggregate. Applications using more than one data stream may find it more convenient and more efficient to be able to use single messages to tear down, extend, and manipulate all middlebox {filter, action} being used by one instance of the application. " -COPS Client Specific objects could have a hierarchical structure. Furthermore, COPS and PIBs allow flexible association of protocol messages to common policy reference points. For example the usage of the COPS Handle State may be associated with the set of closely related policy objects that can be efficiently controlled as a set. "2.2.5: If a peer does not understand an option it must be clear whether the action required is to proceed without the unknown attribute being taken into account or the request is to be rejected. Where attributes may be ignored if not understood, a means may be provided to inform the client about what has been ignored. This states that failure modes must be robust, providing sufficient information for the agent or middlebox to be able to accommodate the failure or to retry with a new option that is more likely to succeed. " -There is clear capability and limitation exchange between the PEP and PDP to make handling of these situations totally deterministic and controlled, with well-known outcomes understood by both the PEP and the PDP. There is also clear error handling for situations when the request is rejected. Aoun et al Informational - Expires September 2002 [Page 7] Internet Draft COPS applicability April 2002 as the MIDCOM protocol "2.2.6: To enable management systems to interact with the Midcom environment, the protocol must include failure reasons that allow the Midcom Agent behavior to be modified as a result of the information contained in the reason. Failure reasons need to be chosen such that they do not make an attack on security easier. " -COPS uses an error object that is used to identify a particular COPS protocol error. The error sub-code field may contain additional detailed client (i.e. the MIDCOM COPS client) specific error codes. "2.3.1: The Midcom protocol must provide for message authentication, confidentiality, and integrity. " Idem to 2.1.8. "2.3.2: The Midcom protocol must allow for optional confidentiality protection of control messages. If provided the mechanism should allow a choice in the algorithm to be used. " Idem to 2.1.8. "2.3.3: The Midcom protocol must operate across un-trusted domains between the Midcom agent and middlebox in a secure fashion. " Idem to 2.1.8. "2.3.4: The Midcom protocol must define mechanisms to mitigate replay attacks on the control messages. " Idem to 2.1.8. 5.2 MIDCOM requirements partially met by COPS "2.2.4: The protocol must allow the midcom agent to extend the lifetime of an existing ruleset that otherwise would be deleted by the middlebox. " -COPS allows a PDP to send unsolicited decisions to the PEP. However the unsolicited events will be relevant to the COPS MIDCOM Aoun et al Informational - Expires September 2002 [Page 8] Internet Draft COPS applicability April 2002 as the MIDCOM protocol specific client or the MIDCOM specific PIB that will need to be defined. This would allow the PDP to extend the lifetime of an existing ruleset. "2.2.7: The Midcom protocol must not preclude multiple authorized agents from working on the same policy rule. " -It is possible to use COPS to operate the same resource with multiple agents. The COPS protocol has all the flexibility to meet this requirement by using a COPS MIDCOM specific client or a MIDCOM specific PIB. The responsibility to ensure the consistence of rulesets as they are worked on by more then one authorized agents is with the design of the middlebox state machine. The COPS protocol encourages good state machine design. "2.2.8: The Midcom protocol must be able to carry filtering rules, including but not limited to the 5-tuple, from the midcom agent to the middlebox. By "5-tuple" we refer to the standard tuple. Other filtering elements may be carried, as well. " -The COPS protocol has all the flexibility to meet this requirement by using a COPS MIDCOM specific client or a MIDCOM specific PIB. "2.2.9: When the middlebox performs a port mapping function, the protocol should allow the Midcom agent to request that the external port number have the same oddity as the internal port. This requirement is to support RTP and RTCP [RFC1889] "oddity" requirements. " -Idem to 2.2.8. "2.2.10: When the middlebox performs a port mapping function, the protocol should allow the Midcom agent to request that a consecutive range of external port numbers be mapped to consecutive internal ports. This requirement is to support RTP and RTCP "sequence" requirements. " -Idem to 2.2.8. "2.2.11: Aoun et al Informational - Expires September 2002 [Page 9] Internet Draft COPS applicability April 2002 as the MIDCOM protocol It should be possible to define policy rules that contain a more specific filter spec than an overlapping ruleset. This should allow agents to request actions for the subset that contradict those of the overlapping set. This should allow Midcom agent to request to a Midcom server controlling a firewall function that a subset of the traffic that would be allowed by the overlapping ruleset be specifically disallowed. " -Idem to 2.2.8. 5.3 Midcom Requirements NOT met by COPS "2.1.1: The Midcom protocol must enable a Midcom agent requiring the services of a middlebox to establish an authorized association between itself and the middlebox. This states that the protocol must allow the middlebox to identify an agent requesting services and make a determination as to whether or not the agent will be permitted to do so. " -COPS does not meet the directionality part of the requirement. COPS was defined to allow a PEP to establish communication with a PDP. However, nothing precludes a PDP to establish communication with a PEP. The PEP could have local policies dictating what action to take when it is contacted by an unknown PDP. These actions, defined in the local policies, would ensure the proper establishment of an authorized association. 6 Summary Initial investigation indicates that the COPS protocol, meets most of the MIDCOM protocol requirements by using the protocolĘs native extension techniques. 7 References [COPS] D.Durham et al, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000 Aoun et al Informational - Expires September 2002 [Page 10] Internet Draft COPS applicability April 2002 as the MIDCOM protocol [COPS-PR] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage for Policy Provisioning," RFC 3084, March, 2001. [MDCMFRWK] P.Srisuresh et al," MIDCOM Architecture & Framework", Internet draft, draft-ietf-midcom-framework-07.txt [MDCMREQ] R.Swale et al, " Middlebox Control (MIDCOM) Protocol Architecture and Requirements", Internet draft, draft-ietf-midcom-requirements-05.txt 8 Author's Address Cedric Aoun Nortel Networks 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 Aoun et al Informational - Expires September 2002 [Page 11] Internet Draft COPS applicability April 2002 as the MIDCOM protocol 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 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 al Informational - Expires September 2002 [Page 12]