Les protocoles et services de présentation :

ASN.1, XDR et Produits

Introduction

• Problématique liée à la représentation de données sur un réseau

• Solutions possibles

• XDR

• ASN.1

• Comparaison XDR / ASN.1

• Applications
  

La couche présentation - Objectif:

- On veut pouvoir conserver le sens des informations transmises à travers le réseau
- Cette couche suppose l'existence d’une communication fiabilisée entre les 2 machines concernées

Problématique

La représentation des données est souvent différente pour 2 machines distantes :

• l'ordre des octets peut être différent (octets les plus significatifs en premier ou alors en dernier)
• les entiers peuvent être codés sur 2 ou 4 octets (voire plus)
• le codage des nombre à virgule flottante est souvent différent
• le codage des caractères peut être réalisé suivant différentes standars (ASCII , Unicode , ...)
• le codage de fin de ligne peut être par exemple la suite de caractères CR / LF ou alors seulement le caractère LF

Il est difficile de transmettre des structures de données complexes : comment choisir l'ordre d'envoi des sous-parties, ...

Il faut pouvoir minimiser le nombre de bits transmis afin de ne pas utiliser la bande passante de façon trop importante

On doit aussi éventuellement pouvoir sécuriser les données qui vont transiter sur le réseau car certaines informations sensibles peuvent être communiquées entre les sites distants.

Solutions techniques

Il est nécessaire de pouvoir disposer d'une représentation commune des données entre les 2 communicants :

Cette représentation correspond à la notion de contexte de présentation qui est défini par le couple :

- Syntaxe abstraite

- Syntaxe de transfert

Syntaxe abstraite :

Syntaxe de transfert :

Illustration de l’utilisation des syntaxes :

Services offerts à la couche application :

• La négociation des contextes de transferts
• La conversion de la syntaxe concrète en syntaxe de transfert (et vice-versa)
  
  

XDR

« eXtended Data Representation »

Protocole développé initialement par SUN pour permettre le transfert des données lors d'appels à des procédures distantes avec RPC.
Défini dans la RFC 1014

• Toutes les données sont codées sur des multiples de 4 octets (avec octet le plus signifiant en premier)
• Le typage est implicite (on ne transmet pas le type des données)
  

Afin d'assurer un alignement des données sur des multiples de 4 octets, des octets résiduels (qui contiennent la valeur 0) sont rajoutés de façon à constituer un bloc de données qui aura une taille multiple de 4. Les types de données ont une et une seule syntaxe de transfert qui est décrite dans le tableau suivant:

Les types complexes sont définis à partir de types simples :

- Array (de taille fixe ou variable) :

- Structure :

Une déclaration de Structure en XDR est basée sur celle qui est définie dans le langage C et à la syntaxe :struct {
composant-1;
...
composant-n;
} nom-structure;

Chaque composant de la structure est encodé dans l'ordre dans lequel il a été déclaré. La taille de chacun des composants doit être un multiple de 4 octets , bien que chaque composant puisse avoir une taille différente.

- Discriminated Union :

- Typedef

- Void

Un element de type void est un quantité de 0 octets qui peut être utilisée dans les spécifications. C'est utilisé pour les opérations qui ne nécéssitent pas de données en entrée ou sortie par exemple. Ce peut être aussi utilisé pour spécifié une branche nulle d'une Discriminated Union

Exemple de spécification XDR :

Struct fichier {
string nomfichier<255>;
opaque donnees;
}

ASN.1

« Abstract Syntax Notation One »

• ASN.1 est issu de X.409 (conçu initialement pour X.400)

• ASN.1 a ensuite été spécifié par les normes ISO 8824 , X.208
  Puis une révision a conduit à la définition des normes X.680,X.681,X.682,X.683

• C'est un langage pour décrire les syntaxes abstraites
  

• La syntaxe abstraite est totalement indépendance des syntaxes de transferts

• Le typage des données est explicite (le type transmis est transféré sur le réseau)

• Définitions des types dans des modules (réutilisables ensuite avec importation)

  Un type est défini par une collection de valeurs qui peut être distinguée effectivement d'autres valeurs.
  Ainsi ce concept peut se rapprocher de la notation de type dans la langage de programmation avec toutefois une différence majeure puisque les types d'ASN.1 sont abstraits. A partir de types existants on peut définir des sous-types, ce qui permet ainsi la définitions de types de façon récursive.
  
  Les types sont divisés en 4 groupes :
  
  
