Veille Technologique Sécurité - cert devoteam

Avril 2001
NOS COMMENTAIRES
LES RFC
RFC 3091
Pi Digit Generation Protocol
Ce standard IETF de 6 pages paru en tout début de mois décrit une implémentation (objets ASCII et protocoles) de
génération de caractères ASCII numériques de type Chargen et appelée PIgen.
Un tel système permet de diffuser des valeurs numériques correspondant à des décimales de la valeur Pi de façon
précise ou approximative soit par une application basée sur TCP en mode connecté, soit sur UDP en mode non
connecté, soit en mode multicast.
Sous TCP, l’application génère de façon périodique les décimales. Notons que la valeur entière ("3") n’est pas
générée, car considérée connue de tous. Sous UDP, il s’agit d’un mode de type question/réponse. La requête émise
doit contenir le numéro de la décimale de Pi requise. La réponse contient 3 éléments : le numéro de la décimale, un
symbole ":" et la valeur de la décimale requise.
Dans le service de génération dit "précis", le port applicatif est fixe et est égal à 31415.
Dans le service de génération dit "approché (ou approximate)", le port applicatif est fixe et est égal à 22007. cette
valeur est, semble-t-il, faite pour rappeler de façon mnémotechnique que le calcul approximé est basé sur le calcul
de la division de la valeur "22" par "7".
Dans le service en mode de diffusion, l’application utilise le protocol UDP et diffuse des blocs aléatoires de valeurs
numériques correspondant à des décimales de Pi. Le groupe de multicast utilisé est 314.159.265.359.
Ce document a pour particularité de contenir au moins 2 éléments que nous nous permettons de qualifier
d’imprécisions majeures.
La première concerne le calcul en mode dit "approximate". En effet, il aurait été préférable de se baser sur la division
de "333" par "106", plus précise, qui a pour mérite de fournir les 4 premières décimales correctes (au lieu de 2 dans
le cas proposé dans la RFC). Dans la logique de la RFC, le port applicatif à utiliser serait plutôt le 333106, tant en
TCP qu’en UDP.
La seconde concerne le choix de l’adresse de multicast et posera sans doute des problèmes d’implémentation. En
effet, il n’est pas précisé quelle était la classe de cette adresse de diffusion : il s’agit d’une erreur surprenante de la
part de l’IETF sachant que 3 des 4 valeurs numériques de cette adresse sont hors normes …
D'une lecture pourtant simple et compréhensible par la plupart des internautes, il s'agit d'un RFC dont on ne risque
pas de voir le contenu implémenté tant que les imprécisions ne seront pas corrigées. Comme il est rappelé dans la
partie "Security Considerations" de ce RFC, il est impératif de se baser sur des serveurs fiables implémentant le
protocole Pigen, car "the imminent collapse of the Internet is assured if this guideline is not strictly followed"
Le lecteur voulant réaliser sa propre implémentation du protocole pourra d’ailleurs trouver des éléments concernants
les décimales de Pi sur le site http://pi.super-computing.org
ftp://ftp.isi.edu/in-notes/rfc3091.txt
RFC 3093
Firewall Enhancement Protocol (FEP)
Ce standard IETF de 11 pages paru lui aussi en tout début de mois décrit une implémentation permettant de
véhiculer tout datagramme TCP ou UDP au sein du protocole HTTP.
L’encapsulation dans le protocole HTTP (TCP sur le port 80) qui passe de façon transparente la quasi totalité des
firewalls du marché, permettrait de véhiculer n’importe quelle application, même les plus complexes qui utilisent des
ports appplicatifs utilisés de façon aléatoire.
Il faut savoir que l’un des auteurs de ce RFC est le célèbre Scott Bradner de l’Université de Harvard, et qu’il semble
avoir usé de sa notoriété pour convaincre les différents vendeurs de gardes barrières d’implémenter sous peu ce
protocole, dont le sigle (FEP) en rappellera sans doute un autre aux personnes ayant travaillé il y a une dizaine
d’années dans le domaine des réseaux (Front End Processor).
Notons que bien qu'il ne s'agisse ici que d'un texte humoristique, le mécanisme présenté est 'hélas' d'ores et déjà
utilisé dans le but de court-circuiter les filtres de sécurité mis en place !
ftp://ftp.isi.edu/in-notes/rfc3093.txt
LES DRAFTS
DRAFT-MONTENEGRO-SUCV-00.TXT
Statistically Unique and Cryptographically Verifiable Identifiers and Addresses
Cette proposition de standard répond au problème de la propriété de l'identifiant dans le monde du "mobile IP" dans
Veille Technologique Sécurité N°33 Page 20/59
© APOGEE Communications - Tous droits réservés Diffusion restreinte aux clients abonnés aux services VTS-RAPPORT et VTS-ENTREPRISE