7. Security Considerations (Considérations de sécurité)

Lorsque l'ID IPv4 est ignoré à la réception (par exemple, pour les datagrammes atomiques), sa valeur devient non contrainte ; par conséquent, ce champ peut plus facilement être utilisé comme canal caché. Pour certains datagrammes atomiques, il est désormais possible, et peut être souhaitable, de réécrire le champ ID d'IPv4 afin d'éviter son utilisation comme tel canal. La réécriture serait interdite pour les datagrammes protégés par l'en-tête d'authentification IPsec (AH), bien que nous ne recommandions pas l'utilisation de l'AH pour obtenir ce résultat [RFC4302].

L'ID IPv4 contribue également désormais beaucoup moins à l'entropie de l'en-tête d'un datagramme. Une telle entropie pourrait être utilisée comme entrée pour des algorithmes cryptographiques ou des générateurs pseudo-aléatoires, bien que les ID n'aient jamais été assurés d'une entropie suffisante pour de tels usages. L'ID IPv4 était auparavant unique (pour une paire source/adresse donnée et un champ protocole donné) au sein d'une MDL, bien que cette exigence n'ait pas été appliquée et soit clairement généralement ignorée. L'ID IPv4 des datagrammes atomiques n'est pas tenu d'être unique et ne contribue donc aucune entropie à l'en-tête.

La dépréciation de l'unicité du champ ID d'IPv4 pour les datagrammes atomiques peut faire échec à la capacité de compter les dispositifs derrière un NAT/ASM/réécrivain [Be02]. Toutefois, cela n'est pas conçu comme une fonctionnalité de sécurité.