• Les types basiques : valeurs caractérisées facilement , indépendamment d'autres types
• Les types structurés : types complexes définis à partir d'autre types
• Les modules : constituent des paquetages de plusieurs définitions de types
• Les tags : permettent de rajouter des informations pour certains types afin de faciliter le codage et décodage (voir plus loin dans la description de BER)
  
  La définition d'un type est constituée de 3 éléments : un nom qui représentera le nouveau type, le symbole '::=' et la description du type :
  [Nom type] ::= [Description du type]
  Pour attribuer une valeur, cela correspond à la définition d'un type en intercalant le nom du type entre la valeur et le symbole ::= :
  [Nom valeur] [Nom type] ::= [Description valeur]
  

Il existe un ensemble de types basiques qui sont les éléments de bases pour décrire la structure des données. On les utilise pour représenter des valeur numériques ainsi que des chaines de caractères :

• BOOLEAN : utilisé pour représenter des informations logiques, peut prendre les valeurs TRUE et FALSE
  
  Ex : Utilisé ::= BOOLEAN
  
  
• INTEGER : entier pouvant être positif, négatif ou nul. Rappel : Il n'y a pas de limite pour les valeurs possibles car on définit une syntaxe abstraite. On peut associer à chaque valeur un identifiant qui lorsqu'il sera employé correspondra à la valeur entière définie par l'identifiant
  
  Ex : Hexadecimal ::= INTEGER { 1(1), 2(2), 3(3), 4(4), 5(5), 6(6), 7(7), 8(8), 9(9), A(10), B(11), C(12), D(13), E(14), F(15) }
  
  
• REAL : nombre réel spécifié sous la forme Mantisse * Base ^ Exposant . La base doit être 2 ou 10 et l'exposant doit être un entier >= 0.
  On peut aussi représenter les valeur + et - infini par les mots clés PLUS-INFINITY et MINUS-INFINITY
  
  Ex : PiArrondi REAL ::= {3145159265,10,-10}
  
  
• NULL : type ne prenant qu'une seule valeur qui est null. Ce type est utilisé par exemple lorsqu'on l'on doit forcément spécifier un type sans forcément transmettre d'information.
  
  Ex : ValeurReelleOptionnel ::= CHOICE {REAL , NULL}
  
  
• ENUMERATED : permet d'énumerer un ensemble de valeurs en associant un entier à un identifiant
  
  Ex : Orientation ::= ENUMERATED { nord(0), sud(1), est(2), ouest(3) }
  
  
• BIT STRING : définition d'une chaine de bits de taille >= 0
  
  Ex : Mot32 ::= BIT STRING (SIZE(32));
  
  
• OCTET STRING : définition d'une chaine d'octets de taille >= 0. Le valeurs à coder peuvent être définies sous forme binaire ou héxadécimale.
  
  Ex : Extension ::= OCTET STRING(SIZE(3))
  
  
• NUMERIC STRING : chaines de caractère composées que de chiffres et d'espaces
• PRINTABLE STRING : chaines composées de A,..,Z a,..,z 0,..,9 (espace)(),-./:=?
• TELEXSTRING : chaines de caractère définies par la norme T61 du CCITT
• VIDEOTEXTSTRING : chaines de caractère définies par la norme T.100 et T.101 du CCITT
• IA5STRING : chaines de caractère de l'alphabet international numéro 5 du CCITT
• VISIBLE STRING : comme IA5STRING avec le caractère espace en plus
• GRAPHICSTRING : chaines de caractères graphiques et l'espace
• GENERALSTRING : comme GRAPHICSTRING avec control et delete
  
  

Définition de types construits:

• SEQUENCE : constitue une collection ordonnée d'éléments distincts, les élements pouvant être de types différents. Les éléments peuvent être de type OPTIONAL indiquant que la valeur n'est pas nécessairement présente dans la sequence. Le mot clé DEFAULT indique que l'on attribue une valeur par défaut au composant lorsqu'il n'est pas spécifié.
  
  Ex : Participant ::= SEQUENCE { nom OCTET STRING, apaye BOOLEAN }
  
  
