Chapitre 1 : Protocoles couches

intermédiaires

1.1 Introduction.

1.1.1Principe

a) modèle en couche
Le modèle en couche permet une approche simplificatrice du fonctionnement d'un réseau, quoi qu'il
en soit, rares sont les implémentations pratiques qui
respectent vraiment le modèle ISO avec ses 7 couches. Application

Les couches basses (Couche physique->couche Couche Application

transport) respectent en général beaucoup mieux ce
modèle, car elles sont liées directement à la
transmission des données et doivent donc avoir une Couche
interopérabilité sans faille pour pouvoir rassembler des Présentation
réseaux différents. Couche
Session

Les couches intermédiaires et hautes (Couches Couche Transport

Session/Présentation/Application), liées aux
applications, ont beaucoup plus de latitudes. Suivant les Couche Réseau
cas, elles peuvent ne permettre que de faire Couche Liaison
communiquer ensemble des machines parfaitement
compatibles ou assurer une interopérabilité complète Couche Physique
mais pour des applications simplifiées.

On trouve 2 catégories d'implémentations :

Les premières sont liées à des protocoles simples style ftp ou telnet, où les couches intermédiaires
n'ont pas d'utilité. La totalité des fonctions du protocole se retrouve dans la couche application qui
est dans un format ASCII.

1
Du coup ces protocoles simples ont une
interopérabilité quasi totale quels que soient la Application
machine et son système d'exploitation à
condition qu'ils soient basées sur TCP/IP, ce qui Couche
est le cas pour tous les échanges réseaux locaux Application... FTP
actuellement.
Couche
TCP
La deuxième catégories d'implémentations Transport
concerne des protocoles complexes où le modèle
possède beaucoup plus de couches, il se IP
rapproche du modèle complet de l'OSI même si
les fonctions de chaque couche ne coïncident pas Ethernet
avec celle du modèle OSI. Elles sont souvent
associées au partage de fichiers et d'imprimantes.
Ethernet
C'est ce qui va nous intéresser dans ce chapitre.

b) Fonctionnalités des couches intermédiaires

Les couches intermédiaires et hautes (Session/Présentation/Application) vont réaliser la gestion de
l’interface avec l'application.
Elles sont constituées de protocoles (PDU : Protocol Data Unit), mais aussi des fonctions associées
(SDU : Service Data Unit). Dans le cas des couches plus élevées, ces SDU ont une importance
fondamentale car toutes les fonctionnalités sont réalisées par les machines qui communiquent (donc
aux 2 bouts car on est au dessus de la couche transport) et sont donc faites logiciellement.

Les PDU sont complexes est souvent de format binaire. Elles ne sont pas forcément normalisées,
mais peuvent être propriétaires (exemple de NetBIOS). Certaines sont décrites dans des RFC
(NBT), d'autres sont seulement fournies par le constructeur (NIS).

Les SDU, ensemble de fonctions assurant l’interface, sont regroupées dans des bibliothèques de
fonctions exécutées sur un ordinateur. Elles sont souvent liées à un système d’exploitation et
associées à des services particuliers. Elles se présentent sous forme d’API.

Ces caractéristiques font que de nombreux problèmes d’interopérabilité apparaissent lorsqu'il s'agit
de faire fonctionner ensemble des applications de ce type provenant de constructeurs différents.
Exemples : partage de ressources (disque/imprimante...)

1.1.2Structures des couches intermédiaires Windows

Le partage de fichiers sous Windows est basé sur une couche d'interface : NetBIOS (Couche
« Session ») et une couche de services : SMB ou CIFS (Couche « Application/Présentation »). Si
SMB/CIFS est resté quasiment constant au cours du temps, la couche d'interface a beaucoup
évoluée en fonction des couches inférieures, pour en arriver à NBT (NetBIOS over TCP/IP) au
dessus d'une couche Transport TCP.

2
 R éseau IB M A p p l ic a t io n A p p l ic a t io n A p p l ic a t io n

xxx xxx xxx

xxx S M B /x x x S M B /x x x

xxx S M B /x x x N e tB IO S N e tB IO S

xxx N e tB IO S SPX TCP

N e tB IO S L L C (8 0 2 .2 ) IP X IP

IB M E th e rn e t/x x x E th e rn e t E th e rn e t

