RFC(F) 3238

From RFC.Wiki
Revision as of 15:34, 26 July 2020 by Sysop (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Groupe de travail du réseau Internet Architecture Board (IAB)   S. Floyd
Demande de commentaires: 3238                                  L. Daigle
Catégorie:                                                    Informatif 
                                                            Janvier 2002

            Considérations architecturales et politiques de l'IAB pour
                      Ouvrez les services Edge enfichables

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 (2002). Tous les droits sont réservés.

Abstrait

   Ce document comprend des commentaires et des recommandations du CCI sur
   certains problèmes d'architecture et de politique liés à la charte de
   Ouvrez Pluggable Edge Services (OPES) dans l'IETF. OPES sont des services
   qui serait déployé au niveau des intermédiaires au niveau de l'application
   réseau, par exemple, dans un cache de proxy Web entre le serveur d'origine
   et le client. Ces intermédiaires transformeraient ou filtreraient
   contenu, avec le consentement explicite du fournisseur de contenu ou
   l'utilisateur final.

1. Introduction

   Open Pluggable Edge Services (OPES) sont des services qui seraient
   déployé sur le réseau, par exemple, dans un cache de proxy Web entre
   le serveur d'origine et le client, qui transformeraient ou filtreraient
   contenu. Des exemples de services OPES proposés incluent l'assemblage
   pages Web personnalisées, ajout d'informations régionales spécifiques à l'utilisateur
   pages Web, analyse de virus, adaptation de contenu pour les clients
   bande passante limitée, traduction linguistique, etc. [OPES].

   La question de l'affrètement d'OPES dans l'IETF ([OPESBOF1], [OPESBOF2],
   [OPESBOF3]) et la controverse associée au sein de la communauté IETF
   ([Carr01], [CDT01], [Morris01], [Orman01], [Routson01]) ont soulevé
   au premier plan plusieurs problèmes architecturaux et politiques relatifs à la robustesse
   et l'intégrité de bout en bout des données (en termes de disparités
   entre ce que le "serveur d'origine" met à disposition et ce que le client
   reçoit). En particulier, des questions ont été soulevées au sujet de la
   exigences éventuelles, pour un protocole à développer et

   normalisé dans l'IETF, pour que ce protocole protège le bout en bout
   confidentialité et intégrité des données. Ce document tente de répondre
   certains des problèmes d'architecture et de politique qui n'ont pas été résolus
   dans la charte d'OPES, et pour arriver à des recommandations communes
   de l'IAB concernant ces questions.

   Le but de ce document n'est pas de recommander des solutions spécifiques
   pour OPES, ou même pour imposer des exigences fonctionnelles spécifiques. Ce
   n'est pas non plus une recommandation à l'IESG quant à savoir si OPES
   devrait être affrété. Au lieu de cela, ce sont des recommandations sur les problèmes
   que toutes les solutions OPES normalisées dans l'IETF devraient être requises
   à adresser, similaire aux "Considérations relatives à la sécurité" actuellement
   requis dans les documents IETF [RFC2316]. À titre d'exemple, une façon de
   résoudre les problèmes de sécurité consiste à montrer qu'une sécurité appropriée
   des mécanismes ont été fournis dans le protocole et une autre façon
   résoudre les problèmes de sécurité consiste à démontrer qu'aucun problème de sécurité
   s'appliquent à ce protocole particulier. (Notez cependant qu'une couverture
   la phrase "aucun problème de sécurité n'est impliqué" n'est jamais prise en compte
   suffisant pour résoudre les problèmes de sécurité dans un protocole avec
   problèmes de sécurité.)

   Ce document essaiera de rendre nos préoccupations sous-jacentes à l'intégrité,
   confidentialité et sécurité aussi claires que possible. Nous recommandons que le
   IESG exige que les documents OPES traitent de l'intégrité, de la confidentialité et
   problèmes de sécurité d'une manière ou d'une autre, soit directement par
   faire la démonstration de mécanismes appropriés ou présenter des arguments convaincants
   qu'il n'y a aucun problème d'intégrité ou de confidentialité concernant un
   document particulier.

   En particulier, il semble inévitable qu'à un moment donné dans le futur
   certains services OPES fonctionneront de manière inappropriée (par exemple, un antivirus
   rejetant le contenu qui n'inclut pas de virus), et certains OPES
   intermédiaire sera compromis par inadvertance ou avec
   malveillance. Compte tenu de cela, il semble nécessaire pour l'ensemble
   architecture pour aider à protéger l'intégrité des données de bout en bout en adressant,
   dès le début du processus de conception, l'exigence d'aider
   mettre fin aux hôtes pour détecter et répondre à un comportement inapproprié par OPES
   intermédiaires.

   L'un des objectifs de l'architecture OPES doit être de maintenir la
   la robustesse longtemps citée comme l'un des objectifs primordiaux d'Internet
   architecture [Clark88]. Compte tenu de cela, nous recommandons que l'IESG
   exiger que l'architecture OPES protège l'intégrité des données de bout en bout
   en prenant en charge la détection de l'hôte final et la réponse à des
   comportement des intermédiaires OPES. Nous notons que dans ce cas par
   "prise en charge de la détection de l'hôte final", nous nous référons à la prise en charge
   détection par les humains responsables des hôtes finaux au niveau du contenu
   fournisseur et client. Nous notons que bon nombre de ces préoccupations concernant

   la capacité des hôtes finaux à détecter et à répondre aux
   le comportement des intermédiaires pourrait être appliqué aux architectures pour
   les caches Web et les infrastructures de distribution de contenu, même sans
   complication supplémentaire d'OPES.

   Chaque section du document contient un ensemble de considérations de l'IAB
   que nous recommanderions d'être traités par l'architecture OPES.
   La section 6 résume en énumérant toutes ces considérations dans un
   endroit.

   Dans ce document, nous essayons d'utiliser une terminologie cohérente avec la RFC 3040
   [RFC 3040] et avec OPES travaille en cours.

2. Un peu d'histoire de la controverse sur l'affrètement d'OPES

   Un point de vue sur OPES a été que "OPES est profondément mauvais et l'IETF
   devrait rester loin, loin de cette abomination hideuse "[ODell01].
   D'autres ont suggéré que "OPES réduirait à la fois l'intégrité et
   la perception de l'intégrité, des communications sur Internet et
   augmenterait considérablement de façon incertaine ce qui aurait pu être
   fait au contenu au fur et à mesure qu'il se déplaçait sur le réseau ", et que par conséquent
   les risques de OPES l'emportent sur les avantages [CDT01]. Cette vue de la
   risques d'OPES a été révisé dans un e-mail ultérieur, sur la base des propositions de
   [Carr01], "en supposant que certaines protections de confidentialité et d'intégrité
   peut être intégré aux objectifs du groupe de travail "[Morris01].

   Un problème concerne le modèle de consentement à une partie. Dans le one-party
   modèle de consentement, l'un des nœuds d'extrémité (c'est-à-dire le contenu
   fournisseur ou l'utilisateur final) est tenu d'autoriser explicitement le
   Service OPES, mais l'autorisation des deux parties n'est pas requise.
   [CDT01] commente se fondant uniquement sur un modèle de consentement à une partie dans
   la charte OPES "pourrait faciliter la participation de tiers ou
   censure du contenu Internet à l'insu ou sans le consentement de
   utilisateurs finaux », entre autres scénarios indésirables.

   Une première question naturelle est de savoir s'il existe des
   avantage à mettre des services spécifiques à l'intérieur du réseau (par exemple, au
   cache Web au niveau de l'application) au lieu de positionner tous les services
   soit chez le fournisseur de contenu, soit chez l'utilisateur final. (Notez que nous sommes
   demander ici s'il y a un avantage architectural, qui n'est pas le
   comme demander s'il existe un modèle commercial.) Centré sur le client
   les services suggérés pour OPES incluent l'analyse antivirus, la langue
   traduction, adaptation limitée de la bande passante client, filtrage des demandes,
   et adaptation des médias en streaming, et suggestion de
   les services comprennent des services basés sur la localisation et des pages Web personnalisées.

   Il semble clair qu'il peut en effet y avoir d'importantes
   bénéficier de la fourniture de certains services OPES à l'intérieur du réseau au
   intermédiaire OPES au niveau de l'application. Par exemple, si certains contenus sont
   déjà disponible à partir d'un cache Web local ou régional, et la fin
   l'utilisateur nécessite une certaine transformation (telle que l'adaptation à un
   chemin de bande passante) appliqué à ces données, fournissant ce service au
   le cache Web lui-même peut empêcher le gaspillage de bande passante d'avoir à
   récupérer plus de données auprès du fournisseur de contenu et en même temps
   éviter les retards inutiles dans la fourniture du service à l'utilisateur final.

   Une deuxième question est de savoir si les avantages architecturaux de fournir
   les services au milieu du réseau l'emportent sur l'architecture
   les coûts, tels que les coûts potentiels concernant l'intégrité des données. Ce
   est similaire aux questions examinées dans la RFC 3135 [RFC 3135] de la
   coûts et avantages relatifs du placement de proxys améliorant les performances
   (PEP) au milieu d'un réseau pour traiter les liens
   dégradations. Dans le cas des PPE, les coûts potentiels comprennent
   désactivation de l'utilisation de bout en bout des mécanismes de sécurité de la couche IP;
   l'introduction d'un nouveau point de défaillance possible qui n'est pas sous le
   contrôle des systèmes terminaux; ajouter une difficulté accrue dans le diagnostic
   et faire face aux échecs; et l'introduction de complications possibles
   avec routage asymétrique ou hôtes mobiles. RFC 3135 attentivement
   considère ces coûts possibles, les atténuations qui peuvent être
   introduit, et les cas où les avantages de l'amélioration des performances
   les procurations à l'utilisateur sont susceptibles de dépasser les coûts. Un similaire
   l'approche pourrait être appliquée aux services OPES (même si nous n'essayons pas
   c'est ici).

   Une troisième question est de savoir si un service OPES, conçu principalement pour un
   action de récupération unique, a un impact sur la couche application
   architecture d’adressage. Ceci est lié au problème d'intégrité
   ci-dessus, mais est indépendante du fait que ces services soient appliqués
   au milieu du réseau ou à l'une ou l'autre extrémité.

   La plupart de ce document traite de la question spécifique de l'intégrité des données
   avec les services OPES, dont l'objectif est de permettre aux hôtes finaux de
   détecter et répondre à un comportement inapproprié de
   intermédiaires OPES compromis.

   Nous convenons que le consentement d'une partie, avec l'un des hôtes finaux explicitement
   autorisant le service OPES, doit être une condition pour qu'OPES soit
   normalisé dans l'IETF.

   Cependant, comme nous le verrons dans la section suivante de ce document, nous sommes d'accord
   avec [CDT01] que le modèle de consentement à une partie en lui-même (par exemple, avec
   l'un des hôtes finaux autorisant le service OPES, et l'autre
   l'hôte final n'est peut-être pas au courant du service OPES) est insuffisant
   pour protéger l'intégrité des données dans le réseau. Nous sommes également d'accord avec

   [CDT01] que, quels que soient les mécanismes de sécurité et d'autorisation
   normalisés pour OPES dans l'IETF, les implémentations OPES pourraient
   probablement être modifié pour contourner ces mécanismes, ce qui
   modification non autorisée du contenu. De nombreux protocoles du
   L'IETF pourrait être modifié à des fins antisociales - protocoles de transport
   pourrait être modifié pour éviter le contrôle d'encombrement de bout en bout, le routage
   les protocoles peuvent être modifiés pour injecter des routes non valides, un proxy Web
   les caches pourraient être utilisés pour la modification non autorisée du contenu
   même sans OPES, et ainsi de suite. Aucun de ceux-ci ne semble convaincant
   raisons de ne pas normaliser les protocoles de transport, les protocoles de routage,
   protocoles de mise en cache Web, ou OPES lui-même. À notre avis, cela signifie plutôt
   que l'infrastructure doit, autant que possible, être conçue pour
   se détecter et se défendre contre les implémentations compromises, et
   les abus de protocoles doivent être traités directement, chacun dans le
   lieu approprié.

   Des mécanismes tels que les signatures numériques, qui aident les utilisateurs à vérifier
   eux-mêmes que le contenu n'a pas été modifié, sont une première étape
   vers la détection de la modification non autorisée de contenu dans
   le réseau. Cependant, dans le cas d'OPES, une protection supplémentaire
   garantir l'intégrité de bout en bout des données est également souhaitable, pour
   exemple, pour aider les utilisateurs finaux à détecter les cas où les intermédiaires OPES
   ont été autorisés à modifier le contenu, mais exécutent de manière inappropriée
   modifications. Nous notons que les mécanismes peuvent * aider * les utilisateurs finaux à
   détecter les intermédiaires OPES compromis dans certains cas, même s'ils le font
   pas * garantir * que les utilisateurs finaux seront en mesure de détecter
   Intermédiaires OPES dans tous les cas.

   Si OPES est agréé, le groupe de travail OPES devra également
   décider et documenter explicitement si l'architecture OPES doit être
   compatible avec l'utilisation du cryptage de bout en bout par une ou plusieurs extrémités
   d'une session avec OPES. Si OPES était compatible avec de bout en bout
   cryptage, cela garantirait effectivement que les boîtiers OPES seraient
   limité à ceux qui sont connus, approuvés, explicitement adressés à
   la couche IP, et autorisé (par la fourniture de clés de décryptage) par
   au moins une des extrémités. Compatibilité avec le chiffrement de bout en bout
   contribuerait également à empêcher le déploiement généralisé d'encore un autre
   ensemble de services dont, pour bénéficier, il faut garder son
   contenu du paquet en clair pour que tous puissent fouiner.

   Considérations IAB:

   (2.1) Consentement à une partie: un cadre OPES normalisé dans l'IETF
   doit exiger que l'utilisation de tout service OPES soit explicitement
   autorisé par l'un des hôtes d'extrémité de la couche application (c'est-à-dire
   le fournisseur de contenu ou le client).

   (2.2) Communications de la couche IP: pour un cadre OPES normalisé
   l'IETF, l'intermédiaire OPES doit être explicitement adressé au
   Couche IP par l'utilisateur final.

   Nous notons que (2.2) ne vise pas à empêcher une chaîne de
   intermédiaires, avec le premier intermédiaire de la chaîne explicitement
   adressé à la couche IP par l'utilisateur final.

3. Intégrité de bout en bout

   Les services OPES proposés ont plusieurs formes possibles, notamment
   services centrés sur le serveur, tels que l'assemblage dynamique de pages Web,
   explicitement autorisé par le fournisseur de contenu; centré sur le client
   services tels que l'analyse antivirus ou la traduction de langue explicitement
   autorisé par l'utilisateur final à agir sur la réponse du contenu
   fournisseur; et des services centrés sur le client tels que les services basés sur la confidentialité
   ou filtrage de contenu explicitement autorisé par l'utilisateur final à agir sur
   la demande de l'utilisateur final au fournisseur de contenu. Nous considérons
   la question de l'intégrité de bout en bout des données séparément pour ces
   différentes classes de services.

   Pour chaque service spécifique, la question se pose de savoir s'il est
   nécessaire pour que le fournisseur de contenu et l'utilisateur final puissent
   pour détecter et répondre aux comportements inappropriés d'OPES
   intermédiaires, ou si cela suffit pour une seule des deux extrémités
   hôtes pour avoir cette capacité. Nous n'essayons pas une réponse générale, mais
   nous discutons les problèmes plus en détail dans les sections ci-dessous.

3.1. Intégrité des données avec les services OPES centrés sur le client sur les réponses

   Pourquoi y a-t-il des préoccupations concernant l'intégrité de bout en bout des données dans un
   service OPES centré sur le client agissant sur une réponse d'un contenu
   fournisseur? Si le client demande un service tel que l'analyse antivirus ou
   traduction de la langue, pourquoi est-ce que cela concerne le contenu
   fournisseur d'une manière ou d'une autre? Une réponse est que l'un des
   les préoccupations de l'IETF sont de concevoir des architectures qui permettent aux hôtes finaux
   pour détecter et répondre aux actions inappropriées sur le réseau. Ce
   semble particulièrement important pour les appareils puissants du réseau
   tels que les intermédiaires OPES, qui sont autorisés par l'un des
   nœuds pour agir ou transformer des données dans le réseau, mais à part cela
   ne sont pas sous le contrôle direct de ce nœud d'extrémité.

   Considérez comme exemple les services de détection de virus ou de langage
   Traduction. L'utilisateur final dispose d'un pouvoir raisonnable pour détecter et
   gérer des antivirus ou un langage imparfaits ou corrompus
   traducteurs qui sont sous son contrôle direct (p. ex., seule
   machine). L'utilisateur final sait exactement quel programme est installé et
   a un accès direct au contenu avant et après le service

   appliqué. L'utilisateur final aurait moins de contrôle sur des services similaires
   offert par OPES dans le réseau lui-même, où l'utilisateur final
   le contrôle peut être celui binaire d'autoriser ou non le contrôle
   un service. (Nous notons également que les services déployés sur l'hôte final dans un
   les modes autonomes, comme un programme local de détection de virus, sont
   pas un service dans le réseau, et ne sont donc pas dans la province
   de l'IETF d'une manière ou d'une autre.)

   Pour un service OPES tel que l'analyse antivirus ou la traduction de langue,
   l'utilisateur final pourrait détecter un intermédiaire corrompu, mais uniquement par
   une approche «boîte noire» de comparaison de l'entrée avec la sortie. Ce
   est également imprécis et nécessite un certain effort, par rapport à l'effort
   requis pour détecter un antivirus corrompu installé seul
   machine. Par exemple, l'utilisateur pourrait récupérer la version "non-OPES"
   du contenu directement du fournisseur de contenu, s'il y a
   version "non-OPES", et comparez-la avec la version "OPES" du
   contenu disponible auprès de l'intermédiaire OPES. Cependant, dans le cas
   de contenu dynamique, la version "non-OPES" du contenu récupéré
   par l'utilisateur directement à partir du fournisseur de contenu peut ne pas nécessairement
   être identique à la version "non-OPES" du contenu considéré par
   l'intermédiaire OPES. Ce contrôle limité par l'utilisateur final du
   Service OPES et la capacité limitée de l'utilisateur final à détecter
   intermédiaires imparfaits ou corrompus, plaide pour une architecture
   qui aide le fournisseur de contenu à détecter et à répondre aux imperfections ou
   des intermédiaires OPES corrompus également.

   Nous considérons l'exemple spécifique du scan antivirus, autorisé par le
   l'utilisateur final en tant que service OPES. On pourrait imaginer l'analyse antivirus comme un
   service OPES largement déployé, augmentant le scan antivirus effectué sur
   l'hôte final lui-même. Si je demande, disons, un article de Steve Bellovin sur
   sécurité et virus sur le réseau, et suis informé par mon
   Service d'analyse antivirus OPES que ce contenu ne passe pas
   antivirus, il existe plusieurs possibilités:

   (1) Inconnu de Steve, le contenu (c'est-à-dire l'article de Steve) contient un
       virus nuisible.

   (2) Steve a volontairement inséré un virus dangereux dans le contenu, avec
       intention ludique ou malveillante.

   (3) Le scanner de virus OPES ne peut pas faire la distinction entre un véritable
       virus et l'article de Steve sur les virus nuisibles.

   (4) Mon antivirus OPES local a été piraté, avec
       intention, de rejeter tout le contenu de Steve Bellovin.

   À un moment donné, pour certains contenus, une implémentation largement déployée
   de certains antivirus OPES est susceptible d'entraîner un problème (3), et
   certaines implémentations OPES sont susceptibles d'être corrompues pour entraîner
   problème (4). Parce que l'utilisateur final a un contrôle limité sur l'OPES
   antivirus, l'utilisateur final est également limité dans sa capacité à détecter
   problèmes (3) ou (4) dans le scanner de virus OPES. De plus, le
   le fournisseur de contenu est probablement celui qui est le plus incité à
   détecter les problèmes (3) ou (4) dans le scanner de virus OPES. (Le contenu
   le fournisseur est généralement fortement incité à détecter le problème (1) car
   Dans ce cas, il semble prudent que l'OPES global
   l'architecture doit être soigneusement conçue pour empêcher le service OPES
   du scan antivirus, tel qu'autorisé par le client, de
   empêcher la distribution de contenu qui en fait n'a pas
   virus.

   De toute évidence, il n'est pas viable de proposer que les fournisseurs de contenu
   indiquent que certains contenus doivent être transmis à l'utilisateur final sans
   analyse antivirus - le but de l'analyse antivirus est que l'utilisateur final
   exercer un contrôle à cet égard. Cependant, si une forme de système d'extrémité
   la notification permet au fournisseur de contenu de savoir que le contenu
   est rejeté par un service d'analyse antivirus au lieu d'être
   livré à l'utilisateur final, puis au fournisseur de contenu (Steve, dans ce
   case) peut souhaiter informer les utilisateurs finaux que ce contenu est connu par
   le fournisseur de contenu de ne pas passer certains services de scan antivirus OPES.
   Les utilisateurs finaux pourraient alors prendre leurs propres décisions sur l'opportunité de
   récupérer ce contenu en contournant le service d'analyse antivirus OPES,
   en s'appuyant sur leur propre antivirus ou sur une autre analyse antivirus
   service pour ce contenu particulier. Une telle notification de système d'extrémité à
   le fournisseur de contenu, s'il est demandé, ne peut pas être appliqué et ne peut pas être
   invoqué par des intermédiaires corrompus, mais il semble important
   Néanmoins.

   Bien sûr, les utilisateurs malveillants peuvent également utiliser leur connaissance du virus
   service d'analyse pour perfectionner leur capacité à construire des
   virus qui peuvent échapper au service d'analyse antivirus. Ce sera fait
   de toute façon, avec n'importe quel service d'analyse de virus, et semble être un
   coût pour permettre aux fournisseurs de contenu une certaine protection contre les aléas
   services OPES imparfaits ou corrompus sur le réseau.

   Ainsi, pour les services demandés par le client tels que l'analyse antivirus et
   traduction de la langue, il est clairement souhaitable pour le serveur d'origine
   d'avoir une notification, s'il le demande, que ces services sont
   en cours sur son contenu avant que le contenu ne soit envoyé au
   client. Une telle notification de système d'extrémité pourrait être accompagnée
   performances réduites (en termes de frais généraux, de retards, etc.) pour l'OPES
   service appliqué à ce contenu. Mais une forme de système d'extrémité

   une notification est clairement nécessaire pour que les fournisseurs de contenu puissent
   pour détecter et répondre aux actions des intermédiaires OPES
   jugé inapproprié par le fournisseur de contenu.

   De même pour un service OPES de traduction de langue basé sur le client, il
   est clairement souhaitable que les fournisseurs de contenu puissent informer et
   utilisateurs lorsque certains contenus sont considérés par le fournisseur de contenu comme
   incompatible avec la traduction linguistique. Dans ce cas, l'important
   le problème n'est pas d'empêcher la traduction en langue OPES d'être
   effectuée sur le contenu, mais à la place de donner au fournisseur de contenu
   un mécanisme pour découvrir la traduction de la langue et pour informer
   l'utilisateur final (ou plus précisément, pour informer l'hôte de l'utilisateur final
   ordinateur) si le fournisseur de contenu estime que cette langue
   la traduction est incompatible avec ce contenu particulier.

   Considérations IAB:

   (3.1) Notification: le cadre global OPES doit aider
   fournisseurs de contenu dans la détection et la réponse aux
   les actions des intermédiaires OPES jugées inappropriées par le
   fournisseur de contenu.

3.2. Intégrité des données avec les services OPES centrés sur le serveur

   Quelles sont les préoccupations, le cas échéant, concernant l'intégrité de bout en bout des données
   dans un service OPES centré sur le serveur, comme des services basés sur la localisation?
   Par exemple, CNN pourrait autoriser un service OPES basé sur l'emplacement, où
   l'intermédiaire OPES insère le bulletin météo ou l'actualité de
   l'intérêt régional dans la page Web demandée. Le même problème de la
   détection et réponse aux intermédiaires OPES cassés ou modifiés
   se produit avec OPES centré sur le serveur comme avec les services OPES centrés sur le client.
   Nous considérons uniquement les services centrés sur le serveur sur les réponses, car nous ne le sommes pas
   au courant de toute proposition de services OPES centrés sur le serveur sur les demandes
   du client au fournisseur de contenu.

   Comment les nœuds d'extrémité détectent-ils les actions inappropriées d'OPES?
   services autorisés par le fournisseur de contenu? Le service OPES est
   effectuée chez un intermédiaire OPES dans le réseau lui-même, et
   pas sous le contrôle direct du fournisseur de contenu; en particulier,
   le fournisseur de contenu n'a peut-être pas la capacité de surveiller directement
   la sortie de l'intermédiaire OPES. On pourrait soutenir que le
   fournisseur de contenu et intermédiaire OPES centré sur le serveur font partie d'un
   application distribuée unique, et peuvent être responsables de leur propre chef
   pour détecter et traiter les OPES cassés ou modifiés
   intermédiaires, sans impliquer l'utilisateur final. Mais c'est
   peu convaincant, arguant essentiellement que la normalisation des protocoles
   l'exécution des services OPES est un problème de réseau dans le domaine de
   l'IETF, mais garantir l'intégrité globale du service est un

   question d'application distribuée, et pas dans la province de l'IETF
   du tout. Il nous semble que vous ne pouvez pas jouer sur les deux tableaux.
   Identifier simplement le fournisseur de contenu et l'intermédiaire OPES comme
   une partie de la même application distribuée ne donne pas le contenu
   fournisseur la capacité de surveiller les actions de l'intermédiaire OPES.

   Cependant, si l'utilisateur final reçoit une forme de notification qui
   ces services OPES ont été fournis et disposent d'un mécanisme pour
   recevoir le contenu "non-OPES" du fournisseur de contenu sans
   les modifications de l'intermédiaire OPES (s'il existe une
   non-OPES du contenu), alors l'utilisateur final est dans une meilleure
   position pour détecter et réagir aux actions inappropriées de
   intermédiaires OPES compromis ou mal conçus. Ainsi, c'est
   clairement qu'une certaine forme de notification du système d'extrémité est nécessaire pour permettre
   l'utilisateur final pour détecter et répondre aux OPES cassés ou modifiés
   intermédiaires. Si l'utilisateur final a une notification d'action par OPES
   intermédiaires, il pourrait «veto» un service OPES simplement en lançant
   le contenu modifié par OPES. Et si le client veut parler
   directement au serveur d'origine pour recevoir la version "non-OPES", et
   le serveur d'origine est configuré pour autoriser cela, puis OPES
   l'intermédiaire doit être conçu de manière à permettre cette opération de bout en bout
   la communication.

   En plus des préoccupations concernant la détection et la réponse aux problèmes
   intermédiaires OPES compromis, il y a
   préoccupations concernant l'intégrité des données. Si le fournisseur de contenu regarde
   à l'adresse IP source de la requête HTTP, ou lance une pièce, dans
   afin de décider quel contenu fournir, alors c'est le contenu
   les affaires du fournisseur. Mais s'il existe une version "non-OPES" de
   certains contenus disponibles auprès du fournisseur de contenu, et également modifiés
   versions disponibles auprès des intermédiaires OPES, alors il est important
   que les utilisateurs finaux pourraient découvrir qu'ils reçoivent un
   version modifiée du réseau, et non la version "non-OPES"
   qui est également disponible directement auprès du fournisseur de contenu.

   Considérations IAB:

   (3.2) Notification: le cadre global OPES devrait aider à
   utilisateurs dans la détection du comportement des intermédiaires OPES, potentiellement
   leur permettant d'identifier les intermédiaires imparfaits ou compromis.

   (3.3) Non bloquant: s'il existe une version "non-OPES" du contenu
   disponible auprès du fournisseur de contenu, l'architecture OPES ne doit pas
   empêcher les utilisateurs de récupérer cette version "non-OPES" du
   fournisseur de contenu.

