as such.
Bypass support has limitations similar to the two notification-
related considerations above.
7. Consideration (4.1) ’URI resolution’
"OPES documentation must be clear in describing these services as
being applied to the result of URI resolution, not as URI resolution
itself" [RFC3238].
"OPES Scenarios and Use Cases" specification [RFC3752] documents
content adaptations that are in scope of the OPES framework.
Scenarios include content adaptation of requests and responses.
These documented adaptations do not include URI resolution. In some
environments, it is technically possible to use documented OPES
mechanisms to resolve URIs (and other kinds of identifiers or
addresses). The OPES framework cannot effectively prevent any
specific kind of adaptation.
For example, a CDN node may substitute domain names in URLs with
CDN-chosen IP addresses, essentially performing a URI resolution on
behalf of the content producer (i.e., the web site owner). An OPES
callout service running on a user PC may rewrite all HTML-embedded
advertisement URLs to point to a user-specified local image,
essentially performing a URI redirection on behalf of the content
consumer (i.e., the end user). Such URI manipulations are outside of
the OPES framework scope, but cannot be effectively eliminated from
the real world.
8. Consideration (4.2) ’Reference validity’
"All proposed services must define their impact on inter- and intra-
document reference validity" [RFC3238].
The OPES framework does not propose adaptation services. However,
OPES tracing requirements include identification of OPES
intermediaries and services (for details, see "Notification"
consideration sections in this document). It is required that
provided identification can be used to locate information about the
OPES intermediaries, including the description of impact on reference
validity [RFC3897].
9. Consideration (4.3) ’Addressing extensions’
"Any 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" [RFC3238].
OPES framework does not contain ad hoc fixes. This document in
combination with and other OPES documents should be sufficient to
inform service creators of IAB considerations. If a service does URI
resolution or silently affects document reference validity, the
authors are requested to review service impact on Internet
application addressing architecture and work within IETF on potential
extension requirements. Such actions would be outside of the current
OPES framework.
10. Consideration (5.1) ’Privacy’
"The overall OPES framework must provide for mechanisms for end users
to determine the privacy policies of OPES intermediaries" [RFC3238].
OPES tracing mechanisms allow end users to identify OPES
intermediaries (for details, see "Notification" consideration
sections in this document). It is required that provided
identification can be used to locate information about the OPES
intermediaries, including their privacy policies.
The term "privacy policy" is not defined in this context (by IAB or
OPES working group). OPES tracing mechanisms allow end users and
content providers to identify an OPES system and/or intermediaries.
It is believed that once an OPES system is identified, it would be
possible to locate relevant information about that system, including
information relevant to requesters perception of privacy policy or
reference validity.
11. Consideration ’Encryption’
"If OPES is chartered, the OPES working group will also have to
explicitly decide and document whether the OPES architecture must be
compatible with the use of end-to-end encryption by one or more ends
of an OPES-involved session. If OPES was compatible with end-to-end
encryption, this would effectively ensure that OPES boxes would be
restricted to ones that are known, trusted, explicitly addressed at
the IP layer, and authorized (by the provision of decryption keys) by
at least one of the ends" [RFC3238].
The above quoted requirement was not explicitly listed as on of the
IAB considerations, but still needs to be addressed. The context of
the quote implies that the phrase "end-to-end encryption" refers to
encryption along all links of the end-to-end path, with the OPES
intermediaries as encrypting/decrypting participants or hops (e.g.,
encryption between the provider and the OPES intermediaries, and
between the OPES intermediaries and the client).
Since OPES processors are regular hops on the application protocol
path, OPES architecture allows for such encryption, provided the
application protocol being adapted supports it. Hop-by-hop
encryption would do little good for the overall application message
path protection if callout services have to receive unencrypted
content. To allow for complete link encryption coverage, OPES
callout protocol (OCP) supports encryption of OCP connections between
an OPES processor and a callout server via optional (negotiated)
transport encryption mechanisms [I-D.ietf-opes-ocp-core].
For example, TLS encryption [RFC2817] can be used among HTTP hops
(some of which could be OPES processors) and between each OPES
processor and a callout server.
12. Security Considerations
This document does not define any mechanisms that may be subject to
security considerations. This document scope is to address specific
IAB considerations. Security of OPES mechanisms are discussed in
Security Considerations sections of the corresponding OPES framework
documents.
For example, OPES tracing mechanisms assist content providers and
consumers in protecting content integrity and confidentiality by
requiring OPES intermediaries to disclose their presence. Security
of the tracing mechanism is discussed in the Security Considerations
section of [RFC3897].
13. Compliance
This document may be perceived as a proof of OPES compliance with IAB
implied recommendations. However, this document does not introduce
any compliance subjects. Compliance of OPES implementations is
defined in other OPES documents discussed above.
14. References
14.1. Normative References
[RFC3238] Floyd, S. and L. Daigle, "IAB
Architectural and Policy Considerations
for Open Pluggable Edge Services", RFC
3238, January 2002.
[RFC3752] 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.
[RFC3835] Barbir, A., Penno, R., Chen, R.,
Hofmann, M., and H. Orman, "An
Architecture for Open Pluggable Edge
Services (OPES)", RFC 3835, August
2004.
[RFC3897] Barbir, A., "Open Pluggable Edge
Services (OPES) Entities and End Points
Communication", RFC 3897, September
2004.
14.2. Informative References
[RFC2227] Mogul, J. and P. Leach, "Simple
Hit-Metering and Usage-Limiting for
HTTP", RFC 2227, October 1997.
[RFC2616] 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.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading
to TLS Within HTTP/1.1", RFC 2817, May
2000.
[I-D.ietf-opes-http] Rousskov, A. and M. Stecher, "HTTP
adaptation with OPES", Work in
Progress, October 2003.
[I-D.ietf-opes-ocp-core] Rousskov, A., "OPES Callout Protocol
Core", Work in Progress, November 2003.
Authors’ Addresses
Abbie Barbir
Nortel Networks
3500 Carling Avenue
Nepean, Ontario
CA
Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com
Alex Rousskov
The Measurement Factory
EMail: rousskov@measurement-factory.com
URI: http://www.measurement-factory.com/
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/S HE
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 IETF’s procedures with respect to rights in IETF 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.