RFC(F) 3837

From RFC.Wiki
Jump to: navigation, search
Groupe de travail du réseau                                    A. Barbir
Demande de commentaires: 3837                            Nortel Networks
Catégorie: Informatif                                         O. Batuner
                                                  Consultant indépendant
                                                             B. Srinivas
                                                                   Nokia
                                                              M. Hofmann
                                           Bell Labs/Technologies Lucent
                                                                H. Orman
                                          Développement de Purple Streak
                                                               Août 2004

Menaces et risques de sécurité pour les services Open Pluggable Edge (OPES)

Statut de ce mémo

   Ce mémo fournit des informations à la communauté Internet. Cela fait
   ne pas spécifier de norme Internet d'aucune sorte. Distribution de ceci
   le mémo est illimité.

Copyright

   Copyright (C) L'Internet Society (2004).

Abstrait

   Le document enquête sur les menaces de sécurité associées à la
   Ouvrez Pluggable Edge Services (OPES) et examine les effets de
   menaces de sécurité sur l'architecture sous-jacente. L'objectif principal de
   ce document est la découverte et l'analyse des menaces. Le document fait
   ne spécifie ni ne recommande aucune solution.

Table des matières

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2. Menaces de flux de données OPES. . . . . . . . . . . . . . . . . . . . 4
       2.1. Menaces au niveau du réseau OPES Flow. . . . . . . . . . . . 5
             2.1.1. Déni de service du flux de connexion (DoS). . . . . 6
             2.1.2. Menaces pesant sur la robustesse du réseau. . . . . . . . . . 6
       2.2. Menaces au niveau de l'application OPES Flow. . . . . . . . . . . 6
             2.2.1. Entités OPES non autorisées. . . . . . . . . . . 6
             2.2.2. Actions non autorisées des entités OPES légitimes 7
             2.2.3. Transformations de contenu indésirables. . . . . . . . 7
             2.2.4. Contenu corrompu. . . . . . . . . . . . . . . 7
             2.2.5. Menaces pour l'intégrité de la structure des messages. . . . . 8
             2.2.6. Granularité de la protection. . . . . . . . . . . 8
             2.2.7. Risques liés à la protection hop-by-hop. . . . . . . . . 8
             2.2.8. Menaces contre l'intégrité des données complexes. . . . . . 8
             2.2.9. Déni de service (DoS). . . . . . . . . . . . 9
             2.2.10. Informations de traçage et de notification. . . . . . 9
             2.2.11. Communication non authentifiée dans OPES Flow. . . 9
   3. Menaces sur les données hors bande. . . . . . . . . . . . . . . . . 9
       3.1. Menaces qui mettent en danger le flux de données OPES. . . . . . . . dix
       3.2. Informations comptables inexactes. . . . . . . . . . . dix
       3.3. Répudiation de demande de service OPES. . . . . . . . . . . . 11
       3.4. Politique de confidentialité incohérente. . . . . . . . . . . . . . 11
       3.5. Exposition des préférences de confidentialité. . . . . . . . . . . . 11
       3.6. Exposition des paramètres de sécurité. . . . . . . . . . . . . 11
       3.7. Application incorrecte de la politique de confidentialité et de sécurité. . 11
       3.8. Attaques DoS. . . . . . . . . . . . . . . . . . . . . . 12
   4. Considérations de sécurité. . . . . . . . . . . . . . . . . . . 12
   5. Références. . . . . . . . . . . . . . . . . . . . . . . . . . 12
       5.1. Références normatives . . . . . . . . . . . . . . . . . . 12
       5.2. Références informatives. . . . . . . . . . . . . . . . . 12
   6. Remerciements. . . . . . . . . . . . . . . . . . . . . . . 12
   7. Adresses des auteurs. . . . . . . . . . . . . . . . . . . . . . 13
   8. Déclaration de copyright complète. . . . . . . . . . . . . . . . . . . 14

