Internet DRAFT - draft-aoun-midcom-cops

draft-aoun-midcom-cops




                                    

   MIDCOM Working Group                                           C.Aoun 
   Internet Draft                                                 K.Chan 
   Category: Informational                                     L-N.Hamer 
   Expires on September 2002                                     R.Penno 
                                                                   S.Sen 
                                                         Nortel Networks 
                                                                May 2002 
                                         
                                              
                 

                    COPS applicability as the MIDCOM protocol 
     

                      <draft-aoun-midcom-cops-02.txt> 
  

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                May 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. 
    
   Within the context of the evaluation, COPS and COPS-PR have the same 
   compliancy towards the MIDCOM protocol requirements, as the major 
   difference between COPS and COPS-PR being how MIDCOM policy rules 
   attributes are described within COPS MIDCOM client specific objects 
   or COPS-PR MIDCOM PIB attributes. 
    
   Therefore the evaluation takes into account both COPS and COPS-PR. 
   The decision on which one should be used as the MIDCOM protocol 
   should be done during the detailed protocol phase, where at that 
   point the feasibility /complexity of the creation/usage of COPS 
   MIDCOM client specific objects and the COPS-PR MIDCOM specific PIBs 
   will be compared. 
    
   Unless specified in the document, when COPS is mentioned the 
   statement is applicable to both COPS and COPS-PR. 

    
 

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 


 
Aoun et al      Informational - Expires September 2002        [Page 2]
                                    

Internet Draft            COPS applicability                May 2002 
                        as the MIDCOM protocol 
   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: 
    
   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. 
 
 

 
Aoun et al      Informational - Expires September 2002        [Page 3]
                                    

Internet Draft            COPS applicability                May 2002 
                        as the MIDCOM protocol 
    
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.   
    
    
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 several 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. But 
   the protocol itself does not preclude this scenario. In fact, when 
   applying COPS to a Midcom scenario, a PEP could establish 
   communication with multiple PDPs by creating a cops client instance 
   per PDP. 
   Nothing precludes in COPS that conflict resolution on resources is 
   solved in an underlying resource management layer that is out of 
   scope of the COPS framework. 
    
   "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. 
    

 
Aoun et al      Informational - Expires September 2002        [Page 4]
                                    

Internet Draft            COPS applicability                May 2002 
                        as the MIDCOM protocol 
   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. " 
    
     -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 any 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. " 
    
 
Aoun et al      Informational - Expires September 2002        [Page 5]
                                    

Internet Draft            COPS applicability                May 2002 
                        as the MIDCOM protocol 
     -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. 
    
   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 
 
Aoun et al      Informational - Expires September 2002        [Page 6]
                                    

Internet Draft            COPS applicability                May 2002 
                        as the MIDCOM protocol 
   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.  
      
      
   "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. " 
    
     -  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. 
     As the Middlebox learns additional requirements, the Middlebox 
   adds these resource requirements under the same handle ID which 
   constitutes the required aggregation. 
      
    
 
Aoun et al      Informational - Expires September 2002        [Page 7]
                                    

Internet Draft            COPS applicability                May 2002 
                        as the MIDCOM protocol 
    
   "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. 
    
    
    
    
    
   "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. 
 
Aoun et al      Informational - Expires September 2002        [Page 8]
                                    

Internet Draft            COPS applicability                May 2002 
                        as the MIDCOM protocol 
    
    
   "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 
   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.  
     An underlying resource management function (separate from the COPS 
   state machine) on the Middlebox will handle the arbitration when 
   resource conflicts happen.  
    
    
   "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 <source address, source port, 
   destination address, destination port, transport protocol> 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. 

 
Aoun et al      Informational - Expires September 2002        [Page 9]
                                    

Internet Draft            COPS applicability                May 2002 
                        as the MIDCOM protocol 
    
   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: 
   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. 
    
    

 
Aoun et al      Informational - Expires September 2002       [Page 10]
                                    

Internet Draft            COPS applicability                May 2002 
                        as the MIDCOM protocol 
    
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  Updates made in this version of the draft 
    
   -Added statement of applicability of the evaluation to both COPS and 
   COPS-PR 
    
   -    Updated compliancy statement to requirement 2.1.3 
   -    Updated partial compliancy statement to requirement 2.2.7 
   -    Added IPR statement 
    
    
    
8  References
         
     [COPS]    D.Durham et al, "The COPS (Common Open Policy Service) 
               Protocol", RFC 2748, January 2000 
      
     [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 
    
9    Acknowledgments 
 

   The author would like to thank Joel Halpern for his useful  
   comments and suggestions related to this draft.     
 
     
     

10 Author's Address 
    
   Cedric Aoun 
   Nortel Networks 
   FRANCE 
   Email: cedric.aoun@nortelnetworks.com 
    
   Kwok-Ho Chan 
   Nortel Networks 
   600 Technology Park Drive 

 
Aoun et al      Informational - Expires September 2002       [Page 11]
                                    

Internet Draft            COPS applicability                May 2002 
                        as the MIDCOM protocol 
   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 
    
      

11 Intellectual Property Statement 
    
   Nortel Networks may have Intellectual Property Rights for  
   technologies described in this draft. The authors would like to  
   refer to the general Nortel Networks IPR statement on the IETF IPR 
   repository.  
    
12 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 

 
Aoun et al      Informational - Expires September 2002       [Page 12]
                                    

Internet Draft            COPS applicability                May 2002 
                        as the MIDCOM protocol 
   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 13]