idnits 2.17.1 draft-ietf-opes-protocol-reqs-02.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 (August 2, 2002) is 7909 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-03 ** 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: January 31, 2003 Lucent Technologies 5 H. Orman 6 Purple Streak Development 7 R. Penno 8 Nortel Networks 9 A. Terzis 10 Individual Consultant 11 August 2, 2002 13 Requirements for OPES Callout Protocols 14 draft-ietf-opes-protocol-reqs-02 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 January 31, 2003. 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 rules 99 installed on the OPES processor. The rules enforcement can trigger 100 the execution of service applications local to the OPES processor. 101 Alternatively, the OPES processor can distribute the responsibility 102 of service execution by communicating and collaborating with one or 103 more remote callout servers. As described in [1], an OPES processor 104 communicates with and invokes services on a callout server by using a 105 callout protocol. This document presents the requirements for such a 106 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 partial or complete 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 callout protocol 133 messages, 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 Callout channel parameters MUST be negotiated on a per-callout 271 channel basis and before any callout transactions are performed over 272 the corresponding channel. Other parameters and capabilities, such 273 as the fail-over behavior, MAY be negotiated between the two 274 endpoints independently of callout channels. 276 The parties to a callout protocol MAY use callout channels to 277 negotiate all or some of their capabilities and parameters. 278 Alternatively, a separate control connection MAY be used for this 279 purpose. 281 3.11 Meta Data and Instructions 283 The OPES callout protocol MUST provide a mechanism for the endpoints 284 of a particular callout transaction to include in callout requests 285 and responses meta data and instructions for the OPES processor or 286 callout server. 288 Specifically, the callout protocol MUST enable an OPES processor to 289 include information about the forwarded application message in a 290 callout request, e.g. in order to specify the type of the forwarded 291 application message or to specify what part(s) of the application 292 message are forwarded to the callout server. Likewise, the callout 293 server MUST be able to include information about the returned 294 application message. 296 The OPES processor MUST further be able to include an ordered list of 297 one or more uniquely specified OPES services which are to be 298 performed on the forwarded application message in the specified 299 order. However, as the callout protocol MAY also choose to associate 300 callout channels with specific OPES services, there may not be a need 301 to identify OPES service on a per-callout transaction basis. 303 Additionally, the OPES callout protocol MUST allow the callout server 304 to indicate to the OPES processor the cacheability of callout 305 responses. This implies that callout responses may have to carry 306 cache-control instructions for the OPES processor. 308 The OPES callout protocol MUST further enable the OPES processor to 309 indicate to the callout server if it has kept a local copy of the 310 forwarded application message (or parts thereof). This information 311 enables the callout server to determine whether the forwarded 312 application message must be returned to the OPES processor even it 313 has not been modified by an OPES service. 315 The OPES callout protocol MUST also allow OPES processors to comply 316 with the tracing requirements of the OPES architecture as laid out in 317 [1] and [5]. This implies that the callout protocol MUST enable a 318 callout server to convey to the OPES processor information about the 319 OPES service operations performed on the forwarded application 320 message. 322 3.12 Asynchronous Message Exchange 324 The OPES callout protocol MUST support an asynchronous message 325 exchange between an OPES processor and a callout server. 327 In order to allow asynchronous processing on the OPES processor and 328 callout server, it MUST be possible to separate request issuance from 329 response processing. The protocol MUST therefore allow multiple 330 outstanding requests and provide a method to correlate responses to 331 requests. 333 Additionally, the callout protocol MUST enable a callout server to 334 respond to a callout request before it has received the entire 335 request. 337 3.13 Message Segmentation 339 The OPES callout protocol MUST allow an OPES processor to forward an 340 application message to a callout server in a series of smaller 341 message fragments. The callout protocol MUST further enable the 342 receiving callout server to assemble the fragmented application 343 message. 345 Likewise, the callout protocol MUST enable a callout server to return 346 an application message to an OPES processor in a series of smaller 347 message fragments. The callout protocol MUST enable the receiving 348 OPES processor to assemble the fragmented application message. 350 Depending on the application-layer protocol used on the data path, 351 application messages may be very large in size (for example in the 352 case of audio/video streams) or of unknown size. In both cases, the 353 OPES processor has to initiate a callout transaction before it has 354 received the entire application message to avoid long delays for the 355 data consumer. The OPES processor MUST therefore be able to forward 356 fragments or chunks of an application message to a callout server as 357 it receives them from the data provider or consumer. Likewise, the 358 callout server MUST be able to process and return application message 359 fragments as it receives them from the OPES processor. 361 4. Performance Requirements 363 4.1 Protocol Efficiency 365 The OPES callout protocol SHOULD be efficient in that it minimizes 366 the additionally introduced latency, for example by minimizing the 367 protocol overhead. 369 As OPES callout transactions introduce additional latency to 370 application protocol transactions on the data path, callout protocol 371 efficiency is crucial. 373 5. Security Requirements 375 In the absence of any security mechanisms, sensitive information 376 might be communicated between the OPES processor and the callout 377 server in violation of either endpoint's security and privacy policy 378 through misconfiguration or a deliberate insider attack. By using 379 strong authentication, message encryption, and integrity checks, this 380 threat can be minimized to a smaller set of insiders and/or operator 381 configuration errors. 383 The OPES processor and the callout servers SHOULD have enforceable 384 policies that limit the parties they communicate with, that determine 385 the protections to use based on identities of the endpoints and other 386 data (such as enduser policies). In order to enforce the policies, 387 they MUST be able to authenticate the callout protocol endpoints 388 using cryptographic methods. 390 5.1 Authentication, Confidentiality, and Integrity 392 The parties to the callout protocol MUST have a sound basis for 393 binding authenticated identities to the protocol endpoints, and they 394 MUST verify that these identities are consistent with their security 395 policies. 397 The OPES callout protocol MUST provide for message authentication, 398 confidentiality, and integrity between the OPES processor and the 399 callout server. It MUST provide mutual authentication. For this 400 purpose, the callout protocol SHOULD use existing security 401 mechanisms. The callout protocol specification is not required to 402 specify the security mechanisms, but it MAY instead refer to a lower- 403 level security protocol and discuss how its mechanisms are to be used 404 with the callout protocol. 406 5.2 Hop-by-Hop Confidentiality 408 If end-to-end encryption is a requirement for the content path, then 409 this confidentiality MUST be extended to the communication between 410 the callout servers and the OPES processor. In order to minimize 411 data exposure, the callout protocol MUST use a different encryption 412 key for each encrypted content stream. 414 5.3 Operation Across Un-trusted Domains 416 The OPES callout protocol MUST operate securely across un-trusted 417 domains between the OPES processor and the callout server. 419 If the communication channels between the OPES processor and callout 420 server cross outside of the organization taking responsibility for 421 the OPES services, then endpoint authentication and message 422 protection (confidentiality and integrity) MUST be used. 424 5.4 Privacy 426 Any communication carrying information relevant to privacy policies 427 MUST protect the data using encryption. 429 6. Security Considerations 431 The security requirements for the OPES callout protocol are discussed 432 in Section 5. 434 References 436 [1] Barbir, A., "An Architecture for Open Pluggable Edge Services 437 (OPES)", draft-ietf-opes-architecture-03 (work in progress), 438 August 2002. 440 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 441 Levels", RFC 2119, March 1997. 443 [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 444 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 445 HTTP/1.1", RFC 2616, June 1999. 447 [4] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 448 "RTP: A Transport Protocol for Real-Time Applications", RFC 449 1889, January 1996. 451 [5] Floyd, S. and L. Daigle, "IAB Architectural and Policy 452 Considerations for Open Pluggable Edge Services", RFC 3238, 453 January 2002. 455 Authors' Addresses 457 Andre Beck 458 Lucent Technologies 459 101 Crawfords Corner Road 460 Holmdel, NJ 07733 461 US 463 EMail: abeck@bell-labs.com 465 Markus Hofmann 466 Lucent Technologies 467 Room 4F-513 468 101 Crawfords Corner Road 469 Holmdel, NJ 07733 470 US 472 Phone: +1 732 332 5983 473 EMail: hofmann@bell-labs.com 474 Hilarie Orman 475 Purple Streak Development 477 EMail: ho@alum.mit.edu 478 URI: http://www.purplestreak.com 480 Reinaldo Penno 481 Nortel Networks 482 2305 Mission College Boulevard 483 San Jose, CA 95134 484 US 486 EMail: rpenno@nortelnetworks.com 488 Andreas Terzis 489 Individual Consultant 490 150 Golf Course Dr. 491 Rohnert Park, CA 94928 492 US 494 Phone: +1 707 586 8864 495 EMail: aterzis@sbcglobal.net 497 Appendix A. Acknowledgments 499 This document is based in parts on previous work by Anca Dracinschi 500 Sailer, Volker Hilt, and Rama R. Menon. 502 The authors would like to thank the participants of the OPES WG for 503 their comments on this draft. 505 Appendix B. Change Log 507 Changes from draft-ietf-opes-protocol-reqs-01.txt 509 o Reworded and clarified several statements of the draft 511 Changes from draft-ietf-opes-protocol-reqs-00.txt 513 o Aligned terminology with [1] 515 o Clarified in Section 3.11 that OCP requests not only have to 516 identify one or more OPES services, but also the order in which 517 the services are to be executed 519 o Removed requirement from Section 4.1 that OCP must satisfy 520 performance requirements of the application-layer protocol used 521 between data consumer and provider 523 Full Copyright Statement 525 Copyright (C) The Internet Society (2002). All Rights Reserved. 527 This document and translations of it may be copied and furnished to 528 others, and derivative works that comment on or otherwise explain it 529 or assist in its implementation may be prepared, copied, published 530 and distributed, in whole or in part, without restriction of any 531 kind, provided that the above copyright notice and this paragraph are 532 included on all such copies and derivative works. However, this 533 document itself may not be modified in any way, such as by removing 534 the copyright notice or references to the Internet Society or other 535 Internet organizations, except as needed for the purpose of 536 developing Internet standards in which case the procedures for 537 copyrights defined in the Internet Standards process must be 538 followed, or as required to translate it into languages other than 539 English. 541 The limited permissions granted above are perpetual and will not be 542 revoked by the Internet Society or its successors or assigns. 544 This document and the information contained herein is provided on an 545 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 546 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 547 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 548 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 549 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 551 Acknowledgement 553 Funding for the RFC Editor function is currently provided by the 554 Internet Society.