1. Introduction

   L’architecture OPES (Open Pluggable Edge Services) [1] permet
   services d'application coopératifs (services OPES) entre une donnée
   fournisseur, un consommateur de données et zéro ou plusieurs processeurs OPES. le
   services applicatifs envisagés analyser et éventuellement
   transformer les messages de niveau application échangés entre les données
   fournisseur et le consommateur de données. Le processeur OPES peut distribuer
   la responsabilité de l'exécution du service en communiquant et
   collaborer avec un ou plusieurs serveurs d'appels distants. Les détails
   de l'architecture OPES peut être trouvée dans [1].

   Les menaces de sécurité liées à OPES peuvent être visualisées à partir de
   angles. Il existe des risques de sécurité qui affectent le consommateur de contenu
   applications et celles qui affectent les applications du fournisseur de données.
   Ces menaces affectent la qualité et l'intégrité des données que le
   les applications produisent ou consomment. D'autre part, le
   les risques de sécurité peuvent également être classés en confiance au sein du système
   (c'est-à-dire les fournisseurs de services OPES) et la protection du système contre
   les menaces imposées par des étrangers tels que les pirates et les attaquants. Initiés
   sont les parties qui font partie du système OPES. Les étrangers sont
   les entités qui ne participent pas au système OPES.

   Il convient de noter que tout le monde dans un chemin de livraison OPES n'est pas
   tout aussi fiable. Chaque domaine d'approbation administratif OPES doit protéger
   lui-même de tous les étrangers. De plus, il peut avoir une confiance limitée
   relation avec un autre domaine administratif OPES pour certains
   fins.

   Les fournisseurs de services OPES doivent utiliser l'authentification comme base
   établir des relations de confiance entre les domaines administratifs.
   Les initiés peuvent, intentionnellement ou non, infliger des préjudices et des dommages
   sur les applications de consommateur de données et de fournisseur de données. Cela peut être
   par une mauvaise configuration du système, l'exécution d'un mauvais logiciel ou, si
   leurs réseaux sont compromis, par des pirates internes ou externes.

   En fonction du scénario de déploiement, la confiance dans OPES
   système est basé sur un ensemble de relations de confiance transitives entre
   l'application du fournisseur de données, les entités OPES et les données
   application grand public. Les menaces pesant sur les entités OPES peuvent provenir de l'OPES
   au niveau du débit et / ou au niveau du réseau.

   Lors de l'examen des menaces pesant sur le système OPES, le document suivra une
   modèle d'analyse des menaces qui identifie les menaces provenant du
   perspective de la façon dont ils affecteront le consommateur de données et les données
   applications du fournisseur.

   L'objectif principal de ce document est la découverte et l'analyse des menaces. le
   le document ne spécifie ni ne recommande aucune solution.

   Il est important de mentionner que l'architecture OPES a de nombreux
   similitudes avec d'autres réseaux dits overlay, en particulier le Web
   caches et réseaux de diffusion de contenu (CDN) (voir [2], [4]). Ce
   document se concentre sur les menaces qui sont introduites par l'existence de
   le processeur OPES et les serveurs d'appel. Menaces de sécurité spécifiques à
   les services de contenu qui n'utilisent pas l'architecture OPES sont considérés
   hors de portée de ce document. Cependant, ce document peut être utilisé comme
   entrée lors de l'examen des implications de sécurité pour les caches Web et les CDN.

   Le document est organisé comme suit: la section 2 traite des menaces
   Flux de données OPES au niveau du réseau et de l'application, section 3
   traite des menaces pour d'autres parties du système, et la section 4
   discute des considérations de sécurité.

2. Menaces de flux de données OPES

   Les menaces pesant sur le flux de données OPES peuvent affecter le consommateur de données et les données
   applications du fournisseur. Au niveau du flux OPES, des menaces peuvent survenir
   Points d'application de la politique et points de décision de politique [3], et ainsi de suite
   le chemin de flux OPES où les éléments du réseau sont utilisés pour traiter
   Les données.

   Un problème sérieux est posé par le fait même que l'OPES
   l'architecture est basée sur des protocoles largement adoptés (HTTP est utilisé comme
   exemple). Le document d'architecture exige spécifiquement que «le
   présence d'un processeur OPES dans le flux de demande / réponse de données DOIT
   NE PAS interférer avec les opérations des clients non compatibles OPES et
   ". Cela facilite grandement le déploiement d'OPES, mais sur le
   d'autre part, une grande majorité des clients (navigateurs) ne pourront pas
   exploiter toutes les garanties ajoutées en tant qu'extensions de protocole de base.

   Pour le consommateur de données habituel, qui pourrait avoir des questions telles que (Où
   d'où vient ce contenu? Puis-je l'obtenir d'une autre manière? Quel est le
   différence? Est-ce légitime?). Même s'il y a des installations et
   l'expertise technique présente pour approfondir ces questions,
   l'examen de chaque résultat est d'un coût prohibitif en termes de
   temps et efforts. Les fournisseurs de contenu compatibles OPES peuvent essayer de protéger
   eux-mêmes en ajoutant des scripts de vérification et une page spéciale
   structures. Les utilisateurs finaux compatibles OPES peuvent utiliser des outils spéciaux. Dans tout
   dans les autres cas (clients et serveurs non compatibles OPES), la protection dépendra
   sur les services de surveillance et d'enquête sur les découvertes occasionnelles
   anomalies.

   Un système OPES présente un danger particulier comme base possible pour
   attaques classiques de l'homme du milieu. L'une des raisons pour lesquelles
   les attaques sont relativement rares est la difficulté de trouver un
   base appropriée: combinaison d'un point d'interception du trafic
   contrôler un grand flux de données et une base de code d'application en cours d'exécution
   sur un matériel performant avec des performances suffisantes pour analyser
   et éventuellement modifier toutes les données qui passent. Un processeur OPES répond à cela
   définition. Cela appelle une attention particulière aux mesures de protection
   à tous les niveaux du système.

   Tout compromis d'un processeur OPES ou d'un serveur d'appel distant peut avoir
   un effet d'entraînement sur l'intégrité des services OPES affectés à travers
   tous les fournisseurs de services qui utilisent le service. Pour atténuer cette menace,
   les procédures et outils de sécurité appropriés (par exemple, un pare-feu) doivent
   sois appliqué.

   Des menaces spécifiques peuvent exister au niveau du réseau et au niveau des données OPES
   niveau de débit.

