peer entity. Other application level related security concerns can
be found in [4].
8.2. Bypass security considerations
The bypass facility for OPES architecture is implemented as a
protocol extension. Inadequate implementations of the bypass
facility may defeat safeguards built into the OPES architecture. The
bypass facility by itself can become a target of malicious attacks or
used to lunch attacks on an OPES System.
Threats caused by or against the bypass facility can be viewed as
threats at the application level in an OPES Flow. In this case, the
threats can affect the data consumer and the data provider
application.
There are risks for the OPES System by non-OPES entities, whereby,
these entities can insert bypass instructions into the OPES Flow.
The threat can come from compromised non-OPES entities. The threat
might affect the overall integrity and effectiveness of an OPES
System. For example, a non-OPES proxy can add bypass instruction to
bypass legitimate OPES entities. The attack might result in
overwhelming the original content provider servers, since the attack
essentially bypass any load balancing techniques. In addition, such
an attack is also equivalent to a DoS attack, whereby, a legitimate
data consumer application may not be able to access some content from
a content provider or its OPES version.
Since an OPES Flow may include non-OPES entities, it is susceptible
to man-in-the-middle attacks, whereby an intruder may inject bypass
instructions into the data path. These attacks may affect content
availability or disturb load balancing techniques in the network.
The above threats can also arise by compromised OPES entities. An
intruder can compromise an OPES entities and then use man-in-the-
middle techniques to disturb content availability to a data consumer
application or overload a content provider server (essentially, some
form of a DoS attack).
Attackers can use the bypass instruction to affect the overall
integrity of the OPES System. The ability to introduce bypass
instructions into a data flow may effect the accounting of the OPES
System. It may also affect the quality of content that is delivered
to the data consumer applications. Similar threats can arise from
bad implementations of the bypass facility.
Inconsistent or selective bypass is also a threat. Here, one end can
try to bypass a subset of OPES entities so that the resulting content
is malformed and crashes or compromises entities that process that
content (and expect that content to be complete and valid). Such
exceptions are often not tested because implementers do not expect a
vital service to disappear from the processing loop.
Other threats can arise from configuring access control policies for
OPES entities. It is possible that systems implementing access
controls via OPES entities may be incorrectly configured to honor
bypass and, hence, give unauthorized access to intruders.
Tap bypass can also be a threat. This is because systems
implementing wiretaps via OPES entities may be incorrectly configured
to honor bypass and, hence, ignore (leave undetected) traffic with
bypass instructions that should have been tapped or logged. It is
also possible for one end to bypass services such as virus scanning
at the receiving end. This threat can be used by hackers to inject
viruses throughout the network. Following an IETF policy on
Wiretapping [7], OPES communication model does not consider
wiretapping requirements. Nevertheless, the documented threat is
real, not obvious, and OPES technology users operating in wiretapping
or similar logging environments should be aware of it.
Other application level related security concerns can be found in
[4].
9. References
9.1. Normative References
[1] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An
Architecture for Open Pluggable Edge Services (OPES)", RFC 3835,
August 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Barbir, A., Batuner, O., Beck, A., Chan, T., and H. Orman,
"Policy, Authorization, and Enforcement Requirements of Open
Pluggable Edge Services (OPES)", RFC 3838, August 2004.
[4] 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.
9.2 Informative References
[5] 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.
[6] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[7] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
10. Acknowledgements
Several people has contributed to this work. Many thanks to: Alex
Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin
Stecher, Marshall Rose and Reinaldo Penno.
11. Author’s Address
Abbie Barbir
Nortel Networks
3500 Carling Avenue
Nepean, Ontario K2H 8E9
Canada
Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com
12. 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.