IB M E th e rn e t/x x x E th e rn e t P h E th e rn e t P h

NetBIOS a existé directement sur une sous-couche MAC ou LLC pour des réseaux locaux, mais
aussi au-dessus de IPX/SPX. Plusieurs encapsulations peuvent exister en même temps sur une
même machine (surtout serveur), mais actuellement seule NBT doit être utilisé sur des réseaux de
machines récentes.

1.1.3Couches intermédiaires sous UNIX

De la même manière que sous Windows, sous UNIX, le partage de fichiers est mis en place en
utilisant la plupart des couches du modèle en couche. Seules les couches hautes diffèrent dans un
réseau TCP/IP. C'est à dire les couches Session/Présentation/Application. Sous UNIX, un
mécanisme particulier les RPC (Remote Procedure Call) permet de rendre transparent le fait que le
fichier ne se situe pas sur la machine où il est utilisé. Le format des PDU est complexe et de type
binaire.

Partage Fichiers sous UNIX :

Application
Couche Application NFS (Network File System)
Couche Présentation XDR (eXchange Data Representation)

Couche « Session » RPC (Remote Procedure Call)

Couche Transport TCP
IP
Ethernet
Ethernet

3
1.2 Couche NetBIOS sur TCP/IP.

1.2.1 Historique

Les premières implémentations de Netbios s'affranchissaient des couches TCP/IP et fonctionnaient

directement sur 802.2 (sous-couche LLC). Face à l'évolution d'Internet, une version basée sur
TCP/IP a été développée par Microsoft. Le principe du protocole est resté.

1.2.2 Principe.

Netbios sur TCP/IP a été défini par les RFC1001 (principes) et RFC1002 (format des trames). Il est
donc public, ce qui a été une nouveauté venant de Microsoft. De fait, la généralisation des échanges
via TCP/IP concernant les échanges inter-réseaux a rendu obligatoire, la mise en oeuvre de
NetBIOS sur un protocole pouvant être routé sur tout l'Internet. Certains y ont même vu un
abandon progressif des protocoles propriétaire Windows, mais depuis la publication des RFC, il
reste toujours le standard, en association avec SMB/CIFS (pour les couches supérieures), de la
communication pour le partage des ressources sous Windows.

Application

Couche Application/Présentation SMB/CIFS

Couche « Session » NetBIOS

Couche d'interface NbT

Couche Transport
TCP

IP

Ethernet

Ethernet

TCP/IP prenant en charge l'essentiel de la communication en mode connecté, NetBIOS s'est

considérablement simplifié.
Il comprend 3 services et protocoles associés (avec 3 formats de trames) :
– Name Service (Name Service Packets )
– Datagram Service (Datagram Service Packets)
– Session Service (Session Service Packets)

4
Le service le plus complexe est le Name Service car il doit prendre en charge tous les problèmes de
compatibilité, les 2 autres s'appuyant largement sur TCP/IP sont plus simples.

1.2.3 Name Service (NetBIOS Name Service).

a) Principe
C'est la déclaration des noms pour une machine. Pour des raisons de compatibilité, les anciens
noms NetBIOS ont été conservés, mais s'y rajoute des noms compatibles DNS. Ce deuxième aspect
est de plus en plus présent surtout avec les dernières versions de Windows Server où un serveur
DNS est intégré, et sert de base à de nombreuses fonctions d'Active Directory. Il va permettre de
réaliser des communications à l'échelle de l'Internet.

Il y a plusieurs service (SDU) : Add Name ; Add Group Name ; Delete Name qui vont permettre de
déclarer des noms de machines, et de découvrir celles avec qui communiquer. Ces services
s'appuient sur des échanges d'informations (PDU).

b) Nom NetBIOS
Initialement, les noms NetBIOS étaient codés sur 16 octets. 15 octets servent au nom, le dernier
étant le type de service. Il existe plusieurs catégories de nom :
Nom individuel (plusieurs pour une machine : aliases)
Nom de groupe (équivalent au workgroup sous windows)
Le 16ème octet permet d'identifier le service associé à une machine (server...).

Pour des raisons de compatibilité avec le système DNS, une représentation dérivée est utilisée pour
la représentation des noms dans les paquets NBT. Elle permet d'utiliser encore une représentation
interne de type NetBIOS 16 octets mais d'avoir un échange compatible DNS. Ce changement de
représentation se fait à 2 niveaux :
1er niveau : traduction des noms NetBIOS en pseudo noms de machine+domaine
2ème niveau : traduction au format DNS