2.1. Menaces au niveau du réseau OPES Flow

   Le processeur OPES et les serveurs d'appel sont sensibles au niveau du réseau
   attaques de l'extérieur ou des réseaux d'autres services OPES
   fournisseurs (c'est-à-dire, si le réseau d'un service OPES sous contrat est
   compromis).

   L'architecture OPES est basée sur des protocoles d'application communs qui
   ne fournissent pas de solides garanties de confidentialité, d'authentification ou
   intégrité. Les considérations de l'IAB [4] exigent que l'adresse IP de
   un processeur OPES soit accessible aux applications de consommation de données au
   Niveau d'adressage IP. Cette exigence limite la capacité de service
   fournisseurs de positionner le processeur OPES derrière des pare-feu et peuvent
   exposer le processeur OPES et les serveurs d'appel distants au niveau du réseau
   attaques. Par exemple, l'utilisation de TCP / IP comme protocole de niveau réseau
   rend les processeurs OPES sujets à de nombreuses attaques connues, telles que IP
   spoofing et vol de session.

   Le système OPES est également sensible à un certain nombre de menaces de sécurité
   qui sont généralement associés à l'infrastructure réseau. Celles-ci
   les menaces comprennent l'espionnage, le déni de service, le sabotage, le vandalisme,
   espionnage industriel et vol de service.

   Il existe des solutions de bonnes pratiques pour atténuer les menaces au niveau du réseau.
   Il est recommandé que la sécurité des entités OPES au
   au niveau du réseau être amélioré à l'aide de techniques et de méthodes connues
   minimiser les risques d'usurpation d'adresse IP, d'espionnage, de déni de service et
   vol de session.

   Au niveau du flux OPES, sécurité au niveau de la connexion entre les OPES
   le processeur et les serveurs d'appel est une considération importante. Pour
   Par exemple, il est possible d'usurper le processeur OPES ou la télécommande
   serveur d'accroche. Il existe des menaces pour la confidentialité des données entre
   le processeur OPES et le serveur d'appel distant dans un flux OPES.

   Les sous-sections suivantes couvrent les attaques DoS possibles sur un processeur OPES,
   serveur d'appel distant ou application de consommation de données, et réseau
   robustesse.

