Les commentaires relatifs =E0 la question pr=E9c=E9dente sur les interfaces=
=E9taient int=E9ressants. Nous avons d=E9riv=E9 un peu, mais c'est normal =
dans un forum de sp=E9cificit=E9 technique.
Le sujet de ce jour concerne le pare-feu du point de vue Ethernet.
Je ne suis pas s=FBr d'arriver =E0 =EAtre suffisammet clair. Tant pis ! Je =
me lance.
Dans n'importe quel autre =E9quipement de r=E9seau, lorsqu'on s'occupe du d=
atagramme IP, on oublie la trame MAC. Celle-ci a =E9t=E9 v=E9rifi=E9e sous =
toutes les coutures, on a remarqu=E9 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 =E7a dans le pare-feu transparent. Toutes les parties de=
la trame MAC sont conserv=E9es de l'entr=E9e =E0 la sortie. Il n'y a pas d=
e d=E9capsulation du datagramme IP et reconstruction d'une autre trame MAC.
Avez-vous d=E9j=E0 pens=E9 =E0 la chose ? Cela vous suscite-t-il des commen=
taires ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Le Forgeron
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))
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))
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.
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 dinformation 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 dun historique circonstancié).
Cordialement, Michelot
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 dinformation 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 dun historique circonstancié).
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 dinformation 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 dun historique circonstancié).
Cordialement, Michelot
Le Forgeron
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).
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).
> 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).