Name Format 1er niveau :

On découpe chaque octet en 2 octets et on ajoute le caractère 'A' (0x41) à chaque demi octet. Ceci
permet d'avoir un nom avec uniquement des codes ASCII compatible DNS.
Si le nom NetBIOS est trop court, il est complété par des espaces, le résultat de cette traduction est
donc toujours un nom de 32 caractères ASCII avec des caractères compris entre 'A' et 'P'.

Exemple FRED (rfc 1001) devient :

EGFCEFEECACACACACACACACACACACACA

Puis on complète par le NetBIOS Scope, c'est à dire le pseudo nom de domaine. Si celui-ci est
telecom.com, le nom complet devient :
EGFCEFEECACACACACACACACACACACACA.telecom.com

Name Format 2ème niveau :

C'est le même genre de traduction que pour le DNS. C'est à dire un octet de longueur qui remplace
le '.' puis la valeur en ASCII. On peut aussi ne pas répéter les chaînes de caractères déjà utilisées et
les remplacer par un code spécifique.

5
c) Mécanisme du Name Service
Le mécanisme du Name Service est un mécanisme assez complexe car il prend en charge plusieurs
types de machines entre autre pour des raisons de compatibilité.

Concernant l'attribution et la résolution de noms, il y a 3 catégories de machines :

– Des B Nodes (BroadCast Nodes) ils mettent en oeuvre la résolution de noms par des BroadCast,
ils ne peuvent donc communiquer que sur un sous-réseau.
– Des P Nodes (Point to Point nodes) qui font cette opération par une demande auprès d’un serveur
NBNS et NBDD
– Des M Nodes (Mixed Nodes) : ils utilisent les 2 techniques, ce qui leur permet de communiquer
avec des B nodes sur le sous-réseau et avec des P nodes ailleurs.

Serveur NBNS (NetBIOS name server) ou Serveur WINS (Windows Internet Name Server) qui est
l'implémentation Microsoft de NBNS.
Serveur NBDD (NetBIOS datagram distribution) qui permet de passer des datagrammes sur
Internet (~passerelle)

Principe :
Une machine va réclamer un nouveau nom via une requête envoyée en multicast sur le réseau local,
si le nom existe la machine le possédant répond. S'il n'y a pas de réponse donc de conflit, la
machine peut se l'attribuer et les serveurs WINS peuvent l'ajouter au voisinage.

Cette opération est en général faite au démarrage de la machine.

Une commande : net name [nom [/add || /delete]] permet aussi de faire cette opération
manuellement.

4 opérations peuvent être présentes :

– Name registration : Each WINS client is configured with the IPv4 address of a WINS server.
When a WINS client starts, it registers its NetBIOS names and their corresponding IPv4 addresses
with its WINS server. The WINS server stores the client’s NetBIOS name-to-IPv4 address
mappings in its database.
– Name renewal : All NetBIOS names are registered on a temporary basis so that if the original
owner stops using a name, a different host can use it later. At defined intervals, the WINS client
renews the registration for its NetBIOS names with the WINS server.
– Name resolution : A WINS client can obtain the IPv4 addresses for NetBIOS names by querying
the WINS server.
– Name release : When a NetBIOS application no longer needs a NetBIOS name, such as when a
NetBIOS-based service is shut down, the WINS client sends a message to the WINS server to
release the name.

d) Name Service Packet

Le format des trames du Name Service Protocol est compatible avec celui du DNS.

6
 0 8 16 21 28 31
Transaction ID Opcode Flag Rcode
Qd Count An Count
NS Count AR Count
Question Entries

Answer Ressource Record

Authority Ressource Record

Additionnal Ressource Record

Name Registration Request (2 champs) :

1 champ question avec le nom demandé
1 champ Additional avec le même nom et un TTL

Positive Name Registration Response (1 champ) :

1 champ réponse : avec le nom demandé
Le flag est à 0x0 (c’est OK)

Negative Name Registration Response (1 champ) :

1 champ réponse : avec le nom demandé
Le champ Flag avec le code de refus :
0x01 : Format Error ; … ; 0x06 : Active Error (le nom est déjà utilisé) …

