Couches OSI et protocoles

Ah mais non mais non je m'insurge.
ssh est transporte par IP, et ne possede aucune des fonctionnalites de
ce dernier.
ssh ne peut pas etre de couche 3.
ssh est aussi transporte par IP.

ssh est transporté par TCP, de niveau 4. Si on suit ton raisonnement, il
est au moins de niveau 5, or, il transporte TCP, de niveau 4. Ca tient
pas debout.

Ensuite, ssh a la faculte de modifier des champs de TCP, mais il ne
remplace pas TCP. C'est pour cela qu'a la rigueur on peut dire qu'il
peut influencer la couche 4, mais pas completement, et il reste
fondamentalement un protocole de couches superieurs.

En fait, ssh *fournit* un service de niveau 3 quand il transporte TCP.
Cela n'empêche pas que le shell que te donne ssh est un service 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

Ensuite, ssh a la faculte de modifier des champs de TCP, mais il ne
remplace pas TCP. C'est pour cela qu'a la rigueur on peut dire qu'il
peut influencer la couche 4, mais pas completement, et il reste
fondamentalement un protocole de couches superieurs.

En fait, ssh *fournit* un service de niveau 3 quand il transporte TCP.
Cela n'empêche pas que le shell que te donne ssh est un service de
niveau 7.

Tiens, j'ai oublié un exemple : quand tu fais du ppp au dessus de ssh,
et que tu considères l'ensemble {ppp, ssh}, tu as une application qui
fournit un service de niveau 2 (ppp), et cela ne l'empêche pas d'être
transportée par un service de niveau 7. Cela n'a rien de contradictoire.

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:

TCP est classiquement considéré comme de couche 4 dans le modèle
OSI. Or, ssh 'transporte' le TCP, donc fournit, à mon sens, un service
de niveau 3.

Ah mais non mais non je m'insurge.
ssh est transporte par IP, et ne possede aucune des fonctionnalites de
ce dernier.

ssh ne peut pas etre de couche 3.
ssh est aussi transporte par IP.

Ensuite, ssh a la faculte de modifier des champs de TCP, mais il ne
remplace pas TCP. C'est pour cela qu'a la rigueur on peut dire qu'il
peut influencer la couche 4, mais pas completement, et il reste
fondamentalement un protocole de couches superieurs.

Zouplaz <pouet@pouet.com> writes:

Quel est le "moyen" utilisé pas ssh (puisque nous suivons cet exemple) pour
"redescendre" au niveau 4 ?

En fait pour etre plus precis, il touche a la couche 4, mais il ne
remplace pas la couche 4.

La couche 4 du modèle OSI c'est tcp/udp.

Euh, pour Internet, oui.

Dans ma ptite tête j'imagine
l'ensemble des couches comme une sorte d'API, chaque couche de bas niveau
proposant des fonctions aux couches supérieures. Normalement les couches de
bas niveau (2 à 4) sont implémentées dans le système d'exploitation et les
5,6,7 dans l'application.

C'est quasimment ca.
Les couches 3 et 4 peuvent aussi etre implantes dans l'espace utilisateur.

Donc, comment ssh s'y prend pour "intercepter" (dans le cas du tunneling)
les appels mettant en oeuvre tcp/udp afin de les bidouiller en interne et
les transmettre via les couches 5,6,7 ? Il détourne les fonctions de l'OS
(me semble bizarre ça) ? Je vois pas...

Tout simplement car la il ne s'agit plus d'une histoire de couche OSI.

Il faut distinguer le modele reseau, et la maniere dont il est mis en
oeuvre.

Je vais prendre le cas d'une carte ethernet que je connais bien.
La carte ethernet gere la couche 1, et partiellement la couche 2.
Elle gere le protocole CSMA/CD, le fanion de debut de trame, mais pas
le contenu lui meme (adresses MAC des cartes, et contenu des trames
bien sur).

Or si tu choisis ce que tu peux mettre dedans, automatiquement, tu as
le controle de tout ce qu'il passe sur le reseau.
Pour les systemes unix, le pilote de la carte reseau fait remonter le
contenu des trames au niveau de l'abstraction des sockets.

Si le systeme d'exploitation gere ca, ben tant pis.
Si rien n'est gere, rien ne se passe.
Mais il est tout a fait possible a l'utilisateur de se placer via
l'abstraction des sockets au niveau des couches 2, 3, 4 voire autre et
faire des programmes en consequent.

Heureusement, sinon il serait impossible de programmer des sniffer,
car si on avait pas acces aux informations de la couche 2, on ne
pourrait pas sniffer des trames ethernet.

