Le protocole
Petit rappel au passage sur la
10:45:24.818912 IP6 (hlim 56, next-header Fragment (44) payload length: 432) 2001:4b98:dc2:45:216:3eff:fe4b:8c5b > 2001:67c:1348:7::86:133: frag (0x000079cc:0|424) 53 > 37407: 25110*- q: ANY? . 24/0/1 . [1d] DNSKEY, . [1d] DNSKEY, . [1d] DNSKEY[|domain]
10:45:24.819008 IP6 (hlim 56, next-header Fragment (44) payload length: 1458) 2001:4b98:dc2:45:216:3eff:fe4b:8c5b > 2001:67c:1348:7::86:133: frag (0x000079cc:424|1450)
Le paquet a l'identificateur 0x000079cc, seul le premier fragment
(de l'octet 0 à l'octet 423)
a pu être analysé (il avait le début de la réponse DNS).
Et voici les deux fragments, analysés par
Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: 2001:4b98:dc2:45:216:3eff:fe4b:8c5b, Dst: 2001:67c:1348:7::86:133
Next header: Fragment Header for IPv6 (44)
Fragment Header
Next header: UDP (17)
Reserved octet: 0x0000
0000 0000 0000 0... = Offset: 0 (0 bytes)
.... .... .... .00. = Reserved bits: 0
.... .... .... ...1 = More Fragments: Yes
Identification: 0x000079cc
Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: 2001:4b98:dc2:45:216:3eff:fe4b:8c5b, Dst: 2001:67c:1348:7::86:133
Next header: Fragment Header for IPv6 (44)
Fragment Header
Next header: UDP (17)
Reserved octet: 0x0000
0000 0001 1010 1... = Offset: 53 (424 bytes)
.... .... .... .00. = Reserved bits: 0
.... .... .... ...0 = More Fragments: No
Identification: 0x000079cc
[2 IPv6 Fragments (1874 bytes): #2(424), #3(1450)]
[Frame: 2, payload: 0-423 (424 bytes)]
[Frame: 3, payload: 424-1873 (1450 bytes)]
[Fragment count: 2]
[Reassembled IPv6 length: 1874]
[Reassembled IPv6 data: 0035921f0752901c6216850000010018000000010000ff00...]
Le
Pourquoi, « malheureux » ? Parce que cela rend l'identificateur
de paquet prévisible pour un observateur extérieur, faisant
ainsi fuir de l'information qui peut être utilisée pour certaines
attaques (section 3) :
En IPv4, le champ Identification fait partie de chaque paquet
(
En théorie, rien de plus simple que d'envoyer un faux paquet
ICMP
Pour éviter ces attaques, que faudrait-il faire ? On souhaite des identificateurs de paquets imprévisibles, mais en même temps ils ne doivent pas être réutilisés, du moins tant qu'on n'est pas sûr que les paquets portant précédemment cet identificateur n'ont pas terminé leur voyage dans le réseau. Des identificateurs complètement aléatoires, par exemple, ne sont pas si idéaux qu'ils le paraissent : il y a un risque de réutilisation accidentelle. Autre contrainte sur les algorithmes de génération de ces identificateurs : ils doivent être très rapides, puisqu'il faut les faire tourner pour chaque paquet fragmenté.
La section 5 de notre RFC décrit les algorithmes possibles. On a vu que l'algorithme « compteur global » était exclu, car il produit des identificateurs prévisibles. Que reste-t-il ?
Le
premier algorithme possible (section 5.1) est « un compteur par
destination ». On maintient un compteur par adresse IP de
destination utilisée, qu'on initialise avec une valeur
aléatoire. Simple à mettre en œuvre (il faut juste un
Deuxième algorithme envisageable, « identificateur aléatoire » (section 5.2). Idéal pour la sécurité, mais il fait courir des risques de réutilisation des identificateurs, et il est plus coûteux en temps de calcul.
Enfin, un troisième algorithme possible est « condensation de
variables » (section 5.3). On prend des variables comme les adresses source et
destination, un compteur (pas forcément global), une valeur secrète et on
L'annexe B de notre RFC est le résultat d'une étude de la
prédictabilité par
% sudo frag6 --frag-id-policy -d www.example
Identifying the 'Fragment ID' generation policy of the target node....
Fragment ID policy: Per-destination IDs with increments of 2 (sdev: 1.112134)
La destination est un
% sudo frag6 --frag-id-policy -d www.freebsd.org
Identifying the 'Fragment ID' generation policy of the target node....
Fragment ID policy: Randomized IDs (Avg. inc.: 2101165500, sdev: 1531579889.681898)
Ici, un
% sudo frag6 --frag-id-policy -d 2001:db8:9321:8bb0:9da8:f055:5381:d54c
Identifying the 'Fragment ID' generation policy of the target node....
Fragment ID policy: Per-destination IDs with increments of 1 (sdev: 1.504380)
On voit, après cet essai sur trois machines différentes, que les
différents algorithmes sont toujours utilisés.