1.2.4 Datagram Service.

C'est un service non fiable, unicast ou broadcast. Il comprend 4 primitives de service (SDU) :
– Send Datagram,
– Send BroadCast Datagram,
– Receive Datagram,
– Receive BroadCast Datagram

Datagram Service Packet

7
 0 8 16 31
Type Flag Datagram ID
Source IP
Source Port Datagram Length (opt)

Data (Opt)

Valeur du champ Type :

0x10 - DIRECT_UNIQUE DATAGRAM
0x11 - DIRECT_GROUP DATAGRAM
0x12 - BROADCAST DATAGRAM
0x13 - DATAGRAM ERROR
0x14 - DATAGRAM QUERY REQUEST
0x15 - DATAGRAM POSITIVE QUERY RESPONSE
0x16 - DATAGRAM NEGATIVE QUERY RESPONSE

Champ Flag :

B0 B1 B2 B3 B4 B5 B6 B7
0 0 0 0 SNT F M

Symbol Description

RESERVED : (B0-B3) Reserved, must be zero (0)

SNT : (B4-B5) Source End-Node type:
00 = B node
01 = P node
10 = M node
11 = NBDD
F : (B6) FIRST packet flag,
Is set then this is first (and possibly only) fragment of NetBIOS datagram
M : (B7) MORE flag, Is set then more NetBIOS datagram fragments follow.

Les champs « Datagram Length » et « Data » sont optionnels et vont dépendre du type de
datagramme.

1.2.5 Session Service.

C'est un service fiable en mode connecté au niveau session.

Il y a gestion d’une session avec 3 phases :

– Etablissement de la session
– Maintien de la session

8
– Arrêt de la session

Les SDU du service fiable (Session Service) :

Call, Listen, Hang Up, Send, Receive, Session status

Les échanges de PDU :

Ouverture en 2 temps : TCP puis NetBIOS

Ouverture d’une connexion TCP (port 139)
Ouverture d’une session NetBIOS
La première est toujours acceptée, la deuxième démarre par une PDU : session request

NBT : séquence d'ouverture de session

Client Serveur
SYN (IP+Port=139)

SYN/ACK

ACK

Session Request Packet

Positive Session Response Packet

Session Message Packet

Session Message Packet

PDU de maintien : Session Keep Alive : envoi périodique si le poste est configuré

Session Service Packet :

0 8 16 31
Type Flag Length

Trailer (Packet dependant)

9
1.3 Couche Application : CIFS/SMB

1.3.1 Principe général.

Le protocole de couche application sous Windows est SMB (Server Message Blocks), renommé
plus tard CIFS (Common Internet File System). Il permet le partage de fichiers en mode
Client/serveur. Il assure une compatibilité avec les différentes versions de Windows. Il existe une
gestion de la sécurité (authentification) et un cryptage des informations sensibles. C'est un échange
de type Client/Serveur simple : Une question -> une réponse

Après connexion, le dialogue est basé sur des commandes simples mais nombreuses.
Il y a plus de 100 commandes :
– SMBmkdir : 0x00 : Create Directory
– SMBOpen : 0x02 : Open a file
– SMBunlink : 0x06 : Delete file
– SMBsends : 0xd0 : Send message...

SMB/CIFS utilise le rassemblement des commandes ANDX batching, c'est à dire que plusieurs
commandes peuvent être passées par la même trame.

Il y a verrouillage des fichiers distants lors de l’utilisation. Plusieurs questions peuvent être en
cours grace au champ "MultiplexID". Ce champ permet au client d’identifier à quelle question
correspond les réponses provenant du serveur.

Exemple d'échange SMB : ouverture session

C lie n t O u v e r t u r e S e s s io n S erv eu r
D e m a n d e S e s s io n N e t B I O S
O u v e rtu re
P o s it iv e A c k n o w le d g e m e n t S e s s io n
N e tB IO S
S M B _ C O M _ N E G O C IA T E
N e g o c ia te
S M B _ C O M _ N E G O C IA T E C IF S
D ia le c t

S M B _ C O M _ S E S S IO N _ S E T U P _ A N D X
U s e r L o g in
S M B _ C O M _ S E S S IO N _ S E T U P _ A N D X -> U ID

SM B _C O M _TR EE_C O N N EC T_A N D X