3.3. Intégrité des données avec les services OPES centrés sur le client sur les demandes

   Il y a également eu des propositions de services OPES autorisés par le
   client sur les demandes du client au fournisseur de contenu. Exemples
   inclure des services qui suppriment des champs de l'en-tête HTTP pour l'ajout
   services de confidentialité et de filtrage de contenu qui filtrent les demandes en fonction
   L'URL demandée. Pour de tels services, il y a encore un besoin de fin
   les hôtes doivent être aidés à détecter et à répondre aux
   intermédiaires corrompus, mais il semble moins clair dans quelle mesure
   s'applique au fournisseur de contenu et dans quelle mesure il s'applique au
   l'utilisateur final qui a autorisé le service. Les exigences seront probablement
   doivent être déterminées par l'OPEES et les communautés plus larges de l'IETF sur un
   au cas par cas pour chaque service spécifique.

4. Adresses de couche application

   La plupart des adressages de couche application tournent autour des URI, qui, pour
   la plupart du temps, donnez une méthode structurée pour faire référence à une seule donnée
   entité sur un serveur distant. Les URI sont universels en ce que, en principe,
   le même résultat est obtenu quelle que soit la localisation du
   client effectuant la résolution.

   La pratique diffère souvent de cette théorie - les suppresseurs d'annonces suppriment des données
   à partir de pages côté client; les batteries de serveurs Web redirigent les clients vers
   l'une des nombreuses machines cibles potentielles pour l'équilibrage de charge ou pour
   donner à l'utilisateur un contenu «localisé».

   Cependant, d'un point de vue architectural, il est important d'être
   clair sur ce qui se fait ici. Dans tous les cas, résolution URI
   les normes (telles que définies pour les schémas d'URI individuels, tels que HTTP) s'appliquent
   inchangé entre le client et l'intermédiaire OPES. Qu'est-ce que
   que l’intermédiaire fait pour répondre à la demande n’est pas
   discussion, et doit produire un résultat conforme à la
   définition du schéma d'URI applicable. En ce sens, l'OPES
   l'intermédiaire est le «point final» de la résolution d'URI.

   Dans OPES centré sur le client, l'intermédiaire résout l'URI sur
   au nom du client, puis appliquer les services demandés par le client à
   fournir une réponse de données au client. Le client obtient les données qu'il
   voulu, mais il n'a pas effectué la résolution d'URI.

   Dans OPES centré sur le serveur, le "serveur d'origine" cède son autorité à
   l'intermédiaire pour déterminer quel est le contenu «approprié» à
   fournir pour un URI donné. Le client peut bien exécuter l'URI standard
   résolution, mais cela ne va pas plus loin que l’intermédiaire.

   Avec ces distinctions fermement à l'esprit, il y a deux
   domaines de préoccupation pour les services de type OPES.

   Le premier est l'examen de l'effet d'une série de
   interactions, au fil du temps et du lieu (c.-à-d.
   récupération). Les problèmes potentiels incluent des incohérences dans les
   et références inter-documents - en fonction du contenu
   modifié, les références d'une version d'un document peuvent ne pas exister dans
   une cible modifiée, etc.

   L'autre préoccupation est de savoir si cela conduit à la création de contenu
   qui est exclusivement accessible par l'utilisation d'un intermédiaire.
   Autrement dit, il n'y a pas de version "non-OPES". Soit cela ne devrait pas être
   autorisé, ou cela plaiderait pour une extension à Internet
   architecture d'adressage de la couche application.

   Considérations IAB:

   (4.1) Résolution d'URI: la documentation OPES doit être claire dans la description
   ces services comme étant appliqués au résultat de la résolution d'URI, et non
   comme résolution URI elle-même.

   (4.2) Validité de référence: tous les services proposés doivent définir leur
   impact sur la validité de référence inter et intra-document.

   (4.3) Tout service qui ne peut être réalisé en respectant ce qui précède
   deux considérations peuvent être examinées en tant qu'exigences potentielles pour
   Applications Internet adressant les extensions d'architecture, mais ne doivent pas
   être entrepris en tant que correctifs ad hoc.

5. Confidentialité

   Les intermédiaires au milieu du réseau augmentent le nombre de
   les emplacements où la confidentialité d'une transaction de bout en bout pourrait être
   compromis. Certains de ces problèmes de confidentialité s'appliquent aux caches Web et
   CDN en général ainsi que spécifiquement aux intermédiaires OPES. Il
   semble une exigence raisonnable, pour OPES d'être affrété dans l'IETF,
   que la question de la fourniture de mécanismes permettant aux utilisateurs finaux de déterminer
   les politiques de confidentialité des intermédiaires OPES devraient être abordées. Celles-ci
   les mécanismes peuvent être très différents pour les clients et les serveurs
   services OPES centrés.

   Pour un problème complexe tel qu'une architecture OPES, qui interagit
   avec les protocoles d'autres organismes de normalisation ainsi que d'autres IETF
   groupes de travail, il semble nécessaire de garder à l’esprit l’ensemble
   image tout en décomposant des parties spécifiques du
   problème à normaliser dans certains groupes de travail. Ainsi, un
   exigence que l'architecture globale OPES traite de la confidentialité
   préoccupations ne signifie pas nécessairement que les mécanismes de ce besoin
   à développer dans l'IETF, ou dans le groupe de travail OPES (s'il
   affrété).

   Considérations IAB:

   (5.1) Confidentialité: le cadre global OPES doit prévoir des mécanismes
   pour que les utilisateurs finaux déterminent les politiques de confidentialité d'OPES
   intermédiaires.