• SEQUENCE OF : constitue une collection ordonnée d'éléments de même type.
  
  Ex : ListeNom ::= SEQUENCE OF VisibleString
  
  
• SET : constitue une collection non ordonnée d'éléments non distincts qui peuvent être de types différents.
  
  Ex : Personne ::= SET { nom VisibleString, prenom VisibleString }
  
  
• SET OF : constitue une collection non ordonnée d'éléments non distincts du même type.
  
  Ex : MotsCles ::= SET OF VisibleString
  
  
• CHOICE : définit une collection de types, chacun etant distinct des autres.
  
  Ex : Nombre ::= CHOICE { reel REAL, entier INTEGER }
  
  
• ANY : c'est un type qui correspond en fait à tous les types possibles

Il y a plusieurs règles de codages disponibles:

• BER (Basic Encoding Rules) : Le plus simple, codage (Type,Longueur,Valeur) mais peu efficace (X.209 et X.690)
• PER (Paquet Encoding Rules) : Codage de façon plus compacte que BER
• LWER (Lightweight Encoding Rules) : Codage / Décodage moins compliqué pour CPU
• Autres règles
  
  

  Le codage BER :
  

  Toutes les primitives sont codées sous la forme (type,longueur,valeur):
  
  
• Les types construits sont codés dans un TLV avec les sous-élements stockés dans la partie V. Les parties T,L et V sont chacunes codées sur un nombre entier d'octets. La partie T identifie sans ambiguité le type de l'élément au sein du contexte dans lequel il va être utilisé, elle est constituée éventuellement du tag que l'utilisateur a spécifié afin de garantir que les éléments T correspondent aux contraintes suivantes :
  
  
• différents pour chacun des éléments d'un CHOICE
• différents pour chacun des éléments d'un SET
• différents pour chacun des éléments optionnels
  
  La partie T contient aussi un bit qui spécifie si V est une primitive ou une série de fragments de type TLV.
  La partie L est toujours présente et spécifie la taille de l'élément, soit sous la forme de son nombre d'octets, soit en indiquant que c'est un ensemble de triplets TLV terminés par un octet à zéro (l'encodage de la partie T assure qu'un octet à 0 ne puisse être associé à un T valide).
  Comme BER a été conçu avant que le sous-typage ASN.1 soit défini, il en résulte que toutes les informations de sous-typage sont complètements ignorées. En conséquence si par exemple une chaine de caractère est spécifiée comme étant de 8 caractères de long dans la notation alors cette information est ignorée et le champ L est toujours encodé. L'encodage des longueurs et des entiers ne pose en fait aucune limite sur la taille des entiers qui peuvent être utilisés (l'encodage de la plus grande valeur entiere prendrait 100 millions d'années pour être transmis sur une ligne à 100 térabits par secondes !). Dans la plupart des cas, un seul octet est utilisé pour coder la longueur de V, ce qui correspond à un overhead de 2 octets par valeur transmise (T étant codé sur un octet). En revanche si la longueur est superieure à 127 alors le codage du nombre d’octets nécessaires pour coder la longueur est codé dans l’octet initial de longueur.
  
  Codage des types primitifs :
  
  
