Pare-feu du point de vue Ethernet

Le
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 d=
atagramme 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 dat=
agramme 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 d=
e 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 commen=
taires ?

Cordialement,
Michelot
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Le Forgeron
Le #25523332
Le 03/07/2013 16:31, Michelot nous fit lire :
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
Le #25525352
Bonjour Le Forgeron,

Merci pour ces 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...



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 tra nsmission 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 com posées de constructeurs, d'intégrateurs, d'opérateurs. Je ne crois pa s que le pare-feu puisse déroger à une quelconque règle normative.

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 tr ouvons toutes les informations d'une architecture TCP/IP. Vous référez- vous à d'autres protocoles réseau ?

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.

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



La remarque est pertinente

en fait, transparent = aucune modification (à part une mise à la po ubelle de la trame))



Mise à la poubelle pour cause de contrôles d'intégrité de chaque un ité (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
Le #25525662
Bonjour,

Le 05/07/2013 10:39, Michelot nous fit lire :
> 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).
Publicité
Poster une réponse
Anonyme