Couches OSI et protocoles

D'abord merci pour vos réponses...

Prenons un autre exemple encore plus tordu.

Hum... allons-y. Près Vincent ? ;-)

1) PPP = Niveau 2, il permet de faire transiter des données entre ma
machine et un point d'accès en RTC (via mon modem donc)... Dans ce cas il
joue le même rôle que ma carte ethernet lors de transmission
d'informations sur le réseau local.

J'ai donc un "programme" ppp sur ma bécane linux. Bien, c'est clair...

OK, PPP niveau 2, avec RTC comme niveau 1.

2) Il se trouve que j'utilise une liaison ADSL. J'utilise donc un autre
programme rp-pppoe qui lui, va mettre en relation ma machine avec un
point d'accès au central ADSL via mon modem ADSL.

Il se trouve que c'est également le même ppp qui (au dessus) fonctionne.
rp-pppoe travaille "au dessous".

Ah non, stop ! PPPoE et PPP sont transportés physiquement par les mêmes
fils (sur un bout de chemin), mais sans suivre le même protocole, et ils
ne s'empiètent pas l'un sur l'autre. Ils sont *à côté*.

Donc PPPoE niveau 2, avec comme niveau 1 Ethernet, puis le réseau
téléphonique (mais avec des fraquences distinctes de celles utilisées
par le premier PPP). Tiens, au passage, ce PPPoE circule pendant un
moment au dessus d'ethernet, lui même de niveau 2.

On pourrait donc considérer que PPPoE et PPP sont tous les deux au niveau
2

Oui.

PPP -> PPPoE

Non, ils sont *à côté* l'un de l'autre. La preuve, si tu en coupes un,
tu n'affectes pas l'autre.

3) Il se trouve que j'ai mis en place sur mon serveur linux un service
PPTP. PPTP = VPN Windows 2000.
Ici c'est le démon PPTP qui va lancer PPP (cette fois ci en tant que
"serveur" je suppose)...

J'ai donc :
PPTP -> PPP -> PPPoE ???

non. Au sens strict, tu as PPTP (niveau 2) au dessus de TCP (il me
semble -- niveau 4, mais vu comme une simple liaison série, niveau 1,
par le PPP de PPTP). TCP est lui même au dessus d'IP (niveau 3), lui
même au dessus du PPP (ou PPPoE, ça dépend si tu utilises ton lien RTC
ou ADSL pour cette connexion -- niveau 2).

Dans ce cas qui bricole quelles couches ?
PPPoE : Bon, couche 2
PPP : Heu... Ici couche 2 mais au "dessus de PPPoE" ???
PPTP : ??? Argl, il est où ??

Tous fournissent un service de niveau 2.

L'exemple de PPTP est plus bon parce que c'est un protocole qui rend
transparente toute communication entre deux hôtes et qui plus est il ne
fourni pas de couche 7 (pas de shell ou bidule dans le même genre).

Où se situe PPTP ??? PPP et PPPoE sont-ils bien au niveau 2 ??

Les trois fournissent un service de niveau 2.

Arf, j'ai 4 mois pour être à l'aise avec tout ça sinon chuis mort !! ;-)

Courage

pierre

--
Pierre LALET
lalet@enseirb.fr -- http://www.enseirb.fr/~lalet
Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc
Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E

Annie D. - annie.demur@free.fr :

Mais, au moins dans le cas de la redirection de port TCP (je ne
connais pas toutes les fonctionnalités de SSH), je doute que SSH ait
besoin d'intervenir au niveau 3 et de transporter des datagrammes TCP
(on dit "datagramme" pour les paquets TCP ?). Je n'ai pas lu les
sources, mais AMA il s'agit plutôt d'un simple relais du flux de
données transporté par TCP et pas de transport de TCP. Pour relayer le
port X de l'extrémité A d'une connexion SSH vers le port Y d'un
serveur S, ça pourrait fonctionner simplement de cette façon :

- L'extrémité A de la connexion SSH écoute sur le port TCP X.
- Quand A reçoit une demande de connexion d'un client C sur le port X,
elle demande à l'autre extrémité, B, d'ouvrir une connexion TCP sur le
port Y du serveur S. On a donc 3 connexions TCP distinctes : la
connexion SSH entre A et B, la connexion entre le client C et A, et la
connexion entre B et le serveur C.
- Le contenu du flux TCP (pas les datagrammes) reçu de C par A est
relayé par SSH à B qui le retransmet à S.
- Réciproquement, le contenu du flux TCP reçu de S par B est relayé
par SSH à A qui le retransmet à C.
- Si C termine la connexion avec A, B termine la connexion avec S.
- Réciproquement, si S termine la connexion avec B, A termine la
connexion avec C.