6. Résumé des considérations de l'IAB

   (2.1) Consentement à une partie: un cadre OPES normalisé dans l'IETF
   doit exiger que l'utilisation de tout service OPES soit explicitement
   autorisé par l'un des hôtes d'extrémité de la couche application (c'est-à-dire
   le fournisseur de contenu ou le client).

   (2.2) Communications de la couche IP: pour un cadre OPES normalisé
   l'IETF, l'intermédiaire OPES doit être explicitement adressé au
   Couche IP par l'utilisateur final.

   (3.1) Notification: le cadre global OPES doit aider
   fournisseurs de contenu dans la détection et la réponse aux
   les actions des intermédiaires OPES jugées inappropriées par le
   fournisseur de contenu.

   (3.2) Notification: le cadre global OPES devrait aider à
   utilisateurs dans la détection du comportement des intermédiaires OPES, potentiellement
   leur permettant d'identifier les intermédiaires imparfaits ou compromis.

   (3.3) Non bloquant: s'il existe une version "non-OPES" du contenu
   disponible auprès du fournisseur de contenu, l'architecture OPES ne doit pas
   empêcher les utilisateurs de récupérer cette version "non-OPES" du
   fournisseur de contenu.

   (4.1) Résolution d'URI: la documentation OPES doit être claire dans la description
   ces services comme étant appliqués au résultat de la résolution d'URI, et non
   comme résolution URI elle-même.

   (4.2) Validité de référence: tous les services proposés doivent définir leur
   impact sur la validité de référence inter et intra-document.

   (4.3) Tout service qui ne peut être réalisé en respectant ce qui précède
   deux considérations peuvent être examinées en tant qu'exigences potentielles pour
   Applications Internet adressant les extensions d'architecture, mais ne doivent pas
   être entrepris en tant que correctifs ad hoc.

   (5.1) Confidentialité: le cadre global OPES doit prévoir des mécanismes
   pour que les utilisateurs finaux déterminent les politiques de confidentialité d'OPES
   intermédiaires.

