draft-ietf-opes-protocol-reqs-00.txt   draft-ietf-opes-protocol-reqs-01.txt 
Open Pluggable Edge Services A. Beck Open Pluggable Edge Services A. Beck
Internet-Draft M. Hofmann Internet-Draft M. Hofmann
Expires: November 22, 2002 Lucent Technologies Expires: December 17, 2002 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
May 24, 2002 June 18, 2002
Requirements for OPES Callout Protocols Requirements for OPES Callout Protocols
draft-ietf-opes-protocol-reqs-00 draft-ietf-opes-protocol-reqs-01
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 November 22, 2002. This Internet-Draft will expire on December 17, 2002.
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 2, line 17 skipping to change at page 2, line 17
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Functional Requirements . . . . . . . . . . . . . . . . . . 5 3. Functional Requirements . . . . . . . . . . . . . . . . . . 5
3.1 Callout Transactions . . . . . . . . . . . . . . . . . . . . 5 3.1 Callout Transactions . . . . . . . . . . . . . . . . . . . . 5
3.2 Callout Channels . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Callout Channels . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Reliability . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Reliability . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4 Congestion and Flow Control . . . . . . . . . . . . . . . . 6 3.4 Congestion and Flow Control . . . . . . . . . . . . . . . . 6
3.5 Support for Keep-Alive Mechanism . . . . . . . . . . . . . . 6 3.5 Support for Keep-Alive Mechanism . . . . . . . . . . . . . . 6
3.6 Operation in NAT Environments . . . . . . . . . . . . . . . 7 3.6 Operation in NAT Environments . . . . . . . . . . . . . . . 7
3.7 Multiple Callout Servers . . . . . . . . . . . . . . . . . . 7 3.7 Multiple Callout Servers . . . . . . . . . . . . . . . . . . 7
3.8 Multiple Data Processors . . . . . . . . . . . . . . . . . . 7 3.8 Multiple OPES Processors . . . . . . . . . . . . . . . . . . 7
3.9 Support for Different Application Protocols . . . . . . . . 7 3.9 Support for Different Application Protocols . . . . . . . . 7
3.10 Capability and Parameter Negotiations . . . . . . . . . . . 7 3.10 Capability and Parameter Negotiations . . . . . . . . . . . 7
3.11 Meta Data and Instructions . . . . . . . . . . . . . . . . . 8 3.11 Meta Data and Instructions . . . . . . . . . . . . . . . . . 8
3.12 Asynchronous Message Exchange . . . . . . . . . . . . . . . 9 3.12 Asynchronous Message Exchange . . . . . . . . . . . . . . . 9
3.13 Message Segmentation . . . . . . . . . . . . . . . . . . . . 9 3.13 Message Segmentation . . . . . . . . . . . . . . . . . . . . 9
4. Performance Requirements . . . . . . . . . . . . . . . . . . 11 4. Performance Requirements . . . . . . . . . . . . . . . . . . 11
4.1 Protocol Efficiency . . . . . . . . . . . . . . . . . . . . 11 4.1 Protocol Efficiency . . . . . . . . . . . . . . . . . . . . 11
5. Security Requirements . . . . . . . . . . . . . . . . . . . 12 5. Security Requirements . . . . . . . . . . . . . . . . . . . 12
5.1 Authentication, Confidentiality, and Integrity . . . . . . . 12 5.1 Authentication, Confidentiality, and Integrity . . . . . . . 12
5.2 Hop-by-Hop Confidentiality . . . . . . . . . . . . . . . . . 12 5.2 Hop-by-Hop Confidentiality . . . . . . . . . . . . . . . . . 12
5.3 Operation Across Un-trusted Domains . . . . . . . . . . . . 12 5.3 Operation Across Un-trusted Domains . . . . . . . . . . . . 12
5.4 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. document are to be interpreted as described in RFC 2119 [2].
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 data 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 filtering
rules installed on the data processor. The rules enforcement can rules installed on the OPES processor. The rules enforcement can
trigger the execution of service applications local to the data trigger the execution of service applications local to the OPES
processor. Alternatively, the data processor can distribute the processor. Alternatively, the OPES processor can distribute the
responsibility of service execution by communicating and responsibility of service execution by communicating and
collaborating with one or more remote callout servers. As described collaborating with one or more remote callout servers. As described
in [1], a data processor communicates with and invokes services on a in [1], an OPES processor communicates with and invokes services on a
callout server by using a callout protocol. This document presents callout server by using a callout protocol. This document presents
the requirements for such a protocol. the requirements for such a 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 data processor and a The OPES callout protocol MUST enable an OPES processor and a callout
callout server to perform callout transactions with the purpose of server to perform callout transactions with the purpose of exchanging
exchanging partial or complete application-level protocol messages partial or complete application-level protocol messages (or
(or modifications thereof). More specifically, the callout protocol modifications thereof). More specifically, the callout protocol MUST
MUST enable an OPES data processor to forward a complete or partial enable an OPES processor to forward a complete or partial application
application message to a callout server so that one or more OPES message to a callout server so that one or more OPES services can
services can process the forwarded application message (or parts process the forwarded application message (or parts thereof). The
thereof). The result of the service operation may be a modified result of the service operation may be a modified application
application message. The callout protocol MUST therefore enable the message. The callout protocol MUST therefore enable the callout
callout server to return a modified application message or the server to return a modified application message or the modified parts
modified parts of an application message to the OPES data 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 data processor and a callout server consisting of a callout OPES processor and a callout server consisting of a callout request
request and a callout response. Both, the callout request as well as and a callout response. Both, the callout request as well as the
the callout response, MAY each consist of one or more protocol callout response, MAY each consist of one or more protocol messages,
messages, i.e. a series of protocol 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 data processor and typically terminated by a callout response an OPES processor and typically terminated by a callout response from
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
MUST ensure, however, that a premature termination of a callout MUST ensure, however, that a premature termination of a callout
transaction does not result in the loss of application message data. transaction does not result in the loss of application message data.
A premature termination of a callout transaction is required to A premature termination of a callout transaction is required to
support OPES services which may terminate even before they have support OPES services which may terminate even before they have
processed the entire application message. Content analysis services, processed the entire application message. Content analysis services,
for example, may be able to classify a Web object after having for example, may be able to classify a Web object after having
processed just the first few bytes of a Web object. processed just the first few bytes of a Web object.
The callout protocol MUST further enable a callout server to report The callout protocol MUST further enable a callout server to report
back to the OPES data processor the result of a callout transaction, back to the OPES processor the result of a callout transaction, e.g.
e.g. in the form of a status code. in the form of a status code.
3.2 Callout Channels 3.2 Callout Channels
The OPES callout protocol MUST enable an OPES data processor and a The OPES callout protocol MUST enable an OPES processor and a callout
callout server to perform multiple callout transactions over a server to perform multiple callout transactions over a callout
callout channel. A callout channel is defined as a logical channel. A callout channel is defined as a logical connection at the
connection at the application-layer between an OPES data processor application-layer between an OPES processor and a callout server.
and a callout server.
Callout channels MUST always be established by an OPES data Callout channels MUST always be established by an OPES processor. A
processor. A callout channel MAY be closed by either endpoint of the callout channel MAY be closed by either endpoint of the callout
callout channel provided that all callout transactions associated channel provided that all callout transactions associated with the
with the channel have terminated. channel have terminated.
A callout channel MAY have certain parameters associated with it, for A callout channel MAY have certain parameters associated with it, for
example parameters that control the fail-over behavior of channel example parameters that control the fail-over behavior of channel
endpoints. Callout channel parameters MAY be negotiated between OPES endpoints. Callout channel parameters MAY be negotiated between OPES
data processors and callout servers (see Section 3.10). processors and callout servers (see Section 3.10).
3.3 Reliability 3.3 Reliability
The OPES callout protocol MUST be able to provide ordered reliability The OPES callout protocol MUST be able to provide ordered reliability
for the communication between OPES data processor and callout server. for the communication between OPES processor and callout server.
Additionally, the callout protocol SHOULD be able to provide Additionally, the callout protocol SHOULD be able to provide
unordered reliability. unordered reliability.
In order to satisfy the reliability requirements, the callout In order to satisfy the reliability requirements, the callout
protocol MAY specify that it must be used with a lower-level protocol MAY specify that it must be used with a lower-level
transport protocol which provides ordered reliability at the transport protocol which provides ordered reliability at the
transport-layer. transport-layer.
3.4 Congestion and Flow Control 3.4 Congestion and Flow Control
skipping to change at page 6, line 45 skipping to change at page 6, line 44
mechanisms or refer to a lower-level transport protocol and discuss mechanisms or refer to a lower-level transport protocol and discuss
how its mechanisms provide for congestion and flow control. how its mechanisms provide for congestion and flow control.
3.5 Support for Keep-Alive Mechanism 3.5 Support for Keep-Alive Mechanism
The OPES callout protocol MUST provide an optional keep-alive The OPES callout protocol MUST provide an optional keep-alive
mechanism which, if used, would allow both endpoints of a callout mechanism which, if used, would allow both endpoints of a callout
channel to detect a failure of the other endpoint even in the absence channel to detect a failure of the other endpoint even in the absence
of callout transactions. The callout protocol MAY specify that keep- of callout transactions. The callout protocol MAY specify that keep-
alive messages be exchanged over existing callout channel connections alive messages be exchanged over existing callout channel connections
or a separate connection between OPES data processor and callout or a separate connection between OPES processor and callout server.
server.
The detection of a callout server failure may enable an OPES data The detection of a callout server failure may enable an OPES
processor to establish a channel connection with a stand-by callout processor to establish a channel connection with a stand-by callout
server so that future callout transactions do not result in the loss server so that future callout transactions do not result in the loss
of application message data. The detection of the failure of an OPES of application message data. The detection of the failure of an OPES
data processor may enable a callout server to release resources which processor may enable a callout server to release resources which
would otherwise not be available for callout transactions with other would otherwise not be available for callout transactions with other
OPES data processors. OPES processors.
3.6 Operation in NAT Environments 3.6 Operation in NAT Environments
The OPES protocol SHOULD be NAT-friendly, i.e. its operation should The OPES protocol SHOULD be NAT-friendly, i.e. its operation should
not be compromised by the presence of one or more NAT devices in the not be compromised by the presence of one or more NAT devices in the
path between an OPES data processor and a callout server. path between an OPES processor and a callout server.
3.7 Multiple Callout Servers 3.7 Multiple Callout Servers
The OPES callout protocol MUST allow an OPES data processor to The OPES callout protocol MUST allow an OPES processor to
simultaneously communicate with more than one callout server. simultaneously communicate with more than one callout server.
In larger networks, OPES services are likely to be hosted by In larger networks, OPES services are likely to be hosted by
different callout servers. Therefore, an OPES data processor will different callout servers. Therefore, an OPES processor will likely
likely have to communicate with multiple callout servers. The have to communicate with multiple callout servers. The protocol
protocol design MUST enable an OPES data processor to do so. design MUST enable an OPES processor to do so.
3.8 Multiple Data Processors 3.8 Multiple OPES Processors
The OPES callout protocol MUST allow a callout server to The OPES callout protocol MUST allow a callout server to
simultaneously communicate with more than one OPES data processor. simultaneously communicate with more than one OPES processor.
The protocol design MUST support a scenario in which multiple OPES The protocol design MUST support a scenario in which multiple OPES
data processors use the services of a single callout server. processors use the services of a single callout server.
3.9 Support for Different Application Protocols 3.9 Support for Different Application Protocols
The OPES callout protocol MUST be application protocol-agnostic, i.e. The OPES callout protocol MUST be application protocol-agnostic, i.e.
it MUST not make any assumptions about the characteristics of the it MUST not make any assumptions about the characteristics of the
application-layer protocol used on the data path between data application-layer protocol used on the data path between data
provider and data consumer. provider and data consumer.
The OPES entities on the data path may use different application- The OPES entities on the data path may use different application-
layer protocols, including, but not limited to, HTTP [3] and RTP [4]. layer protocols, including, but not limited to, HTTP [3] and RTP [4].
It would be desirable to be able to use the same OPES callout It would be desirable to be able to use the same OPES callout
protocol for any such application-layer protocol. protocol for any such application-layer protocol.
3.10 Capability and Parameter Negotiations 3.10 Capability and Parameter Negotiations
The OPES callout protocol MUST support the negotiation of The OPES callout protocol MUST support the negotiation of
capabilities and callout channel parameters between an OPES data capabilities and callout channel parameters between an OPES processor
processor and a callout server. This implies that the OPES data and a callout server. This implies that the OPES processor and the
processor and the callout server MUST be able to exchange their callout server MUST be able to exchange their capabilities and
capabilities and preferences and engage into a deterministic preferences and engage into a deterministic negotiation process at
negotiation process at the end of which the two endpoints have either the end of which the two endpoints have either agreed on the
agreed on the capabilities and parameters to be used for future capabilities and parameters to be used for future callout channel
callout channel transactions or determined that their capabilities transactions or determined that their capabilities are incompatible.
are incompatible.
Capabilities and parameters that could be negotiated between an OPES Capabilities and parameters that could be negotiated between an OPES
data processor and a callout server include (but are not limited to): processor and a callout server include (but are not limited to):
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.
skipping to change at page 8, line 33 skipping to change at page 8, line 30
a need for callout channel parameters, then they MUST be negotiated a need for callout channel parameters, then they MUST be negotiated
on a per-callout channel basis and before any callout transactions on a per-callout channel basis and before any callout transactions
are performed over the corresponding channel. Other parameters and are performed over the corresponding channel. Other parameters and
capabilities, such as the fail-over behavior, MAY be negotiated capabilities, such as the fail-over behavior, MAY be negotiated
between the two endpoints independently of callout channels. 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 data processor and responses meta data and instructions for the OPES processor or
or callout server. callout server.
Specifically, the callout protocol MUST enable an OPES data processor Specifically, the callout protocol MUST enable an OPES processor to
to include information about the forwarded application message in a include information about the forwarded application message in a
callout request, e.g. in order to specify the type of the forwarded callout request, e.g. in order to specify the type of the forwarded
application message or to specify what part(s) of the application application message or to specify what part(s) of the application
message are forwarded to the callout server. Likewise, the callout message are forwarded to the callout server. Likewise, the callout
server MUST be able to include information about the returned server MUST be able to include information about the returned
application message. application message.
The OPES data processor MUST further be able to uniquely specify one The OPES processor MUST further be able to include an ordered list of
or more OPES services which are to be performed on the forwarded one or more uniquely specified OPES services which are to be
application message. The callout protocol MAY also choose to performed on the forwarded application message in the specified
associate callout channels with specific OPES services so that there order. However, as the callout protocol MAY also choose to associate
is no need to identify OPES service on a per-callout transaction callout channels with specific OPES services, there may not be a need
basis. to identify OPES service on a per-callout transaction basis.
Additionally, the OPES callout protocol MUST allow the callout server Additionally, the OPES callout protocol MUST allow the callout server
to indicate to the OPES data processor the cacheability of callout to indicate to the OPES processor the cacheability of callout
responses. This implies that callout responses may have to carry responses. This implies that callout responses may have to carry
cache-control instructions for the OPES data processor. cache-control instructions for the OPES processor.
The OPES callout protocol MUST further enable the OPES data processor The OPES callout protocol MUST further enable the OPES processor to
to indicate to the callout server if it has kept a local copy of the indicate to the callout server if it has kept a local copy of the
forwarded application message (or parts thereof). This information forwarded application message (or parts thereof). This information
enables the callout server to determine whether the forwarded enables the callout server to determine whether the forwarded
application message must be returned to the OPES data processor even application message must be returned to the OPES processor even it
it has not been modified by an OPES service. has not been modified by an OPES service.
The OPES callout protocol MUST also allow OPES data processors to The OPES callout protocol MUST also allow OPES processors to comply
comply with the tracing requirements of the OPES architecture as laid with the tracing requirements of the OPES architecture as laid out in
out in [1] and [5]. This implies that the callout protocol MUST [1] and [5]. This implies that the callout protocol MUST enable a
enable a callout server to convey to the OPES data processor callout server to convey to the OPES processor information about the
information about the OPES service operations performed on the OPES service operations performed on the forwarded application
forwarded application message. message.
3.12 Asynchronous Message Exchange 3.12 Asynchronous Message Exchange
The OPES callout protocol MUST support an asynchronous message The OPES callout protocol MUST support an asynchronous message
exchange between an OPES data processor and a callout server. exchange between an OPES processor and a callout server.
In order to allow asynchronous processing on the OPES data processor In order to allow asynchronous processing on the OPES processor and
and callout server, it MUST be possible to separate request issuance callout server, it MUST be possible to separate request issuance from
from response processing. The protocol MUST therefore allow multiple response processing. The protocol MUST therefore allow multiple
outstanding requests and provide a method to correlate responses to outstanding requests and provide a method to correlate responses to
requests. requests.
Additionally, the callout protocol MUST enable a callout server to Additionally, the callout protocol MUST enable a callout server to
respond to a callout request before it has received the entire respond to a callout request before it has received the entire
request. request.
3.13 Message Segmentation 3.13 Message Segmentation
The OPES callout protocol MUST allow an OPES data processor to The OPES callout protocol MUST allow an OPES processor to forward an
forward an application message to a callout server in a series of application message to a callout server in a series of smaller
smaller message fragments. The callout protocol MUST further enable message fragments. The callout protocol MUST further enable the
the receiving callout server to assemble the fragmented application receiving callout server to assemble the fragmented application
message. message.
Likewise, the callout protocol MUST enable a callout server to return Likewise, the callout protocol MUST enable a callout server to return
an application message to a data processor in a series of smaller an application message to an OPES processor in a series of smaller
message fragments. The callout protocol MUST enable the receiving message fragments. The callout protocol MUST enable the receiving
data processor to assemble the fragmented application message. OPES processor to assemble the fragmented application message.
Depending on the application-layer protocol used on the data path, Depending on the application-layer protocol used on the data path,
application messages may be very large in size (for example in the application messages may be very large in size (for example in the
case of audio/video streams) or of unknown size. In both cases, the case of audio/video streams) or of unknown size. In both cases, the
OPES data processor has to initiate a callout transaction before it OPES processor has to initiate a callout transaction before it has
has received the entire application message to avoid long delays for received the entire application message to avoid long delays for the
the data consumer. The OPES data processor MUST therefore be able to data consumer. The OPES processor MUST therefore be able to forward
forward fragments or chunks of an application message to a callout fragments or chunks of an application message to a callout server as
server as it receives them from the data provider or consumer. it receives them from the data provider or consumer. Likewise, the
Likewise, the callout server MUST be able to process and return callout server MUST be able to process and return application message
application message fragments as it receives them from the data fragments as it receives them from the OPES processor.
processor.
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. At a minimum, the callout protocol SHOULD satisfy protocol overhead.
the performance requirements of the application-layer protocol whose
messages are forwarded from the OPES data processor to the callout
server.
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, calllout 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 data 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
configuration errors. configuration errors.
The OPES data processor and the callout servers SHOULD have The OPES processor and the callout servers SHOULD have enforceable
enforceable policies that limit the parties they communicate with, policies that limit the parties they communicate with, that determine
that determine the protections to use based on identities of the the protections to use based on identities of the endpoints and other
endpoints and other data (such as enduser policies). In order to data (such as enduser policies). In order to enforce the policies,
enforce the policies, they MUST be able to authenticate the callout they MUST be able to authenticate the callout protocol endpoints
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 message authentication,
confidentiality, and integrity between the OPES data processor and confidentiality, and integrity between the OPES processor and the
the callout server. It MUST provide mutual authentication. The callout server. It MUST provide mutual authentication. The callout
callout protocol SHOULD use existing security mechanisms for this protocol SHOULD use existing security mechanisms for this purpose.
purpose. The callout protocol specification is not required to The callout protocol specification is not required to specify the
specify the security mechanisms, but it MAY instead refer to a lower- security mechanisms, but it MAY instead refer to a lower-level
level security protocol and discuss how its mechanisms are to be used security protocol and discuss how its mechanisms are to be used with
with the callout protocol. 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 encryption is a requirement for the content path, then this
confidentiality MUST be extended to the communication between the confidentiality MUST be extended to the communication between the
callout servers and the OPES data processor. In order to minimize callout servers and the OPES processor. In order to minimize data
data exposure, the callout protocol MUST use a different encryption exposure, the callout protocol MUST use a different encryption key
key for each encrypted content stream. 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 data processor and the callout server. domains between the OPES processor and the callout server.
If the communication channels between the OPES data processor and If the communication channels between the OPES processor and callout
callout server cross outside of the organization taking server cross outside of the organization taking responsibility for
responsibility for the OPES services, then endpoint authentication the OPES services, then endpoint authentication and message
and message protection (confidentiality and integrity) MUST be used. protection (confidentiality and integrity) MUST be used.
5.4 Privacy 5.4 Privacy
Any communication carrying information relevant to privacy policies Any communication carrying information relevant to privacy policies
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.
7. Acknowledgments
This document is based in parts on previous work by Anca Dracinschi
Sailer, Volker Hilt, and Rama R. Menon.
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-00 (work in progress), May (OPES)", draft-ietf-opes-architecture-01 (work in progress), May
2002. 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,
skipping to change at page 18, line 4 skipping to change at page 17, line 4
EMail: rpenno@nortelnetworks.com EMail: rpenno@nortelnetworks.com
Andreas Terzis Andreas Terzis
Individual Consultant Individual Consultant
150 Golf Course Dr. 150 Golf Course Dr.
Rohnert Park, CA 94928 Rohnert Park, CA 94928
US US
Phone: +1 707 586 8864 Phone: +1 707 586 8864
EMail: aterzis@sbcglobal.net EMail: aterzis@sbcglobal.net
Appendix A. Acknowledgments
This document is based in parts on previous work by Anca Dracinschi
Sailer, Volker Hilt, and Rama R. Menon.
The authors would like to thank the participants of the OPES WG for
their comments on this draft.
Appendix B. Change Log
Changes from draft-ietf-opes-protocol-reqs-00.txt
o Aligned terminology with [1]
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
the services are to be executed
o Removed requirement from Section 4.1 that OCP must satisfy
performance requirements of the application-layer protocol used
between data consumer and provider
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 

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