D'abord merci pour vos réponses...

Prenons un autre exemple encore plus tordu.

1) PPP = Niveau 2, il permet de faire transiter des données entre ma
machine et un point d'accès en RTC (via mon modem donc)... Dans ce cas il
joue le même rôle que ma carte ethernet lors de transmission
d'informations sur le réseau local.

J'ai donc un "programme" ppp sur ma bécane linux. Bien, c'est clair...

2) Il se trouve que j'utilise une liaison ADSL. J'utilise donc un autre
programme rp-pppoe qui lui, va mettre en relation ma machine avec un
point d'accès au central ADSL via mon modem ADSL.

Il se trouve que c'est également le même ppp qui (au dessus) fonctionne.
rp-pppoe travaille "au dessous".

On pourrait donc considérer que PPPoE et PPP sont tous les deux au niveau
2

PPP -> PPPoE

3) Il se trouve que j'ai mis en place sur mon serveur linux un service
PPTP. PPTP = VPN Windows 2000.
Ici c'est le démon PPTP qui va lancer PPP (cette fois ci en tant que
"serveur" je suppose)...

J'ai donc :
PPTP -> PPP -> PPPoE ???

Dans ce cas qui bricole quelles couches ?
PPPoE : Bon, couche 2
PPP : Heu... Ici couche 2 mais au "dessus de PPPoE" ???
PPTP : ??? Argl, il est où ??


L'exemple de PPTP est plus bon parce que c'est un protocole qui rend
transparente toute communication entre deux hôtes et qui plus est il ne
fourni pas de couche 7 (pas de shell ou bidule dans le même genre).

Où se situe PPTP ??? PPP et PPPoE sont-ils bien au niveau 2 ??


Arf, j'ai 4 mois pour être à l'aise avec tout ça sinon chuis mort !! ;-)

Je ne veux pas etre de mauvaise fois, mais ssh est fait pour etre
transporte par du TCP/IP, si tu enleves ca ca n'est plus du ssh.
On retombe sur un modele point a point apparemment, ce qui change
tout.

Si. Le principe d'indépendance des couches fait que je peux envisager de
faire passer du ssh dans autre chose que le sacro-saint
TCP-au-desus-d'IP, et que cela va rester du ssh.

Le niveau 4 s'occupe surtout du bon acheminement des donnees (les ACK
et autres dans le cas de TCP/IP, la notion de ports...).

Et UDP : il ne s'occupe pas du bon acheminement des données. Est-il de
niveau 4 ?

Bon, plus exactement, la couche 4 s'occupe du bon acheminement entre
deux entités de sessions, ou faire un multiplexage des sessions.
C'est la notion de "port" dans UDP.

Donc en fait il y a plusieurs boulots, et ils peuvent être faits par des
gens différents.

Non. SSL est transporté par TCP.
Apres il y a la cas particulier de IPsec mais la oui on touche
explicitement a la couche 3.

Donc, on peut transporter au dessus d'une couche 3 un serice de couche 3.

SSL est entre TCP et ce qu'il y a au-dessus, mais il ne remplace pas
la couche 4. Donc soit on cree une couche intermediaire entre les
couches sessions et transport, soit on assimile (partiellement) SSL a
une couche de session
Normalement, elle s'occupe d'organiser un etablissement et un
maintient de la connexion. Or c'est TCP qui s'en occupe a un niveau
plus bas. Mais SSL s'occupe aussi d'etablir une sorte de connexion
avec echanges de clef, toussa...
Donc certes SSL n'est pas plus couche 5 que ne l'est TCP, mais SSL
n'est surement pas strictement de couche 4.

Bon, je propose SSL + TCP est de couche 4, comme TCP.

Encore une fois, le modele OSI n'est pas vraiment fait coller au
modele Internet, on ne peut dire : c'est comme ca, point.
Mais dans tous les cas le modele OSI ne prend pas en compte les
encapsulations de protocoles de couches inferieures.

Non, mais il suffit de considérer, comme je l'ai dit dans un autre post,
qu'un même service peut être vu comme fournissant une couche différente
selon le point de vue adopté.