• INTEGER : La partie V des entiers représente le complément à 2 du nombre et est codé sur un ou plusieurs octets. Le nombre d'octets est tel qu'il représente le nombre minimum d'octets nécessaires à la représentation du nombre.
  
  
• BOOLEAN : La partie V est codé sur un octet, la valeur FALSE est encodé comme un zéro et la valeur TRUE sous la forme d'une valeur différente de zéro.
  
  
• ENUMERATED : L'encodage est identique à celui de l'entier correspondant à la valeur associée.
  
  
• REAL : La représentation d'une valeur réelle peut être soit :
  1 - la valeur 0
  La valeur 0.0 est codée en mettant à 0 le champ L. (il n'y a pas de V)
  
  2 - une représentation binaire de la valeur réelle
  Si le 8e bit du premier octet est à 1, alors la valeur le réel est représenté suivant Signe * Mantisse* (2 ^ facteur echelle) * (Base ^ Exposant). Ces informations sont stockées dans le champ V suivant un certains nombre de règles visant à minimiser l'utilisation des octets du champ.
  
  3 - une représentation décimale des caractères representant la valeur réelle
  Si les bits 7 et 8 du premier octets sont à 00 alors on code la représentation ASCII du nombre réel.
  
  4 - certaines valeurs réelles spéciales
  Si les bits 7 et 8 du premier octets sont à 01 alors on peut spécifier que l'on transmet certaines valeurs spéciales telles que + ou - infini en spécifiant seulement l'identifiant prédéfini des ces nombres
  
  Il faut noter que l'on peut ainsi représenter un réel donné de plusieurs façons et que le codage ne se base sur aucun matériel spécifique.
  
  
• NULL : La champ L vaut 0 et il n'y a pas de champ V.
  
  Codage des types composés :
  
  
• SEQUENCE : Consiste à intégrer dans le champ V les codages des types contenus dans la séquence en respectant l'ordre défini dans la notation abstraite.
  
  
• SET : Correspond au codage de SEQUENCE sauf que l'ordre des types contenus dans SET peut être choisi de façon aléatoire par l'encodeur (les ambiguités qui pourraient en résulter sont levées par l'utilisation de tags définis par l'utilisateur afin de différencier les types du SET ayant le même tag prédéfini)
  
  
  Exemple de codage pour :
  
  Participant ::= SEQUENCE {
  nom OCTET STRING
  apaye BOOLEAN
  }
  
  Transmission de (« TOTO »,True):
  
  
  
  
  

  Le codage PER :

  PER est basé sur une approche différente de BER. La partie T n'est pas encodée et les tags issus de la notation sont ignorés. Les ambiguités potentielles sont résolues de la façon suivante :
  
  
• Un CHOICE est encodé en codant d'abord un CHOICE index qui identifie l'alternative choisie par sa position dans la liste de la notation
• La construction SET est traitée exactement comme si c'était une SEQUENCE : les éléments sont transmis dans l'ordre
• Quand un SET ou une SEQUENCE a des éléments OPTIONAL ou DEFAULT, l'encodage de chacun des éléments est précédé par un tableau de bit pour identifier quels éléments OPTIONAL ou DEFAULT sont présents.
  
  De plus PER tient compte des toutes les informations de sous-typage, et n'encode pas le champ L à chaque fois que c'est possible. Ainsi les entiers qui sont sous-typés dans une plage qui peut éventuellement nécessiter plus d'un octet mais jamais plus que 2 octets seront systématiquements codés dans 2 octets sans champ L. Ainsi avec BER, "SEQUENCE OF BOOLEAN" avec 64 valeurs booléenes serait encodé en 196 octets alors qu'en PER cela sera encodé dans 9 octets et "SEQUENCE SIZE(64) OF BOOLEAN" en 8 octets.
  
  Bien que les implantations PER soient capables de générer des encodages plus petits, la meilleure performance en matière d'overhead a tout de même un cout. Les règles dont PER est constitué sont complexes comparé à BER et demandent donc plus de ressources de la part des machines effectuant l'encodage/decodage.
  
  
  

  Le codage LWER :

  
  LWER a été créé pour maximiser la vitesse d'encodage au détriment de la fléxibilité, de l'extensibilité et de la compacité. Cela est rendu possible en définissant la syntaxe de transfert de telle sorte qu'elle se rapproche de la répresentation locale des données. Ainsi LWER définit 6 nouvelles syntaxes de transferts qui couvrent une large gamme de format de représentation. Ces syntaxes définissent des règles avec des mots de taille variables et plusieurs façons d'ordonner les octets. La plus grande vitesse de traitement est en général atteinte quand les 2 systèmes communiquants utilisent leurs contextes natifs.
  
  Le codage des types de données est similaire à ceux employés par de nombreux systèmes informatiques. Les types primitifs comme INTEGER, REAL, ENUMERATED, et BOOLEAN sont codés comme des champs de taille fixe de 1 octet. Les champs de type String comme BIT STRING et OCTET STRING, sont codés avec leur longueur et un pointeur indiquant la position de la chaine stockée après dans la séquence de codage. Les champs de type TAG ne sont jamais inclus dans le codage LWER.
  
  L'utilisation de LWER augmente en règle générale l'overhead d'encodage de façon significative. Cette approche est très utile dans les applications rapides où il y a une très large bande passante, ou quand les ressources des machines sont très limitées.
  

Comparaison ASN.1/XDR

Exemple :

Applications :

XDR

• Protocole RPC (Remote Procedure Call)

  RFC 1831 : Permet la communication entre 2 processus s’exécutant sur 2 machines distinctes. Utilise XDR pour l’échange des données
  
  

• Protocole NFS (Network File System)
  

  RFC 1813 : Défini avec RPC et donc XDR
  

ASN.1

• Administration réseau : SNMP (Simple Network Management Protocol) où les structures de bases de données de chaque équipements sont spécifiées en ASN.1. L'utilisation du type Object Identifier est ici très fréquente pour spécifier de façon unique chaque type d'équipement réseau.
  
  
• Messagerie : standards X.400 (c'est normal étant donné que ASN.1 est issu de X.409) , il y a plus de 5000 lignes de définition en ASN.1
  
  
• Répertoire électronique : dans X.500 pour toutes les requètes et modifications des attributs du DAP (Directory Acces Protocol).
  
  
• Aviation: les contrôles d’échange d’information sont décrits en ASN.1 et codés en PER
  
  
• Secure Electronic Transaction (SET) est un protocole spécifié en ASN.1 qui permet de faire du commerce électronique sur les chemins standards définis par Visa International et MasterCard.
  
  
• Multimédia : MHEG (Multimedia and Hypermedia Information coding Expert Group) : utilise une approche orienté objet pour décrire les représentations des informations de type multimédia et hypermedia qui seront échangées entre les applications. La syntaxe de transfert employée est DER (Distinguished Encoding Rules).
  
  
• Electronic Data Interchange Protocols (EDI) : Utilisé pour l'automatisation d'échange de données entre applications, ce système utilise principalement un service nommé DTAM (Document Transfer And Manipulation Standard) qui est spécifié en ASN.1
  
  
• Authentification : Kerberos (MIT) est un logiciel développé pour sécuriser les échanges de données au sein du réseau d'une université ou d'une entreprise. A partir de la version 5 de ce logiciel , les transferts de données sont spécifiés en ASN.1
  
  
• Cryptographie : PKCS (Public Key Cryptography Standard) est un algorithme de cryptage qui définit en ASN.1 la syntaxe des messages encryptés avec une signature numérique codée en BER
  
  
• Télécommunications : protocole MAP (Mobile Application Part) des GSM, UMTS utilise en grande partie ASN.1 et ECN (Encoding Control Notation qui permet de spécifier de nouvelles règles de codage ASN.1 de manière dynamique)
  
  
• Bluetooth: le service de découverte des autres périphériques Bluetooth est aussi spécifie en ECN
  
  

Liens

Couche Présentation :

Presentation Layer: The Service
http://www.csc.vill.edu/mnt/a/cassel/html/netbook/chap9/node3.html

Presentation Services
http://www-net.cs.umass.edu/cs653-1997/notes/ch4/ch4.htm

XDR :

La RFC spécifiant XDR
ftp://ftp.isi.edu/in-notes/rfc1832.txt

External Data Representation
http://snad.ncsl.nist.gov/snad-staff/olsen/pubs/titlehce/node18.html

Présentation de XDR
http://www.cs.rpi.edu/courses/fall96/netprog/lectures/slds/xdr/sld001.htm

XDR technical notes
http://www.vitele.com:8101/cisco/cc/td/doc/product/software/ioss390/ios390rp/rpxdesc.htm

ASN1 :

Site d'information sur ASN.1
http://asn1.elibel.tm.fr/fr/index.htm

ITU-T : ASN.1 Project
http://www.itu.int/ITU-T/asn1/

ASN.1 ressources
http://www.oss.com/asn1/index.html

Expert Abstract Syntax Notation One Design
http://asn-1.com/

CTI forum : ASN.1 standard
http://www.ctiforum.com/standard/standard/asn.1/asn/asn2.htm

Références sur ASN.1
http://renoir.vill.edu/~cassel/netbook/asn1only/asn1only.html

ASN.1 et la sécurité
http://www.isi.edu/~brian/security/asn1.html

Description de ASN.1 avec ses évolutions possibles
http://byerley.cs.waikato.ac.nz/~tonym/articles/asn/node1.html