draft-ietf-opes-protocol-reqs-01.txt   draft-ietf-opes-protocol-reqs-02.txt 
Open Pluggable Edge Services A. Beck Open Pluggable Edge Services A. Beck
Internet-Draft M. Hofmann Internet-Draft M. Hofmann
Expires: December 17, 2002 Lucent Technologies Expires: January 31, 2003 Lucent Technologies
H. Orman H. Orman
Purple Streak Development Purple Streak Development
R. Penno R. Penno
Nortel Networks Nortel Networks
A. Terzis A. Terzis
Individual Consultant Individual Consultant
June 18, 2002 August 2, 2002
Requirements for OPES Callout Protocols Requirements for OPES Callout Protocols
draft-ietf-opes-protocol-reqs-01 draft-ietf-opes-protocol-reqs-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 17, 2002. This Internet-Draft will expire on January 31, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This document specifies the requirements that the OPES (Open This document specifies the requirements that the OPES (Open
Pluggable Edge Services) callout protocol must satisfy in order to Pluggable Edge Services) callout protocol must satisfy in order to
support the remote execution of OPES services [1]. The requirements support the remote execution of OPES services [1]. The requirements
skipping to change at page 4, line 14 skipping to change at page 4, line 14
2. Introduction 2. Introduction
The Open Pluggable Edge Services (OPES) architecture [1] enables The Open Pluggable Edge Services (OPES) architecture [1] enables
cooperative application services (OPES services) between a data cooperative application services (OPES services) between a data
provider, a data consumer, and zero or more OPES processors. The provider, a data consumer, and zero or more OPES processors. The
application services under consideration analyze and possibly application services under consideration analyze and possibly
transform application-level messages exchanged between the data transform application-level messages exchanged between the data
provider and the data consumer. provider and the data consumer.
The execution of such services is governed by a set of filtering The execution of such services is governed by a set of rules
rules installed on the OPES processor. The rules enforcement can installed on the OPES processor. The rules enforcement can trigger
trigger the execution of service applications local to the OPES the execution of service applications local to the OPES processor.
processor. Alternatively, the OPES processor can distribute the Alternatively, the OPES processor can distribute the responsibility
responsibility of service execution by communicating and of service execution by communicating and collaborating with one or
collaborating with one or more remote callout servers. As described more remote callout servers. As described in [1], an OPES processor
in [1], an OPES processor communicates with and invokes services on a communicates with and invokes services on a callout server by using a
callout server by using a callout protocol. This document presents callout protocol. This document presents the requirements for such a
the requirements for such a protocol. protocol.
The requirements in this document are divided into three categories - The requirements in this document are divided into three categories -
functional requirements, performance requirements, and security functional requirements, performance requirements, and security
requirements. Each requirement is presented as one or more requirements. Each requirement is presented as one or more
statements, followed by brief explanatory material as appropriate. statements, followed by brief explanatory material as appropriate.
3. Functional Requirements 3. Functional Requirements
3.1 Callout Transactions 3.1 Callout Transactions
The OPES callout protocol MUST enable an OPES processor and a callout The OPES callout protocol MUST enable an OPES processor and a callout
server to perform callout transactions with the purpose of exchanging server to perform callout transactions with the purpose of exchanging
partial or complete application-level protocol messages (or partial or complete application-level protocol messages (or
modifications thereof). More specifically, the callout protocol MUST modifications thereof). More specifically, the callout protocol MUST
enable an OPES processor to forward a complete or partial application enable an OPES processor to forward a partial or complete application
message to a callout server so that one or more OPES services can message to a callout server so that one or more OPES services can
process the forwarded application message (or parts thereof). The process the forwarded application message (or parts thereof). The
result of the service operation may be a modified application result of the service operation may be a modified application
message. The callout protocol MUST therefore enable the callout message. The callout protocol MUST therefore enable the callout
server to return a modified application message or the modified parts server to return a modified application message or the modified parts
of an application message to the OPES processor. of an application message to the OPES processor.
A callout transaction is defined as a message exchange between an A callout transaction is defined as a message exchange between an
OPES processor and a callout server consisting of a callout request OPES processor and a callout server consisting of a callout request
and a callout response. Both, the callout request as well as the and a callout response. Both, the callout request as well as the
callout response, MAY each consist of one or more protocol messages, callout response, MAY each consist of one or more callout protocol
i.e. a series of protocol messages. messages, i.e. a series of protocol messages.
Callout transactions are always initiated by a callout request from Callout transactions are always initiated by a callout request from
an OPES processor and typically terminated by a callout response from an OPES processor and typically terminated by a callout response from
a callout server. The OPES callout protocol MUST, however, also a callout server. The OPES callout protocol MUST, however, also
allow either endpoint of a callout transaction to terminate a callout allow either endpoint of a callout transaction to terminate a callout
transaction prematurely, i.e. before a callout request or response transaction prematurely, i.e. before a callout request or response
has been completely received by the corresponding endpoint. The has been completely received by the corresponding endpoint. The
callout protocol MAY provide an explicit (e.g. through a termination callout protocol MAY provide an explicit (e.g. through a termination
message) or implicit (e.g. through a connection tear-down) mechanism message) or implicit (e.g. through a connection tear-down) mechanism
to terminate a callout transaction prematurely. Such a mechanism to terminate a callout transaction prematurely. Such a mechanism
skipping to change at page 8, line 17 skipping to change at page 8, line 17
callout protocol version, transport-layer protocol, fail-over callout protocol version, transport-layer protocol, fail-over
behavior, heartbeat rate for keep-alive messages, security-related behavior, heartbeat rate for keep-alive messages, security-related
parameters etc. parameters etc.
Channel parameters may also pertain to the characteristics of OPES Channel parameters may also pertain to the characteristics of OPES
callout services if, for example, callout channels are associated callout services if, for example, callout channels are associated
with one or more specific OPES services. An OPES service-specific with one or more specific OPES services. An OPES service-specific
parameter may, for example, specify which parts of an application parameter may, for example, specify which parts of an application
message an OPES service requires for its operation. message an OPES service requires for its operation.
Callout channel parameters MUST be negotiated on a per-callout
channel basis and before any callout transactions are performed over
the corresponding channel. Other parameters and capabilities, such
as the fail-over behavior, MAY be negotiated between the two
endpoints independently of callout channels.
The parties to a callout protocol MAY use callout channels to The parties to a callout protocol MAY use callout channels to
negotiate all or some of their capabilities and parameters. They MAY negotiate all or some of their capabilities and parameters.
also use a separate control connection for this purpose. If there is Alternatively, a separate control connection MAY be used for this
a need for callout channel parameters, then they MUST be negotiated purpose.
on a per-callout channel basis and before any callout transactions
are performed over the corresponding channel. Other parameters and
capabilities, such as the fail-over behavior, MAY be negotiated
between the two endpoints independently of callout channels.
3.11 Meta Data and Instructions 3.11 Meta Data and Instructions
The OPES callout protocol MUST provide a mechanism for the endpoints The OPES callout protocol MUST provide a mechanism for the endpoints
of a particular callout transaction to include in callout requests of a particular callout transaction to include in callout requests
and responses meta data and instructions for the OPES processor or and responses meta data and instructions for the OPES processor or
callout server. callout server.
Specifically, the callout protocol MUST enable an OPES processor to Specifically, the callout protocol MUST enable an OPES processor to
include information about the forwarded application message in a include information about the forwarded application message in a
skipping to change at page 11, line 14 skipping to change at page 11, line 14
4. Performance Requirements 4. Performance Requirements
4.1 Protocol Efficiency 4.1 Protocol Efficiency
The OPES callout protocol SHOULD be efficient in that it minimizes The OPES callout protocol SHOULD be efficient in that it minimizes
the additionally introduced latency, for example by minimizing the the additionally introduced latency, for example by minimizing the
protocol overhead. protocol overhead.
As OPES callout transactions introduce additional latency to As OPES callout transactions introduce additional latency to
application protocol transactions on the data path, calllout protocol application protocol transactions on the data path, callout protocol
efficiency is crucial. efficiency is crucial.
5. Security Requirements 5. Security Requirements
In the absence of any security mechanisms, sensitive information In the absence of any security mechanisms, sensitive information
might be communicated between the OPES processor and the callout might be communicated between the OPES processor and the callout
server in violation of either endpoint's security and privacy policy server in violation of either endpoint's security and privacy policy
through misconfiguration or a deliberate insider attack. By using through misconfiguration or a deliberate insider attack. By using
strong authentication, message encryption, and integrity checks, this strong authentication, message encryption, and integrity checks, this
threat can be minimized to a smaller set of insiders and/or operator threat can be minimized to a smaller set of insiders and/or operator
skipping to change at page 12, line 29 skipping to change at page 12, line 29
they MUST be able to authenticate the callout protocol endpoints they MUST be able to authenticate the callout protocol endpoints
using cryptographic methods. using cryptographic methods.
5.1 Authentication, Confidentiality, and Integrity 5.1 Authentication, Confidentiality, and Integrity
The parties to the callout protocol MUST have a sound basis for The parties to the callout protocol MUST have a sound basis for
binding authenticated identities to the protocol endpoints, and they binding authenticated identities to the protocol endpoints, and they
MUST verify that these identities are consistent with their security MUST verify that these identities are consistent with their security
policies. policies.
The OPES callout protocol MUST provide message authentication, The OPES callout protocol MUST provide for message authentication,
confidentiality, and integrity between the OPES processor and the confidentiality, and integrity between the OPES processor and the
callout server. It MUST provide mutual authentication. The callout callout server. It MUST provide mutual authentication. For this
protocol SHOULD use existing security mechanisms for this purpose. purpose, the callout protocol SHOULD use existing security
The callout protocol specification is not required to specify the mechanisms. The callout protocol specification is not required to
security mechanisms, but it MAY instead refer to a lower-level specify the security mechanisms, but it MAY instead refer to a lower-
security protocol and discuss how its mechanisms are to be used with level security protocol and discuss how its mechanisms are to be used
the callout protocol. with the callout protocol.
5.2 Hop-by-Hop Confidentiality 5.2 Hop-by-Hop Confidentiality
If encryption is a requirement for the content path, then this If end-to-end encryption is a requirement for the content path, then
confidentiality MUST be extended to the communication between the this confidentiality MUST be extended to the communication between
callout servers and the OPES processor. In order to minimize data the callout servers and the OPES processor. In order to minimize
exposure, the callout protocol MUST use a different encryption key data exposure, the callout protocol MUST use a different encryption
for each encrypted content stream. key for each encrypted content stream.
5.3 Operation Across Un-trusted Domains 5.3 Operation Across Un-trusted Domains
The OPES callout protocol MUST operate securely across un-trusted The OPES callout protocol MUST operate securely across un-trusted
domains between the OPES processor and the callout server. domains between the OPES processor and the callout server.
If the communication channels between the OPES processor and callout If the communication channels between the OPES processor and callout
server cross outside of the organization taking responsibility for server cross outside of the organization taking responsibility for
the OPES services, then endpoint authentication and message the OPES services, then endpoint authentication and message
protection (confidentiality and integrity) MUST be used. protection (confidentiality and integrity) MUST be used.
skipping to change at page 15, line 8 skipping to change at page 15, line 8
MUST protect the data using encryption. MUST protect the data using encryption.
6. Security Considerations 6. Security Considerations
The security requirements for the OPES callout protocol are discussed The security requirements for the OPES callout protocol are discussed
in Section 5. in Section 5.
References References
[1] Barbir, A., "An Architecture for Open Pluggable Edge Services [1] Barbir, A., "An Architecture for Open Pluggable Edge Services
(OPES)", draft-ietf-opes-architecture-01 (work in progress), May (OPES)", draft-ietf-opes-architecture-03 (work in progress),
2002. August 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[4] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, [4] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC "RTP: A Transport Protocol for Real-Time Applications", RFC
skipping to change at page 18, line 6 skipping to change at page 18, line 6
Appendix A. Acknowledgments Appendix A. Acknowledgments
This document is based in parts on previous work by Anca Dracinschi This document is based in parts on previous work by Anca Dracinschi
Sailer, Volker Hilt, and Rama R. Menon. Sailer, Volker Hilt, and Rama R. Menon.
The authors would like to thank the participants of the OPES WG for The authors would like to thank the participants of the OPES WG for
their comments on this draft. their comments on this draft.
Appendix B. Change Log Appendix B. Change Log
Changes from draft-ietf-opes-protocol-reqs-01.txt
o Reworded and clarified several statements of the draft
Changes from draft-ietf-opes-protocol-reqs-00.txt Changes from draft-ietf-opes-protocol-reqs-00.txt
o Aligned terminology with [1] o Aligned terminology with [1]
o Clarified in Section 3.11 that OCP requests not only have to o Clarified in Section 3.11 that OCP requests not only have to
identify one or more OPES services, but also the order in which identify one or more OPES services, but also the order in which
the services are to be executed the services are to be executed
o Removed requirement from Section 4.1 that OCP must satisfy o Removed requirement from Section 4.1 that OCP must satisfy
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/