7. Conclusions

   Ce document comprend des commentaires et des recommandations du CCI sur
   certains problèmes d'architecture et de politique liés à la charte de
   OPES dans l'IETF.

8. Remerciements

   Ce document a bénéficié de discussions avec les membres de l'IAB
   et l'IESG, contributeurs à OPES, John Wroclawski et autres.
   Cependant, il s'agit d'un document de l'IAB, et nous ne prétendons pas que le
   les autres personnes énumérées ci-dessus sont d'accord avec le contenu.

9. Références

   [Carr01] Wayne Carr, "Suggestions d'exigences OPES pour l'intégrité,
               Confidentialité et sécurité ", email à ietf-openproxy@imc.org,
               16 août 2001. URL "http://www.imc.org/ietf-
               openproxy / mail-archive / msg00869.html ".

   [CDT01] Préoccupations politiques soulevées par le groupe de travail OPES proposé
               Efforts, email à l'IESG, du Center for Democracy
               & Technology, 3 août 2001. URL
               "http://www.imc.org/ietf-openproxy/mail-
               archive / msg00828.html ".

   [Clark88] David D. Clark, La philosophie de conception de la DARPA
               Protocoles Internet, SIGCOMM 1988.

   [Morris01] John Morris, "Re: corrigé - OPES suggéré
               Exigences en matière d'intégrité, de confidentialité et de sécurité ",
               28 septembre 2001. Courriel à ietf-openproxy@imc.org, URL
               "http://www.imc.org/ietf-openproxy/mail-
               archive / msg00935.html ".

   [ODell01] Mike O'Dell, "OPES continue mousse ...", Message-Id:
               <200107101341.JAA30276@ccr.org>, 10 juillet 2001, courriel à
               ietf@ietf.org. URL "http://www1.ietf.org/mail-
               archive / ietf / Current / msg12650.html ".

   [OPES] Ouvrez la page Web des services Edge enfichables (OPES),
               "http://www.ietf-opes.org/".

   [OPESBOF1] OPES BOF, 49e IETF, 12 décembre 2000. Ordre du jour:
               "http://www.ietf.org/ietf/00dec/opes-agenda.txt".
               Procès-verbal: "http://www.ietf.cnri.reston.va.us/
               procedure / 00dec / toc.htm # P25_256 ".

   [OPESBOF2] OPES BOF, 50e IETF, 9 mars 2001. Procès-verbal:
               "http://www.ietf.org/proceedings/01mar/ietf50-40.htm".

   [OPESBOF3] OPES BOF, 51e IETF, août 2001. Ordre du jour:
               "http://www.ietf.org/ietf/01aug/opes.txt". Minutes:
               "http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM".

   [Orman01] Hilarie Orman, "L'intégrité des données pour Open Pluggable
               Services », courriel à ietf-openproxy@imc.org, 15 août
               2001. URL "http://www.imc.org/ietf-openproxy/mail-
               archive / msg00865.html ".

   [RFC 2316] Bellovin, S., "Report of the IAB Security Architecture
               Workshop », RFC 2316, avril 1998.

   [RFC2401] Kent, S. et R. Atkinson, "Security Architecture for the
               Protocole Internet », RFC 2401, novembre 1998.

   [RFC 3040] Cooper, I., Melve, I. et G. Tomlinson, "Internet Web
               Replication and Caching Taxonomy ", RFC 3040, janvier
               2001.

   [RFC 3135] Border, J., Kojo, M., Griner, J., Monténégro, G. et Z.
               Shelby, «Proxies d'amélioration des performances destinées à
               Mitigate Link-Related Degradations ", RFC 3135, juin 2001.

   [Routson01] Joyce Routson, IETF's Edge Standards Controversy, juillet
               11, 2001, Semaine Stardust CDN. URL
               "http://www.stardust.com/cdnweek/articles/2001/07/09/
               opes.htm ".

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

   Ce document ne propose pas de nouveaux protocoles, et
   n'implique aucune considération de sécurité dans ce sens. cependant,
   tout au long de ce document, il y a des discussions sur la confidentialité et
   les problèmes d'intégrité des services OPES et les exigences architecturales
   créé par ces problèmes.

