📄 rfc2748.txt
字号:
2.2.13 PDP Redirect Address (PDPRedirAddr)
A PDP when closing a PEP session for a particular client-type may
optionally use this object to redirect the PEP to the specified PDP
server address and TCP port number:
Durham, et al. Standards Track [Page 16]
RFC 2748 COPS January 2000
C-Num = 13,
C-Type = 1, IPv4 Address + TCP Port
0 1 2 3
+--------------+--------------+--------------+--------------+
| IPv4 Address format |
+--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
C-Type = 2, IPv6 Address + TCP Port
0 1 2 3
+--------------+--------------+--------------+--------------+
| |
+ +
| |
+ IPv6 Address format +
| |
+ +
| |
+--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
2.2.14 Last PDP Address (LastPDPAddr)
When a PEP sends a Client-Open message for a particular client-type
the PEP SHOULD specify the last PDP it has successfully opened
(meaning it received a Client-Accept) since the PEP last rebooted.
If no PDP was used since the last reboot, the PEP will simply not
include this object in the Client-Open message.
C-Num = 14,
C-Type = 1, IPv4 Address (Same format as PDPRedirAddr)
C-Type = 2, IPv6 Address (Same format as PDPRedirAddr)
2.2.15 Accounting Timer Object (AcctTimer)
Times are encoded as 2 octet integer values and are in units of
seconds. The timer value is treated as a delta.
C-Num = 15,
C-Type = 1, Accounting timer value
Durham, et al. Standards Track [Page 17]
RFC 2748 COPS January 2000
Optional timer value used to determine the minimum interval between
periodic accounting type reports. It is used by the PDP to describe
to the PEP an acceptable interval between unsolicited accounting
updates via Report messages where applicable. It provides a method
for the PDP to control the amount of accounting traffic seen by the
network. The range of finite time values is 1 to 65535 seconds
represented as an unsigned two-octet integer. A value of zero means
there SHOULD be no unsolicited accounting updates.
0 1 2 3
+--------------+--------------+--------------+--------------+
| ////////////// | ACCT Timer Value |
+--------------+--------------+--------------+--------------+
2.2.16 Message Integrity Object (Integrity)
The integrity object includes a sequence number and a message digest
useful for authenticating and validating the integrity of a COPS
message. When used, integrity is provided at the end of a COPS
message as the last COPS object. The digest is then computed over all
of a particular COPS message up to but not including the digest value
itself. The sender of a COPS message will compute and fill in the
digest portion of the Integrity object. The receiver of a COPS
message will then compute a digest over the received message and
verify it matches the digest in the received Integrity object.
C-Num = 16,
C-Type = 1, HMAC digest
The HMAC integrity object employs HMAC (Keyed-Hashing for Message
Authentication) [HMAC] to calculate the message digest based on a key
shared between the PEP and its PDP.
This Integrity object specifies a 32-bit Key ID used to identify a
specific key shared between a particular PEP and its PDP and the
cryptographic algorithm to be used. The Key ID allows for multiple
simultaneous keys to exist on the PEP with corresponding keys on the
PDP for the given PEPID. The key identified by the Key ID was used to
compute the message digest in the Integrity object. All
implementations, at a minimum, MUST support HMAC-MD5-96, which is
HMAC employing the MD5 Message-Digest Algorithm [MD5] truncated to
96-bits to calculate the message digest.
This object also includes a sequence number that is a 32-bit unsigned
integer used to avoid replay attacks. The sequence number is
initiated during an initial Client-Open Client-Accept message
exchange and is then incremented by one each time a new message is
Durham, et al. Standards Track [Page 18]
RFC 2748 COPS January 2000
sent over the TCP connection in the same direction. If the sequence
number reaches the value of 0xFFFFFFFF, the next increment will
simply rollover to a value of zero.
The variable length digest is calculated over a COPS message starting
with the COPS Header up to the Integrity Object (which MUST be the
last object in a COPS message) INCLUDING the Integrity object's
header, Key ID, and Sequence Number. The Keyed Message Digest field
is not included as part of the digest calculation. In the case of
HMAC-MD5-96, HMAC-MD5 will produce a 128-bit digest that is then to
be truncated to 96-bits before being stored in or verified against
the Keyed Message Digest field as specified in [HMAC]. The Keyed
Message Digest MUST be 96-bits when HMAC-MD5-96 is used.
0 1 2 3
+-------------+-------------+-------------+-------------+
| Key ID |
+-------------+-------------+-------------+-------------+
| Sequence Number |
+-------------+-------------+-------------+-------------+
| |
+ +
| ...Keyed Message Digest... |
+ +
| |
+-------------+-------------+-------------+-------------+
2.3 Communication
The COPS protocol uses a single persistent TCP connection between the
PEP and a remote PDP. One PDP implementation per server MUST listen
on a well-known TCP port number (COPS=3288 [IANA]). The PEP is
responsible for initiating the TCP connection to a PDP. The location
of the remote PDP can either be configured, or obtained via a service
location mechanism [SRVLOC]. Service discovery is outside the scope
of this protocol, however.
If a single PEP can support multiple client-types, it may send
multiple Client-Open messages, each specifying a particular client-
type to a PDP over one or more TCP connections. Likewise, a PDP
residing at a given address and port number may support one or more
client-types. Given the client-types it supports, a PDP has the
ability to either accept or reject each client-type independently.
If a client-type is rejected, the PDP can redirect the PEP to an
alternative PDP address and TCP port for a given client-type via
COPS. Different TCP port numbers can be used to redirect the PEP to
another PDP implementation running on the same server. Additional
provisions for supporting multiple client-types (perhaps from
Durham, et al. Standards Track [Page 19]
RFC 2748 COPS January 2000
independent PDP vendors) on a single remote PDP server are not
provided by the COPS protocol, but, rather, are left to the software
architecture of the given server platform.
It is possible a single PEP may have open connections to multiple
PDPs. This is the case when there are physically different PDPs
supporting different client-types as shown in figure 2.
+----------------+
| |
| Network Node | Policy Servers
| |
| +-----+ | COPS Client Type 1 +-----+
| | |<-----|-------------------->| PDP1|
| + PEP + | COPS Client Type 2 +-----+
| | |<-----|---------\ +-----+
| +-----+ | \----------| PDP2|
| ^ | +-----+
| | |
| \-->+-----+ |
| | LPDP| |
| +-----+ |
| |
+----------------+
Figure 2: Multiple PDPs illustration.
When a TCP connection is torn down or is lost, the PDP is expected to
eventually clean up any outstanding request state related to
request/decision exchanges with the PEP. When the PEP detects a lost
connection due to a timeout condition it SHOULD explicitly send a
Client-Close message for each opened client-type containing an
<Error> object indicating the "Communication Failure" Error-Code.
Additionally, the PEP SHOULD continuously attempt to contact the
primary PDP or, if unsuccessful, any known backup PDPs. Specifically
the PEP SHOULD keep trying all relevant PDPs with which it has been
configured until it can establish a connection. If a PEP is in
communication with a backup PDP and the primary PDP becomes
available, the backup PDP is responsible for redirecting the PEP back
to the primary PDP (via a <Client-Close> message containing a
<PDPRedirAddr> object identifying the primary PDP to use for each
affected client-type). Section 2.5 details synchronization behavior
between PEPs and PDPs.
Durham, et al. Standards Track [Page 20]
RFC 2748 COPS January 2000
2.4 Client Handle Usage
The client handle is used to identify a unique request state for a
single PEP per client-type. Client handles are chosen by the PEP and
are opaque to the PDP. The PDP simply uses the request handle to
uniquely identify the request state for a particular Client-Type over
a particular TCP connection and generically tie its decisions to a
corresponding request. Client handles are initiated in request
messages and are then used by subsequent request, decision, and
report messages to reference the same request state. When the PEP is
ready to remove a local request state, it will issue a delete message
to the PDP for the corresponding client handle. A handle MUST be
explicitly deleted by the PEP before it can be used by the PEP to
identify a new request state. Handles referring to different request
states MUST be unique within the context of a particular TCP
connection and client-type.
2.5 Synchronization Behavior
When disconnected from a PDP, the PEP SHOULD revert to making local
decisions. Once a connection is reestablished, the PEP is expected to
notify the PDP of any events that have passed local admission
control. Additionally, the remote PDP may request that all the PEP's
internal state be resynchronized (all previously installed requests
are to be reissued) by sending a Synchronize State message.
After a failure and before a new connection is fully functional,
disruption of service can be minimized if the PEP caches previously
communicated decisions and continues to use them for some appropriate
length of time. Specific rules for such behavior are to be defined in
the appropriate COPS client-type extension specifications.
A PEP that caches state from a previous exchange with a disconnected
PDP MUST communicate this fact to any PDP with which it is able to
later reconnect. This is accomplished by including the address and
TCP port of the last PDP for which the PEP is still caching state in
the Client-Open message. The <LastPDPAddr> object will only be
included for the last PDP with which the PEP was completely in sync.
If the service interruption was temporary and the PDP still contains
the complete state for the PEP, the PDP may choose not to synchronize
all states. It is still the responsibility of the PEP to update the
PDP of all state changes that occurred during the disruption of
service including any states communicated to the previous PDP that
had been deleted after the connection was lost. These MUST be
explicitly deleted after a connection is reestablished. If the PDP
issues a synchronize request the PEP MUST pass all current states to
the PDP followed by a Synchronize State Complete message (thus
Durham, et al. Standards Track [Page 21]
RFC 2748 COPS January 2000
completing the synchronization process). If the PEP crashes and loses
all cached state for a client-type, it will simply not include a
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -