idnits 2.17.1 draft-ietf-opes-protocol-reqs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The OPES callout protocol MUST be application protocol-agnostic, i.e. it MUST not make any assumptions about the characteristics of the application-layer protocol used on the data path between data provider and data consumer. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 18, 2002) is 7983 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) == Outdated reference: A later version (-04) exists of draft-ietf-opes-architecture-01 ** Downref: Normative reference to an Informational draft: draft-ietf-opes-architecture (ref. '1') ** Obsolete normative reference: RFC 2616 (ref. '3') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 1889 (ref. '4') (Obsoleted by RFC 3550) ** Downref: Normative reference to an Informational RFC: RFC 3238 (ref. '5') Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Pluggable Edge Services A. Beck 3 Internet-Draft M. Hofmann 4 Expires: December 17, 2002 Lucent Technologies 5 H. Orman 6 Purple Streak Development 7 R. Penno 8 Nortel Networks 9 A. Terzis 10 Individual Consultant 11 June 18, 2002 13 Requirements for OPES Callout Protocols 14 draft-ietf-opes-protocol-reqs-01 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 17, 2002. 39 Copyright Notice 41 Copyright (C) The Internet Society (2002). All Rights Reserved. 43 Abstract 45 This document specifies the requirements that the OPES (Open 46 Pluggable Edge Services) callout protocol must satisfy in order to 47 support the remote execution of OPES services [1]. The requirements 48 are intended to help evaluating possible protocol candidates and to 49 guide the development of such protocols. 51 Table of Contents 53 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Functional Requirements . . . . . . . . . . . . . . . . . . 5 56 3.1 Callout Transactions . . . . . . . . . . . . . . . . . . . . 5 57 3.2 Callout Channels . . . . . . . . . . . . . . . . . . . . . . 5 58 3.3 Reliability . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.4 Congestion and Flow Control . . . . . . . . . . . . . . . . 6 60 3.5 Support for Keep-Alive Mechanism . . . . . . . . . . . . . . 6 61 3.6 Operation in NAT Environments . . . . . . . . . . . . . . . 7 62 3.7 Multiple Callout Servers . . . . . . . . . . . . . . . . . . 7 63 3.8 Multiple OPES Processors . . . . . . . . . . . . . . . . . . 7 64 3.9 Support for Different Application Protocols . . . . . . . . 7 65 3.10 Capability and Parameter Negotiations . . . . . . . . . . . 7 66 3.11 Meta Data and Instructions . . . . . . . . . . . . . . . . . 8 67 3.12 Asynchronous Message Exchange . . . . . . . . . . . . . . . 9 68 3.13 Message Segmentation . . . . . . . . . . . . . . . . . . . . 9 69 4. Performance Requirements . . . . . . . . . . . . . . . . . . 11 70 4.1 Protocol Efficiency . . . . . . . . . . . . . . . . . . . . 11 71 5. Security Requirements . . . . . . . . . . . . . . . . . . . 12 72 5.1 Authentication, Confidentiality, and Integrity . . . . . . . 12 73 5.2 Hop-by-Hop Confidentiality . . . . . . . . . . . . . . . . . 12 74 5.3 Operation Across Un-trusted Domains . . . . . . . . . . . . 12 75 5.4 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 6. Security Considerations . . . . . . . . . . . . . . . . . . 14 77 References . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 79 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 80 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 83 1. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [2]. 89 2. Introduction 91 The Open Pluggable Edge Services (OPES) architecture [1] enables 92 cooperative application services (OPES services) between a data 93 provider, a data consumer, and zero or more OPES processors. The 94 application services under consideration analyze and possibly 95 transform application-level messages exchanged between the data 96 provider and the data consumer. 98 The execution of such services is governed by a set of filtering 99 rules installed on the OPES processor. The rules enforcement can 100 trigger the execution of service applications local to the OPES 101 processor. Alternatively, the OPES processor can distribute the 102 responsibility of service execution by communicating and 103 collaborating with one or more remote callout servers. As described 104 in [1], an OPES processor communicates with and invokes services on a 105 callout server by using a callout protocol. This document presents 106 the requirements for such a protocol. 108 The requirements in this document are divided into three categories - 109 functional requirements, performance requirements, and security 110 requirements. Each requirement is presented as one or more 111 statements, followed by brief explanatory material as appropriate. 113 3. Functional Requirements 115 3.1 Callout Transactions 117 The OPES callout protocol MUST enable an OPES processor and a callout 118 server to perform callout transactions with the purpose of exchanging 119 partial or complete application-level protocol messages (or 120 modifications thereof). More specifically, the callout protocol MUST 121 enable an OPES processor to forward a complete or partial application 122 message to a callout server so that one or more OPES services can 123 process the forwarded application message (or parts thereof). The 124 result of the service operation may be a modified application 125 message. The callout protocol MUST therefore enable the callout 126 server to return a modified application message or the modified parts 127 of an application message to the OPES processor. 129 A callout transaction is defined as a message exchange between an 130 OPES processor and a callout server consisting of a callout request 131 and a callout response. Both, the callout request as well as the 132 callout response, MAY each consist of one or more protocol messages, 133 i.e. a series of protocol messages. 135 Callout transactions are always initiated by a callout request from 136 an OPES processor and typically terminated by a callout response from 137 a callout server. The OPES callout protocol MUST, however, also 138 allow either endpoint of a callout transaction to terminate a callout 139 transaction prematurely, i.e. before a callout request or response 140 has been completely received by the corresponding endpoint. The 141 callout protocol MAY provide an explicit (e.g. through a termination 142 message) or implicit (e.g. through a connection tear-down) mechanism 143 to terminate a callout transaction prematurely. Such a mechanism 144 MUST ensure, however, that a premature termination of a callout 145 transaction does not result in the loss of application message data. 147 A premature termination of a callout transaction is required to 148 support OPES services which may terminate even before they have 149 processed the entire application message. Content analysis services, 150 for example, may be able to classify a Web object after having 151 processed just the first few bytes of a Web object. 153 The callout protocol MUST further enable a callout server to report 154 back to the OPES processor the result of a callout transaction, e.g. 155 in the form of a status code. 157 3.2 Callout Channels 159 The OPES callout protocol MUST enable an OPES processor and a callout 160 server to perform multiple callout transactions over a callout 161 channel. A callout channel is defined as a logical connection at the 162 application-layer between an OPES processor and a callout server. 164 Callout channels MUST always be established by an OPES processor. A 165 callout channel MAY be closed by either endpoint of the callout 166 channel provided that all callout transactions associated with the 167 channel have terminated. 169 A callout channel MAY have certain parameters associated with it, for 170 example parameters that control the fail-over behavior of channel 171 endpoints. Callout channel parameters MAY be negotiated between OPES 172 processors and callout servers (see Section 3.10). 174 3.3 Reliability 176 The OPES callout protocol MUST be able to provide ordered reliability 177 for the communication between OPES processor and callout server. 178 Additionally, the callout protocol SHOULD be able to provide 179 unordered reliability. 181 In order to satisfy the reliability requirements, the callout 182 protocol MAY specify that it must be used with a lower-level 183 transport protocol which provides ordered reliability at the 184 transport-layer. 186 3.4 Congestion and Flow Control 188 The OPES callout protocol MUST ensure that congestion and flow 189 control mechanisms are applied on all callout transactions. For this 190 purpose, the callout protocol MAY specify callout protocol-specific 191 mechanisms or refer to a lower-level transport protocol and discuss 192 how its mechanisms provide for congestion and flow control. 194 3.5 Support for Keep-Alive Mechanism 196 The OPES callout protocol MUST provide an optional keep-alive 197 mechanism which, if used, would allow both endpoints of a callout 198 channel to detect a failure of the other endpoint even in the absence 199 of callout transactions. The callout protocol MAY specify that keep- 200 alive messages be exchanged over existing callout channel connections 201 or a separate connection between OPES processor and callout server. 203 The detection of a callout server failure may enable an OPES 204 processor to establish a channel connection with a stand-by callout 205 server so that future callout transactions do not result in the loss 206 of application message data. The detection of the failure of an OPES 207 processor may enable a callout server to release resources which 208 would otherwise not be available for callout transactions with other 209 OPES processors. 211 3.6 Operation in NAT Environments 213 The OPES protocol SHOULD be NAT-friendly, i.e. its operation should 214 not be compromised by the presence of one or more NAT devices in the 215 path between an OPES processor and a callout server. 217 3.7 Multiple Callout Servers 219 The OPES callout protocol MUST allow an OPES processor to 220 simultaneously communicate with more than one callout server. 222 In larger networks, OPES services are likely to be hosted by 223 different callout servers. Therefore, an OPES processor will likely 224 have to communicate with multiple callout servers. The protocol 225 design MUST enable an OPES processor to do so. 227 3.8 Multiple OPES Processors 229 The OPES callout protocol MUST allow a callout server to 230 simultaneously communicate with more than one OPES processor. 232 The protocol design MUST support a scenario in which multiple OPES 233 processors use the services of a single callout server. 235 3.9 Support for Different Application Protocols 237 The OPES callout protocol MUST be application protocol-agnostic, i.e. 238 it MUST not make any assumptions about the characteristics of the 239 application-layer protocol used on the data path between data 240 provider and data consumer. 242 The OPES entities on the data path may use different application- 243 layer protocols, including, but not limited to, HTTP [3] and RTP [4]. 244 It would be desirable to be able to use the same OPES callout 245 protocol for any such application-layer protocol. 247 3.10 Capability and Parameter Negotiations 249 The OPES callout protocol MUST support the negotiation of 250 capabilities and callout channel parameters between an OPES processor 251 and a callout server. This implies that the OPES processor and the 252 callout server MUST be able to exchange their capabilities and 253 preferences and engage into a deterministic negotiation process at 254 the end of which the two endpoints have either agreed on the 255 capabilities and parameters to be used for future callout channel 256 transactions or determined that their capabilities are incompatible. 258 Capabilities and parameters that could be negotiated between an OPES 259 processor and a callout server include (but are not limited to): 260 callout protocol version, transport-layer protocol, fail-over 261 behavior, heartbeat rate for keep-alive messages, security-related 262 parameters etc. 264 Channel parameters may also pertain to the characteristics of OPES 265 callout services if, for example, callout channels are associated 266 with one or more specific OPES services. An OPES service-specific 267 parameter may, for example, specify which parts of an application 268 message an OPES service requires for its operation. 270 The parties to a callout protocol MAY use callout channels to 271 negotiate all or some of their capabilities and parameters. They MAY 272 also use a separate control connection for this purpose. If there is 273 a need for callout channel parameters, then they MUST be negotiated 274 on a per-callout channel basis and before any callout transactions 275 are performed over the corresponding channel. Other parameters and 276 capabilities, such as the fail-over behavior, MAY be negotiated 277 between the two endpoints independently of callout channels. 279 3.11 Meta Data and Instructions 281 The OPES callout protocol MUST provide a mechanism for the endpoints 282 of a particular callout transaction to include in callout requests 283 and responses meta data and instructions for the OPES processor or 284 callout server. 286 Specifically, the callout protocol MUST enable an OPES processor to 287 include information about the forwarded application message in a 288 callout request, e.g. in order to specify the type of the forwarded 289 application message or to specify what part(s) of the application 290 message are forwarded to the callout server. Likewise, the callout 291 server MUST be able to include information about the returned 292 application message. 294 The OPES processor MUST further be able to include an ordered list of 295 one or more uniquely specified OPES services which are to be 296 performed on the forwarded application message in the specified 297 order. However, as the callout protocol MAY also choose to associate 298 callout channels with specific OPES services, there may not be a need 299 to identify OPES service on a per-callout transaction basis. 301 Additionally, the OPES callout protocol MUST allow the callout server 302 to indicate to the OPES processor the cacheability of callout 303 responses. This implies that callout responses may have to carry 304 cache-control instructions for the OPES processor. 306 The OPES callout protocol MUST further enable the OPES processor to 307 indicate to the callout server if it has kept a local copy of the 308 forwarded application message (or parts thereof). This information 309 enables the callout server to determine whether the forwarded 310 application message must be returned to the OPES processor even it 311 has not been modified by an OPES service. 313 The OPES callout protocol MUST also allow OPES processors to comply 314 with the tracing requirements of the OPES architecture as laid out in 315 [1] and [5]. This implies that the callout protocol MUST enable a 316 callout server to convey to the OPES processor information about the 317 OPES service operations performed on the forwarded application 318 message. 320 3.12 Asynchronous Message Exchange 322 The OPES callout protocol MUST support an asynchronous message 323 exchange between an OPES processor and a callout server. 325 In order to allow asynchronous processing on the OPES processor and 326 callout server, it MUST be possible to separate request issuance from 327 response processing. The protocol MUST therefore allow multiple 328 outstanding requests and provide a method to correlate responses to 329 requests. 331 Additionally, the callout protocol MUST enable a callout server to 332 respond to a callout request before it has received the entire 333 request. 335 3.13 Message Segmentation 337 The OPES callout protocol MUST allow an OPES processor to forward an 338 application message to a callout server in a series of smaller 339 message fragments. The callout protocol MUST further enable the 340 receiving callout server to assemble the fragmented application 341 message. 343 Likewise, the callout protocol MUST enable a callout server to return 344 an application message to an OPES processor in a series of smaller 345 message fragments. The callout protocol MUST enable the receiving 346 OPES processor to assemble the fragmented application message. 348 Depending on the application-layer protocol used on the data path, 349 application messages may be very large in size (for example in the 350 case of audio/video streams) or of unknown size. In both cases, the 351 OPES processor has to initiate a callout transaction before it has 352 received the entire application message to avoid long delays for the 353 data consumer. The OPES processor MUST therefore be able to forward 354 fragments or chunks of an application message to a callout server as 355 it receives them from the data provider or consumer. Likewise, the 356 callout server MUST be able to process and return application message 357 fragments as it receives them from the OPES processor. 359 4. Performance Requirements 361 4.1 Protocol Efficiency 363 The OPES callout protocol SHOULD be efficient in that it minimizes 364 the additionally introduced latency, for example by minimizing the 365 protocol overhead. 367 As OPES callout transactions introduce additional latency to 368 application protocol transactions on the data path, calllout protocol 369 efficiency is crucial. 371 5. Security Requirements 373 In the absence of any security mechanisms, sensitive information 374 might be communicated between the OPES processor and the callout 375 server in violation of either endpoint's security and privacy policy 376 through misconfiguration or a deliberate insider attack. By using 377 strong authentication, message encryption, and integrity checks, this 378 threat can be minimized to a smaller set of insiders and/or operator 379 configuration errors. 381 The OPES processor and the callout servers SHOULD have enforceable 382 policies that limit the parties they communicate with, that determine 383 the protections to use based on identities of the endpoints and other 384 data (such as enduser policies). In order to enforce the policies, 385 they MUST be able to authenticate the callout protocol endpoints 386 using cryptographic methods. 388 5.1 Authentication, Confidentiality, and Integrity 390 The parties to the callout protocol MUST have a sound basis for 391 binding authenticated identities to the protocol endpoints, and they 392 MUST verify that these identities are consistent with their security 393 policies. 395 The OPES callout protocol MUST provide message authentication, 396 confidentiality, and integrity between the OPES processor and the 397 callout server. It MUST provide mutual authentication. The callout 398 protocol SHOULD use existing security mechanisms for this purpose. 399 The callout protocol specification is not required to specify the 400 security mechanisms, but it MAY instead refer to a lower-level 401 security protocol and discuss how its mechanisms are to be used with 402 the callout protocol. 404 5.2 Hop-by-Hop Confidentiality 406 If encryption is a requirement for the content path, then this 407 confidentiality MUST be extended to the communication between the 408 callout servers and the OPES processor. In order to minimize data 409 exposure, the callout protocol MUST use a different encryption key 410 for each encrypted content stream. 412 5.3 Operation Across Un-trusted Domains 414 The OPES callout protocol MUST operate securely across un-trusted 415 domains between the OPES processor and the callout server. 417 If the communication channels between the OPES processor and callout 418 server cross outside of the organization taking responsibility for 419 the OPES services, then endpoint authentication and message 420 protection (confidentiality and integrity) MUST be used. 422 5.4 Privacy 424 Any communication carrying information relevant to privacy policies 425 MUST protect the data using encryption. 427 6. Security Considerations 429 The security requirements for the OPES callout protocol are discussed 430 in Section 5. 432 References 434 [1] Barbir, A., "An Architecture for Open Pluggable Edge Services 435 (OPES)", draft-ietf-opes-architecture-01 (work in progress), May 436 2002. 438 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 439 Levels", RFC 2119, March 1997. 441 [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 442 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 443 HTTP/1.1", RFC 2616, June 1999. 445 [4] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 446 "RTP: A Transport Protocol for Real-Time Applications", RFC 447 1889, January 1996. 449 [5] Floyd, S. and L. Daigle, "IAB Architectural and Policy 450 Considerations for Open Pluggable Edge Services", RFC 3238, 451 January 2002. 453 Authors' Addresses 455 Andre Beck 456 Lucent Technologies 457 101 Crawfords Corner Road 458 Holmdel, NJ 07733 459 US 461 EMail: abeck@bell-labs.com 463 Markus Hofmann 464 Lucent Technologies 465 Room 4F-513 466 101 Crawfords Corner Road 467 Holmdel, NJ 07733 468 US 470 Phone: +1 732 332 5983 471 EMail: hofmann@bell-labs.com 472 Hilarie Orman 473 Purple Streak Development 475 EMail: ho@alum.mit.edu 476 URI: http://www.purplestreak.com 478 Reinaldo Penno 479 Nortel Networks 480 2305 Mission College Boulevard 481 San Jose, CA 95134 482 US 484 EMail: rpenno@nortelnetworks.com 486 Andreas Terzis 487 Individual Consultant 488 150 Golf Course Dr. 489 Rohnert Park, CA 94928 490 US 492 Phone: +1 707 586 8864 493 EMail: aterzis@sbcglobal.net 495 Appendix A. Acknowledgments 497 This document is based in parts on previous work by Anca Dracinschi 498 Sailer, Volker Hilt, and Rama R. Menon. 500 The authors would like to thank the participants of the OPES WG for 501 their comments on this draft. 503 Appendix B. Change Log 505 Changes from draft-ietf-opes-protocol-reqs-00.txt 507 o Aligned terminology with [1] 509 o Clarified in Section 3.11 that OCP requests not only have to 510 identify one or more OPES services, but also the order in which 511 the services are to be executed 513 o Removed requirement from Section 4.1 that OCP must satisfy 514 performance requirements of the application-layer protocol used 515 between data consumer and provider 517 Full Copyright Statement 519 Copyright (C) The Internet Society (2002). All Rights Reserved. 521 This document and translations of it may be copied and furnished to 522 others, and derivative works that comment on or otherwise explain it 523 or assist in its implementation may be prepared, copied, published 524 and distributed, in whole or in part, without restriction of any 525 kind, provided that the above copyright notice and this paragraph are 526 included on all such copies and derivative works. However, this 527 document itself may not be modified in any way, such as by removing 528 the copyright notice or references to the Internet Society or other 529 Internet organizations, except as needed for the purpose of 530 developing Internet standards in which case the procedures for 531 copyrights defined in the Internet Standards process must be 532 followed, or as required to translate it into languages other than 533 English. 535 The limited permissions granted above are perpetual and will not be 536 revoked by the Internet Society or its successors or assigns. 538 This document and the information contained herein is provided on an 539 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 540 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 541 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 542 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 543 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 545 Acknowledgement 547 Funding for the RFC Editor function is currently provided by the 548 Internet Society.