J'ai fait quelques tests d'envois de paquets IP sur mon LAN Ethernet, en
changeant les adresses hardware source et destination par des octets
aléatoires. J'ai bien mis mon IP en source, celle du routeur en
destination, et après l'envoi d'un ICMP echo, j'ai bien reçu la réponse,
destinée à ma carte réseau (la bonne adresse, pas l'aléatoire).
J'observe le même comportement avec TCP, sans doute tous les protocoles
de la couche transport.
Pourquoi mon routeur, voyant arriver un paquet d'une adresse MAC
inconnue, n'envoie-t-il pas une requête ARP pour savoir à qui elle
appartient, ou pour prévenir les autres machines?
De plus, le routeur a su à qui renvoyer la réponse, il s'est donc basé
sur l'IP et non sur l'adresse MAC. Cette priorité est-elle définie
quelque part ?
"Cedric Blancher" a écrit dans le message de news:
Parce que le routeur s'est servi de la requête ARP du XP pour remplir son cache dans la mesure où celle-ci contient toutes les informations nécessaires pour le faire. Le comportement du cache ARP est opportuniste, dans le sens où toute information est utilisée.
Of course
Dans le cas présent, si une machine (XP) nous (Cisco) envoie une requête ARP, c'est qu'elle s'apprête à nous envoyer un paquet IP auquel nous devrons probablement répondre. Pour faire l'économie d'une requête ARP, nous prenons les informations mis en source dans le payload de sa requête pour alimenter notre cache. CQFD.
Je l'avais constaté, mais pas compris que c'était systématique pour toutes les piles. Est-ce Rfc"isé" ou systématique pour tout le monde découlant du bons sens ? Car je n'en ai pas trouvé de trace dans la 826.
Tu peux aller voir http://www.arp-sk.org/, je pense que la description du fonctionnement du cache ARP qui y est faite est assez complète.
Mille excuses de ne pas avoir répondu à Nicolas en ajoutant ton lien http://www.arp-sk.org/ comme référence. Je ne l'oublierais pas la prochaine fois Cédric.
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
"Cedric Blancher" <blancher@cartel-securite.fr> a écrit dans le message de
news: pan.2004.08.18.11.29.46.304977@cartel-securite.fr...
Parce que le routeur s'est servi de la requête ARP du XP pour remplir son
cache dans la mesure où celle-ci contient toutes les informations
nécessaires pour le faire. Le comportement du cache ARP est opportuniste,
dans le sens où toute information est utilisée.
Of course
Dans le cas présent, si une machine (XP) nous (Cisco) envoie une requête
ARP, c'est qu'elle s'apprête à nous envoyer un paquet IP auquel nous
devrons probablement répondre. Pour faire l'économie d'une requête ARP,
nous prenons les informations mis en source dans le payload de sa requête
pour alimenter notre cache. CQFD.
Je l'avais constaté, mais pas compris que c'était systématique pour toutes
les piles. Est-ce Rfc"isé" ou systématique pour tout le monde découlant du
bons sens ? Car je n'en ai pas trouvé de trace dans la 826.
Tu peux aller voir http://www.arp-sk.org/, je pense que la description du
fonctionnement du cache ARP qui y est faite est assez complète.
Mille excuses de ne pas avoir répondu à Nicolas en ajoutant ton lien
http://www.arp-sk.org/ comme référence. Je ne l'oublierais pas la prochaine
fois Cédric.
--
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
"Cedric Blancher" a écrit dans le message de news:
Parce que le routeur s'est servi de la requête ARP du XP pour remplir son cache dans la mesure où celle-ci contient toutes les informations nécessaires pour le faire. Le comportement du cache ARP est opportuniste, dans le sens où toute information est utilisée.
Of course
Dans le cas présent, si une machine (XP) nous (Cisco) envoie une requête ARP, c'est qu'elle s'apprête à nous envoyer un paquet IP auquel nous devrons probablement répondre. Pour faire l'économie d'une requête ARP, nous prenons les informations mis en source dans le payload de sa requête pour alimenter notre cache. CQFD.
Je l'avais constaté, mais pas compris que c'était systématique pour toutes les piles. Est-ce Rfc"isé" ou systématique pour tout le monde découlant du bons sens ? Car je n'en ai pas trouvé de trace dans la 826.
Tu peux aller voir http://www.arp-sk.org/, je pense que la description du fonctionnement du cache ARP qui y est faite est assez complète.
Mille excuses de ne pas avoir répondu à Nicolas en ajoutant ton lien http://www.arp-sk.org/ comme référence. Je ne l'oublierais pas la prochaine fois Cédric.
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Cedric Blancher
Le Wed, 18 Aug 2004 20:59:54 +0200, _SebF - www.frameip.com a écrit :
Je l'avais constaté, mais pas compris que c'était systématique pour toutes les piles. Est-ce Rfc"isé" ou systématique pour tout le monde découlant du bons sens ? Car je n'en ai pas trouvé de trace dans la 826.
Mal lu ;)))
http://www.faqs.org/rfcs/rfc826.html
Voir la section "Packet Reception" :
Lorsqu'une machine reçoit une requête ARP, elle fait :
?Do I have the hardware type in ar$hrd? Yes: (almost definitely) [optionally check the hardware length ar$hln] ?Do I speak the protocol in ar$pro? Yes: [optionally check the protocol length ar$pln] Merge_flag := false If the pair <protocol type, sender protocol address> is already in my translation table, update the sender hardware address field of the entry with the new information in the packet and set Merge_flag to true.
Donc si on reçoit une requête ARP pour une paire de protocoles qu'on comprend, alors on met à jour le cache avec les informations de l'émetteur.
Ce qui est confirmé par l'exemple donné plus bas qui parle d'une machine X, avec une MAX E(X) et une IP IP(X) qui veut causer à une machine Y (E(Y), IP(Y). Elle lui envoie donc une requête ARP. Et la RFC de dire :
"Machine Y gets this packet, and determines that it understands the hardware type (Ethernet), that it speaks the indicated protocol (Internet) and that the packet is for it ((ar$tpa)=IPA(Y)). It enters (probably replacing any existing entry) the information that <ET(IP), IPA(X)> maps to EA(X)."
-- BOFH excuse #406:
Bad cafeteria food landed all the sysadmins in the hospital.
Le Wed, 18 Aug 2004 20:59:54 +0200, _SebF - www.frameip.com a écrit :
Je l'avais constaté, mais pas compris que c'était systématique pour toutes
les piles. Est-ce Rfc"isé" ou systématique pour tout le monde découlant du
bons sens ? Car je n'en ai pas trouvé de trace dans la 826.
Mal lu ;)))
http://www.faqs.org/rfcs/rfc826.html
Voir la section "Packet Reception" :
Lorsqu'une machine reçoit une requête ARP, elle fait :
?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
[optionally check the hardware length ar$hln]
?Do I speak the protocol in ar$pro?
Yes:
[optionally check the protocol length ar$pln]
Merge_flag := false
If the pair <protocol type, sender protocol address> is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
Donc si on reçoit une requête ARP pour une paire de protocoles qu'on
comprend, alors on met à jour le cache avec les informations de
l'émetteur.
Ce qui est confirmé par l'exemple donné plus bas qui parle d'une machine
X, avec une MAX E(X) et une IP IP(X) qui veut causer à une machine Y
(E(Y), IP(Y). Elle lui envoie donc une requête ARP. Et la RFC de dire :
"Machine Y gets this packet, and determines that it understands
the hardware type (Ethernet), that it speaks the indicated protocol
(Internet) and that the packet is for it ((ar$tpa)=IPA(Y)). It enters
(probably replacing any existing entry) the information that <ET(IP),
IPA(X)> maps to EA(X)."
--
BOFH excuse #406:
Bad cafeteria food landed all the sysadmins in the hospital.
Le Wed, 18 Aug 2004 20:59:54 +0200, _SebF - www.frameip.com a écrit :
Je l'avais constaté, mais pas compris que c'était systématique pour toutes les piles. Est-ce Rfc"isé" ou systématique pour tout le monde découlant du bons sens ? Car je n'en ai pas trouvé de trace dans la 826.
Mal lu ;)))
http://www.faqs.org/rfcs/rfc826.html
Voir la section "Packet Reception" :
Lorsqu'une machine reçoit une requête ARP, elle fait :
?Do I have the hardware type in ar$hrd? Yes: (almost definitely) [optionally check the hardware length ar$hln] ?Do I speak the protocol in ar$pro? Yes: [optionally check the protocol length ar$pln] Merge_flag := false If the pair <protocol type, sender protocol address> is already in my translation table, update the sender hardware address field of the entry with the new information in the packet and set Merge_flag to true.
Donc si on reçoit une requête ARP pour une paire de protocoles qu'on comprend, alors on met à jour le cache avec les informations de l'émetteur.
Ce qui est confirmé par l'exemple donné plus bas qui parle d'une machine X, avec une MAX E(X) et une IP IP(X) qui veut causer à une machine Y (E(Y), IP(Y). Elle lui envoie donc une requête ARP. Et la RFC de dire :
"Machine Y gets this packet, and determines that it understands the hardware type (Ethernet), that it speaks the indicated protocol (Internet) and that the packet is for it ((ar$tpa)=IPA(Y)). It enters (probably replacing any existing entry) the information that <ET(IP), IPA(X)> maps to EA(X)."
-- BOFH excuse #406:
Bad cafeteria food landed all the sysadmins in the hospital.
_SebF - www.frameip.com
"Cedric Blancher" a écrit dans le message de news:
Mal lu ;)))
http://www.faqs.org/rfcs/rfc826.html
Voir la section "Packet Reception" :
J'ai bientôt ma visite médicale, je vais leur demander de m'analyser les yeux. :)
Merci Cédric.
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
"Cedric Blancher" <blancher@cartel-securite.fr> a écrit dans le message de
news: pan.2004.08.18.22.14.41.740463@cartel-securite.fr...
Mal lu ;)))
http://www.faqs.org/rfcs/rfc826.html
Voir la section "Packet Reception" :
J'ai bientôt ma visite médicale, je vais leur demander de m'analyser les
yeux. :)
Merci Cédric.
--
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
"Cedric Blancher" a écrit dans le message de news:
Mal lu ;)))
http://www.faqs.org/rfcs/rfc826.html
Voir la section "Packet Reception" :
J'ai bientôt ma visite médicale, je vais leur demander de m'analyser les yeux. :)
Merci Cédric.
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Nicolas Favre-Félix
Nicolas Favre-Félix wrote:
_SebF - www.frameip.com wrote:
Es-tu sur que tu as modifier l'adresse Mac de destination ? Et pas plutôt uniquement la source.
Oui, les deux. Par contre, ici (au boulot), la passerelle (un switch si je me souviens bien) ne répond que si son adresse MAC est spécifiée en destination. L'adresse source semble être ignorée. Ce soir, chez moi, je sniffe tout ça et j'uploade un log ethereal.
Hum, je n'arrive plus à le reproduire, je me suis sans doute trompé. Il est donc possible de modifier l'adresse MAC source mais pas de destination.
Merci pour vos explications.
Nicolas Favre-Félix wrote:
_SebF - www.frameip.com wrote:
Es-tu sur que tu as modifier l'adresse Mac de destination ? Et pas plutôt
uniquement la source.
Oui, les deux. Par contre, ici (au boulot), la passerelle (un switch si
je me souviens bien) ne répond que si son adresse MAC est spécifiée en
destination. L'adresse source semble être ignorée. Ce soir, chez moi, je
sniffe tout ça et j'uploade un log ethereal.
Hum, je n'arrive plus à le reproduire, je me suis sans doute trompé. Il
est donc possible de modifier l'adresse MAC source mais pas de destination.
Es-tu sur que tu as modifier l'adresse Mac de destination ? Et pas plutôt uniquement la source.
Oui, les deux. Par contre, ici (au boulot), la passerelle (un switch si je me souviens bien) ne répond que si son adresse MAC est spécifiée en destination. L'adresse source semble être ignorée. Ce soir, chez moi, je sniffe tout ça et j'uploade un log ethereal.
Hum, je n'arrive plus à le reproduire, je me suis sans doute trompé. Il est donc possible de modifier l'adresse MAC source mais pas de destination.