C o n n e c t to
SM B _C O M _TR EE_C O N N EC T_A N D X R esso u rce
-> T ID

10
1.3.2 Protocole.

SMB Packet

0 8 16 24

0xFF S M B

C om m and E r r o r C la s s 0x00 E rro r C o d e

E r ro r C o d e ( c o n tin u e d ) F la g F la g 2

P a d o r S e c u r it y s ig n a t u r e ( 1 2 b y t e s )

T ree ID P ro c e ss ID

U ser ID M u lt ip le x I D

W o rd C o u n t
P a ra m e te r W o rd s

B y te C o u n t B u ffe r

Signification des champs :

– Tree ID : Défini la ressource concernée (disk, printer…)
– Process ID : identifie le process qui accède à la ressource ce qui évite l’accès concurrent
– User ID : obtenu au moment de la connexion, le serveur donne un ID en début de session
(login+passwd). Il définit les droits d’accès.
– Multiplex ID : identifie les requètes
– Word Count + Parameter words : command specific data
– Byte Count + Buffer : buffer de bytes

1.4Couches hautes sous UNIX : RPC

1.4.1 Principe

Les RPC Remote Procedure Calls (RFC 1831) sont une extension de la notion d’appel de
procédures locales. Les RPC fournissent une API pour que le programmeur ne voit pas de
différence entre l'utilisation d'une procédure locale ou distante.
L’accès aux services en local se fait par des appels à des fonctions systèmes
L’accès Client/Serveur se fera par des RPC
Indépendant de la couche transport

API au dessus de l ’API socket (couche transport)

Créées et définies par Sun Microsystem

11
– Fonctionnement
– Appel identique à une fonction avec des paramètres
– Appel distant bloque le thread jusqu’au retour de la réponse (ou time out)
– La machine serveur exécute réellement la fonction

Mise en œuvre :
un programme est en attente en permanence côté serveur : Daemon (démon), à la réception d’une
demande, il exécute, puis il renvoie le résultat

Client Serveur

Démon
Demande

Réponse

Le démon gère plusieurs fonctions (procédures), il doit identifier la demande grâce aux
informations dans la PDU
Informations nécessaires à la mise en œuvre (Informations qui doivent transiter dans la PDU) :
– Identifier la procédure que le serveur doit exécuter

12
– Vérifier les droits d’accès du client aux fonctionnalités du serveur
– Définir le format des données d’entrée à envoyer
– Définir le format des données de retour

Identification de la procédure distante à exécuter

Une procédure distante est définie par :
– un numéro de programme (~ choix du démon)
– un numéro de version (gestion de plusieurs versions simultanément : compatibilité)
– un numéro de procédure (chaque procédure a un numéro)

Numéro de programme
0x00000000 à 0x1FFFFFFF : définie par Sun
0x20000000 à 0x3FFFFFFF : définie par l’utilisateur
0x40000000 à 0x5FFFFFFF : numéros attribués dynamiquement
0x60000000 à 0xFFFFFFFF : Réservés
Exemples
0x100003 et version 3 : NFS services ; 0x100000 version 2 portmap

Numéro de procédure (dans l’ordre de création)

Procédure 0 (pour NFS) est la procédure NULL : test de l’accès au service
Procédure 1 (pour NFS) : GETATTR, recherche de paramètres
Procédure 3 (pour NFS) : LOOKUP
Procédure 6 (pour NFS) : READ, lecture contenu de fichier

Authentification : la méthodologie d’authentification et d’autorisation est définie indépendamment

du protocole, il y a une zone de données réservée pour cela.

L'échange des données se fait dans un format XDR (décrit ensuite) : RFC 1832 dans la zone
dépendante de la procédure appelée.

1.4.2 La PDU
Echange sur 2 phases PDU Call - PDU Reply

Application Application

NFS (Network File System) NFS (Network File System)

XDR (eXchange Data Represen.) Call XDR (eXchange Data Represen.)

RPC (Remote Procedure Call) RPC (Remote Procedure Call)

TCP Reply TCP

IP IP
Couches basses Couches basses

Format de la PDU de demande call :

13
 0 8 16 31
Transaction ID
Type
RPC version
Program
Program version
Procedure
Credential...

Verifier...

PDU de réponse (reply avec acceptation)

