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]
