Mon blog

Traditionnellement, l'architecture de l'Internet était de bout en bout, ce qui signifie que les éléments intermédiaires ne jouaient qu'un rôle réduit. Aujourd'hui, cette architecture a de fait évolué et les "trucs au milieu", qui changent les données échangées sont de plus en plus nombreux. OPES (Open Pluggable Edge Services) tente de formaliser cette nouvelle architecture.

C'était un principe cardinal de l'Internet : mettre l'intelligence aux bords du réseau, chez le client et le serveur, et ne pas tenter de fournir des servics avancés dans le cœur du réseau. Ce principe a été informellement remis en cause par l'accumulation d'éléments intermédiaires qui ajoutent leur propre traitement. Citons par exemple :

• Un relais Web comme Squid qui garde en mémoire les pages demandées, pour les servir plus rapidement la prochaine fois,
• Un relais Web comme Junkbuster qui filtre les publicités hors des pages Web.

Ces logiciels ne relèvent pas d'une architecture commune et chacun utilise son propre protocole, son propre mécanisme de configuration, ses propres méthodes de traçabilité...

OPES va donc essayer d'ordonner tout cela. Ce premier RFC décrit des scénarios d'usage afin de donner une première approche d'OPES et des cas où il peut être utile.

Notre RFC décrit donc des services qui peuvent modifier les requêtes envoyées à un serveur ou bien modifier les réponses du serveur. Il explique ce qu'est un processeur OPES (l'entité qui va faire les modifications) et un serveur sous-traitant (callout server), auquel le processeur transmet certains traitements. Une description plus précisé de l'architecture d'OPES figure dans le RFC 3238.

Comme OPES soulève d'énormes problèmes à la fois liés à l'architecture (il redéfinit une architecture traditionnelle de l'Internet) et à la sécurité (puisqu'un processeur OPES s'interpose entre deux acteurs, il peut agir de façon maligne), l'IAB a exprimé, dans le RFC 3238 de sérieuses réserves auxquelles le RFC 3835, qui décrit l'architecture d'OPES, répond.