[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
        Network Working Group                          B.S. Srinivas
        Internet Draft                                 T. Chan
        Expires: December 2002                                Nokia
        File: draft-srinivas-opes-threats-00.txt
                                                       June 2002
             Security Threats and Risks for Open Pluggable Edge Services
        Status of this Memo
        This document is an Internet-Draft and is in full conformance with
        all provisions of Section 10 of RFC2026.  Internet-Drafts are
        working documents of the Internet Engineering Task Force (IETF), its
        areas, and its working groups.  Note that other groups may also
        distribute working documents as Internet-Drafts.
        Internet-Drafts are draft documents valid for a maximum of six
        months and may be updated, replaced, or obsoleted by other documents
        at any time.  It is inappropriate to use Internet-Drafts as
        reference material or to cite them other than as ``work in
        The list of current Internet-Drafts can be accessed at
        The list of Internet-Draft Shadow Directories can be accessed at
     Conventions used in this document
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        this document are to be interpreted as described in [RFC-2119].
     1. Abstract
        This Internet Draft is an attempt to define the security threats
        against the OPES protocol. In addition to the threats, the effects
        of such security threats on the underlying architecture as well as
        the requirements of a security solution to mitigate such threats are
        discussed. The threats and requirements identified herein and the
        document should be considered as work in progress.
     Internet Draft         Security Threats for OPES              June 2002
     2. Introduction
        The data stream flowing between a content provider and one or more
        content consumers may be in need of modifications as a function of
        the needs of the consumer, the constraints of her/his device,
        her/his geographical location and numerous other factors. These
        modifications to the traditional scenario (see Figure 1) are
        engineered by means of other application entities. The functions
        that we have in mind include language translation, virus scanning,
        bit-rate reduction in compliance with limited bandwidth
        availability, and many others (see Figure 2).
           ------------                                        ------------
           |          |          /----------------\            |          |
           | Content  |     \   /                  \    \      | Content  |
           | Provider |--------/     IP             \----------| Consumer |
           |          |     /  \   Network          /   /      |          |
           ------------         \                  /           ------------
                       Figure 1: Traditional non-OPES scenario
                 |          |
                 | Content  |
                 | Provider |
                 |          |
                     |   |
                   /-|- -|----\
                  /  |         \
         --------/   |   |      \---|
         |           |              |
         | IP n/w    |   |          |                     ------------
         |      ---------------|    |                     | Callout  |
         |      |    OPES      |    |---------------------| Server   |
         |      | Intermediary |    |- - - - - - - - - - -|          |
         |      |              |    |                     ------------
         |      ----------------    |
         |            |   |         |
          --------\   |        /-----
                   \  |   |   /
                      |   |                  ------ Content flow
                  ------------               - - -  Signaling flow
                  |          |
                  | Content  |
                  | Consumer |
                  |          |
                         Figure 2:OPES Network Architecture
     Srinivas, Chan        Expires December 2002                    [Page 2]

     Internet Draft         Security Threats for OPES              June 2002
        Either the application entities, referred to in the preceding text,
        may be collocated with either of the two ends of the data stream or
        it may be a discrete entity situated elsewhere within the network.
        The last scenario comprises a data stream scenario, which is
        referred to as Open Pluggable Edge Services (OPES). Several such
        provisioning scenarios are described in [OPES-SCENE].
        The document discusses several additional security threats, which
        the data stream might be exposed to owing to the presence of a
        discrete entity, the OPES intermediary (and call-out servers [OPES-
        CALLOUT], if any), that provides the needed modification services.
        Here by data stream, we imply both the content stream as well as the
        signaling stream (to indicate the desired transformation). As
        illustrated in Figure 2, the content stream flows from the content
        provider to the OPES intermediary, which may further be forwarded to
        a call-out server and returned, then finally delivered to the
        content consumer after all the desired transformations are
        performed. The signaling information (or transformation requests)
        can originate from either the Content provider or consumer.
        Moreover, the OPES intermediary may send transformation requests to
        call-out servers as well. Attacks related to the signaling stream
        and content stream may have different results and need to be
        considered separately.
        New functionality when added to a networking architecture invariably
        creates new possibilities for tampering with some signaling
        communications, as well as user data traffic. In other words,
        various forms of protection including physical and/or programmatic
        means are lowered, resulting in new security vulnerabilities. In
        addition to the threats, the document also presents the impacts of
        these threats as well as the requirements of the security solutions
        to mitigate such threats.
        Notice that the security threats corresponding to a content/services
        delivery system without an OPES intermediary, as depicted in Figure
        1, is considered out-of-scope and therefore will not be discussed in
        this document. This document only focuses on threats that are
        introduced by the existence of the OPES intermediary and call-out
        The document is organized as follows: Section 3 discusses the
        security threats introduced by the OPES functionality. Section 4
        discusses the Intellectual Property rights issues if any.
     3. Threats
        With the incorporation of an additional application entity namely
        the OPES intermediary, despite its operation on the data flow
        between the content producer and consumer being authorized, a new
        site for exposure to threats from malicious entities is introduced.
        A whole array of threats, their effects and the suggested security
        solutions are discussed herein. The threats discussed are congruent
        with the security considerations raised in [RFC3238].
     Srinivas, Chan        Expires December 2002                    [Page 3]

     Internet Draft         Security Threats for OPES              June 2002
        In the traditional non-OPES scenario, the communicating end-points
        (the content producer and consumer) have a direct one-to-one
        association between them (see Figure 1). This direct association is
        broken by the existence of OPES intermediaries or callout servers.
        The secure operation of protocols, typically, depends on assumptions
        regarding the identity of the endpoints and the continuity of
        communication between them. The operation of OPES itself has
        security implications and risks.
     3.1. OPES device false registration/deregistration
        Threat:  In the event of the OPES intermediary being absent, a false
        registration / deregistration could be sent by a malicious node on
        behalf of the non-existent OPES intermediary.
        Effect: A false registration / deregistration would result in the
        end-system traffic being hijacked by the malicious node. The traffic
        is then eavesdropped on by the attacker. Moreover, unwanted or
        malicious transformation of the data traffic would occur.
        Alternatively, the malicious node may simply refuse to forward the
        data traffic to the content consumer, resulting in a Denial-of-
        Service attack.
        Solution: Either of the end-points MUST authenticate and authorize
        the OPES intermediary before directing any traffic to it. The
        content consumer MUST NOT accept any (modified) traffic, which has
        been transformed by an unauthenticated or unauthorized entity.
     3.2. OPES device spoofing
        Threat: A malicious node could send false information about an
        intermediate device masquerading as an OPES device.  Alternatively,
        despite the presence of a genuine OPES device which has been
        authenticated, the actual data transformation could be performed in
        a malicious call-out server.
        Effect: Similar to the previous case, the malicious device would be
        able to eavesdrop on all traffic (both data and signaling) between
        the end-systems. In addition, unexpected and undesirable data
        transformation by the malicious intermediary or call-out server
        would result. For example, the malicious node could force the
        consumer or producer to use the services of a malicious OPES
        intermediary, which renders very expensive transformation services.
        Finally, a malicious OPES intermediary may refuse to forward the
        traffic, resulting in a Denial-of-Service attack.
        Solution: The OPES intermediary device and the associated call-out
        server (if any) MUST be authenticated and authorized before any
        messages are sent through it. Notice that the transformation MAY
     Srinivas, Chan        Expires December 2002                    [Page 4]

     Internet Draft         Security Threats for OPES              June 2002
        require more than one call-out server, in which case, all of them
        need to be authenticated.
     3.3. Malicious node performs a replay attack
        Threat: A malicious node could passively eavesdrop on one of the
        communication channels and replay the recorded message (signaling or
        data) later. The signaling request from either the producer or the
        consumer to the OPES intermediary is open to such a kind of replay
        attack. Alternatively, a malicious nodethat serves as the OPES
        intermediary for two distinct data flows could replay the message
        from one data flow onto another.
        Effect: False or spurious action is performed by the OPES device or
        call-out server. A false transformation could be performed by the
        OPES device by replaying a transformation request issued by the
        consumer on a previous occasion. In addition, the transformed
        content could be replayed to the consumer as genuine content.
        Solution:  Care, in the form of sequence numbers, or other
        techniques, MUST be taken to prevent replay attacks. Authentication
        of OPES intermediaries is required such that malicious OPES devices
        will not be used, thereby reducing the possibility of content
     3.4. Re-establishing end-device - OPES device security during failover
        Threat: End-device (producer or consumer) fails over from OPES
        intermediary A to OPES intermediary B. A trust relationship between
        the end-device and A will not automatically translate into the same
        relationship existing between the end-device and B.
        Effect: If there was a trust relationship involving a security
        context between the end-device and A, the equivalent trust
        relationship between the end-device and B will not exist in the
        event of a failover from A to B. The assumption of such a trust
        relationship opens up security holes for malicious OPES
        intermediaries to perform all kinds of attacks.
        Solution: Either notify the application when failover occurs so that
        the application MAY take appropriate action to establish a trust
        relationship between the end-device and B or reestablish the
        security context transparently.
     3.5. Message Integrity
        Threat: Message flow through the OPES device is corrupted. By being
        corrupted, the implication is that, a message, which has been
        subject to unauthorized modification prior to the OPES intermediary,
        is inputted into the OPES intermediary (or call-out server). The
        modification can be on the signaling information related to the
        actions the OPES device needs to perform; or it can be on the
        contents that need to be transformed.
     Srinivas, Chan        Expires December 2002                    [Page 5]

     Internet Draft         Security Threats for OPES              June 2002
        Effect: Corrupted information is received which causes the OPES
        device to either transform the content in a wrong way, or transform
        the wrong content, generating a wrong output.
        Solution: Integrity mechanism is needed to protect both the actions
        specified as well as the contents of all the OPES messages. These
        could include hashing functions, for instance.
     3.6. Data Confidentiality
        Threat: An eavesdropper is typically capable of snooping on fields
        within messages in transit. Using various eavesdropping techniques,
        he may be able to garner various kinds of information including
        topology/location/IP addresses etc. that may not be desirable to
        divulge. He also may be able to eavesdrop on the content messages
        being delivered to the consumer. The delivery of the shared
        encryption keys to the OPES intermediary is subject to the threat of
        being eavesdropped on by a malicious entity.
        Effect: Information that session participants or an administrator do
        not wish to divulge is divulged. If shared encryption keys are
        compromised during key distribution, attackers will be able to
        decrypt encrypted content.
        Solution: Data confidentiality service MUST be provisioned using
        various kinds of encryption. This could be carried out using either
        a shared key or PKI, for instance. Special care needs to be taken in
        the delivery of the key information to the OPES intermediary and the
        callout server (if present).
     3.7. Denial-of-Service (DoS)
        Threat: A hostile or malicious node MAY be able to block all traffic
        on an unprotected link. The data traffic destined for the OPES
        intermediary (or call-out server) MAY NOT be able to use the
        services of the OPES device. The DoS MAY be achieved by preventing
        the data traffic from reaching the intermediary or the call-out
        server. Alternatively, the intermediary or the call-out server can
        be overloaded by spurious service requests issued by a malicious
        node, which denies the legal data traffic the necessary resources to
        render service. The resources include CPU cycles, memory, network
        interfaces, etc. In addition, a malicious node that successfully
        spoofs as an OPES intermediary (or call-out server) can launch DoS
        attacks simply by not forwarding the legitimate traffic to the
        content consumers. A Denial-of-Service attack can be selective,
        generic or random in terms of which communication streams are
        affected [MIP-DOS].
        Distributed DoS is also possible when an attacker successfully
        directs multiple nodes over the network to initiate spurious service
        requests to an OPES intermediary (or call-out server) simultaneously
     Srinivas, Chan        Expires December 2002                    [Page 6]

     Internet Draft         Security Threats for OPES              June 2002
        Effect: Legal data traffic is unable to acquire the services of the
        OPES intermediary (or call-out server) to achieve the desired
        Solution: Malicious data traffic emanating from particular suspect
        ports or IP addresses SHOULD be denied access to the OPES
     3.8.Authorized entity later repudiates a request
        Threat: An entity (producer or consumer) that is authorized to make
        a certain request of the OPES intermediary claims, later, that it
        did not make that request.
        Effect: The entity that repudiates a valid request for
        transformation by the OPES intermediary MAY be held liable for asked
        for changes to the data flow.
        Requirement: Non-repudiation of requests for transformation of a
        data flow by an OPES intermediary or a call-out server needs to be
        provided. This could be accomplished by, for instance, use of
        private keys in encrypting the request for a transformation service.
     4. Intellectual Property Rights
        The authors are not aware of any intellectual property right issues
        pertaining to this document.
     5. References
        [OPES-SCENE] McHenry, S., et. al, "OPES Scenarios and Use Cases",
                   Internet-Draft TBD, May 2002.
        [RFC3238]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
                   Considerations for Open Pluggable Edge Services", RFC
                   3238, January 2002.
        [OPES-CALLOUT] Beck, A., et. al, "Requirements for OPES Callout
                   Protocols," work in progress, May 2002, <draft-ietf-opes-
        [MIP-DOS] Nikander, P., et. al, "Threat Models introduced by Mobile
                  IPv6 and Requirements for Security in Mobile IPv6", work in progress,
                  December 2001, <draft-team-mobileip-mipv6-sec-reqts-00.txt>.
     6. Authors' Addresses
        Bindignavile S. Srinivas
        Tat Chan
        Nokia Research Center
     Srinivas, Chan        Expires December 2002                    [Page 7]

     Internet Draft         Security Threats for OPES              June 2002
        5 Wayside Road
        Burlington, MA 01803
        Email: {bindignavile.srinivas,tat.chan}@nokia.com
        1. Abstract........................................................1
        2. Introduction....................................................2
        3. Threats.........................................................3
           3.1. OPES device false registration/deregistration..............4
           3.2. OPES device spoofing.......................................4
           3.3. Malicious node performs a replay attack....................5
           3.4. Re-establishing end-device - OPES device security during
           3.5. Message Integrity..........................................5
           3.6. Data Confidentiality.......................................6
           3.7. Denial-of-Service (DoS)....................................6
           3.8. Authorized entity later repudiates a request...............7
        4. Intellectual Property Rights....................................7
        5. References......................................................7
        6. Authors' Addresses..............................................7
        Full Copyright Statement...........................................8
     Full Copyright Statement
        Copyright (C) The Internet Society (2002).  All Rights Reserved.
        This document and translations of it may be copied and furnished to
        others, and derivative works that comment on or otherwise explain it
        or assist in its implementation may be prepared, copied, published
        and distributed, in whole or in part, without restriction of any
        kind, provided that the above copyright notice and this paragraph
        are included on all such copies and derivative works.  However, this
        document itself may not be modified in any way, such as by removing
        the copyright notice or references to the Internet Society or other
        Internet organizations, except as needed for the purpose of
        developing Internet standards in which case the procedures for
        copyrights defined in the Internet Standards process must be
        followed, or as required to translate it into languages other than
        The limited permissions granted above are perpetual and will not be
        revoked by the Internet Society or its successors or assigns.
        This document and the information contained herein is provided on an
     Srinivas, Chan        Expires December 2002                    [Page 8]

     Internet Draft         Security Threats for OPES              June 2002
        Funding for the RFC Editor function is currently provided by the
        Internet Society.
     Srinivas, Chan        Expires December 2002                    [Page 9]