Et libre a toi de modifier les trames Internet. Et c'est logique !
Forcement tu dois pouvoir avoir acces aux adresses que tu mets dans
tes trames, car il faut bien que tu dises vers quelles adresses tes
trames doivent aller.
Et forcement tu dois avoir un acces aux ports des trames. Un serveur
web n'est-il pas accessible via le port 80 ? C'est pas le systeme qui
decide, c'est l'utilisateur (ou quasimment).

Donc le serveur ssh ecoute sur un port donne qu'on lui a dit d'ecouter
car on peut le faire et c'est comme ca.
Et c'est tres facile a faire : il suffit d'ouvrir une socket en se
plagant au niveau TCP et en ecoutant un port qu'on dit d'ecouter.

Un modele n'est qu'un modele. Ca ne veut pas dire qu'on ne peut pas
intervenir aux niveaux qu'on le souhaite.
Idealement le paquet passera de couche en couche. Mais pratiquement
des bidouilles et des adaptations se font. Il suffit de se placer au
niveau qu'on le souhaite, tel un sniffer pouvant se placer jusqu'au
niveau 2.

En esperant avoir ete clair.

Pierre LALET <lalet@enseirb.fr> writes:

ssh est transporte par IP, et ne possede aucune des fonctionnalites de
ce dernier.
ssh ne peut pas etre de couche 3.
ssh est aussi transporte par IP.

ssh est transporté par TCP, de niveau 4. Si on suit ton raisonnement,
il est au moins de niveau 5, or, il transporte TCP, de niveau 4. Ca
tient pas debout.

Mais... non.
Ssh touche au niveau 4 mais n'est pas de niveau 4.
Il ne transporte pas TCP. C'est TCP qui transporte ssh.
Les ACK et autres, c'est ssh qui le fait pour toi ???

Meme si dans ses trames sont encapsulees des trames TCP, ssh est
transporte par une autre couche TCP.

Zouplaz <pouet@pouet.com> writes:

Mon besoin est de trouver un ensemble de schémas clairs expliquant
l'interaction entre les principaux protocoles offrant des fonctions de
tunneling et les couches du modèle OSI (sans, encore une fois devoir lire
des rfc qui seront trop complexes pour moi)

Bon, ne te casse pas la tete avec ca.
C'est comme quand une enveloppe timbree contient une autre enveloppe
timbree.

Est-ce que tu vas te demander si le facteur doit ouvrir l'enveloppe
pour acceder a la vrai enveloppe ?
Ben non : en realite, il se contente d'acheminer l'enveloppe selon
l'adresse exterieure. Donc dans le cas de tunnels qui encapsulent des
trames, il faut se concentrer sur le comment du transport du tunnel.

Comme ssh qui est en fait transporte par du TCP et donc ssh ne
remplace pas la couche 4, point.
Une fois desemcapsule on retombe sur le modele classique : j'enleve
l'enveloppe de l'autre enveloppe, et elle devient une enveloppe
timbree a part entiere, meme si elle a ete transportee bizzarrement
jusque la.

Le modele OSI n'est qu'un *modele*, et pas la Verite.
On pourrait creer des modeles speciaux pour ces cas particuliers.

Mais... non.
Ssh touche au niveau 4 mais n'est pas de niveau 4.
Il ne transporte pas TCP. C'est TCP qui transporte ssh.
Les ACK et autres, c'est ssh qui le fait pour toi ???

ssh est transporté par un lien TCP, et est capable de faire du forward
TCP, donc capable de transporter du TCP. Il **fournit** donc un service
qui transporte un protocole de niveau 4, pour moi il **fournit** donc un
service de niveau 3. Cela ne veut pas dire il **est** de niveau 3.

Ssh transporte TCP au même titre qu'IP, je ne vois pas de différence
fondamentale.

Meme si dans ses trames sont encapsulees des trames TCP, ssh est
transporte par une autre couche TCP.

Oui, il est encapsulé dans du TCP, et ? Est-ce que cela l'empêche de
transporter un *autre* lien TCP ? Non.

cf. exemple ppp sur ssh

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 wrote:

Ah mais non mais non je m'insurge.

Chui d'accord avec Vincent ;o)

ssh est transporte par IP, et ne possede aucune des fonctionnalites de
ce dernier.
ssh ne peut pas etre de couche 3.
ssh est aussi transporte par IP.

ssh est transporté par TCP, de niveau 4. Si on suit ton raisonnement, il
est au moins de niveau 5, or, il transporte TCP, de niveau 4. Ca tient
pas debout.

