Bonjour, Le 13/12/2020 à 10:18, Raphaël Jacquot a écrit :
quelqu'un aurait une idée ?
Je n'ai pas d'idée sur la session qui ne monte pas. En revanche, voici ce que j'ai écrit, en 2014, sur ttl-security :
« Le TTL est décrémenté uniquement en cas de forward. Un routeur reçoit un paquet, se rend compte qu'il ne lui est pas destiné, cherche une entrée dans sa FIB, décrémente le TTL. Si TTL = 0, il détruit le paquet et envoie un message ICMP « Time to Live exceeded in Transit » (type 11, code 0 😉 ) à celui qui prétend en être l'expéditeur. Si TTL > 0, le routeur forward le paquet.
Le RFC 5082 - The Generalized TTL Security Mechanism (GTSM) [https://tools.ietf.org/rfc/rfc5082.txt] explique clairement que le paquet doit avoir un TTL fixé à 255 à l'émission et qu'il doit être inchangé à la réception. On lit souvent, y compris dans la CLI Cisco[1], que l'on doit avoir un TTL supérieur ou égal 254 à la réception : c'est une erreur ou plutôt, d'après mes recherches, un sacrifice de la sécurité sur l'autel de la compatibilité avec de vieilles architectures qui ne devaient pas gérer correctement la décrémentation du TTL (source : le plus loin que j'ai pu remonter, la présentation de cette proposition de TTL à 255 lors de la 27e rencontre NANOG : The BGP TTL Security Hack (BTSH) [http://www.nanog.org/meetings/nanog27/presentations/meyer.pdf]). »
Source : <http://www.guiguishow.info/2014/01/14/critique-de-larticle-quelques-pistes-sur-le-renforcement-de-la-securite-autour-du-protocole-de-routage-bgp-misc-70/>
Bonne journée. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
