idnits 2.17.1 draft-ietf-opes-protocol-reqs-00.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 (May 24, 2002) is 8008 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-00 ** 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: November 22, 2002 Lucent Technologies 5 H. Orman 6 Purple Streak Development 7 R. Penno 8 Nortel Networks 9 A. Terzis 10 Individual Consultant 11 May 24, 2002 13 Requirements for OPES Callout Protocols 14 draft-ietf-opes-protocol-reqs-00 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 November 22, 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 Data 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 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 78 References . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 80 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 82 1. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [2]. 88 2. Introduction 90 The Open Pluggable Edge Services (OPES) architecture [1] enables 91 cooperative application services (OPES services) between a data 92 provider, a data consumer, and zero or more data processors. The 93 application services under consideration analyze and possibly 94 transform application-level messages exchanged between the data 95 provider and the data consumer. 97 The execution of such services is governed by a set of filtering 98 rules installed on the data processor. The rules enforcement can 99 trigger the execution of service applications local to the data 100 processor. Alternatively, the data processor can distribute the 101 responsibility of service execution by communicating and 102 collaborating with one or more remote callout servers. As described 103 in [1], a data processor communicates with and invokes services on a 104 callout server by using a callout protocol. This document presents 105 the requirements for such a protocol. 107 The requirements in this document are divided into three categories - 108 functional requirements, performance requirements, and security 109 requirements. Each requirement is presented as one or more 110 statements, followed by brief explanatory material as appropriate. 112 3. Functional Requirements 114 3.1 Callout Transactions 116 The OPES callout protocol MUST enable an OPES data processor and a 117 callout server to perform callout transactions with the purpose of 118 exchanging partial or complete application-level protocol messages 119 (or modifications thereof). More specifically, the callout protocol 120 MUST enable an OPES data processor to forward a complete or partial 121 application message to a callout server so that one or more OPES 122 services can process the forwarded application message (or parts 123 thereof). The result of the service operation may be a modified 124 application message. The callout protocol MUST therefore enable the 125 callout server to return a modified application message or the 126 modified parts of an application message to the OPES data processor. 128 A callout transaction is defined as a message exchange between an 129 OPES data processor and a callout server consisting of a callout 130 request and a callout response. Both, the callout request as well as 131 the callout response, MAY each consist of one or more protocol 132 messages, i.e. a series of protocol messages. 134 Callout transactions are always initiated by a callout request from 135 an OPES data processor and typically terminated by a callout response 136 from a callout server. The OPES callout protocol MUST, however, also 137 allow either endpoint of a callout transaction to terminate a callout 138 transaction prematurely, i.e. before a callout request or response 139 has been completely received by the corresponding endpoint. The 140 callout protocol MAY provide an explicit (e.g. through a termination 141 message) or implicit (e.g. through a connection tear-down) mechanism 142 to terminate a callout transaction prematurely. Such a mechanism 143 MUST ensure, however, that a premature termination of a callout 144 transaction does not result in the loss of application message data. 146 A premature termination of a callout transaction is required to 147 support OPES services which may terminate even before they have 148 processed the entire application message. Content analysis services, 149 for example, may be able to classify a Web object after having 150 processed just the first few bytes of a Web object. 152 The callout protocol MUST further enable a callout server to report 153 back to the OPES data processor the result of a callout transaction, 154 e.g. in the form of a status code. 156 3.2 Callout Channels 158 The OPES callout protocol MUST enable an OPES data processor and a 159 callout server to perform multiple callout transactions over a 160 callout channel. A callout channel is defined as a logical 161 connection at the application-layer between an OPES data processor 162 and a callout server. 164 Callout channels MUST always be established by an OPES data 165 processor. A callout channel MAY be closed by either endpoint of the 166 callout channel provided that all callout transactions associated 167 with the 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 data 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 data 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 data processor and callout 202 server. 204 The detection of a callout server failure may enable an OPES data 205 processor to establish a channel connection with a stand-by callout 206 server so that future callout transactions do not result in the loss 207 of application message data. The detection of the failure of an OPES 208 data processor may enable a callout server to release resources which 209 would otherwise not be available for callout transactions with other 210 OPES data processors. 212 3.6 Operation in NAT Environments 214 The OPES protocol SHOULD be NAT-friendly, i.e. its operation should 215 not be compromised by the presence of one or more NAT devices in the 216 path between an OPES data processor and a callout server. 218 3.7 Multiple Callout Servers 220 The OPES callout protocol MUST allow an OPES data processor to 221 simultaneously communicate with more than one callout server. 223 In larger networks, OPES services are likely to be hosted by 224 different callout servers. Therefore, an OPES data processor will 225 likely have to communicate with multiple callout servers. The 226 protocol design MUST enable an OPES data processor to do so. 228 3.8 Multiple Data Processors 230 The OPES callout protocol MUST allow a callout server to 231 simultaneously communicate with more than one OPES data processor. 233 The protocol design MUST support a scenario in which multiple OPES 234 data processors use the services of a single callout server. 236 3.9 Support for Different Application Protocols 238 The OPES callout protocol MUST be application protocol-agnostic, i.e. 239 it MUST not make any assumptions about the characteristics of the 240 application-layer protocol used on the data path between data 241 provider and data consumer. 243 The OPES entities on the data path may use different application- 244 layer protocols, including, but not limited to, HTTP [3] and RTP [4]. 245 It would be desirable to be able to use the same OPES callout 246 protocol for any such application-layer protocol. 248 3.10 Capability and Parameter Negotiations 250 The OPES callout protocol MUST support the negotiation of 251 capabilities and callout channel parameters between an OPES data 252 processor and a callout server. This implies that the OPES data 253 processor and the callout server MUST be able to exchange their 254 capabilities and preferences and engage into a deterministic 255 negotiation process at the end of which the two endpoints have either 256 agreed on the capabilities and parameters to be used for future 257 callout channel transactions or determined that their capabilities 258 are incompatible. 260 Capabilities and parameters that could be negotiated between an OPES 261 data processor and a callout server include (but are not limited to): 262 callout protocol version, transport-layer protocol, fail-over 263 behavior, heartbeat rate for keep-alive messages, security-related 264 parameters etc. 266 Channel parameters may also pertain to the characteristics of OPES 267 callout services if, for example, callout channels are associated 268 with one or more specific OPES services. An OPES service-specific 269 parameter may, for example, specify which parts of an application 270 message an OPES service requires for its operation. 272 The parties to a callout protocol MAY use callout channels to 273 negotiate all or some of their capabilities and parameters. They MAY 274 also use a separate control connection for this purpose. If there is 275 a need for callout channel parameters, then they MUST be negotiated 276 on a per-callout channel basis and before any callout transactions 277 are performed over the corresponding channel. Other parameters and 278 capabilities, such as the fail-over behavior, MAY be negotiated 279 between the two endpoints independently of callout channels. 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 data processor 286 or callout server. 288 Specifically, the callout protocol MUST enable an OPES data processor 289 to 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 data processor MUST further be able to uniquely specify one 297 or more OPES services which are to be performed on the forwarded 298 application message. The callout protocol MAY also choose to 299 associate callout channels with specific OPES services so that there 300 is no need to identify OPES service on a per-callout transaction 301 basis. 303 Additionally, the OPES callout protocol MUST allow the callout server 304 to indicate to the OPES data processor the cacheability of callout 305 responses. This implies that callout responses may have to carry 306 cache-control instructions for the OPES data processor. 308 The OPES callout protocol MUST further enable the OPES data processor 309 to 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 data processor even 313 it has not been modified by an OPES service. 315 The OPES callout protocol MUST also allow OPES data processors to 316 comply with the tracing requirements of the OPES architecture as laid 317 out in [1] and [5]. This implies that the callout protocol MUST 318 enable a callout server to convey to the OPES data processor 319 information about the OPES service operations performed on the 320 forwarded application message. 322 3.12 Asynchronous Message Exchange 324 The OPES callout protocol MUST support an asynchronous message 325 exchange between an OPES data processor and a callout server. 327 In order to allow asynchronous processing on the OPES data processor 328 and callout server, it MUST be possible to separate request issuance 329 from 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 data processor to 340 forward an application message to a callout server in a series of 341 smaller message fragments. The callout protocol MUST further enable 342 the 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 a data processor in a series of smaller 347 message fragments. The callout protocol MUST enable the receiving 348 data 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 data processor has to initiate a callout transaction before it 354 has received the entire application message to avoid long delays for 355 the data consumer. The OPES data processor MUST therefore be able to 356 forward fragments or chunks of an application message to a callout 357 server as it receives them from the data provider or consumer. 358 Likewise, the callout server MUST be able to process and return 359 application message fragments as it receives them from the data 360 processor. 362 4. Performance Requirements 364 4.1 Protocol Efficiency 366 The OPES callout protocol SHOULD be efficient in that it minimizes 367 the additionally introduced latency, for example by minimizing the 368 protocol overhead. At a minimum, the callout protocol SHOULD satisfy 369 the performance requirements of the application-layer protocol whose 370 messages are forwarded from the OPES data processor to the callout 371 server. 373 As OPES callout transactions introduce additional latency to 374 application protocol transactions on the data path, calllout protocol 375 efficiency is crucial. 377 5. Security Requirements 379 In the absence of any security mechanisms, sensitive information 380 might be communicated between the OPES data processor and the callout 381 server in violation of either endpoint's security and privacy policy 382 through misconfiguration or a deliberate insider attack. By using 383 strong authentication, message encryption, and integrity checks, this 384 threat can be minimized to a smaller set of insiders and/or operator 385 configuration errors. 387 The OPES data processor and the callout servers SHOULD have 388 enforceable policies that limit the parties they communicate with, 389 that determine the protections to use based on identities of the 390 endpoints and other data (such as enduser policies). In order to 391 enforce the policies, they MUST be able to authenticate the callout 392 protocol endpoints using cryptographic methods. 394 5.1 Authentication, Confidentiality, and Integrity 396 The parties to the callout protocol MUST have a sound basis for 397 binding authenticated identities to the protocol endpoints, and they 398 MUST verify that these identities are consistent with their security 399 policies. 401 The OPES callout protocol MUST provide message authentication, 402 confidentiality, and integrity between the OPES data processor and 403 the callout server. It MUST provide mutual authentication. The 404 callout protocol SHOULD use existing security mechanisms for this 405 purpose. The callout protocol specification is not required to 406 specify the security mechanisms, but it MAY instead refer to a lower- 407 level security protocol and discuss how its mechanisms are to be used 408 with the callout protocol. 410 5.2 Hop-by-Hop Confidentiality 412 If encryption is a requirement for the content path, then this 413 confidentiality MUST be extended to the communication between the 414 callout servers and the OPES data processor. In order to minimize 415 data exposure, the callout protocol MUST use a different encryption 416 key for each encrypted content stream. 418 5.3 Operation Across Un-trusted Domains 420 The OPES callout protocol MUST operate securely across un-trusted 421 domains between the OPES data processor and the callout server. 423 If the communication channels between the OPES data processor and 424 callout server cross outside of the organization taking 425 responsibility for the OPES services, then endpoint authentication 426 and message protection (confidentiality and integrity) MUST be used. 428 5.4 Privacy 430 Any communication carrying information relevant to privacy policies 431 MUST protect the data using encryption. 433 6. Security Considerations 435 The security requirements for the OPES callout protocol are discussed 436 in Section 5. 438 7. Acknowledgments 440 This document is based in parts on previous work by Anca Dracinschi 441 Sailer, Volker Hilt, and Rama R. Menon. 443 References 445 [1] Barbir, A., "An Architecture for Open Pluggable Edge Services 446 (OPES)", draft-ietf-opes-architecture-00 (work in progress), May 447 2002. 449 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 450 Levels", RFC 2119, March 1997. 452 [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 453 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 454 HTTP/1.1", RFC 2616, June 1999. 456 [4] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 457 "RTP: A Transport Protocol for Real-Time Applications", RFC 458 1889, January 1996. 460 [5] Floyd, S. and L. Daigle, "IAB Architectural and Policy 461 Considerations for Open Pluggable Edge Services", RFC 3238, 462 January 2002. 464 Authors' Addresses 466 Andre Beck 467 Lucent Technologies 468 101 Crawfords Corner Road 469 Holmdel, NJ 07733 470 US 472 EMail: abeck@bell-labs.com 474 Markus Hofmann 475 Lucent Technologies 476 Room 4F-513 477 101 Crawfords Corner Road 478 Holmdel, NJ 07733 479 US 481 Phone: +1 732 332 5983 482 EMail: hofmann@bell-labs.com 483 Hilarie Orman 484 Purple Streak Development 486 EMail: ho@alum.mit.edu 487 URI: http://www.purplestreak.com 489 Reinaldo Penno 490 Nortel Networks 491 2305 Mission College Boulevard 492 San Jose, CA 95134 493 US 495 EMail: rpenno@nortelnetworks.com 497 Andreas Terzis 498 Individual Consultant 499 150 Golf Course Dr. 500 Rohnert Park, CA 94928 501 US 503 Phone: +1 707 586 8864 504 EMail: aterzis@sbcglobal.net 506 Full Copyright Statement 508 Copyright (C) The Internet Society (2002). All Rights Reserved. 510 This document and translations of it may be copied and furnished to 511 others, and derivative works that comment on or otherwise explain it 512 or assist in its implementation may be prepared, copied, published 513 and distributed, in whole or in part, without restriction of any 514 kind, provided that the above copyright notice and this paragraph are 515 included on all such copies and derivative works. However, this 516 document itself may not be modified in any way, such as by removing 517 the copyright notice or references to the Internet Society or other 518 Internet organizations, except as needed for the purpose of 519 developing Internet standards in which case the procedures for 520 copyrights defined in the Internet Standards process must be 521 followed, or as required to translate it into languages other than 522 English. 524 The limited permissions granted above are perpetual and will not be 525 revoked by the Internet Society or its successors or assigns. 527 This document and the information contained herein is provided on an 528 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 529 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 530 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 531 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 532 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 534 Acknowledgement 536 Funding for the RFC Editor function is currently provided by the 537 Internet Society.