0 8 16 31
Transaction ID
Type
RPC version
Program
Program version
Procedure
Reply state
Verifier...

Accept state

Champ Type :
0 : Envoi d'une PDU de demande (Call)
1 : Retour d'une PDU de réponse (Reply)

Champ Reply State :

0: Accepté
1: Rejeté
Champ Accept State (Si demande acceptée)

14
 0: Exécuté
1: Non exécuté

Exemple de PDU RPC (call) :

XID: 0x822df084 (2184048772)
Message Type: Call (0)
RPC Version: 2
Program: NFS (100003) / Program Version: 3
Procedure: CREATE (8)
Credentials
Flavor: AUTH_UNIX (1) / Length: 32 / Stamp: 0x00000bb4
Machine Name: istapc82 (length: 8 ; contents: istapc82)
UID: 0 / GID: 0
Auxiliary GIDs (GID: 0)
Verifier
Flavor: AUTH_NULL (0) / Length: 0

Exemple d'une PDU RPC reply :

XID: 0x822df084 (2184048772)
Message Type: Reply (1)
Program: NFS (100003)
Program Version: 3
Procedure: CREATE (8)
Reply State: accepted (0)
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Accept State: RPC executed successfully (0)

1.4.3 Implémentation

La création de programme basés sur les RPC se fait via la fourniture d’une API de haut niveau (au
dessus des sockets). Puis on utilise un compilateur spécifique pour créer le programme.

Fonctions utilitaires fournies côté serveur

– Enregistrement des procédures
– Conversion des formats de données

Fonctions utilitaires fournies côté client

– Appel des procédures { call_rpc() }
– Conversion des formats de données

Publication et découverte
Publication : faire connaître ce que propose le serveur
Découverte : déterminer ce que propose le serveur
Résolution d’adresses + numéro de ports

15
Service lookup (RFC 1823)
portmapper (version 2)
rpcbind (version 3 et 4)
Ecoute sur le port 111 (UDP et TCP)
Redirection du client sur le port du programme

Commande rpcinfo -p : affiche les services rpc disponibles (port…)

La connexion d'un client sur un servcie se fait en plusieurs étapes. Pour éviter la multiplication des
ports ouverts, le serveur est en attente sur un port unique (Port 111). Pour répondre à des demandes
de services, il va rediriger les demandes du client vers des ports applicatifs. Les services disponibles
sur le serveur sont préalablement déclarés auprès du Port Mapper.

Déclaration :

Client Serveur
Port 111 Port Mapper

Déclaration

Program

Attente sur le Port 111 :

Client Serveur
Port 111 Port Mapper

Program
Port xxxx

Demande de connexion :

16
 Client Serveur
Port 111 Port Mapper

Port xxxx

Program
Port xxxx

Connexion sur le port applicatif :

Client Serveur
Port 111 Port Mapper

Program
Port xxxx

Il existe plusieurs implémentations :

– RPC ONC : Sun
– RPC DCE : Open Group (gratuit)
– Version Windows
– XML RPC ; SOAP …

1.5 Couche présentation : XDR.

1.5.1 Principe.

XDR (External Data Representation) est un protocole de présentation des données en un format
portable. Il est dans un format proche du Langage C.
Il existe d'autres possibilités : XML...

Aucun échange ne correspond à ce protocole (pas de zone dans la PDU). En effet, la couche
présentation n’a pas besoin de paramètres dans ce cas, il suffit que le format de représentation soit
le même aux deux bouts.

17
 Application Application

NFS NFS

XDR XDR

RPC RPC

TCP TCP

IP IP

Ethernet Ethernet

Ethernet Ethernet

1.5.2 Mise en oeuvre.

Exemple de description de la PDU RPC sous XDR :

struct rpc_msg {
unsigned int xid ;
union switch (msg_type mtype) {
case CALL :
call_body cbody ;
Case REPLY :
reply_body rbody ;
} body ;
} ;

Si c'est une PDU de demande (case CALL valide) :

struct call_body {
unsigned int rpcvers ; /* must be equal to two*/
unsigned int prog ;
unsigned int vers ;
unsigned int proc ;
opaque_auth cred ;
opaque_auth verf ;
/* procedure specific parameters start here */
} ;

Si c'est une PDU de réponse (case REPLY valide) :