Outre le fait que je ne pense pas que SSH transporte TCP, la couche d'un
protocole se définit par les services qu'il propose, pas en ajoutant 1
au numéro de la couche sur laquelle il s'appuie. Par exemple, 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. Il
y a eu un fil à ce sujet ici ou dans fcre il y a quelques temps, dans
lequel j'avais fait montre de ma méconnaissance du sujet.

En fait, ssh *fournit* un service de niveau 3 quand il transporte TCP.
Cela n'empêche pas que le shell que te donne ssh est un service de niveau 7.

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.

Dans cette vision, la gestion réseau (contrôle des erreurs,
retransmission) est géré par les couches TCP des différentes machines,
pas par SSH dont le rôle reste clairement au-dessus de la couche 4.

Mais bon, le relais de port de SSH ne marche peut-être pas du tout comme
ça.

Pierre LALET wrote:

Ah mais non mais non je m'insurge.

Chui d'accord avec Vincent ;o)

ssh est transporte par IP, et ne possede aucune des fonctionnalites de
ce dernier.
ssh ne peut pas etre de couche 3.
ssh est aussi transporte par IP.

ssh est transporté par TCP, de niveau 4. Si on suit ton raisonnement, il
est au moins de niveau 5, or, il transporte TCP, de niveau 4. Ca tient
pas debout.

Outre le fait que je ne pense pas que SSH transporte TCP, la couche d'un
protocole se définit par les services qu'il propose, pas en ajoutant 1
au numéro de la couche sur laquelle il s'appuie. Par exemple, 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. Il
y a eu un fil à ce sujet ici ou dans fcre il y a quelques temps, dans
lequel j'avais fait montre de ma méconnaissance du sujet.

Je sais bien que "la couche d'un protocole se définit par les services
qu'il propose, pas en ajoutant 1 au numéro de la couche sur laquelle il
s'appuie". Relis mes posts, c'est pour ça que j'ai écrit "si on suit ton
raisonnement,...".

Tu dis ici exactement ce que j'essaie de faire comprendre à Vincent, à
part sur un point : je disais que ssh est capable de transporter du TCP,
mais on va y revenir.

En fait, ssh *fournit* un service de niveau 3 quand il transporte TCP.
Cela n'empêche pas que le shell que te donne ssh est un service de niveau 7.

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 :
[SNIP]

Tu as sans doute raison. Donc on peut dire alors que ssh fait le travail
d'une partie de TCP sur un bout du chemin (et ce même s'il fonctionne
lui même au dessus de TCP). Donc il fournit plutôt des services de
niveau 4 ? Enfin, dans tous les cas, ssh est capable de fournir des
services de niveau 3 ou 4, selon comment il fait le travail, et c'est
sans doute 4.

Dans cette vision, la gestion réseau (contrôle des erreurs,
retransmission) est géré par les couches TCP des différentes machines,
pas par SSH dont le rôle reste clairement au-dessus de la couche 4.

Tu as raison.

Mais bon, le relais de port de SSH ne marche peut-être pas du tout comme
ça.

Si, mea culpa, je plaide coupable sans circonstances atténuantes.

Je modifie donc mon assertion en : "ssh fait le travail d'une partie de
TCP sur un bout du chemin et fournit donc des services de niveau 4".
Exactement comme SSL, qui bien qu'encapsulé dans du TCP, fournit des
services de niveau 4.

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> writes:

Outre le fait que je ne pense pas que SSH transporte TCP, la couche d'un
protocole se définit par les services qu'il propose, pas en ajoutant 1
au numéro de la couche sur laquelle il s'appuie. Par exemple, 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.

C'est mieux explique que moi, et c'est ce que je voulais exprimer.

[Snip]

Dans cette vision, la gestion réseau (contrôle des erreurs,
retransmission) est géré par les couches TCP des différentes machines,
pas par SSH dont le rôle reste clairement au-dessus de la couche 4.

Voila.
C'est la-dessus qu'il faut calquer les fonctionnalites de ssh sur le
modele OSI.
Car sinon autant dire que ssh est de niveau 2 car il fait du point a
point entre deux postes !

Il ne faut pas regarder ce qui est transporté, mais la couche qui
transporte. Apres, oui, une fois le paquet desemcapsulé de ssh, on se
retrouve avec un paquet TCP. Mais c'est le meme coup qu'une lettre
dans une lettre. C'est la lettre contenante qu'il faut regarder pour
pouvoir l'acheminer, pas la lettre contenue.