Si un firewall renvoit un ICMP port unreachable pour du TCP, c'est pas
bien !
Certes, mais c'est ce que fait la cible REJECT de ipchains, et c'est le
comportement par défaut de la cible REJECT de Netfilter. Et ça a l'air
d'avoir le même effet.
Si un firewall renvoit un ICMP port unreachable pour du TCP, c'est pas
bien !
Certes, mais c'est ce que fait la cible REJECT de ipchains, et c'est le
comportement par défaut de la cible REJECT de Netfilter. Et ça a l'air
d'avoir le même effet.
Si un firewall renvoit un ICMP port unreachable pour du TCP, c'est pas
bien !
Certes, mais c'est ce que fait la cible REJECT de ipchains, et c'est le
comportement par défaut de la cible REJECT de Netfilter. Et ça a l'air
d'avoir le même effet.
Si je ne m'abuse, un TCP RST est renvoyé lors d'une requête TCP,
l'ICMP port unreachable étant lui réservé à UDP.
Si un firewall renvoit un ICMP port unreachable pour du TCP, c'est pas
bien !
Si je ne m'abuse, un TCP RST est renvoyé lors d'une requête TCP,
l'ICMP port unreachable étant lui réservé à UDP.
Si un firewall renvoit un ICMP port unreachable pour du TCP, c'est pas
bien !
Si je ne m'abuse, un TCP RST est renvoyé lors d'une requête TCP,
l'ICMP port unreachable étant lui réservé à UDP.
Si un firewall renvoit un ICMP port unreachable pour du TCP, c'est pas
bien !
Je ne parlais pas de la pile IP, mais plutôt d'un defaut de mon programme.
Sinon, pour ce qui concerne la pile IP, tu as encore raison, la conclusion
du Post précédent était justement que Le Rst renvoyé était natif au
fonctionnement de la pile IP.
Je ne parlais pas de la pile IP, mais plutôt d'un defaut de mon programme.
Sinon, pour ce qui concerne la pile IP, tu as encore raison, la conclusion
du Post précédent était justement que Le Rst renvoyé était natif au
fonctionnement de la pile IP.
Je ne parlais pas de la pile IP, mais plutôt d'un defaut de mon programme.
Sinon, pour ce qui concerne la pile IP, tu as encore raison, la conclusion
du Post précédent était justement que Le Rst renvoyé était natif au
fonctionnement de la pile IP.
l'ICMP port unreachable étant lui réservé à UDP.
Et éventuellement par défaut à tout autre protocole IP pour lequel la
notion de port ouvert/fermé a un sens.
C'est plutôt ICMP protocol unreachable (code 3, type 2) dans ce cas.
l'ICMP port unreachable étant lui réservé à UDP.
Et éventuellement par défaut à tout autre protocole IP pour lequel la
notion de port ouvert/fermé a un sens.
C'est plutôt ICMP protocol unreachable (code 3, type 2) dans ce cas.
l'ICMP port unreachable étant lui réservé à UDP.
Et éventuellement par défaut à tout autre protocole IP pour lequel la
notion de port ouvert/fermé a un sens.
C'est plutôt ICMP protocol unreachable (code 3, type 2) dans ce cas.
S'il supporte AFP mais qu'aucun processus n'écoute sur le port spécifié,
il me renvoie une erreur ICMP port unreachable.
Non ?
Ca dépends
Le Datagrame ne sera pas envoyé à la couche Tcp ou Udp. Je pense donc que
cela dépend de ton AFP, car c'est toi, Annie, qui définit le fonctionnement
de l'AFP.
Tcp et Udp sont natif à ta pile IP et sont donc intégrés dans la gestion des
Socket. Si tu developpes un process basé sur un "nouveau" type-protocol, ta
pile Ip ne connaitra pas le fonctionnement de ton AFP, il faudra sûrement
que tu gères les renvois d'erreurs.
Qu'en pensez-vous ?
S'il supporte AFP mais qu'aucun processus n'écoute sur le port spécifié,
il me renvoie une erreur ICMP port unreachable.
Non ?
Ca dépends
Le Datagrame ne sera pas envoyé à la couche Tcp ou Udp. Je pense donc que
cela dépend de ton AFP, car c'est toi, Annie, qui définit le fonctionnement
de l'AFP.
Tcp et Udp sont natif à ta pile IP et sont donc intégrés dans la gestion des
Socket. Si tu developpes un process basé sur un "nouveau" type-protocol, ta
pile Ip ne connaitra pas le fonctionnement de ton AFP, il faudra sûrement
que tu gères les renvois d'erreurs.
Qu'en pensez-vous ?
S'il supporte AFP mais qu'aucun processus n'écoute sur le port spécifié,
il me renvoie une erreur ICMP port unreachable.
Non ?
Ca dépends
Le Datagrame ne sera pas envoyé à la couche Tcp ou Udp. Je pense donc que
cela dépend de ton AFP, car c'est toi, Annie, qui définit le fonctionnement
de l'AFP.
Tcp et Udp sont natif à ta pile IP et sont donc intégrés dans la gestion des
Socket. Si tu developpes un process basé sur un "nouveau" type-protocol, ta
pile Ip ne connaitra pas le fonctionnement de ton AFP, il faudra sûrement
que tu gères les renvois d'erreurs.
Qu'en pensez-vous ?
Si on en crois la la RFC 792, qui n'est pas aussi clair que ça :
If, in the destination host, the IP module cannot deliver the
datagram because the indicated protocol module or process port is
not active, the destination host may send a destination
unreachable message to the source host.
Que je traduirais par :
Dans le cas pour la machine destinatrice le module IP n'est pas en
mesure de transmettre le datagramme car le protocole ou le port du
processus n'est pas actif, la machine destinatrice peut envoyer un
message _destination unreachable_ à la machine émetrice.
Dans les choses qui ne sont pas claires :
- est-ce que le _may_ dans _the destination host may send_ doit-il est
compris en anglais (possibilité sans obligation, ce qui correspond à
ce qui est usuellement le cas dans les RFC mais n'est défini que plus
tard RFC 2119) ou en américain (possibilité avec notion d'obligation).
- Il n'est pas explicitement dit le type de message à envoyer en
fonction de la situation bien que le bon sens suppose qu'on envoie un
_port unreachable_ si on sait comment le protocolw en question gère
les ports, il faut pour cela se réferer à la RFC 1812 qui normalement
concerne les routeurs :
Port Unreachable - generated if the designated transport protocol
(e.g., UDP) is unable to demultiplex the datagram in the
transport layer of the final destination but has no protocol
mechanism to inform the sender;
Traduction :
_Port Unreachable_ - ce message est généré si le protocole de transport
spécifié (par exemple UDP) n'est pas capable de démultiplexer le
datagramme de la couche de transport de la destination finale et n'a
pas d'autre moyen d'en informer l'émetteur.
Par contre, il est explicitement dit dans la RFC 792 qu'on est pas
obligé d'envoyer des ICMP sauf pour les problèmes de fragmentation pour
des paquets qui ne concerne pas IP.
Donc pour le protocole AFP (ou un autre), on peut avoir cinq types de
réponse, en situation normale :
1) une réponse AFP positive (la machine gère AFP et le port spécifié est
associé à quelques chose)
2) une réponse AFP négative (la machine gère AFP et le port spécifié est
soit associé à quelques chose et la communication n'est pas
authorisée au niveau applicatif, soit le port n'a aucune association
applicative)
3) une réponse en ICMP _port unreachable_ (la machine connait AFP, mais
il n'y a auncune association applicative)
4) une réponse en ICMP _protocol unreachable_ (la machine ne connait pas
AFP)
5) pas de réponse du tout
Si on se replace dans le monde TCP/UDP un peu plus connu, voici quelque
exemple à chacun des cas :
1) Exemple en UDP, si on fait une requête DNS sur un serveur de nom, on
a une réponse UDP. Pour le TCP la réponse à un SYN doit être un SYN-ACK
2) En TCP, l'exemple est la réponse RST à un SYN. En UDP. le protocole
on a pas cette notion.
3) En UDP, c'est facile il suffit d'essayer une connexion sur un port
sur lequel rien écoute. En TCP si on suit la norme on ne doit pas avoir
ce type de message.
4) Si on essaye de parler autre chose que UDP/TCP/ICMP sur une machine
classique on a un _protocol unreachable_
5) En UDP, si on prend syslog par exemple, le flux est unidirectionnel,
il n'y a pas de réponse du serveur de journalisation.
Si on se place dans le cadre d'un routeur ou d'élément de filtrage, on
peut aussi avoir d'autre réponse de type _destination unreachable_, en
particulier pour un élément de filtrage, on peut émettre un
_Communication Administratively Prohibited_ (type 13), ipour indiquer
que le flux est inderdit par un choix administratif et non que le
service n'est pas disponible pour une raison technique. Il y d'autres
type de réponse listés dans la RFC 1812 (paragraphe 5.2.7.1).
Si on en crois la la RFC 792, qui n'est pas aussi clair que ça :
If, in the destination host, the IP module cannot deliver the
datagram because the indicated protocol module or process port is
not active, the destination host may send a destination
unreachable message to the source host.
Que je traduirais par :
Dans le cas pour la machine destinatrice le module IP n'est pas en
mesure de transmettre le datagramme car le protocole ou le port du
processus n'est pas actif, la machine destinatrice peut envoyer un
message _destination unreachable_ à la machine émetrice.
Dans les choses qui ne sont pas claires :
- est-ce que le _may_ dans _the destination host may send_ doit-il est
compris en anglais (possibilité sans obligation, ce qui correspond à
ce qui est usuellement le cas dans les RFC mais n'est défini que plus
tard RFC 2119) ou en américain (possibilité avec notion d'obligation).
- Il n'est pas explicitement dit le type de message à envoyer en
fonction de la situation bien que le bon sens suppose qu'on envoie un
_port unreachable_ si on sait comment le protocolw en question gère
les ports, il faut pour cela se réferer à la RFC 1812 qui normalement
concerne les routeurs :
Port Unreachable - generated if the designated transport protocol
(e.g., UDP) is unable to demultiplex the datagram in the
transport layer of the final destination but has no protocol
mechanism to inform the sender;
Traduction :
_Port Unreachable_ - ce message est généré si le protocole de transport
spécifié (par exemple UDP) n'est pas capable de démultiplexer le
datagramme de la couche de transport de la destination finale et n'a
pas d'autre moyen d'en informer l'émetteur.
Par contre, il est explicitement dit dans la RFC 792 qu'on est pas
obligé d'envoyer des ICMP sauf pour les problèmes de fragmentation pour
des paquets qui ne concerne pas IP.
Donc pour le protocole AFP (ou un autre), on peut avoir cinq types de
réponse, en situation normale :
1) une réponse AFP positive (la machine gère AFP et le port spécifié est
associé à quelques chose)
2) une réponse AFP négative (la machine gère AFP et le port spécifié est
soit associé à quelques chose et la communication n'est pas
authorisée au niveau applicatif, soit le port n'a aucune association
applicative)
3) une réponse en ICMP _port unreachable_ (la machine connait AFP, mais
il n'y a auncune association applicative)
4) une réponse en ICMP _protocol unreachable_ (la machine ne connait pas
AFP)
5) pas de réponse du tout
Si on se replace dans le monde TCP/UDP un peu plus connu, voici quelque
exemple à chacun des cas :
1) Exemple en UDP, si on fait une requête DNS sur un serveur de nom, on
a une réponse UDP. Pour le TCP la réponse à un SYN doit être un SYN-ACK
2) En TCP, l'exemple est la réponse RST à un SYN. En UDP. le protocole
on a pas cette notion.
3) En UDP, c'est facile il suffit d'essayer une connexion sur un port
sur lequel rien écoute. En TCP si on suit la norme on ne doit pas avoir
ce type de message.
4) Si on essaye de parler autre chose que UDP/TCP/ICMP sur une machine
classique on a un _protocol unreachable_
5) En UDP, si on prend syslog par exemple, le flux est unidirectionnel,
il n'y a pas de réponse du serveur de journalisation.
Si on se place dans le cadre d'un routeur ou d'élément de filtrage, on
peut aussi avoir d'autre réponse de type _destination unreachable_, en
particulier pour un élément de filtrage, on peut émettre un
_Communication Administratively Prohibited_ (type 13), ipour indiquer
que le flux est inderdit par un choix administratif et non que le
service n'est pas disponible pour une raison technique. Il y d'autres
type de réponse listés dans la RFC 1812 (paragraphe 5.2.7.1).
Si on en crois la la RFC 792, qui n'est pas aussi clair que ça :
If, in the destination host, the IP module cannot deliver the
datagram because the indicated protocol module or process port is
not active, the destination host may send a destination
unreachable message to the source host.
Que je traduirais par :
Dans le cas pour la machine destinatrice le module IP n'est pas en
mesure de transmettre le datagramme car le protocole ou le port du
processus n'est pas actif, la machine destinatrice peut envoyer un
message _destination unreachable_ à la machine émetrice.
Dans les choses qui ne sont pas claires :
- est-ce que le _may_ dans _the destination host may send_ doit-il est
compris en anglais (possibilité sans obligation, ce qui correspond à
ce qui est usuellement le cas dans les RFC mais n'est défini que plus
tard RFC 2119) ou en américain (possibilité avec notion d'obligation).
- Il n'est pas explicitement dit le type de message à envoyer en
fonction de la situation bien que le bon sens suppose qu'on envoie un
_port unreachable_ si on sait comment le protocolw en question gère
les ports, il faut pour cela se réferer à la RFC 1812 qui normalement
concerne les routeurs :
Port Unreachable - generated if the designated transport protocol
(e.g., UDP) is unable to demultiplex the datagram in the
transport layer of the final destination but has no protocol
mechanism to inform the sender;
Traduction :
_Port Unreachable_ - ce message est généré si le protocole de transport
spécifié (par exemple UDP) n'est pas capable de démultiplexer le
datagramme de la couche de transport de la destination finale et n'a
pas d'autre moyen d'en informer l'émetteur.
Par contre, il est explicitement dit dans la RFC 792 qu'on est pas
obligé d'envoyer des ICMP sauf pour les problèmes de fragmentation pour
des paquets qui ne concerne pas IP.
Donc pour le protocole AFP (ou un autre), on peut avoir cinq types de
réponse, en situation normale :
1) une réponse AFP positive (la machine gère AFP et le port spécifié est
associé à quelques chose)
2) une réponse AFP négative (la machine gère AFP et le port spécifié est
soit associé à quelques chose et la communication n'est pas
authorisée au niveau applicatif, soit le port n'a aucune association
applicative)
3) une réponse en ICMP _port unreachable_ (la machine connait AFP, mais
il n'y a auncune association applicative)
4) une réponse en ICMP _protocol unreachable_ (la machine ne connait pas
AFP)
5) pas de réponse du tout
Si on se replace dans le monde TCP/UDP un peu plus connu, voici quelque
exemple à chacun des cas :
1) Exemple en UDP, si on fait une requête DNS sur un serveur de nom, on
a une réponse UDP. Pour le TCP la réponse à un SYN doit être un SYN-ACK
2) En TCP, l'exemple est la réponse RST à un SYN. En UDP. le protocole
on a pas cette notion.
3) En UDP, c'est facile il suffit d'essayer une connexion sur un port
sur lequel rien écoute. En TCP si on suit la norme on ne doit pas avoir
ce type de message.
4) Si on essaye de parler autre chose que UDP/TCP/ICMP sur une machine
classique on a un _protocol unreachable_
5) En UDP, si on prend syslog par exemple, le flux est unidirectionnel,
il n'y a pas de réponse du serveur de journalisation.
Si on se place dans le cadre d'un routeur ou d'élément de filtrage, on
peut aussi avoir d'autre réponse de type _destination unreachable_, en
particulier pour un élément de filtrage, on peut émettre un
_Communication Administratively Prohibited_ (type 13), ipour indiquer
que le flux est inderdit par un choix administratif et non que le
service n'est pas disponible pour une raison technique. Il y d'autres
type de réponse listés dans la RFC 1812 (paragraphe 5.2.7.1).
Cependant, je ne vois pas comment, en couche 3 via Icmp, il peux avoir
la connaissance d'un port sur un type protocole qui n'est pas définit.
Le protocole AFP peut très bien gérer des ports au même titre que Tcp
et Udp, mais comment et surtout où est définit l'emplacement de ce
port dans la pile IP de ma machine ? Personne ne peux m'assurer
qu'Annie à placer les ports en début de l'entête, ni d'ailleurs que
ces champs fonts 2 octets.
Je pense que l'AFP est du 100% personnalisée et qu'Icmp ne peux pas se
permettre de prendre l'initiative qu'AFP est formaté exactement comme
Tcp ou Udp. La meilleure preuve est que nous ne l'avons même pas
définit dans ce Post.
A mon avis, le fonctionnement d'Icmp est écrit en dur en fonction des
protocoles existant. Et si tu en créais un, il te faudra lui expliquer
comment réagir. Car imagine que je créais le SFP (SebF Fancy Protocol)
qui gère 3 ports pour les conversations à 3 postes placé à fin de mon
entête. Ceci indiquant ainsi 2 ports sources et un de destination
(Pas la peine de réagir sur ça, c'est Fancy). Icmp réagira comment? Je
pense qu'il ne dois pas réagir sur quelque chose qui ne lui ai pas
définit à la base. Mais c'est peux être au rôle du développeur du SFP
de lui apprendre.
Qu'en pensez-vous ?
Cependant, je ne vois pas comment, en couche 3 via Icmp, il peux avoir
la connaissance d'un port sur un type protocole qui n'est pas définit.
Le protocole AFP peut très bien gérer des ports au même titre que Tcp
et Udp, mais comment et surtout où est définit l'emplacement de ce
port dans la pile IP de ma machine ? Personne ne peux m'assurer
qu'Annie à placer les ports en début de l'entête, ni d'ailleurs que
ces champs fonts 2 octets.
Je pense que l'AFP est du 100% personnalisée et qu'Icmp ne peux pas se
permettre de prendre l'initiative qu'AFP est formaté exactement comme
Tcp ou Udp. La meilleure preuve est que nous ne l'avons même pas
définit dans ce Post.
A mon avis, le fonctionnement d'Icmp est écrit en dur en fonction des
protocoles existant. Et si tu en créais un, il te faudra lui expliquer
comment réagir. Car imagine que je créais le SFP (SebF Fancy Protocol)
qui gère 3 ports pour les conversations à 3 postes placé à fin de mon
entête. Ceci indiquant ainsi 2 ports sources et un de destination
(Pas la peine de réagir sur ça, c'est Fancy). Icmp réagira comment? Je
pense qu'il ne dois pas réagir sur quelque chose qui ne lui ai pas
définit à la base. Mais c'est peux être au rôle du développeur du SFP
de lui apprendre.
Qu'en pensez-vous ?
Cependant, je ne vois pas comment, en couche 3 via Icmp, il peux avoir
la connaissance d'un port sur un type protocole qui n'est pas définit.
Le protocole AFP peut très bien gérer des ports au même titre que Tcp
et Udp, mais comment et surtout où est définit l'emplacement de ce
port dans la pile IP de ma machine ? Personne ne peux m'assurer
qu'Annie à placer les ports en début de l'entête, ni d'ailleurs que
ces champs fonts 2 octets.
Je pense que l'AFP est du 100% personnalisée et qu'Icmp ne peux pas se
permettre de prendre l'initiative qu'AFP est formaté exactement comme
Tcp ou Udp. La meilleure preuve est que nous ne l'avons même pas
définit dans ce Post.
A mon avis, le fonctionnement d'Icmp est écrit en dur en fonction des
protocoles existant. Et si tu en créais un, il te faudra lui expliquer
comment réagir. Car imagine que je créais le SFP (SebF Fancy Protocol)
qui gère 3 ports pour les conversations à 3 postes placé à fin de mon
entête. Ceci indiquant ainsi 2 ports sources et un de destination
(Pas la peine de réagir sur ça, c'est Fancy). Icmp réagira comment? Je
pense qu'il ne dois pas réagir sur quelque chose qui ne lui ai pas
définit à la base. Mais c'est peux être au rôle du développeur du SFP
de lui apprendre.
Qu'en pensez-vous ?
The internet header plus the first 64 bits of the original
datagram's data. This data is used by the host to match the
message to the appropriate process. If a higher level protocol
uses port numbers, they are assumed to be in the first 64 data
bits of the original datagram's data.
Traduction :
L'entête IP et les premiers 64 octets du datagramme original. Ces
données sont utilisées par la machine pour corréler le message au
processus aproprié. Si un protocole de plus au niveau utilise des
ports, on suppose que ces derniers ce situent dans le 64 premiers
octets de données du datagramme original.
The internet header plus the first 64 bits of the original
datagram's data. This data is used by the host to match the
message to the appropriate process. If a higher level protocol
uses port numbers, they are assumed to be in the first 64 data
bits of the original datagram's data.
Traduction :
L'entête IP et les premiers 64 octets du datagramme original. Ces
données sont utilisées par la machine pour corréler le message au
processus aproprié. Si un protocole de plus au niveau utilise des
ports, on suppose que ces derniers ce situent dans le 64 premiers
octets de données du datagramme original.
The internet header plus the first 64 bits of the original
datagram's data. This data is used by the host to match the
message to the appropriate process. If a higher level protocol
uses port numbers, they are assumed to be in the first 64 data
bits of the original datagram's data.
Traduction :
L'entête IP et les premiers 64 octets du datagramme original. Ces
données sont utilisées par la machine pour corréler le message au
processus aproprié. Si un protocole de plus au niveau utilise des
ports, on suppose que ces derniers ce situent dans le 64 premiers
octets de données du datagramme original.
L'entête IP et les premiers 64 octets du datagramme original. Ces
données sont utilisées par la machine pour corréler le message au
processus aproprié. Si un protocole de plus au niveau utilise des
ports, on suppose que ces derniers ce situent dans le 64 premiers
octets de données du datagramme original.
64 bits (8 octets), pas 64 octets...
L'entête IP et les premiers 64 octets du datagramme original. Ces
données sont utilisées par la machine pour corréler le message au
processus aproprié. Si un protocole de plus au niveau utilise des
ports, on suppose que ces derniers ce situent dans le 64 premiers
octets de données du datagramme original.
64 bits (8 octets), pas 64 octets...
L'entête IP et les premiers 64 octets du datagramme original. Ces
données sont utilisées par la machine pour corréler le message au
processus aproprié. Si un protocole de plus au niveau utilise des
ports, on suppose que ces derniers ce situent dans le 64 premiers
octets de données du datagramme original.
64 bits (8 octets), pas 64 octets...
