client specific information for accounting and state monitoring
purposes depending on the type of the client. In such cases the
accounting report type should be specified utilizing the appropriate
client specific information object.
<Report State> ::== <Common Header>
<Client Handle>
<Report-Type>
[<ClientSI>]
[<Integrity>]
3.4 Delete Request State (DRQ) PEP -> PDP
When sent from the PEP this message indicates to the remote PDP that
the state identified by the client handle is no longer
available/relevant. This information will then be used by the remote
PDP to initiate the appropriate housekeeping actions. The reason code
object is interpreted with respect to the client-type and signifies
the reason for the removal.
The format of the Delete Request State message is as follows:
<Delete Request> ::= <Common Header>
<Client Handle>
<Reason>
[<Integrity>]
Given the stateful nature of COPS, it is important that when a
request state is finally removed from the PEP, a DRQ message for this
request state is sent to the PDP so the corresponding state may
likewise be removed on the PDP. Request states not explicitly deleted
by the PEP will be maintained by the PDP until either the client
session is closed or the connection is terminated.
Malformed Decision messages MUST trigger a DRQ specifying the
appropriate erroneous reason code (Bad Message Format) and any
associated state on the PEP SHOULD either be removed or re-requested.
If a Decision contained an unknown COPS Decision Object, the PEP MUST
delete its request specifying the Unknown COPS Object reason code
because the PEP will be unable to comply with the information
contained in the unknown object. In any case, after issuing a DRQ,
the PEP may retry the corresponding Request again.
3.5 Synchronize State Request (SSQ) PDP -> PEP
The format of the Synchronize State Query message is as follows:
<Synchronize State> ::= <Common Header>
[<Client Handle>]
[<Integrity>]
This message indicates that the remote PDP wishes the client (which
appears in the common header) to re-send its state. If the optional
Client Handle is present, only the state associated with this handle
is synchronized. If the PEP does not recognize the requested handle,
it MUST immediately send a DRQ message to the PDP for the handle that
was specified in the SSQ message. If no handle is specified in the
SSQ message, all the active client state MUST be synchronized with
the PDP.
The client performs state synchronization by re-issuing request
queries of the specified client-type for the existing state in the
PEP. When synchronization is complete, the PEP MUST issue a
synchronize state complete message to the PDP.
3.6 Client-Open (OPN) PEP -> PDP
The Client-Open message can be used by the PEP to specify to the PDP
the client-types the PEP can support, the last PDP to which the PEP
connected for the given client-type, and/or client specific feature
negotiation. A Client-Open message can be sent to the PDP at any time
and multiple Client-Open messages for the same client-type are
allowed (in case of global state changes).
<Client-Open> ::= <Common Header>
<PEPID>
[<ClientSI>]
[<LastPDPAddr>]
[<Integrity>]
The PEPID is a symbolic, variable length name that uniquely
identifies the specific client to the PDP (see Section 2.2.11).
A named ClientSI object can be included for relaying additional
global information about the PEP to the PDP when required (as
specified in the appropriate extensions document for the client-
type).
The PEP may also provide a Last PDP Address object in its Client-Open
message specifying the last PDP (for the given client-type) for which
it is still caching decisions since its last reboot. A PDP can use
this information to determine the appropriate synchronization
behavior (See section 2.5).
If the PDP receives a malformed Client-Open message it MUST generate
a Client-Close message specifying the appropriate error code.
3.7 Client-Accept (CAT) PDP -> PEP
The Client-Accept message is used to positively respond to the
Client-Open message. This message will return to the PEP a timer
object indicating the maximum time interval between keep-alive
messages. Optionally, a timer specifying the minimum allowed interval
between accounting report messages may be included when applicable.
<Client-Accept> ::= <Common Header>
<KA Timer>
[<ACCT Timer>]
[<Integrity>]
If the PDP refuses the client, it will instead issue a Client-Close
message.
The KA Timer corresponds to maximum acceptable intermediate time
between the generation of messages by the PDP and PEP. The timer
value is determined by the PDP and is specified in seconds. A timer
value of 0 implies no secondary connection verification is necessary.
The optional ACCT Timer allows the PDP to indicate to the PEP that
periodic accounting reports SHOULD NOT exceed the specified timer
interval per client handle. This allows the PDP to control the rate
at which accounting reports are sent by the PEP (when applicable).
In general, accounting type Report messages are sent to the PDP when
determined appropriate by the PEP. The accounting timer merely is
used by the PDP to keep the rate of such updates in check (i.e.
Preventing the PEP from blasting the PDP with accounting reports).
Not including this object implies there are no PDP restrictions on
the rate at which accounting updates are generated.
If the PEP receives a malformed Client-Accept message it MUST
generate a Client-Close message specifying the appropriate error
code.
3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP
The Client-Close message can be issued by either the PDP or PEP to
notify the other that a particular type of client is no longer being
supported.
<Client-Close> ::= <Common Header>
<Error>
[<PDPRedirAddr>]
[<Integrity>]
The Error object is included to describe the reason for the close
(e.g. the requested client-type is not supported by the remote PDP or
client failure).
A PDP MAY optionally include a PDP Redirect Address object in order
to inform the PEP of the alternate PDP it SHOULD use for the client-
type specified in the common header.
3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP
The keep-alive message MUST be transmitted by the PEP within the
period defined by the minimum of all KA Timer values specified in all
received CAT messages for the connection. A KA message MUST be
generated randomly between 1/4 and 3/4 of this minimum KA timer
interval. When the PDP receives a keep-alive message from a PEP, it
MUST echo a keep-alive back to the PEP. This message provides
validation for each side that the connection is still functioning
even when there is no other messaging.
Note: The client-type in the header MUST always be set to 0 as the KA
is used for connection verification (not per client session
verification).
<Keep-Alive> ::= <Common Header>
[<Integrity>]
Both client and server MAY assume the TCP connection is insufficient
for the client-type with the minimum time value (specified in the CAT
message) if no communication activity is detected for a period
exceeding the timer period. For the PEP, such detection implies the
remote PDP or connection is down and the PEP SHOULD now attempt to
use an alternative/backup PDP.
3.10 Synchronize State Complete (SSC) PEP -> PDP
The Synchronize State Complete is sent by the PEP to the PDP after
the PDP sends a synchronize state request to the PEP and the PEP has
finished synchronization. It is useful so that the PDP will know when
all the old client state has been successfully re-requested and,
thus, the PEP and PDP are completely synchronized. The Client Handle
object only needs to be included if the corresponding Synchronize
State Message originally referenced a specific handle.
<Synchronize State Complete> ::= <Common Header>
[<Client Handle>]
[<Integrity>]
4. Common Operation
This section describes the typical exchanges between remote PDP
servers and PEP clients.
4.1 Security and Sequence Number Negotiation
COPS message security is negotiated once per connection and covers
all communication over a particular connection. If COPS level
security is required, it MUST be negotiated during the initial
Client-Open/Client-Accept message exchange specifying a Client-Type
of zero (which is reserved for connection level security negotiation
and connection verification).
If a PEP is not configured to use COPS security with a PDP it will
simply send the PDP Client-Open messages for the supported Client-
Types as specified in section 4.3 and will not include the Integrity
object in any COPS messages.
Otherwise, security can be initiated by the PEP if it sends the PDP a
Client-Open message with Client-Type=0 before opening any other
Client-Type. If the PDP receives a Client-Open with a Client-Type=0
after another Client-Type has already been opened successfully it
MUST return a Client-Close message (for Client-Type=0) to that PEP.
This first Client-Open message MUST specify a Client-Type of zero and
MUST provide the PEPID and a COPS Integrity object. This Integrity
object will contain the initial sequence number the PEP requires the
PDP to increment during subsequent communication after the initial
Client-Open/Client-Accept exchange and the Key ID identifying the
algorithm and key used to compute the digest.
Similarly, if the PDP accepts the PEP's security key and algorithm by
validating the message digest using the identified key, the PDP MUST
send a Client-Accept message with a Client-Type of zero to the PEP
carrying an Integrity object. This Integrity object will contain the
initial sequence number the PDP requires the PEP to increment during
all subsequent communication with the PDP and the Key ID identifying
the key and algorithm used to compute the digest.
If the PEP, from the perspective of a PDP that requires security,
fails or never performs the security negotiation by not sending an
initial Client-Open message with a Client-Type=0 including a valid
Integrity object, the PDP MUST send to the PEP a Client-Close message
with a Client-Type=0 specifying the appropriate error code.
Similarly, if the PDP, from the perspective of a PEP that requires
security, fails the security negotiation by not sending back a
Client-Accept message with a Client-Type=0 including a valid
Integrity object, the PEP MUST send to the PDP a Client-Close message
with a Client-Type=0 specifying the appropriate error code. Such a
Client-Close message need not carry an integrity object (as the
security negotiation did not yet complete).
The security initialization can fail for one of several reasons: 1.
The side receiving the message requires COPS level security but an
Integrity object was not provided (Authentication Required error
code). 2. A COPS Integrity object was provided, but with an
unknown/unacceptable C-Type (Unknown COPS Object error code
specifying the unsupported C-Num and C-Type). 3. The message digest
or Key ID in the provided Integrity object was incorrect and
therefore the message could not be authenticated using the identified
key (Authentication Failure error code).
Once the initial security negotiation is complete, the PEP will know
what sequence numbers the PDP expects and the PDP will know what
sequence numbers the PEP expects. ALL COPS messages must then include
the negotiated Integrity object specifying the correct sequence
number with the appropriate message digest (including the Client-
Open/Client-Accept messages for specific Client-Types). ALL
subsequent messages from the PDP to the PEP MUST result in an
increment of the sequence number provided by the PEP in the Integrity
object of the initial Client-Open message. Likewise, ALL subsequent
messages from the PEP to the PDP MUST result in an increment of the
sequence number provided by the PDP in the Integrity object of the
initial Client-Accept message. Sequence numbers are incremented by
one starting with the corresponding initial sequence number. For
example, if the sequence number specified to the PEP by the PDP in
the initial Client-Accept was 10, the next message the PEP sends to
the PDP will provide an Integrity object with a sequence number of
11... Then the next message the PEP sends to the PDP will have a
sequence number of 12 and so on. If any subsequent received message
contains the wrong sequence number, an unknown Key ID, an invalid
message digest, or is missing an Integrity object after integrity was
negotiated, then a Client-Close message MUST be generated for the
Client-Type zero containing a valid Integrity object and specifying
the appropriate error code. The connection should then be dropped.
4.2 Key Maintenance
Key maintenance is outside the scope of this document, but COPS
implementations MUST at least provide the ability to manually
configure keys and their parameters locally. The key used to produce
the Integrity object's message digest is identified by the Key ID
field. Thus, a Key ID parameter is used to identify one of
potentially multiple simultaneous keys shared by the PEP and PDP. A
Key ID is relative to a particular PEPID on the PDP or to a
particular PDP on the PEP. Each key must also be configured with
lifetime parameters for the time period within which it is valid as
well as an associated cryptographic algorithm parameter specifying
the algorithm to be used with the key. At a minimum, all COPS
implementations MUST support the HMAC-MD5-96 [HMAC][MD5]
cryptographic algorithm for computing a message digest for inclusion
in the Keyed Message Digest of the Integrity object which is appended
to the message.
It is good practice to regularly change keys. Keys MUST be
configurable such that their lifetimes overlap allowing smooth
transitions between keys. At the midpoint of the lifetime overlap
between two keys, senders should transition from using the current
key to the next/longer-lived key. Meanwhile, receivers simply accept
any identified key received within its configured lifetime and reject
those that are not.
4.3 PEP Initialization
Sometime after a connection is established between the PEP and a
remote PDP and after security is negotiated (if required), the PEP
will send one or more Client-Open messages to the remote PDP, one for
each client-type supported by the PEP. The Client-Open message MUST
contain the address of the last PDP with which the PEP is still
caching a complete set of decisions. If no decisions are being cached
from the previous PDP the LastPDPAddr object MUST NOT be included in
the Client-Open message (see Section 2.5). Each Client-Open message
MUST at least contain the common header noting one client-type
supported by the PEP. The remote PDP will then respond with separate
Client-Accept messages for each of the client-types requested by the
PEP that the PDP can also support.
If a specific client-type is not supported by the PDP, the PDP will
instead respond with a Client-Close specifying the client-type is not
supported and will possibly suggest an alternate PDP address and
port. Otherwise, the PDP will send a Client-Accept specifying the
timer interval between keep-alive messages and the PEP may begin
issuing requests to the PDP.
4.4 Outsourcing Operations
In the outsourcing scenario, when the PEP receives an event that
requires a new policy decision it sends a request message to the
remote PDP. What specifically qualifies as an event for a particular
client-type SHOULD be specified in the specific document for that
client-type. The remote PDP then makes a decision and sends a
decision message back to the PEP. Since the request is stateful, the
request will be remembered, or installed, on the remote PDP. The
unique handle (unique per TCP connection and client-type), specified
in both the request and its corresponding decision identifies this
request state. The PEP is responsible for deleting this request state
once the request is no longer applicable.
The PEP can update a previously installed request state by reissuing
a request for the previously installed handle. The remote PDP is then
expected to make new decisions and send a decision message back to
the PEP. Likewise, the server MAY change a previously issued decision
on any currently installed request state at any time by issuing an
unsolicited decision message. At all times the PEP module is expected
to abide by the PDP's decisions and notify the PDP of any state
changes.
4.5 Configuration Operations
In the configuration scenario, as in the outsourcing scenario, the
PEP will make a configuration request to the PDP for a particular
interface, module, or functionality that may be specified in the
named client specific information object. The PDP will then send
potentially several decisions containing named units of configuration
data to the PEP. The PEP is expected to install and use the
configuration locally. A particular named configuration can be
updated by simply sending additional decision messages for the same
named configuration. When the PDP no longer wishes the PEP to use a
piece of configuration information, it will send a decision message
specifying the named configuration and a decision flags object with
the remove configuration command. The PEP SHOULD then proceed to
remove the corresponding configuration and send a report message to
the PDP that specifies it has been deleted.
In all cases, the PEP MAY notify the remote PDP of the local status
of an installed state using the report message where appropriate.
The report message is to be used to signify when billing can begin,
what actions were taken, or to produce periodic updates for
monitoring and accounting purposes depending on the client. This
message can carry client specific information when needed.
4.6 Keep-Alive Operations
The Keep-Alive message is used to validate the connection between the
client and server is still functioning even when there is no other
messaging from the PEP to PDP. The PEP MUST generate a COPS KA
message randomly within one-fourth to three-fourths the minimum KA
Timer interval specified by the PDP in the Client-Accept message. On
receiving a Keep-Alive message from the PEP, the PDP MUST then
respond to this Keep-Alive message by echoing a Keep-Alive message
back to the PEP. If either side does not receive a Keep-Alive or any
other COPS message within the minimum KA Timer interval from the
other, the connection SHOULD be considered lost.
4.7 PEP/PDP Close
Finally, Client-Close messages are used to negate the effects of the
corresponding Client-Open messages, notifying the other side that the
specified client-type is no longer supported/active. When the PEP
detects a lost connection due to a keep-alive timeout condition it
SHOULD explicitly send a Client-Close message for each opened
client-type specifying a communications failure error code. Then the
PEP MAY proceed to terminate the connection to the PDP and attempt to
reconnect again or try a backup/alternative PDP. When the PDP is
shutting down, it SHOULD also explicitly send a Client-Close to all
connected PEPs for each client-type, perhaps specifying an
alternative PDP to use instead.
5. Security Considerations
The COPS protocol provides an Integrity object that can achieve
authentication, message integrity, and replay prevention. All COPS
implementations MUST support the COPS Integrity object and its
mechanisms as described in this document. To ensure the client (PEP)
is communicating with the correct policy server (PDP) requires
authentication of the PEP and PDP using a shared secret, and
consistent proof that the connection remains valid. The shared secret
minimally requires manual configuration of keys (identified by a Key
ID) shared between the PEP and its PDP. The key is used in
conjunction with the contents of a COPS message to calculate a
message digest that is part of the Integrity object. The Integrity
object is then used to validate all COPS messages sent over the TCP
connection between a PEP and PDP.
Key maintenance is outside the scope of this document beyond the
specific requirements discussed in section 4.2. In general, it is
good practice to regularly change keys to maintain security.
Furthermore, it is good practice to use localized keys specific to a
particular PEP such that a stolen PEP will not compromise the
security of an entire administrative domain.
The COPS Integrity object also provides sequence numbers to avoid
replay attacks. The PDP chooses the initial sequence number for the
PEP and the PEP chooses the initial sequence number for the PDP.
These initial numbers are then incremented with each successive
message sent over the connection in the corresponding direction. The
initial sequence numbers SHOULD be chosen such that they are
monotonically increasing and never repeat for a particular key.
Security between the client (PEP) and server (PDP) MAY be provided by
IP Security [IPSEC]. In this case, the IPSEC Authentication Header
(AH) SHOULD be used for the validation of the connection;
additionally IPSEC Encapsulation Security Payload (ESP) MAY be used
to provide both validation and secrecy.
Transport Layer Security [TLS] MAY be used for both connection-level
validation and privacy.
6. IANA Considerations
The Client-type identifies the policy client application to which a
message refers. Client-type values within the range 0x0001-0x3FFF are
reserved Specification Required status as defined in [IANA-
CONSIDERATIONS]. These values MUST be registered with IANA and their
behavior and applicability MUST be described in a COPS extension
document.
Client-type values in the range 0x4000 - 0x7FFF are reserved for
Private Use as defined in [IANA-CONSIDERATIONS]. These Client-types
are not tracked by IANA and are not to be used in standards or
general-release products, as their uniqueness cannot be assured.
Client-type values in the range 0x8000 - 0xFFFF are First Come First
Served as defined in [IANA-CONSIDERATIONS]. These Client-types are
tracked by IANA but do not require published documents describing
their use. IANA merely assures their uniqueness.
Objects in the COPS Protocol are identified by their C-Num and C-Type
values. IETF Consensus as identified in [IANA-CONSIDERATIONS] is
required to introduce new values for these numbers and, therefore,
new objects into the base COPS protocol.
Additional Context Object R-Types, Reason-Codes, Report-Types,
Decision Object Command-Codes/Flags, and Error-Codes MAY be defined
for use with future Client-types, but such additions require IETF
Consensus as defined in [IANA-CONSIDERATIONS].
Context Object M-Types, Reason Sub-Codes, and Error Sub-codes MAY be
defined relative to a particular Client-type following the same IANA
considerations as their respective Client-type.
7. References
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S.
and S. Jamin, "Resource ReSerVation Protocol
(RSVP) Version 1 - Functional Specification",
RFC2205, September 1997.
[WRK] Yavatkar, R., Pendarakis, D. and R. Guerin, "A
Framework for Policy-Based Admission Control",
RFC2753, January 2000.
[SRVLOC] Guttman, E., Perkins, C., Veizades, J. and M.
Day, "Service Location Protocol , Version 2",
RFC2608, June 1999.
[INSCH] Shenker, S. and J. Wroclawski, "General
Characterization Parameters for Integrated
Service Network Elements", RFC2215, September
1997.
[IPSEC] Atkinson, R., "Security Architecture for the
Internet Protocol", RFC2401, August 1995.
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti,
"HMAC: Keyed-Hashing for Message
Authentication", RFC2104, February 1997.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC1321, April 1992.
[RSVPPR] Braden, R. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) - Version 1 Message Processing
Rules", RFC2209, September 1997.
[TLS] Dierks T. and C. Allen, "The TLS Protocol
Version 1.0", RFC2246, January 1999.
[IANA] http://www.isi.edu/in-
notes/iana/assignments/port-numbers
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in
RFCs", BCP 26, RFC2434, October 1998.
8. Author Information and Acknowledgments
Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs,
Raj Yavatkar, Russell Fenger, Fred Baker, Laura Cunningham, Roch
Guerin, Ping Pan, and Dimitrios Pendarakis for their valuable
contributions.
Jim Boyle
Level 3 Communications
1025 Eldorado Boulevard
Broomfield, CO 80021
Phone: 720.888.1192
EMail: jboyle@Level3.net
Ron Cohen
CISCO Systems
4 Maskit St.
Herzeliya Pituach 46766 Israel
Phone: +972.9.9700064
EMail: ronc@cisco.com
David Durham
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124
Phone: 503.264.6232
EMail: David.Durham@intel.com
Raju Rajan
AT&T Shannon Laboratory
180 Park Avenue
P.O. Box 971
Florham Park, NJ 07932-0971
EMail: rajan@research.att.com
Shai Herzog
IPHighway, Inc.
55 New York Avenue
Framingham, MA 01701
Phone: 508.620.1141
EMail: herzog@iphighway.com
Arun Sastry
Cisco Systems
4 The Square
Stockley Park
Uxbridge, Middlesex UB11 1BN
UK
Phone: +44-208-756-8693
EMail: asastry@cisco.com
9. 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.