union reply_bodyswitch (reply_stat stat) {
case MSG_ACCEPTED : accepted_reply areply ;
Case MSG_DENIED : rejected_reply rreply ;
} reply;

18
Il y a encore 2 cas :
Réponse d'acceptation :
struct accepted_reply {
opaque_auth verf ;
union switch (accept_stat stat) {
case SUCCESS :
opaque results[0];
/* procedure specific results start here*/
case PROG_MISMATCH :
struct {
unsigned int low ;
unsigned int high ;
} mismatch_info ;
default ;
} ;

C'est principalement une représentation des structures de données :

types simples
4 octets mini : int
bool -> enum {0, 1} -> int
double : 8 octets ; quadruple : 16 octets…
structure, union …
opaque : chaîne d ’octets quelconque
string : chaîne de caractères

L'API fournit des procédures de conversion :

xdr_int() : conversion représentation xdr vers int
xdr_bytes()…

1.6 NFS

Généralités
Network File System version 3 (rfc 1813)
Network File System version 4 (rfc 3010, rfc 3530)
Généralisation de la notion de systèmes de fichiers pour des ressources en réseau
Montage de systèmes de fichiers distants
Mise à disposition de ressources (exportation côté serveur)
Utilisation locale (montage côté client)
Communication via des descripteurs (fichier/répertoire)
stocké côté client (serveur sans état)
résultats des requêtes, contenus des répertoires, file handle, noms et attributs des fichiers, valeur du
temps.

1.6.1 Principe général.

Ce service est mise en œuvre par plusieurs démons : nfsd, mountd (rpc.nfsd ; rpc.mountd)

19
Il ya plusieurs fichiers de configuration dont /etc/exports : systèmes de fichiers exportable

Des commandes sont aussi fournis :

/usr/etc/exportfs (gestion du fichier d’exportation)
statistiques : nfsstat
montage : mount -t nfs server001:/home/expt /mnt/essai
showmount -e server001

La sécurité est gérée par RPC

Liste des fonctions NFS et leurs attributs

void NFSPROC3_NULL(void) = 0;
GETATTR3res NFSPROC3_GETATTR(GETATTR3args) = 1;
SETATTR3res NFSPROC3_SETATTR(SETATTR3args) = 2;
LOOKUP3res NFSPROC3_LOOKUP(LOOKUP3args) = 3;
ACCESS3res NFSPROC3_ACCESS(ACCESS3args) = 4;
READLINK3res NFSPROC3_READLINK(READLINK3args) = 5;
READ3res NFSPROC3_READ(READ3args) = 6;
WRITE3res NFSPROC3_WRITE(WRITE3args) = 7;
CREATE3res NFSPROC3_CREATE(CREATE3args) = 8;
MKDIR3res NFSPROC3_MKDIR(MKDIR3args) = 9;
SYMLINK3res NFSPROC3_SYMLINK(SYMLINK3args) = 10;
MKNOD3res NFSPROC3_MKNOD(MKNOD3args) = 11;
REMOVE3res NFSPROC3_REMOVE(REMOVE3args) = 12;
RMDIR3res NFSPROC3_RMDIR(RMDIR3args) = 13;
RENAME3res NFSPROC3_RENAME(RENAME3args) = 14;
LINK3res NFSPROC3_LINK(LINK3args) = 15;
READDIR3res NFSPROC3_READDIR(READDIR3args) = 16;
READDIRPLUS3res NFSPROC3_READDIRPLUS(READDIRPLUS3args) = 17;
FSSTAT3res NFSPROC3_FSSTAT(FSSTAT3args) = 18;
FSINFO3res NFSPROC3_FSINFO(FSINFO3args) = 19;
PATHCONF3res NFSPROC3_PATHCONF(PATHCONF3args) = 20;
COMMIT3res NFSPROC3_COMMIT(COMMIT3args) = 21;

Type et contenu des paramètres dans la RFC (description au format XDR)

Exemple de description format XDR, Procedure 7: WRITE - Write to file

Déclaration fonction et arguments d'entrée
WRITE3res NFSPROC3_WRITE(WRITE3args) = 7;
enum stable_how {UNSTABLE = 0,DATA_SYNC = 1,FILE_SYNC = 2};
struct WRITE3args {
nfs_fh3 file;
offset3 offset;
count3 count;
stable_how stable;
opaque data<>;
};

Déclaration arguments de sortie :

20
 struct WRITE3resok { struct WRITE3resfail {
wcc_data file_wcc; wcc_data
file_wcc;
count3 count; };
stable_how committed;
writeverf3 verf;
};

union WRITE3res switch (nfsstat3 status) {

case NFS3_OK : WRITE3resok resok;
default : WRITE3resfail resfail;
};

1.7 NIS

NIS est lui aussi basé sur les RPC suivant le même principe que NFS. NIS étant un produit SUN
Microsystem, il n'y a pas de description dans les RFC. Quoi qu'il en soit le code source se trouve
dans toutes les distributions Linux par exemple.

21
1.8TP n°3 suite : Etude des protocoles réseaux NetBIOS
Ce TP vient en complément de celui sur le serveur Windows, afin de bien comprendre les
mécanismes des échanges.

Phase 1 : Questions concernant la déclaration des noms NetBIOS :

Etude du protocole NBNS et du lien avec le DNS

1) Par la commande net name, créer un nouvel alias (votre nom) pour votre machine. Visualiser les
trames envoyées par votre machine.
- Qu'en déduisez–vous sur les protocoles actifs sur votre PC ?
- Sous quelle forme sont envoyés les paquets (type d'adresses en dessous de NetBIOS) ?
- Décrivez les différents systèmes de nommage (adressage) de NetBIOS.
- Analyser le contenu des autres champs des trames NetBIOS.

2) Tenter de créer un nouvel alias, mais d'un nom déjà utilisé par la deuxième machine de votre
binôme. Décrivez les trames échangées, et les champs NetBIOS.