11. Considérations IANA

   Il n'y a pas de considérations IANA concernant ce document.

Adresses des auteurs

   Conseil d'architecture Internet
   Courriel: iab@iab.org

   Adhésion au moment de la rédaction de ce document:

   Harald Alvestrand
   Ran Atkinson
   Rob Austein
   Fred Baker
   Steve Bellovin
   Brian Carpenter
   Jon Crowcroft
   Leslie Daigle
   Steve Deering
   Sally Floyd
   Geoff Huston
   John Klensin
   Henning Schulzrinne

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

   Copyright (C) L'Internet Society (2002). Tous les droits sont réservés.

   Ce document et ses traductions peuvent être copiés et fournis à
   d'autres et des œuvres dérivées qui le commentent ou l'expliquent autrement
   ou aider à sa mise en œuvre peut être préparé, copié, publié
   et distribué, en tout ou en partie, sans restriction d'aucune
   genre, à condition que l'avis de droit d'auteur ci-dessus et ce paragraphe soient
   inclus sur toutes ces copies et œuvres dérivées. Cependant, ce
   le document lui-même ne peut être modifié d'aucune manière, par exemple en supprimant
   l'avis de droit d'auteur ou les références à l'Internet Society ou à d'autres
   Organisations Internet, sauf en cas de besoin aux fins de
   élaborer des normes Internet, auquel cas les procédures
   les droits d'auteur définis dans le processus des normes Internet doivent être
   suivi, ou au besoin pour le traduire dans des langues autres que
   Anglais.

   Les autorisations limitées accordées ci-dessus sont perpétuelles et ne seront pas
   révoqué par l'Internet Society ou ses successeurs ou ayants droit.

   Ce document et les informations qu'il contient sont fournis sur un
   Base "TEL QUEL" et LA SOCIÉTÉ INTERNET ET L'INGÉNIERIE INTERNET
   TASK FORCE DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS
   MAIS SANS S'Y LIMITER UNE GARANTIE QUE L'UTILISATION DES INFORMATIONS
   LES PRÉSENTES NE VIOLENT AUCUN DROIT NI AUCUNE GARANTIE IMPLICITE DE
   QUALITÉ MARCHANDE OU ADÉQUATION À UN USAGE PARTICULIER.

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/