2.1.1. Déni de service du flux de connexion (DoS)

   Les processeurs OPES, les serveurs d'appel et les applications de consommation de données peuvent
   être vulnérable aux attaques DoS. Les attaques DoS peuvent être de différents types.
   Un exemple d'attaque DoS est la surcharge des processeurs OPES ou
   serveurs d'appel par de fausses demandes de service émises par un
   node, qui refuse au trafic légal de données les ressources nécessaires pour
   rendre service. Les ressources comprennent les cycles CPU, la mémoire, le réseau
   interfaces, etc. Une attaque par déni de service peut être sélective,
   génériques, ou aléatoires en termes de flux de communication
   affecté.

   Distributed DoS est également possible lorsqu'un attaquant réussit
   dirige plusieurs nœuds sur le réseau pour lancer un service parasite
   requêtes à un processeur OPES (ou serveur d'appel) simultanément.

2.1.2. Menaces pesant sur la robustesse du réseau

   Si la mise en œuvre d'OPES viole les principes d'adressage de bout en bout, elle
   pourrait mettre en danger l'infrastructure Internet en compliquant le routage
   et gestion des connexions. S'il n'utilise pas le contrôle de flux
   principes de gestion des connexions, ou si cela interfère avec les
   contrôle de flux de bout en bout des connexions dont il n'est pas issu, puis
   pourrait entraîner une congestion Internet.

   Une implémentation qui enfreint l'exigence IAB d'IP explicite
   adressage de niveau (par exemple, en ajoutant des capacités fonctionnelles OPES
   à un mandataire d'interception) peut vaincre certains des
   mécanismes et garanties intégrés dans l'architecture OPES.

2.2. Menaces au niveau de l'application OPES Flow

   Au niveau du contenu, les menaces sur le système OPES peuvent provenir
   des étrangers ou des initiés. La menace des étrangers est fréquemment
   intentionnel. Les menaces d'initiés peuvent être intentionnelles ou accidentelles.
   Les accidents peuvent résulter d'erreurs de programmation ou de configuration
   entraîner un mauvais comportement du système.

   Les problèmes au niveau de l'application et les menaces pour les systèmes OPES sont
   discuté ci-dessous:

2.2.1. Entités OPES non autorisées

   Bien que l'autorisation d'une partie soit mandatée par l'OPES
   architecture, une telle autorisation se produit hors bande. Découvrir le
   la présence d'une entité OPES et la vérification de l'autorisation nécessite
   actions spéciales et peut présenter un problème.

   Ajout d'informations de notification et d'autorisation aux données
   messages (en utilisant les extensions de protocole de base) peuvent aider, surtout si
   le logiciel du consommateur de données est conscient de ces extensions.

2.2.2. Actions non autorisées des entités OPES légitimes

   Selon l'architecture OPES, l'autorisation n'est pas strictement
   associée à des règles et procédures spécifiques déclenchées par les règles.
   Même si une obligation d'approuver chaque règle et procédure particulière
   a été défini, il semble au moins impossible, voire impossible, de demander
   une telle autorisation de l'utilisateur final. La granularité des autorisations s'étend
   aux classes de transformation, mais pas aux règles individuelles ou
   transformations. Les règles réelles et les procédures déclenchées peuvent
   (par malveillance ou en raison d'une erreur de programmation) exécutez des actions
   ne sont pas autorisés pour.

2.2.3. Transformations de contenu indésirables

   Un service OPES autorisé peut effectuer des actions qui ne respectent pas
   les attentes de la partie qui a donné l'autorisation de
   un service. Les exemples peuvent inclure l'inondation d'annonces par une insertion d'annonce locale
   service ou utilisation d'une politique inappropriée par un filtrage de contenu
   un service.

   D'un autre côté, une entité OPES agissant au nom d'une partie peut
   effectuer des transformations qu'une autre partie juge inappropriées.
   Les exemples peuvent inclure le remplacement des publicités initialement insérées par le contenu
   fournisseur ou en appliquant des transformations de filtrage qui modifient
   sens du texte.

2.2.4. Contenu corrompu

   Le système OPES peut fournir des données obsolètes ou déformées
   informations dues à des problèmes de programmation ou à la suite de
   attaques. Par exemple, un serveur compromis, au lieu d'effectuer un
   Service OPES, peut injecter un contenu bidon. Une telle action peut être un acte
   de cyber-vandalisme (y compris l'injection de virus) ou intentionnel
   distribution d'informations trompeuses (comme des manipulations avec
   données financières).

   Un serveur OPES compromis ou une entité malveillante dans le flux de données peut
   introduire des changements spécifiquement destinés à provoquer des actions inappropriées
   le serveur OPES ou le serveur d'appel. Ces changements peuvent être dans le
   corps du message, en-têtes ou les deux. Ce type de menace est abordé dans
   plus de détails ci-dessous.

2.2.5. Menaces pour l'intégrité de la structure des messages

   Un serveur OPES peut ajouter, supprimer ou supprimer certains en-têtes dans un
   message de demande et / ou de réponse (par exemple, pour implémenter
   protection de la vie privée ou aide au filtrage du contenu). De tels changements peuvent
   enfreindre les exigences d'intégrité de bout en bout ou annuler les services qui utilisent
   informations fournies dans ces en-têtes (par exemple, certains
   services de filtrage ou services de référence).

2.2.6. Granularité de la protection

   Les services OPES ont l'autorisation implicite de modifier le contenu. cependant,
   les autorisations ne s'appliquent généralement qu'à des parties du contenu, pour
   exemple, URL entre des balises HTML particulières, du texte dans les titres, ou
   URL correspondant à des modèles particuliers. Afin d'exprimer une telle
   politiques, il faut pouvoir se référer à des portions de messages et
   détecter les modifications des parties du message.

   Parce qu'il y a actuellement très peu de soutien pour les politiques qui sont
   exprimé en termes de parties de message, il sera difficile de
   attribuer toute modification particulière à un processeur OPES particulier,
   ou pour détecter automatiquement les violations de politique.

   Un langage politique précis devrait être conçu, et il pourrait être
   appliquée à l'aide de signatures numériques. Cela éviterait les problèmes
   inhérent aux mesures d'intégrité des données bond par bond (voir la section suivante).

2.2.7. Risques de la protection hop-by-hop

   En règle générale, les services OPES ne peuvent pas être appliqués aux données protégées par
   méthodes de chiffrement de bout en bout car la clé de déchiffrement ne peut pas être
   partagé avec les processeurs OPES sans compromettre le
   confidentialité des données. Cela signifie que si le point final
   les politiques autorisent les services OPES, les données doivent être transmises
   sans protection de confidentialité ni modèle alternatif pour mettre fin
   le cryptage de bout en bout doit être développé, un dans lequel la confidentialité
   est garanti saut par saut. Extension du modèle de chiffrement de bout en bout
   est hors de portée de ce travail.

   Les services OPES qui modifient les données sont incompatibles avec les services de bout en bout
   méthodes de protection de l'intégrité, et ce travail ne tentera pas de
   définir les méthodes de protection de l'intégrité bond par bond.

2.2.8. Menaces pour l'intégrité des données complexes

   Le système OPES peut violer l'intégrité des données en appliquant des
   transformations en objets de données ou références interdépendants dans
   objet de données. Les problèmes peuvent provenir d'une structure de référence brisée

   (cibles modifiées / manquantes, références à des emplacements incorrects ou manquants
   documents) pour remplacer / supprimer / insérer délibérément des liens
   violer les intentions du fournisseur de contenu.

2.2.9. Déni de service (DoS)

   L'application consommateur de données peut ne pas être en mesure d'accéder aux données si
   Le système OPES échoue pour une raison quelconque.

   Un nœud malveillant ou défectueux peut bloquer tout le trafic.
   Le trafic de données destiné au processeur OPES (ou serveur d'appel)
   peut ne pas être en mesure d'utiliser les services de l'appareil OPES. Le DoS peut
   être atteint en empêchant le trafic de données d'atteindre le
   processeur ou le serveur d'appel.

2.2.10. Informations de traçage et de notification

   Mise en œuvre inadéquate ou vulnérable du traçage et
   les mécanismes de notification peuvent faire échouer les garanties intégrées dans l'OPES
   architecture.

   Les fonctions de traçage et de notification peuvent devenir la cible de
   attaque. Une telle attaque peut créer des problèmes pour découvrir et
   arrêter d'autres attaques.

   L'absence de norme pour les informations de traçage et de notification
   peut présenter un problème supplémentaire. Ces informations sont produites et
   consommés par les entités indépendantes (serveurs OPES / agents utilisateurs /
   installations du fournisseur de contenu). Cela nécessite un ensemble de normes
   liés à chaque protocole de base utilisé.

2.2.11. Communication non authentifiée dans OPES Flow

   Il y a des risques et des menaces qui pourraient résulter de non authentifiés
   communication entre le serveur OPES et les serveurs d'appel. Manque de
   utilisation d'une authentification forte entre les processeurs OPES et l'appel
   les serveurs peuvent ouvrir des failles de sécurité par lesquelles DoS et d'autres types de
   des attaques (voir sections [2 et 3]) peuvent être effectuées.

3. Menaces pesant sur les données hors bande

   L'architecture OPES sépare un flux de données d'un contrôle
   flux d'informations (chargement des ensembles de règles, établissement de la confiance, traçage,
   propagation de politique, etc.). Certaines exigences sont définies pour
   ce dernier, mais aucun mécanisme spécifique n'est prescrit. Cela donne plus
   flexibilité pour les implémentations, mais crée plus de charge pour
   les implémenteurs et les clients potentiels pour s'assurer que chaque

   la mise en œuvre répond à toutes les exigences de sécurité des données, entité
   authentification et autorisation d'action.

   En plus d'effectuer des actions correctes sur le flux de données OPES, tout
   La mise en œuvre d'OPES doit fournir un mécanisme adéquat pour
   exigences relatives aux données hors bande et aux informations de signalisation
   intégrité.

   Quel que soit le mécanisme spécifique, il devient inévitablement sujet
   à de multiples menaces de sécurité et attaques possibles. La façon dont le
   les menaces et les attaques peuvent être réalisées dépend de la mise en œuvre
   détails, mais le préjudice qui en résulte se divise généralement en deux catégories:
   menaces pour le flux de données OPES et menaces pour l'intégrité des données.

   Les menaces spécifiques sont:

3.1. Menaces qui mettent en danger le flux de données OPES

   Toute faiblesse dans la mise en œuvre d'une sécurité, d'une authentification ou
   mécanisme d'autorisation peut ouvrir la porte aux attaques décrites dans
   section 2.

   Une mise en œuvre d'un système OPES doit traiter toutes ces menaces et
   prouver sa robustesse et sa capacité à résister aux attaques malveillantes ou
   problèmes de réseautage et de programmation.

3.2. Informations comptables inexactes

   La collecte et la communication de données comptables précises peuvent être vitales lorsque
   Les serveurs OPES sont utilisés pour étendre un modèle économique d'un contenu
   fournisseur, fournisseur de services ou comme base d'un service tiers.
   La capacité de collecter et de traiter les données comptables est un élément important
   partie de la fonctionnalité du système OPES. Cette fonctionnalité peut être
   remis en cause par la distorsion ou la destruction des données comptables de base
   (généralement des journaux), les données comptables traitées, les paramètres comptables et
   configuration des rapports.

   En conséquence, un consommateur de données peut être facturé de manière inappropriée
   affichage d'un contenu qui n'a pas été livré avec succès ou d'un contenu
   le fournisseur ou le fournisseur de services OPES indépendant peut ne pas être indemnisé
   pour les services rendus.

   Le système OPES peut utiliser des informations comptables pour diffuser
   ressources entre différents consommateurs ou limiter l'utilisation des ressources par un
   consommateur spécifique. Dans ce cas, une attaque contre le système comptable
   (par distorsion des données ou émission de fausses commandes de configuration)
   entraînent une gestion incorrecte des ressources et un DoS artificiel
   la famine des ressources.

3.3. Répudiation de demande de service OPES

   Une entité (producteur ou consommateur) peut faire une demande autorisée et
   plus tard, il n'a pas fait cette demande. En conséquence, un OPES
   l'entité peut être tenue responsable des modifications non autorisées du flux de données,
   ou ne pourra pas recevoir de compensation pour un service.

   Il devrait y avoir une demande claire indiquant que ce service est requis et
   il devrait y avoir une ligne de conduite claire au nom de toutes les parties.
   Cette action doit avoir une demande, une action, un moyen non répudiable
   de vérifier la demande, et un moyen de spécifier l'effet de la
   action.

3.4. Politique de confidentialité incohérente

   Les entités OPES peuvent avoir des politiques de confidentialité qui ne sont pas cohérentes
   avec l'application de consommateur de données ou l'application de fournisseur de contenu.

   Les problèmes liés à la confidentialité peuvent être encore plus compliqués si les entités OPES,
   les fournisseurs de contenu et les utilisateurs finaux appartiennent à des juridictions différentes
   avec des exigences différentes et différents niveaux de protection juridique.
   En conséquence, l'utilisateur final peut ne pas savoir qu'il ou elle ne
   bénéficient de la protection juridique attendue. Le fournisseur de contenu peut être
   exposés à des risques juridiques en raison d'un non-respect de la réglementation
   dont il n’a même pas conscience.

3.5. Exposition des préférences de confidentialité

   Le système OPES peut exposer par inadvertance ou par malveillance l'utilisateur final
   paramètres et exigences de confidentialité.

3.6. Exposition des paramètres de sécurité

   Le système OPES risque d'exposer la sécurité de l'utilisateur final
   paramètres lors du traitement de la demande et des réponses. Les données utilisateur doivent
   être traitées comme des informations système sensibles et protégées contre
   divulgation accidentelle et délibérée.

3.7. Application incorrecte de la politique de confidentialité et de sécurité

   Les entités OPES font partie du système de distribution de contenu et à ce titre
   assumer certaines obligations pour soutenir les politiques de sécurité et de confidentialité
   mandaté par le producteur de contenu et / ou l'utilisateur final. Cependant il y a un
   danger que ces politiques ne soient pas correctement mises en œuvre et appliquées.
   L'application consommateur de données peut ne pas savoir que ses protections
   ne sont plus en vigueur.

   Il y a aussi la possibilité de fuites de sécurité et de confidentialité dues à
   la mauvaise configuration accidentelle ou, en raison d'un malentendu
   les règles sont en vigueur pour un utilisateur ou une demande en particulier.

   Les parties des systèmes liées à la confidentialité et à la sécurité peuvent être ciblées par
   les attaques malveillantes et la capacité de résister à de telles attaques est
   importance primordiale.

3.8. Attaques DoS

   Les attaques DoS peuvent être de différents types. Un type d'attaque DoS prend
   effet en surchargeant le client. Par exemple, un intrus peut
   ordonner à un processeur OPES d'émettre de nombreuses réponses à un client.
   Il existe également un risque de déni de service supplémentaire lié à une mauvaise configuration des règles
   voudrait que le processeur OPES ignore une application de consommation de données.

4. Considérations relatives à la sécurité

   Ce document traite de plusieurs problèmes de sécurité et de confidentialité liés
   aux services OPES.

5. Références

5.1. Références normatives

   [1] Barbir, A., Penno, R., Chen, R., Hofmann, M. et H. Orman, "An
        Architecture pour Open Pluggable Edge Services (OPES) ", RFC 3835,
        Août 2004.

   [2] Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H. et R.
        Penno, «OPES Use Cases and Deployment Scenarios», RFC 3752,
        Avril 2004.

   [3] Barbir, A., Batuner, O., Beck, A., Chan, T. et H. Orman,
        "Exigences en matière de politique, d'autorisation et d'application de Open
        Pluggable Edge Services (OPES) ", RFC 3838, août 2004.

5.2. Références informatives

   [4] Floyd, S. et L. Daigle, "IAB Architectural and Policy
        Considérations relatives aux services Open Pluggable Edge ", RFC 3238,
        Janvier 2002.

6. Remerciements

   Un grand merci à T. Chan (Nokia) et A. Beck (Lucent).

7. Adresses des auteurs

   Abbie Barbir
   Nortel Networks
   3500 avenue Carling
   Nepean, Ontario K2H 8E9
   Canada

   Téléphone: +1613763 5229
   Courriel: abbieb@nortelnetworks.com

   Oskar Batuner
   Consultant indépendant

   Courriel: batuner@attbi.com

   Bindignavile Srinivas
   Nokia
   Route 5 Wayside
   Burlington, MA 01803
   Etats-Unis

   Courriel: bindignavile.srinivas@nokia.com

   Markus Hofmann
   Bell Labs / Technologies Lucent
   Salle 4F-513
   101, chemin Crawfords Corner
   Holmdel, NJ 07733
   NOUS

   Téléphone: +1732332 5983
   COURRIEL: hofmann@bell-labs.com

   Hilarie Orman
   Développement de Purple Streak

   COURRIEL: ho@alum.mit.edu

8. Déclaration de droit d'auteur complète

   Copyright (C) L'Internet Society (2004). Ce document est sujet
   aux droits, licences et restrictions contenus dans BCP 78, et
   sauf indication contraire, les auteurs conservent tous leurs droits.

   Ce document et les informations qu'il contient sont fournis sur un
   "TEL QUEL" et LE CONTRIBUTEUR, L'ORGANISATION QU'IL / ELLE REPRÉSENTE
   OU EST SPONSORISÉ PAR (LE CAS ÉCHÉANT), LA SOCIÉTÉ INTERNET ET INTERNET
   GÉNIE TASK FORCE DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE,
   INCLUANT, MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION
   LES INFORMATIONS CI-DESSUS NE VIOLENT AUCUN DROIT OU TOUT DROIT IMPLICITE
   GARANTIES DE QUALITÉ MARCHANDE OU D'ADÉQUATION À UN USAGE PARTICULIER.

Propriété intellectuelle

   L'IETF ne prend aucune position concernant la validité ou la portée de tout
   Droits de propriété intellectuelle ou autres droits susceptibles d'être revendiqués
   concernent la mise en œuvre ou l'utilisation de la technologie décrite dans
   ce document ou la mesure dans laquelle une licence en vertu de ces droits
   peut ou peut ne pas être disponible; il ne signifie pas non plus qu'il a
   fait tout effort indépendant pour identifier ces droits. Information
   sur les procédures relatives aux droits dans les documents RFC peuvent être
   trouvé dans BCP 78 et BCP 79.

   Copies des divulgations de DPI faites au Secrétariat de l'IETF et
   les assurances de licences à mettre à disposition, ou le résultat d'un
   tentative faite pour obtenir une licence générale ou une autorisation pour l'utilisation de
   ces droits de propriété par les exécutants ou les utilisateurs de ce
   Les spécifications peuvent être obtenues auprès du référentiel IPR en ligne de l'IETF à l'adresse
   http://www.ietf.org/ipr.

   L'IETF invite toute partie intéressée à porter à son attention toute
   droits d'auteur, brevets ou demandes de brevets, ou autres
   les droits qui peuvent couvrir la technologie qui peut être nécessaire pour mettre en œuvre
   cette norme. Veuillez adresser les informations à l'IETF à l'ietf-
   ipr@ietf.org.

Reconnaissance

   Le financement de la fonction RFC Editor est actuellement assuré par le
   Société Internet.

Balisage HTML produit par rfcmarkup 1.129d, disponible sur https://tools.ietf.org/tools/rfcmarkup/