| +----------+ | | | | | | +----------+ |
| | OPES | | | | OPES | |
| +----------+ |processor| | | |processor| +----------+ |
| | | | | | | | | | | |
| | data | | | | | | | | data | |
| | provider | | | | | | | | consumer | |
| | | +---------+ | | +---------+ +----------+ |
| +----------+ || || | | || || +----------+ |
| || || || | | || || || |
| ============= ================= =========== |
| | | |
+-------------------------------+ +-------------------------------+
| <----------------- OPES flow -----------------> |
Figure 4: OPES administrative domains and policy distribution
In order to understand the trust relationships between OPES entities,
each is labeled as residing in an administrative domain. Entities
associated with a given OPES flow may reside in one or more
administrative domains.
An OPES processor may be in several trust domains at any time. There
is no restriction on whether the OPES processors are authorized by
data consumers and/or data providers. The original party has the
option of forbidding or limiting redelegation.
An OPES processor MUST have a representation of its trust domain
memberships that it can report in whole or in part for tracing
purposes. It MUST include the name of the party that delegated each
privilege to it.
3.2. Establishing Trust and Service Authorization
The OPES processor will have a configuration policy specifying what
privileges the callout servers have and how they are to be
identified. OPES uses standard protocols for authentication and
other security communication with callout servers.
An OPES processor will have a trusted method for receiving
configuration information, such as rules for the data dispatcher,
trusted callout servers, primary parties that opt-in or opt-out of
individual services, etc.
Protocol(s) for policy/rule distribution are out of scope for this
document, but the OPES architecture assumes the existence of such a
mechanism.
Requirements for the authorization mechanism are set in a separate
document [4].
Service requests may be done in-band. For example, a request to
bypass OPES services could be signalled by a user agent using an HTTP
header string "Bypass-OPES". Such requests MUST be authenticated.
The way OPES entities will honor such requests is subordinate to the
authorization policies effective at that moment.
3.3. Callout Protocol
The determination of whether or not OPES processors will use the
measures that are described in the previous section during their
communication with callout servers depends on the details of how the
primary parties delegated trust to the OPES processors and the trust
relationship between the OPES processors and the callout server.
Strong authentication, message authentication codes, and encryption
SHOULD be used. If the OPES processors are in a single
administrative domain with strong confidentiality and integrity
guarantees, then cryptographic protection is recommended but
optional.
If the delegation mechanism names the trusted parties and their
privileges in some way that permits authentication, then the OPES
processors will be responsible for enforcing the policy and for using
authentication as part of that enforcement.
The callout servers MUST be aware of the policy governing the
communication path. They MUST not, for example, communicate
confidential information to auxiliary servers outside the trust
domain.
A separate security association MUST be used for each channel
established between an OPES processor and a callout server. The
channels MUST be separate for different primary parties.
3.4. Privacy
Some data from OPES flow endpoints is considered "private" or
"sensitive", and OPES processors MUST advise the primary parties of
their privacy policy and respect the policies of the primary parties.
The privacy information MUST be conveyed on a per-flow basis. This
can be accomplished by using current available privacy techniques
such as P3P [7] and HTTP privacy capabilities.
The callout servers MUST also participate in the handling of private
data, they MUST be prepared to announce their own capabilities, and
enforce the policy required by the primary parties.
3.5. End-to-End Integrity
Digital signature techniques can be used to mark data changes in such
a way that a third-party can verify that the changes are or are not
consistent with the originating party’s policy. This requires an
inline method to specify policy and its binding to data, a trace of
changes and the identity of the party making the changes, and strong
identification and authentication methods.
Strong end-to-end integrity can fulfill some of the functions
required by "tracing".
4. IAB Architectural and Policy Considerations for OPES
This section addresses the IAB considerations for OPES [2] and
summarizes how the architecture addresses them.
4.1. IAB Consideration (2.1) One-Party Consent
The IAB recommends that all OPES services be explicitly authorized by
one of the application-layer end-hosts (that is, either the data
consumer application or the data provider application).
The current work requires that either the data consumer application
or the data provider application consent to OPES services. These
requirements have been addressed in sections 2 (section 2.1) and 3.
4.2. IAB Consideration (2.2) IP-Layer Communications
The IAB recommends that OPES processors must be explicitly addressed
at the IP layer by the end user (data consumer application).
This requirement has been addressed in section 2.1, by the
requirement that OPES processors be addressable at the IP layer by
the data consumer application.
4.3. IAB Consideration (3.1 and 3.2) Notification
The IAB recommends that the OPES architecture incorporate tracing
facilities. Tracing enables data consumer and data provider
applications to detect and respond to actions performed by OPES
processors that are deemed inappropriate to the data consumer or data
provider applications.
Section 3.2 of this document discusses the tracing and notification
facilities that must be supported by OPES services.
4.4. IAB Consideration (3.3) Non-Blocking
The OPES architecture requires the specification of extensions to
HTTP. These extensions will allow the data consumer application to
request a non-OPES version of the content from the data provider
application. These requirements are covered in Section 3.2.
4.5. IAB Consideration (4.1) URI Resolution
This consideration recommends that OPES documentation must be clear
in describing OPES services as being applied to the result of URI
resolution, not as URI resolution itself.
This requirement has been addressed in sections 2.5 and 3.2, by
requiring OPES entities to document all the transformations that have
been performed.
4.6. IAB Consideration (4.2) Reference Validity
This consideration recommends that all proposed services must define
their impact on inter- and intra-document reference validity.
This requirement has been addressed in section 2.5 and throughout the
document whereby OPES entities are required to document the performed
transformations.
4.7. IAB Consideration (4.3) Application Addressing Extensions
This consideration recommends that any OPES services that cannot be
achieved while respecting the above two considerations may be
reviewed as potential requirements for Internet application
addressing architecture extensions, but must not be undertaken as ad
hoc fixes.
The current work does not require extensions of the Internet
application addressing architecture.
4.8. IAB Consideration (5.1) Privacy
This consideration recommends that the overall OPES framework must
provide for mechanisms for end users to determine the privacy
policies of OPES intermediaries.
This consideration has been addressed in section 3.
5. Security Considerations
The proposed work has to deal with security from various
perspectives. There are security and privacy issues that relate to
data consumer application, callout protocol, and the OPES flow. In
[6], there is an analysis of the threats against OPES entities.
6. IANA Considerations
The proposed work will evaluate current protocols for OCP. If the
work determines that a new protocol needs to be developed, then there
may be a need to request new numbers from IANA.
7. Summary
Although the architecture supports a wide range of cooperative
transformation services, it has few requirements for
interoperability.
The necessary and sufficient elements are specified in the following
documents:
o the OPES ruleset schema, which defines the syntax and semantics of
the rules interpreted by a data dispatcher; and,
o the OPES callout protocol (OCP) [5], which defines the
requirements for the protocol between a data dispatcher and a
callout server.
8. References
8.1. Normative References
[1] Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., and R.
Penno, "Open Pluggable Edge Services (OPES) Use Cases and
Deployment Scenarios", RFC 3752, April 2004.
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[4] Barbir, A., Batuner, O., Beck, A., Chan, T., and H. Orman,
"Policy, Authorization, and Enforcement Requirements of the Open
Pluggable Edge Services (OPES)", RFC 3838, August 2004.
[5] Beck, A., Hofmann, M., Orman, H., Penno, R., and A. Terzis,
"Requirements for Open Pluggable Edge Services (OPES) Callout
Protocols", RFC 3836, August 2004.
[6] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H.
Orman, "Security Threats and Risks for Open Pluggable Edge
Services (OPES)", RFC 3837, August 2004.
8.2. Informative References
[7] Cranor, L. et. al, "The Platform for Privacy Preferences 1.0
(P3P1.0) Specification", W3C Recommendation 16
http://www.w3.org/TR/2002/REC-P3P-20020416/, April 2002.
9. Acknowledgements
This document is the product of OPES WG. Oskar Batuner (Independent
consultant) and Andre Beck (Lucent) are additional authors that have
contributed to this document.
Earlier versions of this work were done by Gary Tomlinson (The
Tomlinson Group) and Michael Condry (Intel).
The authors gratefully acknowledge the contributions of: John Morris,
Mark Baker, Ian Cooper and Marshall T. Rose.
10. Authors’ Addresses
Abbie Barbir
Nortel Networks
3500 Carling Avenue
Nepean, Ontario K2H 8E9
Canada
Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com
Yih-Farn Robin Chen
AT&T Labs - Research
180 Park Avenue
Florham Park, NJ 07932
US
Phone: +1 973 360 8653
EMail: chen@research.att.com
Markus Hofmann
Bell Labs/Lucent Technologies
Room 4F-513
101 Crawfords Corner Road
Holmdel, NJ 07733
US
Phone: +1 732 332 5983
EMail: hofmann@bell-labs.com
Hilarie Orman
Purple Streak Development
EMail: ho@alum.mit.edu
Reinaldo Penno
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
USA
EMail: rpenno@nortelnetworks.com
11. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.