idnits 2.17.1 draft-kala-dtcp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 21, 2017) is 2500 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '9' on line 141 -- Looks like a reference, but probably isn't: '3' on line 552 == Missing Reference: '0-9a-f' is mentioned on line 554, but not defined -- Looks like a reference, but probably isn't: '4' on line 554 == Missing Reference: 'Criteria' is mentioned on line 1094, but not defined == Missing Reference: 'Stats' is mentioned on line 1122, but not defined -- Looks like a reference, but probably isn't: '7' on line 1661 -- Looks like a reference, but probably isn't: '8' on line 1691 == Unused Reference: 'RFC5938' is defined on line 2030, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1945 ** Downref: Normative reference to an Informational RFC: RFC 2104 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Performance Metrics Group Sumit. Kala 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track David. Cavuto 5 Expires: December 21, 2017 ATT 6 June 21, 2017 8 DTCP: Dynamic Tasking Control Protocol 9 draft-kala-dtcp-01 11 Abstract 13 Dynamic Tasking Control Protocol is a message-based interface by 14 which an authorized client may connect to a server -- usually a 15 network element (NE) or security policy enforcement point (PEP) -- 16 and issue dynamic requests for data. These tasking requests contain, 17 among other parameters, packet matching criteria that may apply to 18 certain packets flowing through that network element. The primary 19 intent of the tasking request is to instruct that network element to 20 send copies of packets matching those criteria to a destination 21 (usually via tunneling) for further inspection or other action. The 22 protocol contains a security architecture to address client or server 23 spoofing as well as replay prevention. The protocol assumes that 24 multiple clients may simultaneously control a single server. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 21, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Operational Modes . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Performance Considerations . . . . . . . . . . . . . . . . 4 62 1.3. Conventions used in this document . . . . . . . . . . . . 5 63 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.3. Control Source . . . . . . . . . . . . . . . . . . . . . . 5 67 2.4. Content Destination . . . . . . . . . . . . . . . . . . . 5 68 2.5. Criteria . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 70 3.1. Request-Response Paradigm . . . . . . . . . . . . . . . . 6 71 3.2. Asynchronous Notifications . . . . . . . . . . . . . . . . 7 72 3.3. Data Delivery Mechanism . . . . . . . . . . . . . . . . . 8 73 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1. No Information Exposure . . . . . . . . . . . . . . . . . 9 75 4.2. Independence of Control Sources . . . . . . . . . . . . . 9 76 4.3. Control Source to Content Destination Access Control . . . 9 77 4.4. Per-Message Security Mechanisms . . . . . . . . . . . . . 9 78 4.4.1. Sequence Number . . . . . . . . . . . . . . . . . . . 9 79 4.4.1.1. Sequence Number Negative Window . . . . . . . . . 10 80 4.4.2. Hashing Message Authentication Code (HMAC) . . . . . . 11 81 5. Application-Layer Message Formats . . . . . . . . . . . . . . 12 82 5.1. Request General Format . . . . . . . . . . . . . . . . . . 13 83 5.2. Response General Format . . . . . . . . . . . . . . . . . 13 84 5.3. Notification General Format . . . . . . . . . . . . . . . 13 85 5.4. Add Request . . . . . . . . . . . . . . . . . . . . . . . 14 86 5.4.1. Criteria Timeouts . . . . . . . . . . . . . . . . . . 15 87 5.5. Add Response . . . . . . . . . . . . . . . . . . . . . . . 16 88 5.6. Delete Request . . . . . . . . . . . . . . . . . . . . . . 17 89 5.7. Delete Response . . . . . . . . . . . . . . . . . . . . . 18 90 5.8. Refresh Request . . . . . . . . . . . . . . . . . . . . . 19 91 5.9. Refresh Response . . . . . . . . . . . . . . . . . . . . . 20 92 5.10. List Request . . . . . . . . . . . . . . . . . . . . . . . 21 93 5.11. List Response . . . . . . . . . . . . . . . . . . . . . . 21 94 5.12. NoOp Request . . . . . . . . . . . . . . . . . . . . . . . 23 95 5.13. NoOp Response . . . . . . . . . . . . . . . . . . . . . . 24 96 5.14. Restart Notification . . . . . . . . . . . . . . . . . . . 24 97 5.15. Rollover Notification . . . . . . . . . . . . . . . . . . 24 98 5.16. NoOp Notification . . . . . . . . . . . . . . . . . . . . 24 99 5.17. Timeout Notification . . . . . . . . . . . . . . . . . . . 25 100 5.18. Congestion Notification . . . . . . . . . . . . . . . . . 25 101 5.19. CongestionDelete Notification . . . . . . . . . . . . . . 26 102 5.20. DuplicatesDropped Notification . . . . . . . . . . . . . . 26 103 6. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 27 104 6.1. Special treatment of response to List request . . . . . . 27 105 6.2. Error or Exception Conditions . . . . . . . . . . . . . . 29 106 6.3. Extensions in ABNF . . . . . . . . . . . . . . . . . . . . 30 107 6.4. Current Version . . . . . . . . . . . . . . . . . . . . . 30 108 6.5. No specific port . . . . . . . . . . . . . . . . . . . . . 30 109 6.6. Unimplemented Protocol Methods and Parameters . . . . . . 31 110 6.7. Version Mismatches . . . . . . . . . . . . . . . . . . . . 31 111 6.7.1. DTCP Client version exceeds DTCP Server version . . . 32 112 6.7.2. DTCP Server version exceeds DTCP Client version . . . 32 113 7. Message Payload Examples . . . . . . . . . . . . . . . . . . . 32 114 7.1. Successful ADD Request and Response Payload . . . . . . . 33 115 7.2. Unsuccessful DELETE Request and Response Payload . . . . . 33 116 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 34 117 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 118 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 119 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 41 120 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 121 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 122 Appendix A. Prior Implementation . . . . . . . . . . . . . . . . . 42 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 125 1. Introduction 127 The Dynamic Tasking Control Protocol (DTCP) is a mechanism used to 128 dynamically control network elements in the course of performing a 129 security or other analysis on a transient network event. 131 Network Security personnel typically have little visibility into the 132 very networks they are monitoring. Routers and switches have awkward 133 mechanisms such as port mirroring and cFlowd to enable personnel some 134 meager view into the traffic flowing through a device. 136 However, when a security incident does happen to be detected, the 137 security analysis staff struggles to gain more insight as to the 138 actual content of the incident, via inference from these tools. This 139 is a time-consuming and cumbersome task. 141 cFlowd [9] and other aggregation mechanisms provide only session- 142 level statistics about the event, and fail to provide any view into 143 the actual packet data. In contrast, wholesale backhauling of port- 144 mirrored data is often cumbersome (and expensive) to set up, since it 145 requires pre-provisioned free bandwidth on wide-area links, and often 146 additional network hardware to implement. 148 The intent of DTCP is to provide a simple mechanism by which a third- 149 party device can interact with a network element or security policy- 150 enforcement-point (PEP) that normally processes packetized network 151 data, and in that interaction cause the PEP to take some action 152 (usually copy) on a defined subset of that packet data to be 153 forwarded for further inspection and analysis. 155 packet +---+ packet 156 data ->---|NE |--->- data 157 +---+ 158 ^ | 159 | | 160 DTCP ----+ +---> copy of selected packet data 162 Figure 1 - DTCP interacting with a network element. 164 The Network Element (NE) or PEP may be a firewall or proxy server, or 165 some other non-security-specific network element, such as a router or 166 a switch. This is illustrated in Figure 1. 168 1.1. Operational Modes 170 The primary operation in DTCP is the specification of the filter 171 criteria used to select or filter packets. DTCP is designed to work 172 in an IPv4 environment, and accordingly all selection criteria are 173 chosen from IPv4 and higher-layer protocol definitions. Note that 174 current DTCP syntax is limited to L3 and L4, but could be expanded to 175 higher layers. Basic filter criteria definitions have semantic (if 176 not syntactic) similarity to well-known router access-control lists 177 (ACLs) or firewall rulesets. 179 The primary operational mode of DTCP is the "copy" mode, whereby the 180 controlled network element forwards the packet towards its intended 181 destination, and also makes a copy of that packet, which it forwards 182 towards a preconfigured collection and analysis center. In this 183 mode, the original packet flow is not interrupted. DTCP makes no 184 provisions for the potential performance impact on the network 185 element when performing this function; obviously a negligible impact 186 is most desirable. 188 DTCP also supports optional modes for purely redirecting the packet 189 data (instead of making a copy of it), as well as blocking packet 190 data. These modes, if implemented, can provide additional 191 functionality for network security personnel, who may have decided 192 that particular traffic is disallowed on the network and wishes to 193 interrupt the selected flow of traffic. 195 Of critical distinction to DTCP is the basic paradigm that DTCP does 196 NOT involve a "reprovisioning" or "reconfiguration" of the controlled 197 device. DTCP is by its very nature transient; controlled devices 198 should not attempt to maintain DTCP state in a non-volatile storage 199 system. 201 1.2. Performance Considerations 202 It is envisioned that the controlling side of DTCP will be 203 implemented by both human-interactive systems and automated systems. 204 Since controlled Network Element MUST be able to respond to automated 205 requests at a potentially high rate (due to floods or other attacks), 206 the protocol implies a high performance requirement during the 207 "criteria specification" phase of the interaction. In particular, 208 the response time of the Network Element to respond to the DTCP 209 request to monitor data is of considerable importance, as the traffic 210 intended to be monitored may be short-lived. 212 While concrete performance requirements are outside the scope of this 213 document, implementers are urged to focus performance on this part of 214 the client-server interaction. 216 1.3. Conventions used in this document 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in RFC 2119 [RFC2119]. 222 2. Definitions 224 The following sections define terms that have special significance 225 within the DTCP context. 227 2.1. Server 229 The DTCP Server is the PEP or network element that controls the data 230 of interest. The DTCP Server will be controlled in turn via DTCP. 231 The Server is responsible for maintaining state of DTCP Client 232 Requests, and forwarding data accordingly. Usually the DTCP Server 233 will be implemented on a firewall or router (or an accessory device 234 attached to one). The Server generally Responds to Requests, and can 235 also initiate Asynchronous Notifications. One Server generally 236 services more than one Client. 238 2.2. Client 240 The DTCP Client is an arbitrary host that initiates Requests to the 241 Server via DTCP. 243 2.3. Control Source 245 A Control Source is the instantiation of one DTCP Client, with 246 respect to a given Server. Each Control Source is preconfigured and 247 pre-authorized on a given Server to be able to interact with it via 248 DTCP. Control Sources may also receive Asynchronous Notifications. 249 There may be many Control Sources configured on a given Server. A 250 Control Source MUST NOT be identified by IP address; rather, Control 251 Sources are identified by user-configured character strings. 253 2.4. Content Destination 254 A Content Destination is the recipient of the extracted data, once it 255 is forwarded by the server. Content Destinations are also 256 preconfigured on the server. A Content Destination MUST NOT be 257 identified by IP address; rather, Content Destinations are identified 258 by user-configured character strings. 260 2.5. Criteria 262 The Criteria is the list of matching conditions under which a packet 263 is selected and acted upon by the server. Criteria are specified in 264 requests from the client to the server, which maintains a list of 265 active criteria for each client. 267 3. Overview of Operation 269 This section describes the basic interaction between the DTCP 270 elements, as well as the protocol message flows. 272 3.1. Request-Response Paradigm 274 The basic model for DTCP is a request-response message exchange 275 paradigm, where the server waits for messages on a specific UDP port 276 from authorized Control Sources. When a request message arrives, the 277 server processes the request, performs the necessary internal state 278 change as per the request, and then sends a reply message. 280 Note that although DTCP is specified as a message-based protocol, it 281 is designed and specified here to operate via single UDP/IP packets, 282 for performance reasons. While it is certainly possible for DTCP to 283 be operated over TCP/IP for reliable connections, such use is 284 unexplored as yet, and any implementation-specific decisions made are 285 unspecified herein. This document is written assuming that UDP will 286 be used as the Layer-4 transport mechanism. 288 A DTCP Server MUST allocate at least ONE IP address and ONE UDP port 289 for inbound connections from clients. Each DTCP Client MUST be 290 statically configured with at least ONE IP address and ONE UDP port 291 representing the server. 293 There is no mechanism defined that ensures proper configuration 294 between DTCP Clients and servers for requests and responses. 296 In general, each request and each reply are a single UDP message, 297 contained within a single IP packet. Since IP packets may be 298 fragmented during delivery, each DTCP endpoint MUST be capable of IP 299 fragment reassembly. 301 An IP packet containing a DTCP Request message from a client to a 302 server MUST have the following attributes properly set: 304 1. Destination IP Address MUST equal an IP address of a DTCP Server; 306 2. IP Protocol MUST equal 17 (UDP); 307 3. Destination UDP Port MUST equal a UDP port being listened on by 308 the respective DTCP Server. 310 The DTCP Server MUST NOT rely on the source IP address or source UDP 311 port of inbound request packets for any identification or 312 authentication of the message. 314 An IP packet containing a DTCP Reply message from a server to a 315 client MUST have the following attributes properly set: 317 1. Source IP Address MUST equal the Destination IP Address of the IP 318 packet containing the Request; 320 2. Destination IP address MUST equal the Source IP Address of the IP 321 packet containing the Request; 323 3. IP Protocol MUST equal 17 (UDP); 325 4. Destination UDP port MUST equal the Source UDP port of the UDP 326 message containing the Request; 328 5. Source UDP port MUST equal the Destination UDP port of the UDP 329 message containing the Request. 331 There is no specific UDP port registered for DTCP; rather, each DTCP 332 Server SHOULD permit the user to configure the port or set of ports 333 on which it will listen for inbound DTCP requests. Additionally, a 334 DTCP Server MAY choose to implement address or other filters on the 335 source of inbound client requests; however, this is optional and 336 implementation specific. (Recall that clients are identified by 337 strings, NOT IP addresses.) 339 3.2. Asynchronous Notifications 341 Notifications are sent out by the DTCP Server to a set of statically 342 preconfigured DTCP Clients who wish to receive notifications of 343 asynchronous events. Such messages are sent to IP addresses that 344 have been preconfigured therein. 346 A DTCP Client MAY provide a mechanism for accepting and processing 347 Notifications. The DTCP Server MUST be preconfigured with an IP 348 address and UDP port for each DTCP Client that wishes to receive 349 Notifications. 351 There is no mechanism defined that ensures proper configuration 352 between DTCP Clients and servers for Notifications. 354 An IP packet containing a DTCP Notification message from a server to 355 a client MUST have the following attributes properly set: 357 1. Destination IP address MUST equal the configured DTCP Client IP 358 address; 360 2. IP Protocol MUST equal 17 (UDP); 362 3. Destination UDP port MUST equal the configured DTCP Client UDP 363 port. 365 A future enhancement to this document may be to provide a mechanism 366 for clients to dynamically self-register for notifications. 368 A DTCP Server SHOULD include a configuration parameter for each 369 configured Control Source to indicate the Notification Version for 370 that Control Source. If such a parameter is configured for a given 371 Control Source, all Asynchronous Notifications sent from the DTCP 372 Server to that Control Source MUST precisely match the Notification 373 Version configured for that Control Source. Additionally, if such a 374 parameter is configured for a given Control Source, the DTCP Server 375 MUST NOT send Asynchronous Notifications to that Control Source that 376 do not exist in the DTCP specification indicated for that Control 377 Source. Finally, the DTCP Server MUST ensure that Asynchronous 378 Notifications whose formats have been modified in newer versions of 379 DTCP are properly formatted to meet the older DTCP specification 380 version indicated for that Control Source. 382 Note that in general the DTCP Server SHOULD accept requests from a 383 DTCP Client using a DTCP Version other than that specified in the 384 Notification Version for that client. 386 If the DTCP Server is unable to meet these requirements, upon 387 receiving a request from a DTCP Client with a mismatching version, it 388 MUST return a a "505 DTCP Version not supported" error message *using 389 the highest version supported by the DTCP Server*, and discontinue 390 processing of that request. 392 It is recommended, however, that the DTCP Server reject such a state 393 at configuration time rather than at run time. 395 3.3. Data Delivery Mechanism 397 Since the original packet IP header is not originally addressed to 398 the intended Content Destination, each DTCP Server implementation 399 MUST provide a mechanism for delivery of redirected data packets to 400 appropriate Content Destinations. This explicitly includes IP 401 checksums and IP TTL, as well as any higher-layer headers -- which 402 SHOULD NOT be altered once captured -- but may not include MAC or 403 lower-layer checksums. 405 DTCP explicitly does not specify the mechanism of data delivery to 406 the Content Destination. Such a delivery mechanism is 407 implementation- specific, and is outside the scope of this document. 409 As an example, Servers could utilize such technologies as VLAN 410 tagging or IP tunneling to deliver entire unaltered data packets to 411 Content Destinations. 413 4. Security Model 415 Since DTCP is, by design, a security protocol, it is imperative that 416 it be resistant to malicious use. 418 4.1. No Information Exposure 420 DTCP was designed with the explicit paradigm that only information 421 intentionally available to a given Control Source is ever exposed to 422 that Control Source. For example: the existence of other Control 423 Sources, or Content Destinations to which it has no access MUST NOT 424 be exposed to a given Control Source, e.g. via notifications or 425 error messages. Also, the server MUST NOT respond to any message 426 that fails its security checks. This basic paradigm MUST be upheld 427 in DTCP Server implementations. 429 4.2. Independence of Control Sources 431 DTCP may be implemented on network elements providing service to 432 different customers. If each customer is allowed access to the DTCP 433 Server, they MUST NOT be aware that another customer is using the 434 DTCP Server. More specifically, neither customer's use (or misuse) 435 of the DTCP Server can affect the other customer's use of it. 437 Limits on service-affecting actions that may be taken by a DTCP 438 Client are outside the scope of this document. 440 4.3. Control Source to Content Destination Access Control 442 A DTCP Server SHOULD provide a mechanism by which each configured 443 Control Source is granted access to one or more Content Destinations. 445 4.4. Per-Message Security Mechanisms 447 The primary motivation behind the per-message security mechanisms is 448 to provide both message integrity as well as source authenticity. 449 Additionally, providing insulation against replay-type attacks is 450 also a motivation, though secondary. 452 DTCP currently provides no mechanism for confidentiality. If 453 confidentiality is required, it is recommended that DTCP messages be 454 sent via a secure transport. 456 Note: Authentication failures, defined as a failure of these per- 457 message security mechanisms, MUST NOT be reported to the DTCP Client. 458 They SHOULD be logged on the DTCP server, and possibly acted upon by 459 administration staff. 461 4.4.1. Sequence Number 462 Every message initiated by a DTCP Client MUST contain a sequence 463 number. The request sequence number is an unsigned 64-bit whole 464 number chosen arbitrarily by the client and maintained by the server 465 persistently for each Control Source. All requests from a given 466 Control Source MUST contain a monotonically-increasing sequence 467 number. The sequence number for each successive request may 468 increment by no more than 256. The stored last-valid sequence number 469 shall only be updated upon receipt of a valid, authentic message. 471 A reply message to a valid request MUST contain the identical 472 sequence number as the associated request. 474 Other than as specified below in "Sequence Number Negative Window", 475 repetition of the last sequence number, or an invalid (non- 476 monotonically-increasing) sequence number, in an otherwise-valid 477 message MUST result in the message being dropped and a security 478 violation being logged, except when the sequence number wraps over 479 zero due to bit-field-length constraints. 481 Rollover of the sequence number shall only be permitted when the MSB 482 of the current sequence number is all-ones; otherwise this shall be 483 considered a security violation. A rollover of the sequence number 484 shall cause both an asynchronous notification message to be sent to 485 any configured static address(es) for the respective Control Source 486 as well as a log message to be generated. 488 It is suggested that clients do whatever possible to persistently 489 store the current sequence number as there is no DTCP method by which 490 to reset the current sequence number. 492 DTCP Servers SHOULD provide some mechanism for manually resetting the 493 sequence number for a given client. 495 Additionally, DTCP Servers SHOULD implement a Negative Window feature 496 as specified in the following section. 498 4.4.1.1. Sequence Number Negative Window 500 Under high load, a multithreaded DTCP client may send multiple 501 requests (with properly incrementing sequence numbers) to the DTCP 502 Server without waiting for each reply to come back individually. 503 Because packets may be reordered through the network, they may arrive 504 at the DTCP Server out of order. 506 For example, the DTCP client may send: 508 1. Request 1 (Seq = 1) 509 2. Request 2 (Seq = 2) 511 3. Request 3 (Seq = 3) 513 But due to network reordering, the DTCP Server may receive: 515 1. Request 1 (Seq = 1) 517 2. Request 3 (Seq = 3) 519 3. Request 2 (INVALID) 521 Unfortunately, the specification of the sequence number above will 522 make Request 2 invalid, because once Request 3 is processed, the 523 stored sequence number in the DTCP Server for that Client has been 524 incremented to 3. 526 Therefore to correct this problem, the DTCP Server SHOULD include a 527 "negative" window as well as the required "positive" window for 528 sequence numbers, and keep track of received sequence numbers within 529 that negative window. However, in order to maintain the replay- 530 protection afforded by the sequence number in the first place, any 531 DTCP Server implementing a negative window MUST also implement 532 tracking of particular sequence numbers received within the union of 533 both windows, and MUST NOT respond to any requests containing a 534 sequence number already received. 536 If the received sequence number is in the negative window, the DTCP 537 Server would simply store that sequence number as seen from that 538 particular DTCP Client and process the packet. If the sequence 539 number of the packet is in the positive window, the new positive and 540 negative window would begin and end at this packet's sequence number 541 respectively with the window sizes remaining the same. So a DTCP 542 packet with sequence number within the negative window but that has 543 not been seen (or anywhere within the positive window) is valid. 545 4.4.2. Hashing Message Authentication Code (HMAC) 547 A DTCP Server MUST store a statically-provisioned secret key for each 548 configured client. This key is manually shared with each DTCP 549 Client. Each request and response message MUST contain, as the last 550 entry, a parameter called Authentication-Info, whose value is the 551 HMAC algorithm specified in [RFC2104] of the rest of the message 552 payload (including the sequence number) generated using a SHA-1 [3] 553 digest and the secret key. This digest is expressed in hexadecimal 554 notation ([0-9a-f]), using 40 UTF-8 [4] characters to express the 555 160-bit SHA-1 hash. 557 Original Message: text 558 Secret Key: K 559 HMAC: hash = SHA1HMAC(K, text) 560 New Message: text + "Authentication-Info: " + hash 562 Figure 2 - Generating the message HMAC from the original message. 564 The shared secret key MUST NOT be sent in any DTCP message. 566 The precise algorithm, excerpted here from RFC-2104 for reference 567 purposes (using SHA-1 as the hashing function H and byte length B=64) 568 is as follows: 570 We define two fixed and different strings ipad and opad as follows 571 (the 'i' and 'o' are mnemonics for inner and outer): 572 ipad = the byte 0x36 repeated B times 573 opad = the byte 0x5C repeated B times. 575 To compute HMAC over the data `text' we perform 576 H(K XOR opad, H(K XOR ipad, text)) 578 5. Application-Layer Message Formats 580 In general, the best source for the message formats is the Formal 581 Syntax specified below. The following prose is provided for 582 informational purposes and implementation guidelines. Where apparent 583 syntactic conflicts exist, the Formal Syntax is defined to be 584 correct. 586 DTCP messages are formatted in human-readable CRLF-delimited UTF-8 587 text format, using a mechanism similar to HTTP [RFC1945] or SIP 588 [RFC3261]. Each message begins with an initial "command" line, 589 followed by an optional series of parameter-value lines. Each token 590 in the command line as well as each option line is separated by one 591 or more white space characters. The entire message MUST end with two 592 CRLFs. 594 The final token in any line MAY have whitespace before its 595 terminating CRLF, but is not so required, and is not so reflected in 596 the ABNF. DTCP servers SHOULD ignore extra whitespace between the 597 final token and the terminating CRLF, but MUST return a Syntax Error 598 otherwise. 600 Parameter names are specified in mixed case, but MUST be matched 601 regardless of case. 603 Control characters or other unprintable characters in the parameter 604 value may be indicated by a backslash (\) followed by precisely three 605 digits indicating the UTF-8 value for the character, possibly 606 including leading zeros. The backslash notation may be used to 607 express any character, including whitespace. Backslash notation is 608 explicitly forbidden from being interpreted as either an inter-token 609 delimiter or an inter-parameter delimiter. 611 DTCP Clients and server MUST NOT rely upon the order of parameters 612 within the DTCP message, since it is not guaranteed (other than the 613 final "Authentication-Info" parameter as noted below). 615 Every DTCP message MUST contain the "Authentication-Info" parameter, 616 and it MUST be the final parameter in the message. Any parameters in 617 any DTCP message following the Authentication-Info parameter MUST be 618 disregarded. 620 If a parameter appears multiple times, the behavior is undefined and 621 not guaranteed; however, if a parameter does show up multiple times, 622 the endpoint SHOULD take the value of the first occurrence and 623 disregard any successive occurrences. 625 5.1. Request General Format 627 Each client-to-server message in DTCP begins with a single request 628 command line with the following format: 630 CRLF 632 The command line is followed by one or more parameter-value pairs, 633 comprising the message body. The message is terminated by two CRLFs. 635 A DTCP request MUST contain the Sequence Number and the Control 636 Source ID parameters. 638 5.2. Response General Format 640 Each server-to-client response message in DTCP shall begin with a 641 single response line with the following format: 643 CRLF 645 where the response-code is a three-digit numeric value, and the 646 response-text is an arbitrary-length text string intended to be 647 human-readable. The response line is followed by one or more 648 parameter-value pairs comprising the message body. The message is 649 terminated by two CRLFs. 651 Responses to successful requests MUST contain the response-code "200" 652 and the response-text "OK". 654 A DTCP response MUST contain the Sequence Number parameter. A DTCP 655 response MUST also contain the Timestamp parameter. 657 5.3. Notification General Format 659 Each server-to-client notification message in the control protocol 660 shall begin with a single response line with the following format: 662 CRLF 664 where the response-code is a three-digit numeric value, and the 665 response-text is an arbitrary-length text string intended to be 666 human-readable. The response line is followed by one or more 667 parameter-value pairs comprising the message body. The message is 668 terminated by two CRLFs. 670 A DTCP notification message MUST contain the Timestamp parameter. 672 5.4. Add Request 674 The Add request specifies a new filter criteria to be merged with the 675 existing tasking list for a given Control Source and Content 676 Destination (regardless of order added). Any missing parameters in 677 the request will inferred to be a wildcard or "don't care". The Add 678 request MAY be accompanied by one or more of the following required 679 filter criterion parameters: 681 1. Source IP address, range or IP + bitmask, or wildcard 683 2. Destination IP address, range, or IP + bitmask, or wildcard 685 3. IP Protocol or range, or wildcard 687 4. Source Layer-4 Port or range, or wildcard (parameter only 688 meaningful when IP protocol range includes protocols 6 or 17) 690 5. Destination Layer-4 Port or range, or wildcard (parameter only 691 meaningful when IP protocol range includes 6 or 17) 693 6. ICMP Type or range, or wildcard (parameter only meaningful when 694 IP protocol range includes protocol 1) 696 7. ICMP Code or range, or wildcard (parameter only meaningful when 697 IP protocol range includes protocol 1) 699 A wildcard in a given field implies that any value will match it 700 (i.e. "don't care"). 702 Additionally, the Add request MUST contain one or more of the 703 following parameters: 705 1. Timeout specified in seconds idle (maximum one day) 707 2. Timeout specified in seconds total (maximum one day) 709 3. Timeout specified in packets (maximum 64 bits) 710 4. Timeout specified in bytes (maximum 64 bits) 712 5. Flag: Static, which indicates that this criterion will never 713 timeout and persist until explicitly deleted. All other timeouts 714 shall be ignored if a STATIC flag is present. 716 Additionally, the Add request may contain one or more of the 717 following parameters: 719 1. Relative Priority (unsigned integer, minimum value 1) (optional, 720 defaults to 1) 722 2. Flag: Send Timeout Async (optional), which will cause the server 723 to send a Asynchronous Notification when the criterion times out 724 for any reason. 726 3. Action (optional), which specifies whether the packet stream 727 identified by the criterion will be a) copied to the Content 728 Destination and also forwarded to its original intended 729 destination ("Copy"), b) copied but not forwarded ("Redirect"), 730 or c) not copied and not forwarded ("Block"). By default, Action 731 is "Copy". 733 Finally, the Add request MUST contain the following control protocol 734 parameters: 736 1. Control Source Identifier 738 2. Content Destination Identifier 740 3. Sequence number (MUST be monotonically increasing for each 741 request from a given Control Source) 743 4. HMAC authenticator (MUST span message payload, plus secret key) 745 Although not explicitly expressed in the request, the DTCP Server 746 MUST maintain the date/time of each filter criterion successfully 747 added. This time is the local DTCP Server time, either maintained 748 independently by the server or synchronized via NTP. 750 5.4.1. Criteria Timeouts 752 Timeouts are required for each filter criterion added. These 753 timeouts may be specified in any of four formats: seconds-idle, 754 seconds-total, bytes, or packets. Any combination of these four 755 timeouts may be used in a filter criterion as long as at least one is 756 used. 758 Once a criterion is added, the timeouts will begin decrementing as 759 appropriate. Only the timeouts that are specified in the request 760 will be used for timing-out that criterion. When any active timeout 761 is decremented to zero, the DTCP Server will automatically delete the 762 filter criterion. For each Control Source, if enabled, when a 763 criterion times-out and is deleted, timeout notifications will be 764 sent to any statically-configured Notification Destination(s) 765 associated with that Control Source. 767 A criterion may be added as STATIC. Any such criterion shall persist 768 in the active state unless and until explicitly deleted or deleted 769 due to congestion, provided the DTCP Server maintains its normal 770 operational state. (See section 5.18 Congestion Notification for 771 more information on congestion and timeouts.) 773 If all timeout values are zero and the criterion is not marked 774 STATIC, the DTCP Server MUST return Error 433 (Improper Timeout 775 Specification) and the criterion must not be added. For STATIC 776 criteria, the DTCP Server MUST ignore the all timeout values. 778 If the server fails, STATIC rules may be lost. Any Control Source 779 that uses STATIC criteria SHOULD attempt to ensure that such criteria 780 are still up and active following any maintenance or failure event on 781 the server. 783 5.5. Add Response 785 The response to a successful Add request will consist of the 786 following parameters: 788 Criteria ID 790 The Criteria ID will be persistent for the duration of that request, 791 until it is removed explicitly by the client, or is removed 792 implicitly by either timeout or some failure of the DTCP Server. The 793 Criteria ID MUST uniquely identify that particular filter criterion 794 for that particular Control Source (and be agnostic to the Content 795 Destination). 797 DTCP Servers MUST ensure that generated Criteria ID are unique for 798 all currently-active requests for a given Control Source. 800 Ideally, the Criteria ID SHOULD be globally unique across Control 801 Sources, but this is not strictly required (since all requests will 802 always be from a particular Control Source). 804 DTCP Servers SHOULD provide unique Criteria IDs for new requests, 805 even if old ones have been deleted resulting in a fragmented ID 806 space. This prevents race conditions that can cause inconsistent 807 behavior e.g., a criterion specified in an Add request gets the same 808 Criterion Id as a recently deleted criterion (deleted due to 809 timeout), and before the delete notification could reach the Control 810 Source, it sends out an explicit delete request for the old 811 criterion, which when received by the DTCP Server would delete the 812 recently added criterion, which is clearly undesirable. 814 This response MUST also include the following parameters: 816 1. Timestamp 818 2. Sequence number (MUST match the sequence number for the request) 820 3. HMAC authenticator (MUST span message payload, plus secret key) 822 Responses to unsuccessful Add requests may take any of the following 823 forms: 825 o Syntax Error 827 o Improper Filter Criterion Specification 829 o Unknown Destination Identifier 831 o Invalid Timeout Specification 833 o Improper Authentication (logged, but never sent to client) 835 o Invalid Sequence Number (logged, but never sent to client) 837 o Unknown Control Source Identifier (logged, but never sent to 838 client) 840 5.6. Delete Request 842 The Delete request removes a particular filter criterion (or 843 optionally all filter criteria) for the particular Control Source. 844 The Delete request MUST take precisely one of the following 845 parameters: 847 o Criteria ID or list of ranges of Criteria IDs 849 o Content Destination Identifier 851 Additionally, the Delete request may contain one or more of the 852 following parameters: 854 o Flag: Static, which indicates that criteria added as STATIC should 855 be deleted as well. (optional) If this flag is omitted, STATIC 856 criteria MUST NOT be deleted. 858 If a single Criteria ID or list of ranges Criteria IDs is specified, 859 the respective criterion/criteria is/are removed from the list of 860 filter conditions that apply for that Control Source. 862 If a Content Destination Identifier is specified, all criteria are 863 removed from the list of filter conditions to that particular Content 864 Destination for that Control Source, except for STATIC criteria 865 --unless the STATIC flag is specified. (Note that any other criteria 866 specified by any other Control Sources MUST remain unaffected.) 868 Additionally, the Delete request MUST contain the following 869 parameters: 871 o Control Source Identifier 873 o Sequence number (MUST be monotonically increasing for each request 874 from a given Control Source) 876 o HMAC authenticator (MUST span message payload, plus secret key) 878 5.7. Delete Response 880 The response to a successful Delete will consist of the following 881 parameter: 883 o Number of Criteria Deleted 885 This parameter is an integer specifying the total number of filter 886 criteria that were actually deleted. The number will be precisely 1 887 if a single, valid Criteria ID is supplied in the Delete request. If 888 multiple valid Criteria IDs are supplied, the number of criteria 889 actually deleted will be returned. 891 If any individual Criteria ID is invalid, the entire response will 892 return an error and no action shall be taken by the server for any 893 supplied Criteria ID. If a Content Destination Identifier is 894 supplied, the number of criteria deleted shall be equal to the total 895 number of active filter criteria from the requesting Control Source 896 to that particular Content Destination. If no such criteria exist, 897 the DTCP Server will return a successful delete response (with 898 criteria deleted parameter set to zero). 900 When a range is specified, any existing criteria matching the 901 Criteria ID in that range (inclusive) will be deleted and the true 902 number of criteria deleted (including possibly zero) will be 903 returned. 905 Trying to delete a STATIC criterion without the STATIC flag in the 906 Delete request will result in that criterion NOT being deleted. Such 907 a deletion attempt will return a success (non-error) response, 908 including the actual number of criteria deleted (which may be zero). 910 This response MUST also include the following parameters: 912 o Timestamp 914 o Sequence number (MUST match the sequence number for the request) 916 o HMAC authenticator (MUST span message payload, plus secret key) 918 Responses to unsuccessful Delete requests may take any of the 919 following forms: 921 o Syntax Error 923 o Unknown Criteria ID 925 o Unknown Destination Identifier 927 o Improper Authentication (logged, but never sent to client) 929 o Invalid Sequence Number (logged, but never sent to client) 931 o Unknown Control Source Identifier (logged, but never sent to 932 client) 934 5.8. Refresh Request 936 The Refresh request updates the timeout for a particular filter 937 criterion or set of filter criteria (or optionally all filter 938 criteria) for the particular Control Source assigned to a particular 939 Content Destination. This is used to maintain active criteria that 940 are in danger of timing-out based on the original Add request. The 941 updated timeout will replace the current remaining timeout, NOT be 942 added to it. The Refresh request MUST take precisely one of the 943 following parameters: 945 o Criteria ID or list of ranges of Criteria IDs 947 o Content Destination Identifier 949 Additionally, the Refresh request MUST contain one or more of the 950 following parameters: 952 o Timeout specified in seconds total 954 o Timeout specified in seconds idle 956 o Timeout specified in packets 958 o Timeout specified in bytes 960 (Note that a Refresh request MUST NOT be used to make an existing 961 filter criterion STATIC. A criterion MUST be added explicitly as 962 STATIC in its original Add.) 964 Finally, the Refresh request MUST contain the following parameters: 966 o Control Source Identifier 968 o Sequence number (MUST be monotonically increasing for each request 969 from a given Control Source) 971 o HMAC authenticator (MUST span message payload, plus secret key) 973 5.9. Refresh Response 975 The response to a successful Refresh will consist of the following 976 parameters: 978 o Number of Criteria Refreshed 980 This parameter is an integer specifying the total number of filter 981 criteria that were actually updated. The number will be precisely 1 982 if a single, valid Criteria ID is supplied. If multiple valid 983 Criteria ID are supplied, the number of criteria updated will be 984 returned, and that will equal the number of supplied Criteria IDs. 985 If any Criteria ID is invalid, the entire response will return an 986 error and no action shall be taken by the server for any supplied 987 Criteria ID. If a Content Destination Identifier is supplied, the 988 number of criteria updated shall be equal to the total number of 989 active filter criteria from the requesting Control Source to that 990 particular Content Destination, including zero (which will NOT return 991 an error). 993 This response MUST also include the following parameters: 995 o Timestamp 997 o Sequence number (MUST match the sequence number for the request) 999 o HMAC authenticator (MUST span message payload, plus secret key) 1001 Responses to unsuccessful Refresh requests may take any of the 1002 following forms: 1004 o Syntax Error 1006 o Invalid Timeout Specification 1008 o Unknown Criteria ID 1010 o Unknown Destination Identifier 1012 o Improper Authentication (logged, but never sent to client) 1014 o Invalid Sequence Number (logged, but never sent to client) 1016 o Unknown Control Source Identifier (logged, but never sent to 1017 client) 1019 5.10. List Request 1021 The List request makes no change on the DTCP Server, but returns a 1022 list of all criteria that a particular Control Source has added. The 1023 Control Source may request this list on the basis of Content 1024 Destination, Criteria ID, or overall (for that particular Control 1025 Source). The List request takes the following parameters: 1027 o Content Destination Identifier (optional) 1029 o Criteria ID or List of ranges of Criteria IDs (optional) 1031 o Flag: Statistics / Criteria / All 1033 If neither of the optional parameters is included, the server MUST 1034 reply with the full set of criteria associated with that Control 1035 Source. 1037 Additionally, the List request MUST contain the following parameters: 1039 o Control Source Identifier 1041 o Sequence number (MUST be monotonically increasing for each request 1042 from a given Control Source) 1044 o HMAC authenticator (MUST span message payload, plus secret key) 1046 5.11. List Response 1048 The response to a successful List will consist of a formatted list -- 1049 essentially a table -- of filter criteria and related parameters. 1051 Fields will be included and excluded depending on the presence and 1052 the value of Stats/Criteria/All entry in the request as noted in 1053 square brackets [] following the value listed below. Each entry in 1054 the List list shall contain the following fields as specified in the 1055 original criteria: 1057 o Control Source Identifier 1059 o Control Source IP Address 1061 o Content Destination Identifier 1063 o Criteria ID 1065 o Date/Time added 1067 o Specified Source IP address, range or IP + bitmask , or wildcard 1068 [Criteria] 1070 o Specified Destination IP address, range, or IP + bitmask, or 1071 wildcard [Criteria] 1073 o IP Protocol or range, or wildcard [Criteria] 1075 o Source Layer-4 Port or range, or wildcard (parameter only 1076 meaningful when IP protocol range includes protocols 6 or 17) 1077 [Criteria] 1079 o Destination Layer-4 Port or range, or wildcard (parameter only 1080 meaningful when IP protocol range includes 6 or 17) [Criteria] 1082 o ICMP Type or range, or wildcard (parameter only meaningful when IP 1083 protocol range includes protocol 1) [Criteria] 1085 o ICMP Code or range, or wildcard (parameter only meaningful when IP 1086 protocol range includes protocol 1) [Criteria] 1088 o Timeout specified in seconds total [Criteria] 1090 o Timeout specified in seconds idle [Criteria] 1092 o Timeout specified in packets [Criteria] 1094 o Timeout specified in bytes [Criteria] 1096 The List list shall also contain the following statistical 1097 information based on each criterion: 1099 o An ordinal counter to specify the position of this entry in the 1100 context of the list 1102 o An integer specifying the total number of entries in the list 1104 o Timeout remaining in seconds total [Stats] 1106 o Timeout remaining in seconds idle [Stats] 1108 o Timeout remaining in packets [Stats] 1110 o Timeout remaining in bytes [Stats] 1112 o An indication if the timeout is STATIC 1114 o Last 10-second average bandwidth, in bits/second [Stats] 1116 o Total number of packets that have matched this Criteria [Stats] 1118 o Total number of bytes that have matched this Criteria [Stats] 1120 o Total times this rule has been Refreshed [Stats] 1122 o Date/Time of last Refresh [Stats] 1123 This response MUST also include the following parameters: 1125 o Timestamp 1127 o Sequence number (MUST match the sequence number for the request) 1129 o HMAC authenticator (MUST span message payload, plus secret key) 1131 Responses to unsuccessful List requests may take any of the following 1132 forms: 1134 o Syntax Error 1136 o Unknown Destination Identifier 1138 o Unknown Criteria ID 1140 o Improper Authentication (logged, but never sent to client) 1142 o Invalid Sequence Number (logged, but never sent to client) 1144 o Unknown Control Source Identifier (logged, but never sent to 1145 client) 1147 Important Note: the response to the List message, in particular all 1148 entries in the generated table, SHOULD be internally consistent and 1149 atomic, regardless of the activity in progress at the time of and 1150 during the course of transmission of the message. The data SHOULD 1151 represent a snapshot of the relevant information at the quantum in 1152 time that the List message is processed. 1154 5.12. NoOp Request 1156 This request takes no action on the server whatsoever, other than 1157 returning a successful response. The sole purpose of this command is 1158 to verify the end-to-end application-layer connectivity between a 1159 Control Source and the DTCP Server. The NoOp request may contain the 1160 following parameter: 1162 o Flag: SendAsync 1164 See 5.13 NoOp Response for a description of the SendAsync flag. 1166 Additionally, the NoOp request MUST contain the following parameters: 1168 o Control Source Identifier 1170 o Sequence number (MUST be monotonically increasing for each request 1171 from a given Control Source) 1173 o HMAC authenticator (MUST span message payload, plus secret key) 1175 5.13. NoOp Response 1177 The response to a successful NoOp will consist of a successful 1178 response message indicator, and contain the following parameters: 1180 o Timestamp 1182 o Sequence number (MUST match the sequence number for the request) 1184 o HMAC authenticator (MUST span message payload, plus secret key) 1186 If the SendAsync parameter is specified in the NoOp request, the 1187 server shall cause an asynchronous notification message to be sent to 1188 any configured notification destinations for that particular Control 1189 Source. 1191 5.14. Restart Notification 1193 The Restart notification shall be sent from the server to any 1194 configured notification-recipient when the system experiences a 1195 failure such that all the filter criteria are lost. The Restart 1196 notification shall contain the following parameters: 1198 o Restart Reason, a text string indicating the reason for the 1199 restart, if known 1201 o Timestamp 1203 o HMAC authenticator (MUST span message payload, plus secret key) 1205 5.15. Rollover Notification 1207 The Rollover notification shall be sent from the server to any 1208 configured notification-recipient when the server experiences a 1209 sequence-number rollover. The Rollover notification shall contain 1210 the following parameters: 1212 o Timestamp 1214 o HMAC authenticator (MUST span message payload, plus secret key) 1216 5.16. NoOp Notification 1218 The NoOp notification shall be sent from the server to any configured 1219 notification-recipient when the DTCP Server receives a NoOp message 1220 with the SendAsync parameter present. The NoOp notification shall 1221 contain the following parameters: 1223 o Timestamp 1225 o HMAC authenticator (MUST span message payload, plus secret key) 1227 5.17. Timeout Notification 1229 The Timeout notification shall be sent from the server to the 1230 appropriate notification-recipient(s) when the server times out a 1231 filter criterion on any one of its configured timeout parameters and 1232 the criterion contains a SendTimeoutAsync parameter. 1234 The Timeout notification shall contain the following parameters: 1236 o Criteria ID, to indicate the particular criteria that has timed 1237 out 1239 o Timeout specified in seconds total [omit if unconfigured] 1241 o Timeout remaining in seconds total [omit if unconfigured] 1243 o Timeout specified in seconds idle [omit if unconfigured] 1245 o Timeout remaining in seconds idle [omit if unconfigured] 1247 o Timeout specified in packets [omit if unconfigured] 1249 o Timeout remaining in packets [omit if unconfigured] 1251 o Timeout specified in bytes [omit if unconfigured] 1253 o Timeout remaining in bytes [omit if unconfigured] 1255 o Timestamp 1257 o HMAC authenticator (MUST span message payload, plus secret key) 1259 5.18. Congestion Notification 1261 The Congestion notification shall be sent from the server to any 1262 configured notification-recipient when the total 10-second average 1263 data rate (in bits/second) summed over all active filter criteria to 1264 a configured Content Destination exceeds the configured soft limit 1265 for that destination. The Congestion notification shall contain the 1266 following parameters: 1268 o Content Destination ID, to indicate the particular destination 1269 experiencing excessive bandwidth 1271 o Current total 10-second average Bandwidth, in bits/second 1273 o Configured SoftLimit Threshold, in bits/second 1275 o Configured HardLimit Threshold, in bits/second 1276 o Timestamp 1278 o HMAC authenticator (MUST span message payload, plus secret key) 1280 Note that since multiple Control Sources may be responsible for this 1281 overload, this Notification MUST be sent to all configured Control 1282 Sources that have currently-active filter criteria to this particular 1283 Content Destination. 1285 5.19. CongestionDelete Notification 1287 The CongestionDelete notification shall be sent from the server to 1288 any configured notification-recipient when the total 10-second 1289 average data rate (in bits/second) summed over all active filter 1290 criteria to a configured Content Destination exceeds the configured 1291 hard limit for that destination, causing the DTCP Server to begin 1292 purging filter criteria. The CongestionDelete notification shall 1293 contain the following parameters: 1295 o Content Destination ID 1297 o List of Criteria ID purged 1299 o Timestamp 1301 o HMAC authenticator (MUST span message payload, plus secret key) 1303 CongestionDelete messages MUST be specifically and uniquely sent to 1304 all configured notification-recipients for the Control Sources to 1305 which they apply. To be clear: a given Control Source notification- 1306 recipient MUST only receive CongestionDelete messages containing 1307 Criteria ID created by that Control Source. 1309 5.20. DuplicatesDropped Notification 1311 The DuplicatesDropped notification shall be sent from the server to 1312 any configured notification-recipient when capacity has been exceeded 1313 in such a way as to cause packets matching criteria added by the 1314 corresponding Control Source to be dropped. This notification will 1315 be sent periodically as long as packets continue to be dropped. The 1316 DuplicatesDropped notification shall contain the following 1317 parameters: 1319 o Content Destination ID 1321 o Applicable CriteriaID pertaining to Dropped Packets 1323 o Total Number of Dropped Packets 1324 o Sum of Bytes contained in Dropped Packets 1326 o Timestamp 1328 o HMAC authenticator (MUST span message payload, plus secret key) 1330 DuplicatesDropped messages MUST be specifically and uniquely sent to 1331 all configured notification-recipients for the Control Sources to 1332 which they apply. 1334 6. Miscellaneous 1336 6.1. Special treatment of response to List request 1338 The List request inherently provides unique functionality with 1339 respect to the messaging architecture of DTCP. All other requests 1340 result in reasonably terse replies, which can be encapsulated in, at 1341 worst, a few IP packets. 1343 However, the List request will generate an arbitrary amount of reply 1344 data, since it could contain all requests that are still active, up 1345 to the limit of the device. This section specifically describes how 1346 responses to the List request are sent. 1348 a) The full reply to the List request MAY consist of multiple 1349 packets. Each packet will contain a single "Response" element; 1350 therefore, each packet will have a single Status-Line and a single 1351 trailer (Authentication-Info) terminated by 2xCRLF. A UDP packet MUST 1352 NOT contain more than ONE "Response" element. 1354 b) A "Response" element in each packet shall contain zero or more 1355 "List-Resp-Entry" elements (in "List-Resp-Parameters"). Each filter 1356 criteria is encoded into a single "List-Resp-Entry" element. The 1357 sequence number MUST be identical for all "Response" elements in a 1358 multi-packet reply. 1360 c) Each "List-Resp-Entry" element MUST contain the following two 1361 elements: "Criteria-Num" and "Criteria-Count". "Criteria-Num" MUST 1362 be valued as an enumeration starting with 1 (one) and incrementing by 1363 one for each "List-Resp-Entry" sent. "Criteria-Count" SHOULD be set 1364 to the total number of matching Criteria in the given particular LIST 1365 response (see below for potential exceptions). 1367 d) Therefore, a full reply to the List request shall consist of as 1368 many "List-Resp-Entry" elements as necessary to fully transmit the 1369 List, divided into multiple packets as described above. 1371 e) DTCP Servers SHOULD ensure that each "List-Resp-Entry" element is 1372 not divided across multiple IP packets. 1374 f) DTCP Clients can use the simple test (Criteria-Num==Criteria- 1375 Count) to determine if they've received the last packet in the 1376 series. However, in order to ensure that all packets were received 1377 (and, respectively, all List-Resp-Entry elements), the DTCP Client 1378 MUST traverse through the list of Criteria-Count to ensure it's 1379 complete from 1 to XX where XX==Criteria-Num==Criteria-Count. 1381 g) At the UDP layer, all packets in the response MUST contain 1382 identical UDP port numbers. DTCP Clients SHOULD maintain their 1383 socket open until either all expected Response messages are received, 1384 or a timeout occurs. 1386 h) If the List request matches no criteria, but does not supply 1387 invalid Criteria-IDs, the "Response" element will contain zero "List- 1388 Resp-Entry" elements. 1390 i) DTCP Servers MAY simplify their implementation by only including a 1391 single "List-Resp-Entry" element in each "Response" element (and 1392 therefore in each packet). 1394 j) DTCP Servers MAY simplify their implementation by transmitting the 1395 "Criteria-Count" element in each List-Resp-Entry element as ZERO (0) 1396 until the final element is sent, whereupon it is set to the proper 1397 value. 1399 A List response that matches 3 criteria may look as follows: 1401 =============== First UDP packet 1402 DTCP header 1403 Seq: A 1404 criteria-id: x ; this is the first List-Resp-Entry element 1405 ... 1406 criteria-num: 1 1407 criteria-count: 3 1408 criteria-id: y ; this is the second List-Resp-Entry element 1409 ... 1410 criteria-num: 2 1411 criteria-count: 3 1412 HMAC 1413 ================ 1414 =============== Second UDP packet 1415 DTCP header 1416 Seq: A 1417 criteria-id: z ; this is the third List-Resp-Entry element 1418 ... 1419 criteria-num: 3 1420 criteria-count: 3 1421 HMAC 1422 ================ 1424 If the list request matches no criteria, it will look as follows: 1426 =============== First UDP packet 1427 DTCP header 1428 Seq: B 1429 HMAC 1430 ================ 1432 6.2. Error or Exception Conditions 1434 Errors in DTCP requests are reported in response messages via any 1435 Response-Code other than "200" (OK). When such error or exception 1436 condition exists, the server SHOULD attempt to indicate the precise 1437 nature of the error or exception using the Error-Parameters element. 1438 This behavior, though helpful, is not strictly required by the 1439 protocol. 1441 For example, if a Delete request contained a specific Criteria-ID not 1442 currently active in the server, the response error message MUST begin 1443 with a 431 - Unknown Criteria ID response line. The server SHOULD 1444 also add the Criteria-ID parameter indicating the unknown Criteria 1445 ID. 1447 Again, note that authentication failures MUST NOT be reported in 1448 response messages; they MUST be silently dropped. 1450 The DTCP Server MUST attempt to provide the most specific error 1451 message to report the specific error or exception condition. When 1452 the request message meets any of the following conditions, if no such 1453 specific error message exists, the server MAY return a 400 (Bad 1454 Request) error: 1456 o Missing required fields 1458 o Parse failure 1460 o Parameters beyond range 1462 In these cases, the server SHOULD include the specific line from the 1463 request that caused the condition using the Error-Parameters element. 1465 6.3. Extensions in ABNF 1467 Extension placeholders are provided in the formal syntax for the 1468 definition of future methods, parameters, and response-codes. 1469 Vendors SHOULD NOT define implementation-specific extensions; rather, 1470 such extensions SHOULD be brought to the DTCP working group for 1471 inclusion into the protocol, to ensure interoperability. 1473 However, in order to provide faster extensions to the protocol, the 1474 "X-" extension parameter construct has been borrowed from other 1475 protocols, including SIP and SMTP. 1477 The DTCP Server or the DTCP Client MAY include an arbitrary 1478 parameter-value pair, as long as the parameter is preceded by the 1479 character string "X-", and all other parameter-value conventions are 1480 followed. 1482 The sender of such extension parameters MUST NOT rely on the 1483 recipient correctly processing those values. 1485 The recipient of such extension parameters MAY process the values as 1486 appropriate upon receipt, but MUST discard without error those 1487 extension parameters that it does not recognize. 1489 6.4. Current Version 1491 The current version string for this release of the DTCP protocol is: 1493 DTCP/0.7 1495 6.5. No specific port 1497 While it is common practice to register and/or publish a TCP or UDP 1498 port for applications that define them as a layer-4 transport, DTCP 1499 has no specific UDP ports predefined. This is intended both to allow 1500 flexibility for implementers and users, as well as to make it more 1501 difficulty to detect DTCP messages on untrusted networks. 1503 6.6. Unimplemented Protocol Methods and Parameters 1505 Some DTCP Server vendors have indicated their interest in supporting 1506 a subset of the functionality specified here, due to their position 1507 in the security space. Additionally, some constructs (arbitrary 1508 lists, in particular) add complexity to implementations that may not 1509 require that complexity. 1511 To address this need, rather than adding complexity by changing the 1512 grammar to indicate optional sections, specific error messages have 1513 been added to indicate to the client that the server cannot process 1514 the request in its current format. Depending on the request, the 1515 client might be able to reformat that request into one that the 1516 server implementation is able to process. 1518 In order to be compliant with this protocol, the following rules 1519 apply: 1521 a) If a vendor chooses not to implement one or more DTCP Methods, 1522 when responding to a request containing one of the unsupported 1523 methods, the DTCP Server MUST send a "501 Not Implemented" Response 1524 error message, and discontinue processing of that request. 1526 b) If a vendor chooses not to implement a list element, when 1527 responding to a request containing such a list, the DTCP Server MUST 1528 send a "501 Not Implemented" Response error message, and discontinue 1529 processing of that request. 1531 c) If a vendor chooses not to implement one or more specific 1532 parameters or parameter value options in a request, the DTCP Server 1533 MUST send a "501 Not Implemented" Response error message, and 1534 discontinue processing of that request. 1536 d) The DTCP Server SHOULD include the method, parameter, or value 1537 which caused the "501 Not Implemented" error to be sent, within the 1538 error response message (to be consistent with 6.4 above) 1540 e) The DTCP Server SHOULD support prior versions of DTCP. However, if 1541 the vendor chooses not to implement prior versions of the protocol, 1542 the DTCP Server MUST send a "505 DTCP Version not supported" error 1543 message, and discontinue processing of that request. 1545 The onus is on the client to determine if it can reformat the message 1546 to make it acceptable to the particular DTCP Server implementation. 1548 6.7. Version Mismatches 1549 The intent of this section is to clarify any ambiguity arising from 1550 mismatches between DTCP versions supported by the DTCP Client and the 1551 DTCP Server. In practice is has been observed that unintended 1552 consequences have arisen by leaving the implementation vague, so it 1553 was decided that clarifing at least a set of reccomendations, if not 1554 rising to the level of requirements, will help guide DTCP 1555 implementations and help ensure interoperability. 1557 Two possible cases of mismatch exist: when the client exceeds the 1558 server version, and when the server exceeds the client version. They 1559 are handled separately, but the motivation in each case is to permit 1560 maximum compatibility. 1562 In this case, versions are compared numerically, with a single digit 1563 after decimal point. For example: 0.4 is greater than 0.2, 1.9 is 1564 greater than 1.4, and 3.1 is greater than 2.9 1566 6.7.1. DTCP Client version exceeds DTCP Server version 1568 If the DTCP Client attempts to make a request to a DTCP Server using 1569 a DTCP version greater than that supported by the DTCP Server, the 1570 DTCP Server MUST return a "505 DTCP Version not supported" error 1571 message using the GREATEST DTCP version supported by the DTCP Server, 1572 and discontinue processing of that request. It has not way of 1573 knowing what new parameters might exist in a newer version of the 1574 protocol and simply has to abandon processing altogether. 1576 In this case, the onus is on the DTCP Client to revert to an older 1577 version of the protocol specification to talk with this DTCP Server 1578 to ensure that its request is properly handled. 1580 6.7.2. DTCP Server version exceeds DTCP Client version 1582 It is expected that a given DTCP Server will support a range of DTCP 1583 protocol specification versions, for interoperability purposes. 1585 If the DTCP Server receives a request from a DTCP Server using a DTCP 1586 version lesser than the most current version supported by the DTCP 1587 Server, the server SHOULD attempt to process that response using the 1588 semantics of the earlier specification, and MUST reply using the 1589 precise DTCP version included in the request. 1591 If the DTCP server is unable to do this, the DTCP Server MUST return 1592 a "505 DTCP Version not supported" error message using the LEAST DTCP 1593 version supported by the DTCP Server, and discontinue processing of 1594 that request 1596 Asynchronous Notifications sent to a client using an earlier version 1597 are addressed in Section 3.2 (Asynchronous Notifications). 1599 7. Message Payload Examples 1600 Note: These are only examples of message payloads, and are not 1601 intended to illustrate the full breadth of the protocol. Also, 1602 please note that the Authentication-Info shown are correct if each 1603 line is terminated with CRLF as specified and the key "secret" is 1604 used. (Terminating CRLFs are not shown.) 1606 7.1. Successful ADD Request and Response Payload 1608 Following is an example of the UDP payload for an Add request: 1610 ADD DTCP/0.6 1611 Source-Address: 192.168.10.4 1612 Dest-Address: 10.1.1.1-10.1.1.10 1613 Protocol: 6,17 1614 Dest-Port: 53 1615 Timeout-Idle: 600 1616 Action: Copy 1617 Priority: 2 1618 Flags: SendAsync 1619 Cdest-ID: cdst_b 1620 Csource-ID: csrc_a 1621 Seq: 3827443 1622 Authentication-Info: 28eb606458ba46160d7a59da48763020f5aef9f5 1624 Following is the UDP payload of one potential successful response to 1625 that Add request: 1627 DTCP/0.6 200 OK 1628 Criteria-ID: 38224 1629 Seq: 3827443 1630 Timestamp: 2005-01-01 12:01:01.111 1631 Authentication-Info: 38099d03fcb5b12a849b36f9bdccc757303fafd0 1633 7.2. Unsuccessful DELETE Request and Response Payload 1635 Following is an example of the UDP payload for an Delete request: 1637 DELETE DTCP/0.6 1638 Criteria-ID: 55331 1639 Csource-ID: csrc_d 1640 Flags: Static 1641 Seq: 2655371 1642 Authentication-Info: 6af62247a2b59a2a06e0ca08ec5a80a644e2cd67 1644 Following is the UDP payload of one potential unsuccessful response 1645 to that Delete request: 1647 DTCP/0.6 431 Unknown Criteria ID 1648 Criteria-ID: 55331 1649 Seq: 2655371 1650 Timestamp: 2005-02-02 12:02:02.222 1651 Authentication-Info: 5de4552e98832c2d2c3a9ffa8a2958c967b4e1e8 1653 This delete request was unsuccessful because the Criteria ID supplied 1654 did not exist. Note that the error-causing parameter is included 1655 within the reply to assist in debugging. 1657 8. Formal Syntax 1659 All of the mechanisms specified in this document are described in 1660 both prose and an Augmented Backus-Naur Form (ABNF) defined in RFC 1661 4234 [7]. Section 6.1 of RFC 4234 defines a set of core rules that 1662 are used by this specification, and not repeated here. Implementers 1663 need to be familiar with the notation and content of RFC 4234 in 1664 order to understand this specification. Certain basic rules are in 1665 uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. 1667 Note that while much of this syntax is taken from the Session 1668 Initiation Protocol (SIP), some of its constructs have been 1669 simplified for this application here. Where appropriate, these 1670 digressions have been noted with comments. 1672 The following core definitions appear throughout the formal syntax: 1674 COL = *(WSP) ":" *(WSP) ; used in parameter-value pair 1675 NPCHAR = "\" 3DIGIT ; used to express ctrl-chars 1676 DSTRING = *(VCHAR / NPCHAR) ; no embedded whitespace 1677 WC = "*" ; wildcard character for matching 1678 NOT = "!" ; invert character for matching 1679 N64BITNUM = 1*20DIGIT 1680 N32BITNUM = 1*10DIGIT 1681 N16BITNUM = 1*5DIGIT 1682 N8BITNUM = 1*3DIGIT 1683 DAYSEC = 1*5DIGIT 1684 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 1685 TEXT = 1*(1*(VCHAR) WSP) ; includes whitespace 1686 DTCP-Time = 4DIGIT "-" 2DIGIT "-" 2DIGIT SP 2DIGIT ":" 1687 2DIGIT ":" 2DIGIT "." 3DIGIT 1688 ; This is ISO date/time: YYYY-MM-DD sp HH:MM:SS.TTT 1690 Additionally, the following definitions are excerpted from RFC 3986 1691 [8]: 1693 IPv6address = 6( h16 ":" ) ls32 1694 / "::" 5( h16 ":" ) ls32 1695 / [ h16 ] "::" 4( h16 ":" ) ls32 1696 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 1697 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 1698 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 1699 / [ *4( h16 ":" ) h16 ] "::" ls32 1700 / [ *5( h16 ":" ) h16 ] "::" h16 1701 / [ *6( h16 ":" ) h16 ] "::" 1703 ls32 = ( h16 ":" h16 ) / IPv4address 1704 ; least-significant 32 bits of address 1706 h16 = 1*4HEXDIG 1707 ; 16 bits of address represented in hexadecimal 1709 Here begins the formal syntax: 1711 DTCP-Message = Request / Response / Notification 1713 Request = Request-Line 1714 ( Add-Req-Parameters 1715 / Delete-Req-Parameters 1716 / Refresh-Req-Parameters 1717 / List-Req-Parameters 1718 / Noop-Req-Parameters) 1719 *(extension-parameter) 1720 Csource-ID 1721 Seq 1722 Authentication-Info 1723 CRLF 1725 Response = Status-Line 1726 ( ( Add-Resp-Parameters 1727 / Delete-Resp-Parameters 1728 / Refresh-Resp-Parameters 1729 / List-Resp-Parameters 1730 / Noop-Resp-Parameters) / Error-Parameters ) 1731 *(extension-parameter) 1732 Timestamp 1733 Seq ; note absence of Csource-ID 1734 Authentication-Info 1735 CRLF 1737 Notification = Status-Line 1738 ( Restart-Notif-Parameters 1739 / Rollover-Notif-Parameters 1740 / Noop-Notif-Parameters 1741 / Timeout-Notif-Parameters 1742 / Congestion-Notif-Parameters 1743 / CongDel-Notif-Parameters ) 1744 *(extension-parameter) 1745 Timestamp 1746 Authentication-Info ; note absence of Seq 1747 CRLF 1749 DTCP-Version = "DTCP" "/" 1*DIGIT "." 1*DIGIT 1751 Status-Line = DTCP-Version SP Status-Code SP Reason-Phrase CRLF 1752 Request-Line = Method SP DTCP-Version CRLF 1754 Method = "ADD" / "DELETE" / "REFRESH" / "LIST" / "NOOP" 1755 / extension-method 1757 extension-method = DSTRING 1759 Status-Code = Provisional 1760 / Success 1761 / Redirection 1762 / Request-Failure 1763 / Server-Failure 1764 / Global-Failure 1765 / extension-code 1767 Reason-Phrase = TEXT ; differs from SIP 1768 extension-code = 3DIGIT 1770 Provisional = "130" ; Sequence Number Rollover (Notif) 1771 / "131" ; NoOp Notification (Notif) 1772 Success = "200" ; OK 1773 Redirection = "390" ; Criterion Timeout Delete (Notif) 1774 Request-Failure = "400" ; Bad Request 1775 / "430" ; Unknown Content Destination 1776 / "431" ; Unknown Criteria ID 1777 / "432" ; Improper Filter Specification 1778 / "433" ; Improper Timeout Specification 1779 / "497" ; Invalid Authentication 1780 ; (never sent to client) 1781 / "498" ; Invalid Sequence Number 1782 ; (never sent to client) 1783 / "499" ; Unknown Control Source Identifier 1784 ; (never sent to client) 1785 Server-Failure = "500" ; Server Internal Error 1786 / "501" ; Not Implemented 1787 / "505" ; DTCP Version not supported 1788 / "550" ; Max Criteria Limit Exceeded 1789 / "551" ; Max Content Destination Exceeded 1790 / "580" ; Congestion (Notif) 1791 / "598" ; Duplicate Packets Dropped (Notif) 1792 / "599" ; Server Restart (Notif) 1793 Global-Failure = "680" ; Criterion Congestion Delete (Notif) 1795 Error-Parameters = Cdest-ID 1796 / Criteria-ID 1797 / Filter-Block 1798 / Timeout-Block 1800 Add-Req-Parameters = Filter-Block Timeout-Block [Action] 1801 Option-Block [Flags] Cdest-ID 1803 Filter-Block = *(Filter-Element) 1804 Timeout-Block = *(Timeout-Element) 1805 TRemaining-Block = *(TRemaining-Element) 1806 Option-Block = *(Option-Element) 1807 Timeout-Required-Block = 1*(Timeout-Element) 1808 TRemaining-Required-Block = 1*(TRemaining-Element) 1810 Filter-Element = Source-Address 1811 / Dest-Address 1812 / Protocol 1813 / Source-Port 1814 / Dest-Port 1815 / ICMP-Type 1816 / ICMP-Code 1818 Timeout-Element = Timeout-Idle 1819 / Timeout-Total 1820 / Timeout-Packets 1821 / Timeout-Bytes 1823 TRemaining-Element = Remaining-Idle 1824 / Remaining-Total 1825 / Remaining-Packets 1826 / Remaining-Bytes 1828 Option-Element = Priority 1830 Add-Resp-Parameters = Criteria-ID 1832 Delete-Req-Parameters = ( (Criteria-ID / Criteria-ID-Filter) 1833 Cdest-ID ) [Flags] 1834 Delete-Resp-Parameters = Criteria-Count 1836 Refresh-Req-Parameters = ( (Criteria-ID / Criteria-ID-Filter) 1837 Cdest-ID ) Timeout-Required-Block 1838 Refresh-Resp-Parameters = Criteria-Count 1840 List-Req-Parameters = [ ( (Criteria-ID / Criteria-ID-Filter) 1841 Cdest-ID ) ] [Flags] 1843 List-Resp-Parameters = *(List-Resp-Entry CRLF) 1845 List-Resp-Entry = Criteria-Count Criteria-Num Main-List 1846 [Criteria-List] [Stats-List] 1848 Main-List = Csource-ID Csource-Address Cdest-ID 1849 Criteria-ID Timestamp 1850 Criteria-List = *(Filter-Element) *(Timeout-Element) [Flags] 1851 Stats-List = TRemaining-Block Stats-Block 1853 Stats-Block = Average-Bandwidth Matching-Packets 1854 Matching-Bytes Num-Refresh Last-Refresh 1856 Noop-Req-Parameters = [Flags] 1857 Noop-Resp-Parameters = [] ; no parameters 1859 Restart-Notif-Parameters = Alert-Info 1860 Rollover-Notif-Parameters = [] ; no parameters 1861 Noop-Notif-Parameters = [] ; no parameters 1862 Timeout-Notif-Parameters = Criteria-ID 1863 / Timeout-Required-Block 1864 / TRemaining-Required-Block 1865 Congestion-Notif-Parameters = Cdest-ID Average-Bandwidth 1866 Alert-Bandwidth Max-Bandwidth 1867 CongDel-Notif-Parameters = Cdest-ID Criteria-ID-Filter 1869 extension-parameter = "X-" DSTRING COL DSTRING CRLF 1870 Csource-ID = "Csource-ID" COL DSTRING CRLF 1871 Seq = "Seq" COL N64BITNUM CRLF 1872 Authentication-Info = "Authentication-Info" COL 40HEXDIG CRLF 1873 ID-List = DSTRING *("," DSTRING) 1874 Cdest-ID = "Cdest-ID" COL ID-List CRLF 1875 Source-Address = "Source-Address" COL IPFilter CRLF 1876 Dest-Address = "Dest-Address" COL IPFilter CRLF 1877 Protocol = "Protocol" COL ProtFilter CRLF 1878 Source-Port = "Source-Port" COL PortFilter CRLF 1879 Dest-Port = "Dest-Port" COL PortFilter CRLF 1880 ICMP-Type = "ICMP-Type" COL ICMPFilter CRLF 1881 ICMP-Code = "ICMP-Code" COL ICMPFilter CRLF 1882 Timeout-Idle = "Timeout-Idle" COL DAYSEC CRLF 1883 Timeout-Total = "Timeout-Total" COL DAYSEC CRLF 1884 Timeout-Packets = "Timeout-Packets" COL N32BITNUM CRLF 1885 Timeout-Bytes = "Timeout-Bytes" COL N64BITNUM CRLF 1886 Priority = "Priority" COL N8BITNUM CRLF 1887 Criteria-ID = "Criteria-ID" COL N32BITNUM CRLF 1888 Criteria-ID-Filter = "Criteria-ID" COL CritFilter CRLF 1889 Criteria-Count = "Criteria-Count" COL N32BITNUM CRLF 1890 Criteria-Num = "Criteria-Num" COL N32BITNUM CRLF 1891 Csource-Address = "Csource-Address" COL (IPv4address / 1892 IPv6address) CRLF 1893 Timestamp = "Timestamp" COL DTCP-Time CRLF 1894 Remaining-Idle = "Remaining-Idle" COL DAYSEC CRLF 1895 Remaining-Total = "Remaining-Total" COL DAYSEC CRLF 1896 Remaining-Packets = "Remaining-Packets" COL N32BITNUM CRLF 1897 Remaining-Bytes = "Remaining-Bytes" COL N64BITNUM CRLF 1898 Average-Bandwidth = "Average-Bandwidth" COL N64BITNUM CRLF 1899 Matching-Packets = "Matching-Packets" COL N64BITNUM CRLF 1900 Matching-Bytes = "Matching-Bytes" COL N64BITNUM CRLF 1901 Num-Refresh = "Num-Refresh" COL N32BITNUM CRLF 1902 Last-Refresh = "Last-Refresh" COL DTCP-Time CRLF 1903 Alert-Info = "Alert-Info" COL TEXT CRLF 1904 Alert-Bandwidth = "Alert-Bandwidth" COL N64BITNUM CRLF 1905 Max-Bandwidth = "Max-Bandwidth" COL N64BITNUM CRLF 1906 Action = "Action" COL ActionEntry CRLF 1908 ActionEntry = "Copy" 1909 / "Block" 1910 / "Redirect" 1911 / extension-action 1913 extension-action = DSTRING 1914 Flags = "Flags" COL FlagEntry *("," FlagEntry) CRLF 1916 FlagEntry = "Static" 1917 / "SendAsync" 1918 / "Stats" 1919 / "Criteria" 1920 / "Both" 1922 IPFilter = [NOT] IPEntry *("," [WSP] [NOT] IPEntry) 1923 ProtFilter = [NOT] ProtEntry *("," [WSP] [NOT] ProtEntry) 1925 PortFilter = [NOT] PortEntry *("," [WSP] [NOT] PortEntry) 1927 ICMPFilter = [NOT] ICMPEntry *("," [WSP] [NOT] ICMPEntry) 1929 CritFilter = [NOT] CritEntry *("," [WSP] [NOT] CritEntry) 1931 IPEntry = IPv4Entry 1932 / IPv6Entry 1934 IPv4Entry = IPv4address ; Single Entry 1935 / IPv4address "/" N8BITNUM ; Address/mask 1936 / IPv4address "-" IPv4address ; Range 1937 / IPv4address "-" WC ; Range to UBOUND 1938 / WC "-" IPv4address ; LBOUND to Range 1939 / WC ; Pure Wildcard 1941 IPv6Entry = IPv6address ; Single Entry 1942 / IPv6address "/" N8BITNUM ; Address/mask 1943 / IPv6address "-" IPv6address ; Range 1944 / IPv6address "-" WC ; Range to UBOUND 1945 / WC "-" IPv6address ; LBOUND to Range 1946 / WC ; Pure Wildcard 1948 PortEntry = N16BITNUM ; Single Entry 1949 / N16BITNUM "-" N16BITNUM ; Range 1950 / N16BITNUM "-" WC ; Range to UBOUND 1951 / WC "-" N16BITNUM ; LBOUND to Range 1952 / WC ; Pure Wildcard 1954 ProtEntry = N8BITNUM ; Single Entry 1955 / N8BITNUM "-" N8BITNUM ; Range 1956 / N8BITNUM "-" WC ; Range to UBOUND 1957 / WC "-" N8BITNUM ; LBOUND to Range 1958 / WC ; Pure Wildcard 1960 ICMPEntry = N8BITNUM ; Single Entry 1961 / N8BITNUM "-" N8BITNUM ; Range 1962 / N8BITNUM "-" WC ; Range to UBOUND 1963 / WC "-" N8BITNUM ; LBOUND to Range 1964 / WC ; Pure Wildcard 1966 CritEntry = N64BITNUM ; Single Entry 1967 / N64BITNUM "-" N64BITNUM ; Range 1968 / N64BITNUM "-" WC ; Range to UBOUND 1969 / WC "-" N64BITNUM ; LBOUND to Range 1970 / WC ; Pure Wildcard 1972 9. Security Considerations 1973 DTCP empowers network security personnel to monitor packet data 1974 transitioning through a network element. As such, it is a powerful 1975 protocol that can cause any network data to be redirected to a 1976 arbitrary location for inspection. Consequently, it is of greatest 1977 criticality that any DTCP Servers fully implement the security model 1978 outlined in this draft. Failure to do so could result in malicious 1979 individuals either obtaining unauthorized access to data or 1980 interruption of data transmission. 1982 10. IANA Considerations 1984 This document has no actions for IANA. 1986 11. Conclusions 1988 This protocol has undergone extensive testing and several rounds of 1989 refinements. The resulting protocol is highly effective at meeting 1990 its goals of providing a real-time mechanism to inspect raw packets 1991 containing security-related events traversing a network in real-time. 1993 12. Acknowledgments 1995 Thanks to all at AT&T and Juniper Networks who provided testing and 1996 support for this experimental protocol 1998 The authors would specifically like to thank Joju Chevookaran, and 1999 Saravanan Deenadayalan from Juniper since they have not only worked 2000 hard on the implementation, but also on the some of the enhancements 2001 (specially VRF support, input/out interface filters etc). 2003 Also, Rick Suntag, Michael Nanashko, and Michael St. Angelo from 2004 AT&T all deserve special note for extensive testing as well as 2005 excellent protocol definition suggestions and corrections. 2007 13. References 2009 [RFC1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext 2010 Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 10.17487/ 2011 RFC1945, May 1996, . 2014 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 2015 Hashing for Message Authentication", RFC 2104, DOI 2016 10.17487/RFC2104, February 1997, . 2019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2020 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 2021 RFC2119, March 1997, . 2024 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2025 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 2026 "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487 2027 /RFC3261, June 2002, . 2030 [RFC5938] Morton, A. and M. Chiba, "Individual Session Control 2031 Feature for the Two-Way Active Measurement Protocol 2032 (TWAMP)", RFC 5938, DOI 10.17487/RFC5938, August 2010, 2033 . 2035 Appendix A. Prior Implementation 2037 This document fully and accurately describes the operation of DTCP/ 2038 0.7 implementations. However, in development of this protocol, some 2039 implementations with working versions of the protocol were released. 2040 This appendix describes the differences between the DTCP/0.7 protocol 2041 specification documented herein and the prior DTCP/0.5 and DTCP/0.6 2042 protocol specifications. 2044 Other than the changes documented in this appendix, the older 2045 protocol specifications precisely follow DTCP/0.7 described herein. 2046 This appendix is provided for backward-compatibility purposes only; 2047 all new implementations should ignore this appendix. 2049 A.1. Version Number 2051 Authors' Addresses 2053 Sumit Kala 2054 Juniper Networks 2055 Flat #202, Propulsive Pride Apartment, Doddakannelli Road 2056 Bangalore, Karnataka 560035 2057 INDIA 2059 Phone: +91 8197477794 2060 Email: sumitk@juniper.net 2062 David Cavuto 2063 ATT