Pare-feu du point de vue Ethernet

[Michelot]

Bonjour,

Les commentaires relatifs à la question précédente sur les interfaces étaient intéressants. Nous avons dérivé un peu, mais c'est normal dans un forum de spécificité technique.

Le sujet de ce jour concerne le pare-feu du point de vue Ethernet.

Je ne suis pas sûr d'arriver à être suffisammet clair. Tant pis ! Je me lance.

Dans n'importe quel autre équipement de réseau, lorsqu'on s'occupe du datagramme IP, on oublie la trame MAC. Celle-ci a été vérifiée sous toutes les coutures, on a remarqué qu'elle portait en charge utile un datagramme IP, on l'extrait et on jette tout ce qui concerne MAC.

A tel point que si on veut renvoyer le datagramme IP dans une trame MAC, on reconstruit celle-ci : DA, SA, TAG, FCS.

Ce n'est pas comme ça dans le pare-feu transparent. Toutes les parties de la trame MAC sont conservées de l'entrée à la sortie. Il n'y a pas de décapsulation du datagramme IP et reconstruction d'une autre trame MAC.

Avez-vous déjà pensé à la chose ? Cela vous suscite-t-il des commentaires ?

Cordialement,
Michelot

[Le Forgeron]

Post by Michelot
Ce n'est pas comme ça dans le pare-feu transparent. Toutes les parties de la trame MAC sont conservées de l'entrée à la sortie. Il n'y a pas de décapsulation du datagramme IP et reconstruction d'une autre trame MAC.
Avez-vous déjà pensé à la chose ? Cela vous suscite-t-il des commentaires ?

C'est pour quoi ? un examen de philo sur les équipements qui ne respecte
pas les attentes d'un élément réseau (pour diverses raisons, plus ou
moins justifiables, allant des proxy aux équipements d'espionnage en
passant par ceux de filtrages entre deux prises) ?

En outre votre raisonnement semble se limiter au paquet IP... il y a
plus de choses sous le soleil que juste des paquets IP.

Enfin, pourquoi réencoder et perdre du temps et de la ressource (et
prendre des risques) alors qu'on peut conserver l'original pour le
retransmettre (si on est "transparent", on ne décrémente pas les TTL
IP... en fait, transparent = aucune modification (à part une mise à la
poubelle de la trame))

[Michelot]

Bonjour Le Forgeron,

Merci pour ces commentaires.

Post by Le Forgeron
C'est pour quoi ? un examen de philo sur les équipements
qui ne respecte pas les attentes d'un élément réseau
(pour diverses raisons, plus ou moins justifiables...

J'accepte le fait que j'ai introduit ceci sous l'angle d'une méditation métaphysique, que l'on pourrait caractériser par une ontologie de la transmission de données.

Par contre, les attentes d'un élément de réseau (NE) sont spécifiés dans des documents normatifs. L'IEEE et l'UIT-T sont des entités composées de constructeurs, d'intégrateurs, d'opérateurs. Je ne crois pas que le pare-feu puisse déroger à une quelconque règle normative.

Post by Le Forgeron
En outre votre raisonnement semble se limiter au paquet IP...
il y a plus de choses sous le soleil que juste des paquets IP.

Diantre ! le datagramme IP dispose d'une charge utile dans laquelle nous trouvons toutes les informations d'une architecture TCP/IP. Vous référez-vous à d'autres protocoles réseau ?

Post by Le Forgeron
Enfin, pourquoi réencoder et perdre du temps et de la ressource
(et prendre des risques) alors qu'on peut conserver l'original
pour le retransmettre

L'argument peut être tenu bien que, dans le mode transparent du pare-feu, on ne commute pas et on ne route pas. On pointe des champs d’information sans décapsuler.

Post by Le Forgeron
(si on est "transparent", on ne décrémente pas les TTL IP...

La remarque est pertinente

Post by Le Forgeron
en fait, transparent = aucune modification (à part une mise à la poubelle de la trame))

Mise à la poubelle pour cause de contrôles d'intégrité de chaque unité (erreurs de transmission) et pour cause de règles de corrélation entre les unités (avec stockage d’un historique circonstancié).

Cordialement,
Michelot

[Le Forgeron]

Bonjour,

Post by Michelot

Post by Le Forgeron
En outre votre raisonnement semble se limiter au paquet IP...
il y a plus de choses sous le soleil que juste des paquets IP.

Diantre ! le datagramme IP dispose d'une charge utile dans laquelle nous trouvons toutes les informations d'une architecture TCP/IP. Vous référez-vous à d'autres protocoles réseau ?

Ce groupe concerne Ethernet... il ne me semblait donc pas inutile de
rappeler qu'il y a plus qu'IP de possible dans Ethernet (ne serait-ce
que ARP et RARP pour cette famille).