Il n'est pas fait pour ca.

Non, mais je ne trouve pas qu'il s'y adapte mal.

Et donc redescendre du ssh a un niveau 4 voire 3 est pour moi un
non-sens.

Je ne redescends rien, j'accepte de voir que ssh fait un bout du boulot
de niveau 4. Cela ne l'empêche pas d'être en lui même de niveau 7.

pierre

--
Pierre LALET
lalet@enseirb.fr -- http://www.enseirb.fr/~lalet
Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc
Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E

Mais moi ça ne me gêne pas qu'un service soit de couches différentes
selon le point de vue adopté, et je trouve le modèle OSI assez adapté
pour décrire ça.

Tiens donc ?
Alors admettons que ton ssh soit de niveau 3.

Le fait que ssh propose un service qui est utilisé comme service de
couche 3 n'empêche pas qu'il soit de niveau 7. Bon, en plus sur ce
point, c'est niveau 4, comme me l'a fait remarquer Annie, et j'ai dit
que j'avais eu tort de prétendre qu'il faisait un peu de travail de
niveau 3.

Tout est une question de point de vue adopté !

Le TCP/IP qui le transporte est de quelle couche ?

IP 3, TCP 4.

Et dans la maniere dont toi tu te connectes habituellement, le PPP
transportant ces paquets TCP/IP, PPP passant par une connexion ssh qui
elle meme est sur du tcp/ip passant sur du ethernet, tu le mets où
dans le modele OSI ?

J'accepte le fait qu'un service soit vu différemment selon le point de
vue adopté. Et cela permet d'être beaucoup plus efficace pour concevoir
des architectures réseaux complexes, il me semble.

Ce modele n'est pas fait pour accumuler quantités de protocoles sur
une seule couche.
Ce modele n'est pas adapté a ca. Ou alors il faut considerer
"l'enveloppe exterieure".

Bein non, je trouve qu'il est assez bien adapté. Il n'est certes pas
parfait, mais il est bien pratique. Le tout est d'accepter de changer de
point de vue.

pierre

--
Pierre LALET
lalet@enseirb.fr -- http://www.enseirb.fr/~lalet
Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc
Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E

Pierre LALET <lalet@enseirb.fr> writes:

Euh, pierre, je te signale que l'implication "protocole de niveau 4,
donc ne transporte que du 5" est de toi...

oui, précédé d'un "si on suit ton raisonnement", je disais ça pour
essayer de te montrer que tu avais tort, pas parce que je le pensais,
puisque c'est le contraire que je dis.

Grmf, le café a pas marché génial je crois. Je laisse tomber ce point,
car je n'ai plus d'aspirine.

[Snip]

Eh bien, c'est le contraire de ce que dit Annie : "tous les PPP sur
quelque chose (oE, oA, PPTP, tunnel L2TP...) sont de couche 2, même
s'ils sont encapsulés dans un protocole de couche 2, 3 ou plus",
puisqu'elle dit qu'un PPP, même encapsulé dans IP (lui même
éventuellement encapsulé dans un autre PPP), est de niveau 2.

Cf ma reponse dans un article annexe.

[Snip]

Tu regardes trop haut et tu oublies que SSH est lui-meme transporte
par du TCP/IP. Il faut se placer du point de vue reseau et pas du
point de vue paquet, le modele OSI est un modele reseau.

Mais je m'en fous, de savoir par quoi est transporté ssh. Tiens,
d'ailleurs, si dans ssh je remplace le socket TCP par une liaison
série comprenant un mécanisme d'aquitement, ssh n'est *plus* au dessus
de TCP, et pourtant ça ne change *rien*.

Je ne veux pas etre de mauvaise fois, mais ssh est fait pour etre
transporte par du TCP/IP, si tu enleves ca ca n'est plus du ssh.
On retombe sur un modele point a point apparemment, ce qui change
tout.

[Snip]

Le niveau 4 s'occupe surtout du bon acheminement des donnees (les ACK
et autres dans le cas de TCP/IP, la notion de ports...).

Et UDP : il ne s'occupe pas du bon acheminement des données. Est-il de
niveau 4 ?

Bon, plus exactement, la couche 4 s'occupe du bon acheminement entre
deux entités de sessions, ou faire un multiplexage des sessions.
C'est la notion de "port" dans UDP.

