Bonjour, j’ai une debian 4.0, noyeau 2.6.18-5-686 #1.
Le paramétre timesstamp est actif :
qos@PCQOS1:~$ cat /proc/sys/net/ipv4/tcp_timestamps
1
Pourtant lors des traces avec ethereal, il est inactif (mon client demande dans le syn l’activation du timestamp)
Comment l’activer ?
Metttant en cause mon PC client, j’ai refait les même trace vers un solaris => timestamp présent.
Quelqu’un aurais une explication à ce manque de timestamp ?
Vivien.
Désolé, je n’ai pas d’idées mais va donc faire un tour sur le mailing list netfilter, ils pourront sûrement t’aider à moins que quelqu’un sur le forum ait la réponse.
hello,
Il y a pas une régle firewall qui bloque ton syn ? ou ce situe le pc sur ton reseau ? derriere un routeur/firewall ou quelque chose comme ça ?
C’est une Debian 4.0 LAMP minimal fraichement installé
J’ai testé également avec plusieurs servuers Ubuntu server 7.04 32 et 64 bits, j’ai bien /proc/sys/net/ipv4/tcp_timestamps à 1 pourtant ils ne sont pas présent dans les traces.
Wireshark est installé sur un portable WinXP, Firefox est le client web.
[SYN] (client => serveur) dans les options TCP j’ai entre autre Timestamps: TSval 0, TSecr 0
[SYN, ACK] (serveur => client) dans les options TCP je n’ai pas de Timestamps
[ACK] (client => serveur) je n’ai plus d’options TCP, le client abandonne l’idée de faire du timestamp
Avec une BSD ou Solaris, la réponse du serveur [SYN, ACK] contient un premier timestamp.
J’ai testé avec un réseau complet ou avec un cable croisé directement entre le client et le servuer => même probléme.
J’ai trouvé l’explication :
snort.org/docs/TIMESTAMP.Aug032007.PDF
Page 6
Il y a un beau graphiseme qui explique bien
“First, let’s examine what transpires on the three-way handshake shown in Figure 2. Both client and server must support the TCP timestamp option for either to employ it. Each signals its intent to use the TCP timestamp by including it in the TCP options field when it sends the segment where the SYN flag is set. A client that uses a timestamp on the three-way handshake typically sets its timestamp value to the current timestamp clock value and sets the receiver’s timestamp to zero. However, some operating systems, such as Windows set both the sender’s and receiver’s timestamps to zero and wait until after the completion of the three-way handshake to begin to record their own timestamp and echo the receiver’s timestamp. Servers that run different operating systems uniquely respond to a client initiation where the TCP timestamp values are zero.”
En gros pour que le time stam foncitonne il faut 3 conditions :
Le couple windows / linux n’arrive donc pas a s’entendre là dessus.
[quote=“vivienfr”][…]
Donc, d’après ce que je comprends, dans les paquets initiants une connexion (flag SYN seul monté), on ne se préoccupe pas de la valeur de TSecr, mais uniquement de la valeur de TSval)
Ensuite, la valeur de TSval est recopiée dans TSecr, lors de la réponse (flag ACK seul monté), or il est dit que Tsecr n’est pas valide si sa valeur est de zéro. Du coup, la gestion des timestamps n’est pas activée.
Cependant, tu as remarqué que le poste linux avec un noyau 2.4 n’ajoute même pas les options timestamps, ce qui pourrait me paraître logique. Il semble donc que le poste windows soit en tord sur ce point là. Je ne trouve pas logique de mettre un zéro dans TSval puisque de cette façon, toutes les requêtes de demande de connexion ont un timestamp équivalent de zéro : un peu bizzare, non ?
C’est ce que j’en pense, mais peut-être faudrait-il prendre en compte le protocole TCP d’un point de vue plus générale, et ne pas se contenter d’un seul paragraphe !
Qu’en est-il sur un noyau 2.6 : (je n’ai pas de machine windows sous la main)
[quote=“thialme”][quote=“vivienfr”][…]
Qu’en est-il sur un noyau 2.6 : (je n’ai pas de machine windows sous la main)[/quote][/quote]
Effectivement c’est microsoft qui ne respecte pas la norme en envoyant TSval 0, TSecr 0 lors du SYN alors que ce n’est pas le cas d’un client linux qui envoi TSval 16111025, TSerc 0 lors d’un SYN. (16111025 est un exemple)
Linux 2.4 / Linux 2.6 => Timestamps non activés si client Windows , activés si client Linux.
BSD / Windows => Timestamps activés si client Windows / linux
J’ai des traces pour ceux que cela intéresse.
Petite note : La RFC 1323 met en évidence la mise en place des timestamps, mais ce n’est pas une norme : Microsoft n’est pas obligé de s’y plier. Il est en tord par rapport à la RFC mais pas par rapport à une norme.
[quote]
Linux 2.4 / Linux 2.6 => Timestamps non activés si client Windows , activés si client Linux.
BSD / Windows => Timestamps activés si client Windows / linux
J’ai des traces pour ceux que cela intéresse.[/quote]
Merci pour l’info. Pour les traces je te fais confiance !
Bonjour à tous
Vivienfr (que je connais pas ailleurs) m’a ‘embrigadé’ dans une discussion sur ce sujet “windows pas ‘rfc’ 1323 compliant” sur prise en charge du “Time-Stamp” sur un autre forum (forum.paubc.info) où on discutait ‘optimisation TCP’, et m’a renvoyé à votre discussion sur ce même sujet.
En lisant vos posts précédents concernant ce problème, en refaisant des tcp dumps pour me rendre compte par moi même, je ne peux que constater que XP SP2 (cas du test, avec l’option TCP1323opts à 3 pour activer la prise en charge du Time-Stamp en tant que client) met effectivement à zéro la TSval lors du SYN d’ouverture de session TCP
(ce devrait etre pareil sur w2k ou w2k3 d’ailleurs)
Sur ce point nous sommes d’accord 
J’ai donc entrepri de ré-étudier la rfc 1323 et voici ce que j’en ressort :
La valeur TSval “initiale” à envoyer est une valeur arbitrairement choisi par celui qui la génère (client ou serveur, chacun générant la sienne propre pour la session TCP qui débute),
La seule contrainte est que durant la session cette valeur soit incrémentée d’une manière ‘synchrone’ avec le temps réel (par exemple toutes les x secondes ou millisecondes) afin d’être ‘relative’ au temps pour effectivement pouvoir calculer les variations de RTT, sens de ces variations permettant d’augmenter ou diminuer la ‘fenêtre’.
Ainsi, cette valeur “initiale” peut tout aussi bien être 1418 ou 31415926 ou un modulo de l’heure de l’ordinateur à l’instant de la génération du paquet SYN, ou ce que vous voulez … dont “zéro”.
DONT ZÉRO ??? Nous y voilà
Vous dite (en résumé) “A mais non ! Pas zéro ! c’est une valeur invalide !” :
Je ne suis pas d’accord avec cette assertion, et je vais vous le démontrer :
Reprenons la partie “litigieuse” de la RFC présenté phrase par phrase pour plus de clarté, et quelques annotations personnelles :
(1) - The Timestamp Value field (TSval) contains the current value of the timestamp clock of the TCP sending the option.
-> rien à dire, clair, précis, limpide.
(2) - The Timestamp Echo Reply field (TSecr) is only valid if the ACK bit is set in the TCP header;
-> TSecr n’est “valide” QUE dans un paquet avec le flag ACK
(3) - if it is valid, it echos a times-stamp value that was sent by the remote TCP in the TSval field of a Timestamps option.
-> C’est la continuation de (2).
On parle toujours de la validité de TSecr, donc, suivant (2) validité de TSecr acquise uniquement SI le TCP Header a le flag ACK.
En aucun cas ici on ne ‘valide’ ou ‘dévalide’ TSval reçu dans ce même paquet. On le prend comme il est en vertu de (1).
(4) - When TSecr is not valid, its value must be zero
On parle encore de la validité de TSecr, validité établie ou non encore par (2). En fait il est dit ici en subtance que SI on n’est pas en présence d’un paquet avec le flag ACK, cette valeur doit être mise à zéro (sous entendu, l’émetteur doit mettre ce champ à zéro)
Encore ici, en aucun cas on ne ‘valide’ ou ‘dévalide’ TSval réçu dans ce même paquet. On le prend comme il est en vertu de (1).
J’ai beau relire la RFC je ne vois nul part l’interdiction d’utiliser comme valeur de départ pour TSval dans le SYN “initial” la valeur ZERO.
Je ne vois non plus aucune mention indiquant QUAND TSval doit être considéré comme ‘invalide’ sur le paquet SYN "initial"
La seule chose qui puisse ‘invalider’ la valeur de TSval, c’est qu’il soit inférieur à la valeur précédement reçu dans cette même session TCP (“3.4 Which Timestamp to Echo” et suivantes)
Difficile de comparer la valeur “initiale” à celle qui l’a précèdé, cette denière n’existe pas encore 
Donc, utiliser ZERO comme valeur initiale dans le paquet SYN (seul) est légal
Il semble donc que ce soit la pile TCP/IP de “linux” qui ne soit pas “RFC1323 compliant” en ne voulant pas faire du TimeStamp lorsque l’autre partie met son TSval initial à zéro
(tout au moins lorsque l’autre partie est le client, je n’ai pas encore fait le test inverse, voir si “linux” en tant que client initiateur de la session accepte ou pas un TSval initial dans le SYN du serveur. A vérifier donc aussi)
Ceci est bien sûr mon analyse personnelle de la RFC 1323 et n’engage que moi
C’est tout a fait ‘logique’ suivant l’implémentation de la gestion du TimeStamp ‘clock’.
Rien dans la RFC n’oblige à n’utiliser qu’une unique “TimeStamp clock” dont devraient se ‘partager’ toutes les session TCP. L’implémenteur peut très bien choisir de créer une “TimeStamp clock” par session TCP.
C’est même mieux pour éviter certains “problèmes” comme l’illustre fort bien cet article :
"TCP Timestamp and Advanced Fingerprinting"
http://www.securiteam.com/securityreviews/5LP0K2KF6I.html
Il est même recommandé dans cet article que la valeur du TimeStamp “initial” soit, soit aléatoire, soit à ZERO
Notez au passage que Windows semble maintenant faire comme NetBSD 2.0 à l’époque de l’article, soit 2005, c-a-d initialiser le TimeStamp à “0” (encore …) à chaque session TCP (et gérer donc une “TimeStamp clock” par session TCP), bien que à l’époque de cette l’article, 2005 donc, ce n’était pas le cas (tout au moins pour la valeur 0. Pour le ‘TimeStamp clock’ partagé ou pas, je ne sais pas).
Ce TSval “initial” à 0 rend désormais Win 2K/XP/2K3 non vulnérable vis à vis du sujet cet l’article. (je pense que celà a dû se faire via un patch de sécurité à un moment donné, mais je n’ai pas cherché depuis quand)
[quote=“feyb64”]Il semble donc que ce soit la pile TCP/IP de “linux” qui ne soit pas “RFC1323 compliant” en ne voulant pas faire du TimeStamp lorsque l’autre partie met son TSval initial à zéro
(tout au moins lorsque l’autre partie est le client, je n’ai pas encore fait le test inverse, voir si “linux” en tant que client initiateur de la session accepte ou pas un TSval initial dans le SYN du serveur. A vérifier donc aussi)
[/quote]
Pour permettre de débatre “RFC1323 compliant” de linux et windows, voici quelques captures :
Client windows XP qui se connecte a un serveur linux 2.6 :
=> Winodws demande l’activation des timestamps avec 0,0 linux n’active rien.
Client linux 2.6 qui se connecte a un serveur linux 2.6 :
=> Tout se passe bien. On note que dans le [SYN, ACK] la TSER est celle du [SYN] ce qui est conforme a la RFC
Client linux 2.6 qui se connecte a un microsoft.fr (je suppose un serveur Windows) :
=> On remaruqe que les timestamps sont activé avec microsoft.fr mais pas avec la seconde connexion avec microsoft.com
La où microsoft me semble non compliant (bine que cela ne semble pas gêner linux) c’est sur le [SYN, ACK] ou le TSER=0 alors qu’il aurais du reprendre la valeur TSV=829739 du [SYN]
Vivien.
Effectivement, dans tes derniers exemples le Windows en tant que ‘répondeur’ (le linux étant l’initiateur de la session TCP ici) celà semble incorrect, mais il sagit du premier paquet “SYN ACK” de réponse (et pas seulement ACK). A vérifier donc ce qu’on peut mettre dans le 'SYN ACK’
Ce qui me fait me poser la question c’est :
Personnellement je n’ai pas fait ‘gaffe’ sagissant pour moi de regarder uniquement quand on pouvait mettre quoi dans TSval 
Je vais à nouveau devoir décortiquer la RFC … pour TSecr
Notes toutefois que tu te places maintenant dans le cas inverse par rapport à la discussion initiale ou le Windows était initiateur de la session TCP (le linux étant alors ‘répondeur’) et qui posait grosso modo la question “Peut on ou pas mettre le TSval à 0 dans le SYN initial quand on est l’initiateur de la session”.
Je serait intêressé par ton avis sur ce premier ‘problème’. Qui a raison dans ce cas précis ? Le windows ? le Linux ?
Notes que ce TSval à 0 ne semble géner que Linux apparement, d’après tes propres indications, je serait curieux de savoir pourquoi les autres acceptent.
A vu des deux cas, serait on dans un cas ‘extrême’ où suivant qui initie la connection entre un windows et un linux, c’est un coup l’un, un coup l’autre qui est ‘non compliant’ ? ce serait drôle 
Une réponse de l’un à ne pas vouloir faire du TimeStamp avec l’autre parce que l’autre lui refuse dans l’autre sens ?
La guerre des OS jusque dans les échanges entre eux ?
Maintenant je comprends encore moins qu’avant. Il serait bon de savoir comment faire pour initier le dialogue avec les timestamps, le mécanisme PAWS. La RFC 1323 me semble plutôt vague, et c’est ce qui me pose problème.
Mais bon, au moins il y en a d’autres qui travaillent dessus :
Il est mentionné que les stacks pour les différents OS diffèrent sur ce point, et il est ainsi difficile de satisfaire tout le monde…
C’est pas simple Je voulais m’assurer du fonctionnement du noyau au niveau des timestamps, j’ai bien déniché des pistes pour l’instant mais je n’ai pas encore trouvé exactement ce que je voulais (initiation du dialogue). Pour l’instant je suis dans tcp_input.c / tcp.h et tcp_ipv4.c
Après plusieurs tests comparatifs, il advient que :
(en supposant bien entendu que la gestion ‘TimeStamp’ est été convenablement activée sur les OS cités)
1 - Linux :
Lorsqu’il n’est pas 'initiateur de la session TCP, et que l’initiateur met 0 (zéro) comme valeur initiale de son TSval dans l’option TimeStamp de son paquet SYN d’ouverture de session, Linux abandonne purement et simplement la gestion de l’option TimeStamp.
Ceci est en violation de la RFC1323 qui ne précise rien en ce qui concerne la validité de la valeur TSVal reçu, cette valeur étant destinée uniquement à être renvoyée dans le TSecr pour usage exclusif de celui qui a envoyé cette valeur TSVal (ici l’initiateur), à ce dernier de contrôler si cette valeur TSecr est compatible et ‘valable’.
Le receveur (initiateur ou pas) d’une option TimeSpam DOIT, s’il la gestion de l’option ‘TimeStamp’ est activée de son côté, renvoyer TELLE QU’ELLE le TSval reçu en utilisant le champ TSecr dans le paquet suivant qu’elle veut envoyer, ceci quelque soit le paquet (SYN,ACK ou ACK ou Data).
2 - Windows (au moins versions 2000 et XP, pas pû encore testé avec 2003/2003R2 et 2008) :
a : Lors de sa réponse SYN,ACK au SYN de l’initiateur de la session TCP, il renvoie une option TimeStamp avec un TSecr à 0 (zéro).
Ceci est en violation de la RFC1323 qui précise que le champ TSecr DOIT renvoyer la valeur TSval indiquée précédement par l’autre (à moins que l’autre ai justement envoyé 0 comme valeur initiale de son TSval, cas entre deux Windows).
A noter que ce problème se pose uniquement sur l’échange SYN <-> SYN,ACK. Par la suite, dès le premier paquet suivant qu’il génère (non SYN ou SYN,ACK) Windows recopie bien la valeur TSval dernièrement reçue dans le TSecr qu’il va envoyer.
A noter aussi que cette valeur potentiellement inattendue dans le SYN,ACK n’invalide pas pour autant la gestion du ‘TimeStamp’, le receveur de cette valeur ‘invalide’ pouvant soit l’ignorer s’il est ‘sûr’ qu’elle l’est (cas ici car on est au début de la session, peu de chance donc que le compteur TimeStamp clock ai fait un ‘boucle’ totale repassant par ‘zero’), soit calculer quand même une estimation RTT qui sera probablement fausse provoquant temporairement une augmentation de la “fenêtre”, chose qui sera rétablie avec les deux prochains échanges où Windows renvoie bien alors dans le TSecr qu’il envoie le TSval reçu.
b : Un autre problème potentiel que j’ai décelé lors des échanges TimeStamp sur Windows :
Alors qu’il envoie son premier TSval à 0 (zéro), chose ‘autorisée’ par la RFC 1323 (voir 1), que ce soit dans le SYN ou le SYN,ACK (qu’il est donc initiateur ou pas de la session TCP), lors de l’envoie son prochain paquet ACK ou DATA, il place une valeur largement supérieure à zéro dans son TSval, celle valeur étant probablement la vrai valeur initiale qu’il aurait dû envoyer dans son SYN ou SYN,ACK.
A noter que celà NE DOIT GENERE en rien l’autre partie car celle ci NE DOIT QUE copier le TSval reçu dans le TSecr qu’il enverra et n’a pas à les contrôler/valider/… Donc bien que ‘étrange’ comme comportement, celà ne génera pas l’autre partie dans son propre calcul de RTT puisque se basant uniquement sur ses propres valeurs TSval qu’il a émit et ses TSecr qu’il reçoit en écho.
Que peut provoquer ce problème du côté du Windows :
Notez que ce problème b n’entraine pas la non conformité à la RFC1323 en ce qui concerne le TimeStamp, celui qui envoi un TSval ‘bizarre’, le choisi en toute liberté et c’est son problème, et c’est uniquement lui même qui sera ‘embêté’ l’autre n’ayant juste qu’à le recopier en TSecr.
En résumé :
Le point 1 est crucial, empêchant Windows (initiateur) de faire du TimeStamp avec Linux.
Le point 2 est génant pour le ‘serveur’, pouvant provoquer une estimation excessive de taille de fenêtre pendant les quelques premiers échanges.
Le point 3 n’est génant que pour windows (client ou serveur) pouvant provoquer de sa part une estimation excessive de taille de fenêtre pendant les quelques premiers échanges.
[quote=“feyb64”]Après plusieurs tests comparatifs, il advient que :
Le point 1 est crucial, empêchant Windows (initiateur) de faire du TimeStamp avec Linux.
Le point 2 est génant pour le ‘serveur’, pouvant provoquer une estimation excessive de taille de fenêtre pendant les quelques premiers échanges.
Le point 3 n’est génant que pour windows (client ou serveur) pouvant provoquer de sa part une estimation excessive de taille de fenêtre pendant les quelques premiers échanges.[/quote]
Je suis daccord avec tes conclusions sauf sur le “provoquer une estimation excessive de taille de fenêtre pendant les quelques premiers échanges.” n effet il me semble qu’il est laissé a liberté de chacun pile TCP/IP d’incrémenter comme il veut le timestamps : certains le font a chaque paquet d’autre tous les 500ms, ect… (je pense au solaris qu laisse pleusieurs paquet d’affilé avec le même timestamp) La seul reégle etant qu’il doit toujours augmenter.
tu confirme ?
[quote=“vivienfr”][quote=“feyb64”]Après plusieurs tests comparatifs, il advient que :
Le point 1 est crucial, empêchant Windows (initiateur) de faire du TimeStamp avec Linux.
Le point 2 est génant pour le ‘serveur’, pouvant provoquer une estimation excessive de taille de fenêtre pendant les quelques premiers échanges.
Le point 3 n’est génant que pour windows (client ou serveur) pouvant provoquer de sa part une estimation excessive de taille de fenêtre pendant les quelques premiers échanges.[/quote]
Je suis daccord avec tes conclusions sauf sur le “provoquer une estimation excessive de taille de fenêtre pendant les quelques premiers échanges.” n effet il me semble qu’il est laissé a liberté de chacun pile TCP/IP d’incrémenter comme il veut le timestamps : certains le font a chaque paquet d’autre tous les 500ms, ect… (je pense au solaris qu laisse pleusieurs paquet d’affilé avec le même timestamp) La seul reégle etant qu’il doit toujours augmenter.
tu confirme ?[/quote]
Pas tout à fait sur “il est laissé la liberté de chaque pile d’incrémenter comme il veut le timestamps” avec “certains le font a chaque paquet”
Dans le principe (grosso modo), le ‘TimeStamp’ comme son nom l’indique consiste à horodater d’une manière ou d’une autre chaque paquet transmis, afin de pouvoir déterminer le temps écoulé entre les couples ‘Data’-‘ACK’ successifs. Il sagit d’avoir au final une estimation du RTT (ou de sa variation pour faire varier en conséquence la fenêtre tcp).
Il faut donc que les valeurs TSval soient d’une manière ou d’un autre ‘synchrones’ avec le temps qui passe.
Incrémenter ‘bêtement’ ce TSval à chaque paquet n’a rien de ‘temporel’ en soit, et on pourrait se contenter alors des champs existants dans l’entête TCP/IP de ‘séquence’/‘numérotation’ des trames.
Ce qui est possible c’est de choisir l’interval de temps auquel on incrémente le TSval (incrémentation avec une constante bien sûr qui peut être choisi de n’importe quelle valeur). Ainsi certains incrémentent le TSval toutes les 50ms, d’autres tous les 100ms, peut importe, l’important étant que c’est incrémenté tous les Xsecondes, X devant resté fixe.
(la RFC donne un tas d’infos sur le choix du X)
Le fait de voir plusieurs paquets d’affilé avec le même TSval provient du fait que ces paquets sont simplement envoyés dans le temps X entre deux incréments successifs, le TSval n’a donc pas encore avancé
Même le linux renvoie des fois le même TSval sur plusieurs paquets. Regarde les premiers échanges.
Ce phénomène se constate surtout en cas d’échange de 'petits" paquets ou lorsque le RTT est faible entre les deux protagonistes. La où cela peut devenir génant c’est si c’est très fréquent avec des paquets plus importants, un RTT réel important sur une liaison rapide car alors on a pas assez de ‘résolution’ et de ‘progression’ pour estimer convenablement le delta de RTT.
Maintenant si le Solaris envoie effectivement des TSval incrémentés de 1 à chaque paquet :
D’ailleurs cette solution est un excellent moyen d’éviter le fameux problème “TCP Timestamp and Advanced Fingerprinting”, puisque alors on ne dévoile pas du tout d’information temporelle dans les TimeStamps, juste des numéros en séquence sans lien apparent avec le temps si on ne connais pas la ‘table’ interne. Après tout rien dans la RFC 1323 n’oblige à ce que le TSval lui même indique sur le réseau une valeur directement liable au ‘temporel’ par simple lecture, il suffit que l’émetteur de son propre TSval qui le reçoit en TSecr en écho, sache à quoi il en retourne ‘temporellement’, puisque celà ne regarde que lui (l’autre utilise son propre TSval renvoyé en TSecr).
Et en, plus, si le premier TSval est aléatoire puis incrémenté ou encore chaque TSVal est aléatoire (mais unique dans la même session tcp), du moment qu’il sait en interne à quoi ‘temporellement’ celà correspond, c’est encore mieux contre le “Advanced Fingerprint” 
Mais on sort du sujet là
[quote=“feyb64”]Maintenant si le Solaris envoie effectivement des TSval incrémentés de 1 à chaque paquet :
Je vouslais dire que sur certains OS la granularité est faible (a chaque paquet on note une valeur différente, pas une incrémentaiton de 1) et sur d’autre difficilement utilisable pour le RTT (cas de solarias qui de mémoire augmente timestamp de 1 toutes les 500ms - a vérifier)
Je n’avais pas bien compris l’incrément
C’est sûr qu’avec un TimeStamp clock de 500ms, difficile de prédire le RTT lorsqu’on est en présence de lignes à RTT de moins de 500ms, ce qui est plutôt la tendance générale 
Au fait, où doit on aller pour faire un rapport de bug sur la pile TCP de Linux ?
Faudrait peut être, non ?