[Fwd: Re: draft-ietf-cdi-threat-00.txt]
Kobus van der Merwe <[email protected]> Tue, 01 Oct 2002 13:17:38 -0400
| Newsgroups | gmane.ietf.cdi |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------040505020009060704040705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Comments from Fred Douglis which did not appear to have made it on to the list. Kobus --------------040505020009060704040705 Content-Type: message/rfc822; name="Re: draft-ietf-cdi-threat-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: draft-ietf-cdi-threat-00.txt" Return-Path: <[email protected]> Received: via tmail-4.1(10) for kobus+; Tue, 1 Oct 2002 08:05:24 -0400 (EDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id IAA04043 for <[email protected]>; Tue, 1 Oct 2002 08:05:22 -0400 (EDT) Received: by mail-blue.research.att.com (Postfix) id 0F4284D20A; Tue, 1 Oct 2002 08:04:54 -0400 (EDT) Delivered-To: [email protected] Received: from janus (fpfw.research.att.com [135.207.1.2]) by mail-blue.research.att.com (Postfix) with SMTP id 762FA4D2E4 for <[email protected]>; Tue, 1 Oct 2002 08:02:35 -0400 (EDT) Received: from mail-red.research.att.com ([192.20.225.110]) by janus; Tue, 01 Oct 2002 08:00:07 -0400 (EDT) Received: (from postfixfilter@localhost) by mail-red.research.att.com (8.11.6/8.11.6) id g911pnH03560 for [email protected]; Mon, 30 Sep 2002 21:51:49 -0400 X-Authentication-Warning: mail-red.research.att.com: postfixfilter set sender to [email protected] using -f Received: from igw3.watson.ibm.com (unknown [198.81.209.18]) by mail-red.research.att.com (Postfix) with ESMTP id 003B91AB4FC for <[email protected]>; Mon, 30 Sep 2002 21:51:49 -0400 (EDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g911pFf125388; Mon, 30 Sep 2002 21:51:15 -0400 Received: from DOUGLIS (DOUGLIS.watson.ibm.com [9.2.10.111]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with SMTP id g911pF050208; Mon, 30 Sep 2002 21:51:15 -0400 Message-ID: <[email protected]> From: "Fred Douglis" <[email protected]> To: "Kobus van der Merwe" <[email protected]> Cc: <[email protected]> Subject: Re: draft-ietf-cdi-threat-00.txt Date: Mon, 30 Sep 2002 21:50:20 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01C268CB.5F186800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-1.6 required=5.0 tests=COPYRIGHT_CLAIMED version=2.20 This is a multi-part message in MIME format. ------=_NextPart_000_0042_01C268CB.5F186800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Draft looks good overall. Some overall comments, then an edited version cleaning up some typos and confusing phrases here and there. Most important observation: the I-D purports to be about threats, yet mentions several times unintentional actions. To me, those are not security threats. For instance, someone who misconfigures the request routing unintentional may break things, but it's not a threat to security. Perhaps the title and abstract should change from "threat" models to "failure" models and emphasize that most of these, but not all, are from explicit intentional threats. Of course, some "threats" are not actually "failures" so perhaps that doesn't quite work... maybe "threat and failure"?? Terminology: "CDN" crept in there a few times. Should all references to "CDN" be "CN"? (I changed these in my copy.) "Resultant" appeared here and there. I had to look it up to be sure it was a word. It is, and basically means "resulting". Why use such an obscure word instead? Is there a distinction in meaning? 3.2.4.1 talks about a CN exposing passwords & credit card numbers. This seems to be supposing a lot -- are there CNs today that actually see credit card numbers? 3.2.7.2 refers to a location of a surrogate "generally transparent to the client". To me "transparent" means it is NOT seen, but it sounds here like you mean "visible", the opposite. No? In Sec. 5 it is "recommended not to send passwords in the clear" -- why not required? Fred ------------------ INTERNET-DRAFT draft-ietf-cdi-threat-00.txt Page 1 Network Working Group L. Amini Internet-Draft IBM Research Expires: March 31, 2003 A. Barbir Nortel Networks Oskar Batuner Independent consultant M. Day Cisco Systems O. Spatscheck AT&T Labs Kobus van der Merwe AT&T Labs 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 progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 31, 2003 Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. INTERNET-DRAFT draft-ietf-cdi-threat-00.txt Page 2 Security Threats for Content Internetworking draft-ietf-cdi-threat-00.txt Abstract Content internetworking (also referred to as content distribution internetworking, or CDI) is the technology for interconnecting content networks. The CDI model allows for interconnecting various Content Networks. The internetworking task requires request routing and content distribution protocols. This document investigates the security risks and threats associated with the content internetworking. Proposed remedies are viewed not as design recommendations but more as illustrations of the nature of threats. 1. Introduction Content internetworking (CDI) combines the resources of multiple content networks (CN) to increase their scale and reach. At the core of CDI are a request routing system and a distribution system. The request-routing system (RRS) directs client requests to surrogates and/or CNs that can best service the request. The internetworking of CNs is performed through Content Internetworking Gateway (CIG). The internetworking distribution system is responsible for moving content from one Distribution CN to another Distribution CN. Finally, the accounting infrastructure tracks and collects data on request-routing, distribution, and delivery functions within the CN. The details of the CDI model can be found in [1]. The use of CDI - as any new mechanism - introduces new security risks and threats to the internetworked CNs. Some of these threats are specific to the CDI model, some are inherited from the CN systems. This document covers both new and inherited threats with distinctions made where appropriate. The security risks within CDI can be classified along various dimensions including: - the source of the threat ("insider" versus "outsider"), - the level at which the attack occurs (network-level attack versus application-level attack), - the type of harm that results from an attack (harm to content, harm to identity, harm to finances). INTERNET-DRAFT draft-ietf-cdi-threat-00.txt Page 3 - the elements of the architecture attacked (e.g., the Distribution System, the Request Routing System, the Accounting System, the clients, or publishers) All of these dimensions are considered in this document (some in greater detail) to develop a complete view of the threat model for content internetworking. However, this document focuses only on those threats specific to the content internetworking model. It does not consider, for example, the following issues: - The security risks within an individual CN, such as denial of service attacks on individual surrogates, are beyond the scope of this document. - Content security issues, such as the integrity of transformations or adaptations performed on content, are outside the scope of the current work. - This document does not specify or recommend any particular solutions. In some cases however, potential threat mitigation steps are given to help illustrate a given threat. The remainder of this document is organized as follows. We begin by describing the CDI Trust Model, and distinguish between "insider" and "outsider" attacks. Next, we broadly classify attacks as occurring at the network, content internetworking, or application level, and detail the resultant type of harm. We refine this list by detailing how the attacks might be perpetrated on specific components of the CDI architecture, and potential mitigation steps. 1.1 Conventions used in this document Key terms in ALL CAPS, except those qualified with explicit citations, are defined in [1]. 2. Content Internetworking Trust model Relationships between CN's in the CDI model can be decomposed into relationships between individual pairs comprising a CONTENT SOURCE and a CONTENT DESTINATION. The ORIGIN refers to the point at which CONTENT enters the CDI model, and therefore is a specific type of CONTENT SOURCE. The trust model utilized within CDI is based on a transitive trust between a CONTENT SOURCE and a CONTENT DESTINATION. The transitive nature of the trust originates from the need of an ORIGIN to rely on one or more CONTENT SOURCE - CONTENT DESTINATION INTERNET-DRAFT draft-ietf-cdi-threat-00.txt Page 4 pairs to deliver CONTENT to CLIENTs on the ORIGIN's behalf. The trust model involves the following parties in trust relationships: - CONTENT SOURCE and CONTENT DESTINATION - CONTENT SOURCE and CLIENT - CONTENT DESTINATION and CLIENT We will use the term TRUSTED PARTY to refer to a party involved in a trust relationship. We begin by classifying security risks into two main categories: threats from "insiders," and threats from "outsiders." Outsiders are those entities that have not established a trust relationship within the content internetworking system. Insiders are TRUSTED PARTIES that are participating in a trust relationship within the content internetworking system. Threats from within the system may be intentional or unintentional. Intentional threats refer to the ability of a TRUSTED PARTY of a CDI relationship to mislead, or harm, the party with which it has a trust relationship. For example, the TRUSTED PARTY, a CONTENT DESTINATION, might misrepresent quality or quantity of the service provided to the trusting party, a CONTENT SOURCE. This is distinct from the case when a TRUSTED PARTY's system is compromised by an outsider, which is covered as an "outsider" threat. Unintentional threats refer to the ability of a TRUSTED PARTY, through improper implementation or configuration resulting in bad system behavior, to mislead or harm the party with which it has a trust relationship. Content internetworking allows for relationships whose terms and conditions are partially or completely established outside the context of the content internetworking protocols, and refers to these relationships as NEGOTIATED RELATIONSHIPS. Just as trust relationships established completely within the context of content internetworking protocols, NEGOTIATED RELATIONSHIPS can result in intentional or unintentional threats. Threats from outside the system, or outsiders, may also be intentional or unintentional. Since unintentional threats from outsiders do not rely on the trust model, and are not specific to the content internetworking model, this document will consider only outsider threats that are intentionally perpetrated. In this document, we will focus on intentional and unintentional threats from within the system, and intentional threats from outside the system. INTERNET-DRAFT draft-ietf-cdi-threat-00.txt Page 5 3. Threat classification by architectural level In this section, we broadly classify threats according the architectural level -- network, content internetworking, or application -- at which the threat occurs. We refer to threats exploiting design or implementation weaknesses of internetworking and transport protocols (i.e., layer 3 and below of the TCP/IP protocol suite) as network-level threats. We refer to threats exploiting weaknesses in content internetworking protocols as content internetworking-level threats. We include in content internetworking level attacks, threats against CONTENT distributed using CDI-specific protocols. Finally, we refer to threats to applications that utilize a content internetworking system as application-level threats. Where appropriate, the type of harm that can result from an attack is provided to show the complex interaction between different threats and/or attacks. For example, harm to content in the form of content degradation or content substitution might harm the finances of the content provider, which might in turn harm the finances of the service provider. A denial of service attack or theft of identity might have a similar effect on parties involved with CDI. 3.1 Network-level Threats. The content internetworking model comprises CONTENT NETWORKs, which in turn comprise CONTENT NETWORK ELEMENTS. A CONTENT NETWORK ELEMENT is a network device that performs at least some of its processing by examining CONTENT-related parts of network messages. Examples of CONTENT NETWORK ELEMENTS include CONTENT INTERNETWORKING GATEWAYs (CIG) and SURROGATES. In IP-based networks, a CONTENT NETWORK ELEMENT is a device whose processing depends on examining some or all of an IP packet's body. As such, CONTENT NETWORK ELEMENTs are vulnerable to many types of network-level attacks. Examples of TCP/IP attacks include IP spoofing and session stealing. The CERT Coordination Center [2] maintains an extensive repository of Internet Security vulnerabilities. Harm specific to CONTENT NETWORK ELEMENTS, such as a CIG, achievable by hijacking a TCP/IP session includes the ability of outsiders to inject believable content distribution and request routing messages into the communication between CIG peers. This may lead to the injection of bogus content or bogus routing information that may lead to the breaking of the peer-to-peer connection. Any break in the INTERNET-DRAFT draft-ietf-cdi-threat-00.txt Page 6 peer-to-peer communication can have a ripple effect on the request routing system or the distribution system that could lead to disrupted services to end users. CONTENT NETWORK ELEMENTS are also susceptible to a number of security threats commonly associated with network infrastructure. These threats include snooping, denial of service, sabotage, vandalism, industrial espionage, theft of service and inadequate system configuration that leaves unneeded ports and services open to the public. 3.2 . Content Internetworking-level Threats. Content internetworking-level threats generally belong to one or more of the following categories: - denial of service - content distortion - threats to identity - threats to privacy - content theft - security threats - threats to finances In the following subsections we elaborate on these threats and potential resultant harm. 3.2.1 Denial of service threats. At the Content Internetworking-level, a denial of service (DoS) threat can be perpetrated on a number of levels. For example, an attack could be launched: - specifically against a CONTENT SOURCE, thereby preventing any distribution from taking place - against a content set, causing all CNs servicing this content set to be affected. - against all SURROGATES of a specific CN. A CONTENT SOURCE distributing streaming content, due to its high bandwidth nature and, in the case of live streaming, limited injection points, are likely to be especially vulnerable to DoS threats. Misuse of a CN may make its facilities unavailable or available only at reduced functionality. Denial of service attacks can be targeted at a CN accounting system, distribution system, or request-routing system. INTERNET-DRAFT draft-ietf-cdi-threat-00.txt Page 7 3.2.1.1. "Complexity threat": both CN and CDI introduce many components and complex infrastructure. Malfunctioning of these components and infrastructure may result in DoS. 3.2.1.2. Misconfigured request routing (unintentional or malicious) may cause request loss or looping and result in DoS. 3.2.1.3. Conflicts between request routing and accounting mechanisms may create a DoS threat: a CN may refuse to deliver content because the authorization system treats a valid request as invalid (not coming from an authorized customer). 3.2.1.4. By redistributing the load between CNs CDI may cause DoS by unintentionally overloading one of CNs. Usually CNs have a specific (proprietary) adaptive mechanisms for load balancing. CDI load balancing mechanisms may be inadequate/malfunction or be incompatible with corresponding CN load balancing. 3.2.1.5. A CN may cause problems in another CN by sending (unintentionally or with malicious intent) more content than advertised capacity permits. 3.2.1.6. Corruption (intentional or non intentional) of security related metadata (authentication data) might result in DoS: CN or CDI may refuse to perform a legitimate service. 3.2.1.7. False advertisement (unintentional or malicious) of nonexistent distribution/coverage capacity may result in failure of several CNs. Same problems may result when advertisement and usage policy do not reflect dynamic conditions. 3.2.1.8. Incompatible request routing systems may cause problems resulting in DoS. 3.2.1.9. Peering agreements may be vital for CN functionality. This makes peering reliability a security issue. CIGs (distribution CIG and request routing CIG) may introduce a single point of failure. Attack on (or malfunctioning of) a CIG may result in system disintegration and DoS for both CNs. 3.2.2 Content distortion threats. 3.2.2.1 An attacker may cause a CN to advertise bogus content, e.g. replacing proper content with bogus content either at the injection point of the system (CN or CDI) or inside elements of the system (e.g. surrogates inside the CN). INTERNET-DRAFT draft-ietf-cdi-threat-00.txt Page 8 3.2.2.2. A CN may provide bogus information, e.g. a rogue "CN" inserting itself in the distribution path between two CNs to monitor and/or modify the content that they exchange. 3.2.2.3. A CN may advertise the availability of content which it doesn't have and can not distribute. This attack can be the result of a malicious CIG taking over the identity of a CIG to be able to inject bogus info into system, or a CIG that is compromised. 3.2.3 Threats to user identity. Identity/authentication threats may result from third party getting access to authentication data of end user or system component (surrogate, CIG) and this data permits unauthorized actions to be performed. Note that the last condition is essential: interception of session initiation packets of replay-resistant secure authentication protocol does not create such a threat. Storage of security related data (user identities, passwords, etc.) creates an additional security threat. 3.2.4 Threats to privacy. Privacy threats may result in personal user information made available to third party without a user's consent. 3.2.4.1. A CN may inadvertently or maliciously expose private information (passwords, buying patterns, page views, and credit card numbers) as it collects it and transits from surrogate to origin and/or publisher. 3.2.4.2. Accounting information transfer may jeopardize privacy. 3.2.4.3. Privacy threats may result from differences in privacy policy of Publisher, CN and CDI. 3.2.4.4. Privacy and security threats from crossing jurisdiction boundaries: transfer and storage of sensitive privacy-related data (accounting, logs), transfer and storage of (secure) content and distribution of content from a different jurisdiction may create a security threat due to different level of legal protection. 3.2.5. Legal threats: by extending activities through jurisdiction boundaries CN and CDI may unintentionally violate local regulations (privacy and security policies). 3.2.6 Content theft. Unauthorized access to non-public (secure or non-secure) content. For INTERNET-DRAFT draft-ietf-cdi-threat-00.txt Page 9 secure content such unauthorized access clearly violates intention of security system and usually constitutes a content theft (paid content, proprietary data). An example of unauthorized access to non-secure content is interception of form data in not-secure transmission or direct access to a URL that is not supposed to be publicly available. 3.2.7 Security threats 3.2.7.1 Unauthorized access to metadata that is not supposed to be publicly available. This may include access to logs and accounting data containing private user's information, access to configuration data that may be used to facilitate future attacks and so on. 3.2.7.2 Exposure of Security Settings: There may be risks that expose client's security settings when content is served from surrogates as opposed to origin servers. Since the location of the surrogate is generally transparent to the client, the client may be aware that its protections are no longer enforced. 3.2.7.3 Improper enforcement of Security Policy Policy information regarding security of the client may not be properly propagated when the requests are directed to surrogates in a CN that are different from the origin server. Client passwords and personal information may be less secure. 3.2.8. Improper Carriage of Security Policies Surrogate may not employ the same security policies and procedures as the origin server. This may expose the client private information to access by unauthorized entities. The same threat may also result if the legal jurisdiction of the surrogate is different from that of the origin. 3.2.8.1. Different implementation of security at Publisher, CN and CDI level may create security threats 3.2.8.2. Distribution of content from a different network location may create a security threat if client security policy depends on network location ("Internet Web Content Zone"). 3.2.8.3. Transfer and storage of secure content create additional security threats. 3.2.8.4. The process of propagation of security policy and security related data (user identities, passwords, etc.) creates security INTERNET-DRAFT draft-ietf-cdi-threat-00.txt Page 10 threats both at CN and CDI level. 3.2.9 Threats to finances Delivery of inaccurate accounting information or malicious distortion of this information may cause financial harm to all participating parties. 3.2.9.1 The client may be inappropriately charged for viewing content that was not successfully accessed or delivered according to some QoS criteria. 3.2.9.2 If a CN or Publisher is unable to collect or receive correct accounting information they may be unable to collect compensation for services. 3.3 Application-level threats. TBD (section should include attacks targeting applications that utilize the content internetworking system) 4. Threats against specific elements of the CDI architecture In this section, we refine the list of threats by detailing how the attacks might be perpetrated on specific components of the CDI architecture. This section is intended to be used input to specify the security requirements for the content distribution and request routing protocols. Along the dimension of threats against specific elements of the architecture, threats against the accounting system should also be noted. A detailed analysis of the threats against the accounting system can however only be done within the framework of a specific accounting system and is considered outside the scope of this document. 4.1 Threats to the Content Internetworking Gateway The CIG is the connecting point for the CNs that are participating in the CDI model. CIGs from various CNs establish peer-to-peer relationships in order to exchange content distribution and request routing information. Threats on the CIG can be perpetrated at all levels, the network, content internetworking, and application level. A CIG must be accessible at the network level from many other CIGs. The CIG is vulnerable to any of the network-level attacks specified in Section 3.1. The CIG is susceptible to network level INTERNET-DRAFT draft-ietf-cdi-threat-00.txt Page 11 attacks from outsiders, which may or may not be posing as the CIG of a TRUSTED PARTY, and from CIGs of TRUSTED PARTIES. 4.2 Threats to Distribution System Threats to distribution system from insiders can be intentional or the result of bad implementation. Outsiders can pose the same threats if they acquire access to the distribution system. The threats include: 4.2.1 Advertising of unavailable content. 4.2.3 Advertising of bad metrics that are associated with a given content. 4.2.4 Delivery of bad content to surrogates in the connected CN 4.2.5 Using badly formed messages for advertisements 4.3 Threats to Request Routing System Threats to the request routing system from insiders or outsiders include: 4.3.1 Advertising of wrong metrics to force unfair or inaccurate redirection to a given CN. 4.3.2 Redirection to a CN that does not have the content. 4.3.3 The introduction of loops in the requesting routing system. 4.3.4 Redirection to an inappropriate surrogate. 4.3.5 Forwarding request when no forwarding is appropriate. 4.3.6 Failing to forward requests when forwarding is appropriate. 4.3.7 Using badly formed messages for advertisements h) TBD 5. CDI Security Threat Mitigation The main security issues for the CDI model are focused on the Trust model. Insiders are TRUSTED PARTIES, while outsiders are not. Threats from outsiders are primarily at the network level. There are well known solutions to network-level threats that are practiced in the industry. In this work, it is recommended that the security of the CONTENT NETWORK ELEMENTs at the network level be enhanced using standard techniques and methods that minimize the risks of IP spoofing, snooping, denial of service and session stealing. Threats at the content internetworking and application levels can be mitigated by using strong authentication and encryption techniques. Therefore, there may be the need to make strong authentication and encryption a requirement for the CDI model. IPSec INTERNET-DRAFT draft-ietf-cdi-threat-00.txt Page 12 and TLS are solutions for this requirement. Regardless of the choice of the protocol, the solution must scale to accommodate large number of interconnected CNs. Furthermore, it is recommended not to send passwords in the clear. To mitigate threats from insiders CDI must implement appropriate monitoring, signaling, logging, dynamic authorization and verification mechanisms. The following sections provide more detailed guidelines for development of request routing and distribution protocols for content internetworking. 5.1 Treatment of malformed messages Malformed message can be the result of bad implementation or a consequence of an outside attack on a given CN whereby, the attacker gains access of the peering system. A Malformed messages is a message that does not comply with the message format for the distribution (or request routing) protocol. A malformed message may be a message that has wrong content attributes in it or wrong IP footprint. A malformed IP or IPSec packet is not considered a malformed message. In the event that a CN detect malformed messages terminating the session appears to be the only safe way to handle it. Terminating a session does not mean terminating the peering relationship. The session can be restarted after termination. If the problem of malformed messages persists, the interconnected CNs must verify the cause of the problem and proceed with a solution. The treatment of malformed messages is different than the case where a peer intentionally or unintentionally sends incorrect advertisements which might lead to incorrect selections. For example, a CN might incorrectly advertise low load, low cost and good coverage and therefore attract a large proportion of traffic. This problem can be somewhat mitigated through filtering of advertisements and local policies but ultimately comes down to a trust relationship between peers. 5.2 General Distribution and Request Routing Protocol Requirements Based on the security threats that are faced by other peer-to-peer based protocols such as BGP, this section provide some guidelines that should be used during the design of the request routing and content distribution protocols. 5.2.1 There should be a mechanism that provides strong protection of the integrity, freshness and source authenticity of the messages in INTERNET-DRAFT draft-ietf-cdi-threat-00.txt Page 13 the protocol. Techniques such as digital signature may be used. 5.2.2 There should be a mechanism to validate the authenticity of a CN_Path value. 5.2.3 There should be a mechanism to use IP-level protection that can be used to provide connectionless integrity, data origin authentication, and secure authentication. 5.2.4 There should be a mechanism to protect the peer-to-peer connection by applying cryptographic protection at the TCP level to provide connectionless integrity and data origin authentication. References [1] Day, M., Cain, B. and G. Tomlinson, "A Model for Content Distribution Internetworking", January 2001. [2] CERT Coordination Center (CERT/CC). http://www.cert.org/nav/index_main.html ------=_NextPart_000_0042_01C268CB.5F186800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff><FONT face=3DHelv size=3D2> <P>Draft looks good overall. Some overall comments, then an edited = version=20 cleaning up some typos and confusing phrases here and there.</P> <P><FONT face=3DArial>Most important observation: the I-D purports to be = about=20 threats, yet mentions several times unintentional actions. To me, = those=20 are not security threats. For instance, someone who misconfigures = the=20 request routing unintentional may break things, but it's not a threat to = security. Perhaps the title and abstract should change from = "threat"=20 models to "failure" models and emphasize that most of these, but not = all, are=20 from explicit intentional threats. Of course, some "threats" are = not=20 actually "failures" so perhaps that doesn't quite work... maybe "threat = and=20 failure"??</FONT></P> <P><FONT face=3DArial>Terminology: "CDN" crept in there a few = times. Should=20 all references to "CDN" be "CN"? (I changed these in my = copy.) =20 "Resultant" appeared here and there. I had to look it up to be = sure it was=20 a word. It is, and basically means "resulting". Why use such = an=20 obscure word instead? Is there a distinction in meaning? = </FONT></P> <P><FONT face=3DArial>3.2.4.1 talks about a CN exposing passwords & = credit=20 card numbers. This seems to be supposing a lot -- are there CNs = today that=20 actually see credit card numbers? </FONT></P> <P><FONT face=3DArial>3.2.7.2 refers to a location of a surrogate = "generally=20 transparent to the client". To me "transparent" means it is NOT = seen, but=20 it sounds here like you mean "visible", the opposite. = No?</FONT></P> <P><FONT face=3DArial>In Sec. 5 it is "recommended not to send passwords = in the=20 clear" -- why not required?</FONT></P> <P><FONT face=3DArial>Fred</FONT></P> <P><FONT face=3DArial>------------------</FONT></P> <P><FONT face=3DArial>INTERNET-DRAFT =20 draft-ietf-cdi-threat-00.txt Page = 1</FONT></P><FONT=20 face=3DArial> <P><BR>Network Working=20 Group &n= bsp; &nb= sp; =20 L.=20 Amini<BR>Internet-Draft &n= bsp; &nb= sp; =20 IBM Research<BR>Expires: March 31, 2003<BR>A. Barbir<BR>Nortel = Networks</P> <P>Oskar Batuner<BR>Independent consultant</P> <P>M. Day<BR>Cisco Systems</P> <P>O. Spatscheck<BR>AT&T Labs</P> <P>Kobus van der Merwe<BR>AT&T Labs</P> <P> </P> <P><BR>Status of this Memo</P> <P>This document is an Internet-Draft and is in full conformance with=20 all<BR>provisions of Section 10 of RFC2026.</P> <P>Internet-Drafts are working documents of the Internet Engineering=20 Task<BR>Force (IETF), its areas, and its working groups. Note that=20 other<BR>groups may also distribute working documents as = Internet-Drafts.</P> <P>Internet-Drafts are draft documents valid for a maximum of six = months<BR>and=20 may be updated, replaced, or obsoleted by other documents at = any<BR>time. It is=20 inappropriate to use Internet-Drafts as reference material<BR>or to cite = them=20 other than as "work in progress."</P> <P>The list of current Internet-Drafts can be accessed at<BR><A=20 href=3D"http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/i= etf/1id-abstracts.txt</A>.</P> <P>The list of Internet-Draft Shadow Directories can be accessed = at<BR><A=20 href=3D"http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html<= /A>.</P> <P>This Internet-Draft will expire on March 31, 2003 Copyright = Notice</P> <P>Copyright (C) The Internet Society (2000). All Rights Reserved.</P> <P> </P> <P> </P> <P><BR>INTERNET-DRAFT =20 draft-ietf-cdi-threat-00.txt Page 2</P> <P> </P> <P> </P> <P><BR>Security Threats for Content=20 Internetworking<BR>draft-ietf-cdi-threat-00.txt</P> <P>Abstract</P> <P>Content internetworking (also referred to as content=20 distribution<BR>internetworking, or CDI) is the technology for = interconnecting=20 content<BR>networks. The CDI model allows for interconnecting = various=20 Content<BR>Networks. The internetworking task requires request = routing=20 and<BR>content distribution protocols. This document investigates=20 the<BR>security risks and threats associated with the=20 content<BR>internetworking. Proposed remedies are viewed not as=20 design<BR>recommendations but more as illustrations of the nature of=20 threats.</P> <P>1. Introduction</P> <P>Content internetworking (CDI) combines the resources of = multiple<BR>content=20 networks (CN) to increase their scale and reach. At the core<BR>of CDI = are a=20 request routing system and a distribution system. The<BR>request-routing = system=20 (RRS) directs client requests to surrogates<BR>and/or CNs that can best = service=20 the request. The internetworking of<BR>CNs is performed through Content=20 Internetworking Gateway (CIG). The<BR>internetworking distribution = system is=20 responsible for moving content<BR>from one Distribution CN to another=20 Distribution CN. Finally, the<BR>accounting infrastructure tracks = and=20 collects data on<BR>request-routing, distribution, and delivery = functions within=20 the CN.<BR>The details of the CDI model can be found in [1].</P> <P>The use of CDI - as any new mechanism - introduces new security = risks<BR>and threats to the internetworked CNs. Some of these threats=20 are<BR>specific to the CDI model, some are inherited from the CN=20 systems.<BR>This document covers both new and inherited threats with=20 distinctions<BR>made where appropriate.</P> <P>The security risks within CDI can be classified along=20 various<BR>dimensions including:</P> <P>- the source of the threat ("insider" versus "outsider"),</P> <P>- the level at which the attack occurs (network-level attack=20 versus<BR>application-level attack),</P> <P>- the type of harm that results from an attack (harm to content, = harm<BR>to=20 identity, harm to finances).</P> <P><BR>INTERNET-DRAFT =20 draft-ietf-cdi-threat-00.txt Page 3</P> <P> </P> <P>- the elements of the architecture attacked (e.g., the=20 Distribution<BR>System, the Request Routing System, the Accounting = System,=20 the<BR>clients, or publishers)</P> <P>All of these dimensions are considered in this document (some = in<BR>greater=20 detail) to develop a complete view of the threat model = for<BR>content=20 internetworking. However, this document focuses only on = those<BR>threats=20 specific to the content internetworking model. It does = not<BR>consider,=20 for example, the following issues:</P> <P>- The security risks within an individual CN, such as denial = of<BR>service=20 attacks on individual surrogates, are beyond the scope of<BR>this = document.</P> <P>- Content security issues, such as the integrity of = transformations<BR>or=20 adaptations performed on content, are outside the scope of = the<BR>current=20 work.</P> <P>- This document does not specify or recommend any=20 particular<BR>solutions. In some cases however, potential threat=20 mitigation steps<BR>are given to help illustrate a given threat.</P> <P><BR>The remainder of this document is organized as follows. We = begin=20 by<BR>describing the CDI Trust Model, and distinguish between = "insider" =20 and<BR>"outsider" attacks. Next, we broadly classify attacks = as =20 occurring<BR>at the network, content internetworking, or application = level,=20 and<BR>detail the resultant type of harm. We refine this = list by=20 detailing<BR>how the attacks might be perpetrated on specific = components =20 of the<BR>CDI architecture, and potential mitigation steps.</P> <P><BR>1.1 Conventions used in this document</P> <P>Key terms in ALL CAPS, except those qualified with = explicit<BR>citations, are=20 defined in [1].</P> <P>2. Content Internetworking Trust model</P> <P>Relationships between CN's in the CDI model can be decomposed=20 into<BR>relationships between individual pairs comprising a CONTENT = SOURCE=20 and<BR>a CONTENT DESTINATION. The ORIGIN refers to the point at=20 which<BR>CONTENT enters the CDI model, and therefore is a specific = type=20 of<BR>CONTENT SOURCE. The trust model utilized within = CDI is=20 based on a<BR>transitive trust between a CONTENT SOURCE and a = CONTENT=20 DESTINATION.<BR>The transitive nature of the trust originates from = the=20 need of an<BR>ORIGIN to rely on one or more CONTENT SOURCE - = CONTENT=20 DESTINATION</P> <P><BR>INTERNET-DRAFT =20 draft-ietf-cdi-threat-00.txt Page 4</P> <P><BR>pairs to deliver CONTENT to CLIENTs on the ORIGIN's behalf.</P> <P>The trust model involves the following parties in trust = relationships:<BR>-=20 CONTENT SOURCE and CONTENT DESTINATION<BR>- CONTENT SOURCE and = CLIENT<BR>-=20 CONTENT DESTINATION and CLIENT</P> <P>We will use the term TRUSTED PARTY to refer to a party involved in=20 a<BR>trust relationship.</P> <P>We begin by classifying security risks into two main = categories:<BR>threats=20 from "insiders," and threats from "outsiders." Outsiders=20 are<BR>those entities that have not established a trust = relationship=20 within<BR>the content internetworking system. Insiders are = TRUSTED=20 PARTIES<BR>that are participating in a trust relationship within = the=20 content<BR>internetworking system.</P> <P>Threats from within the system may be intentional or=20 unintentional.<BR>Intentional threats refer to the ability of a TRUSTED = PARTY of=20 a CDI<BR>relationship to mislead, or harm, the party with which it has a = trust<BR>relationship. For example, the TRUSTED PARTY, a CONTENT=20 DESTINATION,<BR>might misrepresent quality or quantity of the = service=20 provided to the<BR>trusting party, a CONTENT SOURCE. This is = distinct from=20 the case when<BR>a TRUSTED PARTY's system is compromised by an = outsider,=20 which is<BR>covered as an "outsider" threat.</P> <P>Unintentional threats refer to the ability of a TRUSTED PARTY,=20 through<BR>improper implementation or configuration resulting in bad=20 system<BR>behavior, to mislead or harm the party with which it has = a=20 trust<BR>relationship.</P> <P>Content internetworking allows for relationships whose terms=20 and<BR>conditions are partially or completely established outside=20 the<BR>context of the content internetworking protocols, and = refers to=20 these<BR>relationships as NEGOTIATED RELATIONSHIPS. Just as=20 trust<BR>relationships established completely within the context = of=20 content<BR>internetworking protocols, NEGOTIATED RELATIONSHIPS can = result=20 in<BR>intentional or unintentional threats.</P> <P>Threats from outside the system, or outsiders, may also be = intentional<BR>or=20 unintentional. Since unintentional threats from outsiders do = not<BR>rely=20 on the trust model, and are not specific to the = content<BR>internetworking=20 model, this document will consider only outsider<BR>threats that are=20 intentionally perpetrated.</P> <P>In this document, we will focus on intentional and = unintentional<BR>threats=20 from within the system, and intentional threats from = outside<BR>the=20 system.</P> <P><BR>INTERNET-DRAFT =20 draft-ietf-cdi-threat-00.txt Page 5</P> <P> </P> <P><BR>3. Threat classification by architectural level</P> <P>In this section, we broadly classify threats according = the<BR>architectural=20 level -- network, content internetworking, or<BR>application -- at = which=20 the threat occurs. We refer to threats<BR>exploiting design = or =20 implementation weaknesses of internetworking and<BR>transport protocols=20 (i.e., layer 3 and below of the TCP/IP protocol<BR>suite) as = network-level=20 threats. We refer to threats exploiting<BR>weaknesses in = content=20 internetworking protocols as content<BR>internetworking-level = threats. We=20 include in content internetworking<BR>level attacks, threats against = CONTENT=20 distributed using CDI-specific<BR>protocols. Finally, we refer to = threats=20 to applications that utilize<BR>a content internetworking system = as=20 application-level threats.</P> <P>Where appropriate, the type of harm that can result from an attack=20 is<BR>provided to show the complex interaction between different=20 threats<BR>and/or attacks. For example, harm to content in the form of=20 content<BR>degradation or content substitution might harm the = finances of=20 the<BR>content provider, which might in turn harm the finances of the=20 service<BR>provider. A denial of service attack or theft of identity = might have=20 a<BR>similar effect on parties involved with CDI.</P> <P><BR>3.1 Network-level Threats.</P> <P>The content internetworking model comprises CONTENT NETWORKs, which=20 in<BR>turn comprise CONTENT NETWORK ELEMENTS. A CONTENT = NETWORK=20 ELEMENT is<BR>a network device that performs at least some of its=20 processing by<BR>examining CONTENT-related parts of network=20 messages. Examples of<BR>CONTENT NETWORK ELEMENTS include = CONTENT=20 INTERNETWORKING GATEWAYs<BR>(CIG) and SURROGATES.</P> <P>In IP-based networks, a CONTENT NETWORK ELEMENT is a device=20 whose<BR>processing depends on examining some or all of an IP = packet's=20 body.<BR>As such, CONTENT NETWORK ELEMENTs are vulnerable to many = types=20 of<BR>network-level attacks. Examples of TCP/IP = attacks=20 include IP<BR>spoofing and session stealing. The CERT = Coordination=20 Center [2]<BR>maintains an extensive repository of Internet =20 Security<BR>vulnerabilities.</P> <P>Harm specific to CONTENT NETWORK ELEMENTS, such as a CIG,=20 achievable<BR>by hijacking a TCP/IP session includes the ability = of=20 outsiders to<BR>inject believable content distribution and = request=20 routing messages<BR>into the communication between CIG peers. This = may=20 lead to the<BR>injection of bogus content or bogus routing = information=20 that may lead<BR>to the breaking of the peer-to-peer = connection. Any=20 break in the</P> <P><BR>INTERNET-DRAFT =20 draft-ietf-cdi-threat-00.txt Page 6</P> <P><BR>peer-to-peer communication can have a ripple effect = on the=20 request<BR>routing system or the distribution system that = could lead=20 to<BR>disrupted services to end users.</P> <P>CONTENT NETWORK ELEMENTS are also susceptible to a number of=20 security<BR>threats commonly associated with network = infrastructure.=20 These<BR>threats include snooping, denial of service, sabotage,=20 vandalism,<BR>industrial espionage, theft of service and = inadequate=20 system<BR>configuration that leaves unneeded ports and services = open to=20 the<BR>public.</P> <P>3.2 . Content Internetworking-level Threats.</P> <P>Content internetworking-level threats generally belong to one or more = of=20 the<BR>following categories:</P> <P>- denial of service<BR>- content distortion<BR>- threats to = identity<BR>-=20 threats to privacy<BR>- content theft<BR>- security threats<BR>- threats = to=20 finances</P> <P>In the following subsections we elaborate on these threats and=20 potential<BR>resultant harm.</P> <P>3.2.1 Denial of service threats.</P> <P>At the Content Internetworking-level, a denial of service (DoS) = threat<BR>can=20 be perpetrated on a number of levels. For example, an=20 attack<BR>could be launched:</P> <P>- specifically against a CONTENT SOURCE, thereby preventing any=20 distribution<BR>from taking place<BR>- against a content set, causing = all CNs=20 servicing this content set to be<BR>affected.<BR>- against all = SURROGATES of a=20 specific CN.</P> <P>A CONTENT SOURCE distributing streaming content, due to its=20 high<BR>bandwidth nature and, in the case of live streaming,=20 limited<BR>injection points, are likely to be especially = vulnerable to=20 DoS<BR>threats.</P> <P>Misuse of a CN may make its facilities unavailable or available=20 only<BR>at reduced functionality. Denial of service attacks can be = targeted<BR>at a CN accounting system, distribution system, or=20 request-routing<BR>system.</P> <P><BR>INTERNET-DRAFT =20 draft-ietf-cdi-threat-00.txt Page 7</P> <P> </P> <P>3.2.1.1. "Complexity threat": both CN and CDI introduce = many<BR>components=20 and complex infrastructure. Malfunctioning of these<BR>components = and=20 infrastructure may result in DoS.</P> <P>3.2.1.2. Misconfigured request routing (unintentional or = malicious)<BR>may=20 cause request loss or looping and result in DoS.</P> <P>3.2.1.3. Conflicts between request routing and accounting = mechanisms<BR>may=20 create a DoS threat: a CN may refuse to deliver content = because<BR>the=20 authorization system treats a valid request as invalid = (not<BR>coming from=20 an authorized customer).</P> <P>3.2.1.4. By redistributing the load between CNs CDI may cause DoS=20 by<BR>unintentionally overloading one of CNs. Usually CNs have a=20 specific<BR>(proprietary) adaptive mechanisms for load balancing. = CDI=20 load<BR>balancing mechanisms may be inadequate/malfunction or be=20 incompatible<BR>with corresponding CN load balancing.</P> <P>3.2.1.5. A CN may cause problems in another CN by = sending<BR>(unintentionally=20 or with malicious intent) more content than<BR>advertised capacity = permits.</P> <P>3.2.1.6. Corruption (intentional or non intentional) of = security<BR>related=20 metadata (authentication data) might result in DoS: CN or = CDI<BR>may=20 refuse to perform a legitimate service.</P> <P>3.2.1.7. False advertisement (unintentional or malicious)=20 of<BR>nonexistent distribution/coverage capacity may result in = failure=20 of<BR>several CNs. Same problems may result when advertisement and = usage<BR>policy do not reflect dynamic conditions.</P> <P>3.2.1.8. Incompatible request routing systems may cause = problems<BR>resulting=20 in DoS.</P> <P>3.2.1.9. Peering agreements may be vital for CN functionality.=20 This<BR>makes peering reliability a security issue. CIGs = (distribution CIG=20 and<BR>request routing CIG) may introduce a single point of = failure.=20 Attack<BR>on (or malfunctioning of) a CIG may result in system=20 disintegration<BR>and DoS for both CNs.</P> <P><BR>3.2.2 Content distortion threats.</P> <P>3.2.2.1 An attacker may cause a CN to advertise bogus = content,<BR>e.g.=20 replacing proper content with bogus content either at = the<BR>injection=20 point of the system (CN or CDI) or inside elements of = the<BR>system (e.g.=20 surrogates inside the CN).</P> <P><BR>INTERNET-DRAFT =20 draft-ietf-cdi-threat-00.txt Page 8</P> <P> </P> <P>3.2.2.2. A CN may provide bogus information, e.g. a rogue = "CN"<BR>inserting=20 itself in the distribution path between two CNs to = monitor<BR>and/or=20 modify the content that they exchange.</P> <P>3.2.2.3. A CN may advertise the availability of content which = it<BR>doesn't=20 have and can not distribute. This attack can be the result<BR>of a = malicious CIG taking over the identity of a CIG to be able = to<BR>inject=20 bogus info into system, or a CIG that is compromised.</P> <P>3.2.3 Threats to user identity.</P> <P>Identity/authentication threats may result from third party = getting<BR>access=20 to authentication data of end user or system component<BR>(surrogate, = CIG) and=20 this data permits unauthorized actions to be<BR>performed. Note = that the=20 last condition is essential: interception of<BR>session initiation = packets of=20 replay-resistant secure authentication<BR>protocol does not create such = a=20 threat.</P> <P>Storage of security related data (user identities, passwords,=20 etc.)<BR>creates an additional security threat.</P> <P>3.2.4 Threats to privacy. Privacy threats may result in = personal=20 user<BR>information made available to third party without a user's = consent.</P> <P>3.2.4.1. A CN may inadvertently or maliciously expose =20 private<BR>information (passwords, buying patterns, page views, and = credit=20 card<BR>numbers) as it collects it and transits from surrogate to=20 origin<BR>and/or publisher.</P> <P>3.2.4.2. Accounting information transfer may jeopardize privacy.</P> <P>3.2.4.3. Privacy threats may result from differences in privacy=20 policy<BR>of Publisher, CN and CDI.</P> <P>3.2.4.4. Privacy and security threats from crossing=20 jurisdiction<BR>boundaries: transfer and storage of sensitive=20 privacy-related data<BR>(accounting, logs), transfer and storage = of=20 (secure) content and<BR>distribution of content from a different=20 jurisdiction may create a<BR>security threat due to different = level of=20 legal protection.</P> <P>3.2.5. Legal threats: by extending activities through=20 jurisdiction<BR>boundaries CN and CDI may unintentionally violate = local=20 regulations<BR>(privacy and security policies).</P> <P>3.2.6 Content theft.</P> <P>Unauthorized access to non-public (secure or non-secure) content. = For</P> <P><BR>INTERNET-DRAFT =20 draft-ietf-cdi-threat-00.txt Page 9</P> <P><BR>secure content such unauthorized access clearly violates = intention=20 of<BR>security system and usually constitutes a content theft (paid=20 content,<BR>proprietary data).</P> <P>An example of unauthorized access to non-secure content = is<BR>interception of=20 form data in not-secure transmission or direct access<BR>to a URL that = is not=20 supposed to be publicly available.</P> <P>3.2.7 Security threats</P> <P>3.2.7.1 Unauthorized access to metadata that is not supposed to=20 be<BR>publicly available. This may include access to logs and = accounting<BR>data=20 containing private user's information, access to configuration<BR>data = that may=20 be used to facilitate future attacks and so on.</P> <P>3.2.7.2 Exposure of Security Settings: There may be risks that=20 expose<BR>client's security settings when content is served from=20 surrogates as<BR>opposed to origin servers. Since the location of = the=20 surrogate is<BR>generally transparent to the client, the client = may be=20 aware that its<BR>protections are no longer enforced.</P> <P>3.2.7.3 Improper enforcement of Security Policy</P> <P>Policy information regarding security of the client may not=20 be<BR>properly propagated when the requests are directed to = surrogates in=20 a<BR>CN that are different from the origin server. Client = passwords=20 and<BR>personal information may be less secure.</P> <P>3.2.8. Improper Carriage of Security Policies</P> <P>Surrogate may not employ the same security policies and procedures = as<BR>the=20 origin server. This may expose the client private information = to<BR>access=20 by unauthorized entities. The same threat may also result = if<BR>the legal=20 jurisdiction of the surrogate is different from that of = the<BR>origin.</P> <P>3.2.8.1. Different implementation of security at Publisher, CN = and<BR>CDI=20 level may create security threats</P> <P>3.2.8.2. Distribution of content from a different network location=20 may<BR>create a security threat if client security policy depends = on=20 network<BR>location ("Internet Web Content Zone").</P> <P>3.2.8.3. Transfer and storage of secure content create = additional<BR>security=20 threats.</P> <P>3.2.8.4. The process of propagation of security policy and=20 security<BR>related data (user identities, passwords, etc.) = creates=20 security</P> <P><BR>INTERNET-DRAFT =20 draft-ietf-cdi-threat-00.txt Page 10</P> <P><BR>threats both at CN and CDI level.</P> <P><BR>3.2.9 Threats to finances</P> <P>Delivery of inaccurate accounting information or malicious = distortion<BR>of=20 this information may cause financial harm to all=20 participating<BR>parties.</P> <P>3.2.9.1 The client may be inappropriately charged for viewing = content<BR>that=20 was not successfully accessed or delivered according to some=20 QoS<BR>criteria.</P> <P>3.2.9.2 If a CN or Publisher is unable to collect or receive=20 correct<BR>accounting information they may be unable to collect=20 compensation for<BR>services.</P> <P><BR>3.3 Application-level threats.</P> <P>TBD (section should include attacks targeting applications=20 that<BR>utilize the content internetworking system)</P> <P>4. Threats against specific elements of the CDI architecture</P> <P>In this section, we refine the list of threats by detailing how=20 the<BR>attacks might be perpetrated on specific components of the=20 CDI<BR>architecture. This section is intended to be used input to=20 specify<BR>the security requirements for the content distribution = and=20 request<BR>routing protocols.</P> <P>Along the dimension of threats against specific elements of=20 the<BR>architecture, threats against the accounting system should also=20 be<BR>noted. A detailed analysis of the threats against the = accounting<BR>system=20 can however only be done within the framework of a = specific<BR>accounting system=20 and is considered outside the scope of this document.</P> <P><BR>4.1 Threats to the Content Internetworking Gateway The CIG is=20 the<BR>connecting point for the CNs that are participating in the =20 CDI<BR>model. CIGs from various CNs establish peer-to-peer relationships = in<BR>order to exchange content distribution and request=20 routing<BR>information. Threats on the CIG can be perpetrated at = all=20 levels, the<BR>network, content internetworking, and application=20 level.</P> <P>A CIG must be accessible at the network level from many = other<BR>CIGs.=20 The CIG is vulnerable to any of the network-level = attacks<BR>specified in=20 Section 3.1. The CIG is susceptible to network level</P> <P><BR>INTERNET-DRAFT =20 draft-ietf-cdi-threat-00.txt Page 11</P> <P><BR>attacks from outsiders, which may or may not be posing as = the CIG=20 of<BR>a TRUSTED PARTY, and from CIGs of TRUSTED PARTIES.</P> <P><BR>4.2 Threats to Distribution System</P> <P>Threats to distribution system from insiders can be intentional or=20 the<BR>result of bad implementation. Outsiders can pose the same = threats=20 if<BR>they acquire access to the distribution system. The threats=20 include:</P> <P>4.2.1 Advertising of unavailable content.<BR>4.2.3 Advertising of bad = metrics=20 that are associated with a given content.<BR>4.2.4 Delivery of bad = content to=20 surrogates in the connected CN<BR>4.2.5 Using badly formed messages for=20 advertisements</P> <P><BR>4.3 Threats to Request Routing System</P> <P>Threats to the request routing system from insiders or outsiders = include:</P> <P>4.3.1 Advertising of wrong metrics to force unfair or=20 inaccurate<BR>redirection to a given CN.<BR>4.3.2 Redirection to a CN = that does=20 not have the content.<BR>4.3.3 The introduction of loops in the = requesting=20 routing system.<BR>4.3.4 Redirection to an inappropriate = surrogate.<BR>4.3.5=20 Forwarding request when no forwarding is appropriate.<BR>4.3.6 Failing = to=20 forward requests when forwarding is appropriate.<BR>4.3.7 Using badly = formed=20 messages for advertisements</P> <P>h) TBD</P> <P><BR>5. CDI Security Threat Mitigation</P> <P>The main security issues for the CDI model are focused on the=20 Trust<BR>model. Insiders are TRUSTED PARTIES, while outsiders are = not.</P> <P>Threats from outsiders are primarily at the network level. There = are<BR>well=20 known solutions to network-level threats that are practiced in<BR>the = industry.=20 In this work, it is recommended that the security of the<BR>CONTENT = NETWORK=20 ELEMENTs at the network level be enhanced using<BR>standard=20 techniques and methods that minimize the risks of IP<BR>spoofing, = snooping,=20 denial of service and session stealing.</P> <P>Threats at the content internetworking and application levels can=20 be<BR>mitigated by using strong authentication and=20 encryption<BR>techniques. Therefore, there may be the need to make = strong<BR>authentication and encryption a requirement for the CDI = model.=20 IPSec</P> <P><BR>INTERNET-DRAFT =20 draft-ietf-cdi-threat-00.txt Page 12</P> <P><BR>and TLS are solutions for this requirement. Regardless of = the=20 choice<BR>of the protocol, the solution must scale to accommodate = large =20 number<BR>of interconnected CNs. Furthermore, it is recommended = not to=20 send<BR>passwords in the clear.</P> <P>To mitigate threats from insiders CDI must implement=20 appropriate<BR>monitoring, signaling, logging, dynamic = authorization=20 and<BR>verification mechanisms. The following sections provide = more=20 detailed<BR>guidelines for development of request routing and=20 distribution<BR>protocols for content internetworking.</P> <P><BR>5.1 Treatment of malformed messages</P> <P>Malformed message can be the result of bad implementation or = a<BR>consequence=20 of an outside attack on a given CN whereby, the attacker<BR>gains = access=20 of the peering system. A Malformed messages is a message<BR>that = does not=20 comply with the message format for the distribution (or<BR>request = routing) protocol. A malformed message may be a message = that<BR>has wrong=20 content attributes in it or wrong IP footprint. A malformed<BR>IP = or IPSec=20 packet is not considered a malformed message.</P> <P>In the event that a CN detect malformed messages terminating = the<BR>session=20 appears to be the only safe way to handle it. Terminating = a<BR>session=20 does not mean terminating the peering relationship. The<BR>session = can be=20 restarted after termination. If the problem of<BR>malformed = messages=20 persists, the interconnected CNs must verify the<BR>cause of the = problem=20 and proceed with a solution.</P> <P>The treatment of malformed messages is different than the case where=20 a<BR>peer intentionally or unintentionally sends incorrect=20 advertisements<BR>which might lead to incorrect selections. For = example, a=20 CN might<BR>incorrectly advertise low load, low cost and good = coverage=20 and<BR>therefore attract a large proportion of traffic. This = problem can=20 be<BR>somewhat mitigated through filtering of advertisements and =20 local<BR>policies but ultimately comes down to a trust relationship=20 between<BR>peers.</P> <P><BR>5.2 General Distribution and Request Routing Protocol = Requirements</P> <P>Based on the security threats that are faced by other=20 peer-to-peer<BR>based protocols such as BGP, this section provide = some=20 guidelines<BR>that should be used during the design of the request = routing=20 and<BR>content distribution protocols.</P> <P>5.2.1 There should be a mechanism that provides strong protection = of<BR>the=20 integrity, freshness and source authenticity of the messages = in</P> <P><BR>INTERNET-DRAFT =20 draft-ietf-cdi-threat-00.txt Page 13</P> <P><BR>the protocol. Techniques such as digital signature may be = used.</P> <P>5.2.2 There should be a mechanism to validate the authenticity of=20 a<BR>CN_Path value.</P> <P>5.2.3 There should be a mechanism to use IP-level protection that = can<BR>be=20 used to provide connectionless integrity, data = origin<BR>authentication,=20 and secure authentication.</P> <P>5.2.4 There should be a mechanism to protect the = peer-to-peer<BR>connection=20 by applying cryptographic protection at the TCP level = to<BR>provide=20 connectionless integrity and data origin authentication.</P> <P><BR>References</P> <P>[1] Day, M., Cain, B. and G. Tomlinson, "A Model for=20 Content<BR>Distribution Internetworking", January = 2001.<BR>[2] CERT=20 Coordination Center (CERT/CC).<BR><A=20 href=3D"http://www.cert.org/nav/index_main.html">http://www.cert.org/nav/= index_main.html</A></P> <P><BR></FONT> </P></FONT></BODY></HTML> ------=_NextPart_000_0042_01C268CB.5F186800-- --------------040505020009060704040705--