Si on le place au niveau 4 c'est par abus, car il transporte des
données de niveau 5.
Pour moi SSL offre un service de Session, donc niveau 5.

Mais non. Au dessus de SSL, on a *exactement* la même chose qu'au
dessus de TCP.

Oui.

En dessous, ça se passe différemment, mais on s'en fout.

Non. SSL est transporté par TCP.
Apres il y a la cas particulier de IPsec mais la oui on touche
explicitement a la couche 3.
SSL est entre TCP et ce qu'il y a au-dessus, mais il ne remplace pas
la couche 4. Donc soit on cree une couche intermediaire entre les
couches sessions et transport, soit on assimile (partiellement) SSL a
une couche de session
Normalement, elle s'occupe d'organiser un etablissement et un
maintient de la connexion. Or c'est TCP qui s'en occupe a un niveau
plus bas. Mais SSL s'occupe aussi d'etablir une sorte de connexion
avec echanges de clef, toussa...
Donc certes SSL n'est pas plus couche 5 que ne l'est TCP, mais SSL
n'est surement pas strictement de couche 4.

Encore une fois, le modele OSI n'est pas vraiment fait coller au
modele Internet, on ne peut dire : c'est comme ca, point.
Mais dans tous les cas le modele OSI ne prend pas en compte les
encapsulations de protocoles de couches inferieures.

Il n'est pas fait pour ca.

Et donc redescendre du ssh a un niveau 4 voire 3 est pour moi un
non-sens.

Pierre LALET <lalet@enseirb.fr> writes:

Mais le modele OSI n'est pas fait pour qu'on lui colle dessus de
l'ethernet qui transporte du tcp du tcp-ip qui transporte du ssh qui
transporte du ppp qui transporte du tcp-ip qui transporte du ssh qui
transporte du ssl qui transporte du http...
Le modele OSI n'est pas fait pour ca.

Bein il faut pas l'utiliser pour parler d'encapsulation, alors.

Exact.

Mais moi ça ne me gêne pas qu'un service soit de couches différentes
selon le point de vue adopté, et je trouve le modèle OSI assez adapté
pour décrire ça.

Tiens donc ?
Alors admettons que ton ssh soit de niveau 3.
Le TCP/IP qui le transporte est de quelle couche ?
Et dans la maniere dont toi tu te connectes habituellement, le PPP
transportant ces paquets TCP/IP, PPP passant par une connexion ssh qui
elle meme est sur du tcp/ip passant sur du ethernet, tu le mets où
dans le modele OSI ?

Ce modele n'est pas fait pour accumuler quantités de protocoles sur
une seule couche.
Ce modele n'est pas adapté a ca. Ou alors il faut considerer
"l'enveloppe exterieure".

Pierre LALET <lalet@enseirb.fr> writes:

On part des basses couches pour aller vers les plus hautes.
On s'interesse aux couches qui transportent, et non pas à ce qui est
transporté.

Et alors ? Ton paquet n'est qu'un flux d'électron, et je ne veux pas
en savoir plus ?

On monte dans les couches. On ne stagne pas.

Nous ne serons pas d'accord, tant pis, mais ce que tu dis est
simplement idiot. C'est comme si je disais que tes paquets, quand ils
sont sur une ligne téléphonique, ne sont que des sons, et rien d'autre.

On monte dans les couches.
Je vois Ethernet.
Je vois IP.
Je vois TCP.
Je vois SSH.
SSH est la destination, le paquet est traité par le serveur ou le
client car c'est la destination finale du paquet sur un poste
informatique apres passage par le reseau. SSH elabore un nouveau
paquet a renvoyer sur le reseau, un nouveau cycle recommence.

Je vois PPP.
Je vois IP.
Je vois TCP.
Je vois SSH.
SSH est la destination, le paquet est traité par le serveur ou client
SSH sur un poste informatique qui est une fin de réseau, un nouveau
paquet est cree et renvoye.