3) Refaire la même manipulation avec un alias correspondant au serveur Windows. Pourquoi y a t’il
une différence ?

4) Détruire les alias créés. Cela génère-t-il des trames sur le réseau ? Si oui lesquelles ?

Phase 2 : Questions concernant NetBIOS sur TCP/IP (NbT) :

Etude du protocole Session Service Protocol

a) Par le voisinage réseau, aller sur le serveur, accéder à votre répertoire personnel et ouvrir un
fichier texte. Déterminer les différentes trames échangées pour effectuer cette opération. Vous
pourrez séparer l'analyse en plusieurs acquisitions pour bien mettre en évidence le séquencement de
ces trames (si il y a authentification –car pas de connexion antérieure- les mots de passe ne
circulent pas en clair).

b) Analyser le champ NetBIOS de ces trames ? Où sont mises en œuvre les différentes fonctions
des trames NetBIOS précédentes ?

c) Peut-on reconstituer la session complète en partant de la connection TCP ? Si non, déconnectez-

vous et reconnectez-vous puis capturez les trames avant toute action sur le voisinage réseau.
Identifiez le début, la fin et les paquets intermédiaires.

Phase 3 : Questions concernant SMB/CIFS (avec NetBIOS sur TCP/IP) :

a) En utilisant la capture du a) précédent, faire la même analyse sur la partie SMB de ces trames.
Détermination des différents types de trames. Séquencement de l'échange. Analyse du contenu des
champs. Repérer en particulier les trames associées (question-réponse) par les différents ID.

22
b) Par la commande "net use", associer le répertoire applint du serveur ist-bessat à un disque réseau
m: sur votre client. Dans ce cas aussi analyser les échanges SMB. Y a-t-il de nouveaux types de
trames ? Si oui analyser les.

c) Supprimer l'association. Trames SMB échangées ?

d) En réutilisant la capture du c) précédent, analyser l’échange relatif à l’authentification du point

de vue de la couche SMB.

e) Analyser de même les trames SMB échangées pour :

- la création d’un répertoire
- le déplacement dans un sous-répertoire
- la destruction d’un répertoire
- la création d’un fichier
- la lecture d’un fichier
- la destruction d’un ficher
- la copie d’un fichier

Pour tous ces échanges, seule la partie SMB/CIFS sera à considérer, il sera surtout important de
mettre l’accent sur les catégories de trames utilisées pour chaque fonction ainsi que sur leurs
paramètres spécifiques. L’analyse des champs récurrents ne sera pas nécessaire puisque vous l’aurez
faite à la question a). Il est nécessaire de bien visualiser le début, la fin et les paquets intermédiaires
dans l'échange.

23