Soit il est traité directement par la meme machine si c'est la
destination finale, sinon on l'encapsule par des couches inferieures
pour les reenvoyer (encore du PPP, de l'ATM, ou autre...)

qu'est-ce que ça change ? ssh fournit un bout de travail de niveau 4.

Sur un poste informatique, entre deux applications, mais pas entre
deux reseaux. OSI est un modele reseau.

Sauf, bien sur, si on se place du point de vue applicatif puisque le
but de ca c'est d'avoir une session ftp. Mais le reseau, et le modele
reseau, ils n'en ont rien à faire.

Réfléchir comme tu le fais, c'est ne pas tenir compte de l'étanchéité
entre les couches.

Je ne vois pas ce que tu entends par la.

Pierre LALET <lalet@enseirb.fr> writes:

On part des basses couches pour aller vers les plus hautes.
On s'interesse aux couches qui transportent, et non pas à ce qui est
transporté.
Et alors ? Ton paquet n'est qu'un flux d'électron, et je ne veux pas

en savoir plus ?
On monte dans les couches. On ne stagne pas.

Hein ? Mais **pourquoi** ? pourquoi le fait qu'au lieu d'avoir une ligne
physique, tu aies un protocole réseau d'empêche de voir le reste ?

Nous ne serons pas d'accord, tant pis, mais ce que tu dis est
simplement idiot. C'est comme si je disais que tes paquets, quand ils
sont sur une ligne téléphonique, ne sont que des sons, et rien d'autre.

On monte dans les couches.
[SNIP]

Je repose la même question. Quand tu encapsules du PPP dans une liaison
série, tu fais *la même chose* que quand tu la mets au dessus d'ethernet.

qu'est-ce que ça change ? ssh fournit un bout de travail de niveau 4.

Sur un poste informatique, entre deux applications, mais pas entre
deux reseaux. OSI est un modele reseau.

Entre deux machines. Comme pour les protocoles point à point. Sur une
machine, rien (ou presque) ne différencie un PPP au dessus d'une liaison
série implémentée par un RS232 d'une liaison série au dessus d'une
liaison série implémentée par un ssh.

Donc OSI est un modèle réseau qui s'applique bien ici.

Réfléchir comme tu le fais, c'est ne pas tenir compte de l'étanchéité
entre les couches.

Je ne vois pas ce que tu entends par la.

C'est très simple. Tu dois étudier une couche sans regarder ce qu'il y a
en dessous, ni au dessus. Simplement ce qu'elle fait, ce qu'elle utilise
(de la couche en dessous) et ce qu'elle propose (à la couche au dessus).
C'est grâce à ce concept qu'on peut faire cohabiter sur le réseau des
machines connectées différemment.

pierre

--
Pierre LALET
lalet@enseirb.fr -- http://www.enseirb.fr/~lalet
Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc
Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E

Pierre LALET - lalet@enseirb.fr :

PPP -> PPPoE

Non, ils sont *à côté* l'un de l'autre. La preuve, si tu en coupes un,
tu n'affectes pas l'autre.

Heu... A côté ?
Mais pourtant PPPoE a un besoin IMPERIEUX du process pppd (à moins que ce
soit le contraire), pareil pour PPTP si je dégomme pppd de mon install ça
fonctionne plus...

Si je fais un kill de pppd (je viens de le faire), adieu ma connexion adsl
(et pourtant le process pppoe, lui tourne toujours).

Oula ! Tu confonds le protocole et le process, qui n'ont *rien* à voir.
Je pensais que tu avais un PPP au dessus de RTC, et un PPPoE pour l'ADSL.

Donc quand tu dis "si tu en coupes un, tu n'affectes pas l'autre", je veux
bien mais pourtant ça ne va pas dans le sens de ce que je viens de
constater...

Cela n'a rien à voir. Ici, le *process* pppoe ne fait pas tout seul du
PPPoE. Il a besoin du process pppd. Mais ce qu'ils font ensemble, ce
n'est que du PPPoE, et certainement pas du PPPoE sur PPP.

pierre

--
Pierre LALET
lalet@enseirb.fr -- http://www.enseirb.fr/~lalet
Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc
Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E

Pierre LALET - lalet@enseirb.fr :

PPP -> PPPoE

Non, ils sont *… c“t‚* l'un de l'autre. La preuve, si tu en coupes un,
tu n'affectes pas l'autre.

Heu... A côté ?
Mais pourtant PPPoE a un besoin IMPERIEUX du process pppd (à moins que ce
soit le contraire), pareil pour PPTP si je dégomme pppd de mon install ça
fonctionne plus...

Si je fais un kill de pppd (je viens de le faire), adieu ma connexion adsl
(et pourtant le process pppoe, lui tourne toujours).
Donc quand tu dis "si tu en coupes un, tu n'affectes pas l'autre", je veux
bien mais pourtant ça ne va pas dans le sens de ce que je viens de
constater...

Ou est le hic ?