Aller au contenu principal

RFC 6864 - Spécification mise à jour du champ ID IPv4

  • Statut: Proposed Standard
  • Publié: February 2013
  • Stream: IETF
  • Met à jour: RFC791, RFC1122, RFC2003
  • Errata: Pas d'errata

Statut de ce mémo​

Ceci est un document Internet Standards Track.

Ce document est un produit de l'Internet Engineering Task Force (IETF). Il représente le consensus de la communauté IETF. Il a fait l'objet d'un examen public et a été approuvé pour publication par l'Internet Engineering Steering Group (IESG). De plus amples informations sur les normes Internet sont disponibles dans la section 2 de la RFC 5741.

Les informations sur le statut actuel de ce document, les errata et les moyens de fournir des commentaires peuvent être obtenues à l'adresse http://www.rfc-editor.org/info/rfc6864.

Avis de droit d'auteur​

Copyright (c) 2013 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Ce document est soumis au BCP 78 et aux dispositions légales de l'IETF Trust relatives aux documents IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Veuillez examiner attentivement ces documents, car ils décrivent vos droits et restrictions concernant ce document.

Résumé​

Le champ d'identification IPv4 (ID) permet la fragmentation et le réassemblage et, selon la spécification actuelle, doit être unique dans la durée de vie maximale pour tous les datagrammes avec le même tuple adresse source/adresse de destination/protocole. Cependant, les implémentations actuelles ne suivent pas cette spécification et traitent le champ ID comme une valeur unique pour chaque datagramme, ce qui peut entraîner l'épuisement du champ ID sur les appareils à haute vitesse. Ce document met à jour la spécification du champ ID IPv4 dans RFC 791, RFC 1122 et RFC 2003 pour la rapprocher de la pratique actuelle et discute des implications de ces changements pour les concepteurs de datagrammes.

Table des matières​

1. Introduction​

2. Le champ ID IPv4​

3. Mises à jour de la spécification ID IPv4​

4. Impact des changements proposés​

5. Mises à jour des normes existantes​

6. Considérations de sécurité​

7. Références​

Annexe A. Détectabilité des doublons​

Annexe B. Remerciements​

Source officielle: IETF RFC 6864

1. Introduction​

Dans IPv4, le champ d'identification (ID) est une valeur de 16 bits utilisée pour prendre en charge la fragmentation et le réassemblage des datagrammes. Selon la spécification actuelle, le champ ID doit être unique dans la durée de vie maximale des segments (MSL) pour les datagrammes ayant la même adresse source, adresse de destination et protocole. Cependant, les implémentations actuelles ne suivent pas strictement cette spécification et traitent le champ ID comme un identifiant unique pour chaque datagramme, qu'il soit fragmenté ou non.

Dans IPv4, les protocoles de transport et de niveau supérieur utilisent généralement des champs de 16 ou 32 bits pour détecter les datagrammes en double, tels que les numéros de séquence TCP ou les sommes de contrôle UDP. Cependant, le champ ID IPv4 n'a que 16 bits, ce qui signifie que dans des environnements réseau à haute vitesse, le champ ID peut être épuisé en peu de temps, rendant impossible l'attribution de valeurs ID uniques pour les nouveaux datagrammes.

Dans IPv6, la fragmentation n'est effectuée que par le nœud source, et l'en-tête de fragmentation contient un champ d'identification de 32 bits. La spécification IPv6 indique explicitement que ce champ d'identification ne doit être unique que lorsque le datagramme est fragmenté. En revanche, le champ ID IPv4 est présent dans tous les datagrammes, qu'ils soient fragmentés ou non.

Ce document met à jour la spécification du champ ID IPv4 dans RFC 791, RFC 1122 et RFC 2003 pour la rapprocher de la pratique actuelle et la rendre cohérente avec le traitement IPv6. En particulier, ce document clarifie les points suivants:

  1. Datagrammes atomiques: Pour les datagrammes avec le drapeau DF (Don't Fragment) défini, le champ ID peut être défini sur n'importe quelle valeur, et le récepteur doit ignorer la valeur du champ.

  2. Datagrammes non atomiques: Pour les datagrammes sans le drapeau DF défini, le champ ID doit être unique pendant la période de délai de réassemblage pour garantir un réassemblage correct des fragments.

  3. Compatibilité: Ce document discute des impacts de ces changements sur les équipements et protocoles existants et fournit des recommandations pour la période de transition.

1.1 Terminologie​

Ce document utilise les termes suivants:

  • Datagramme atomique: Datagramme IPv4 avec le drapeau DF défini (DF=1)
  • Datagramme non atomique: Datagramme IPv4 sans le drapeau DF défini (DF=0)
  • Nœud source: Hôte ou dispositif qui génère des datagrammes IPv4
  • Nœud intermédiaire: Routeur ou passerelle qui transmet des datagrammes IPv4
  • Nœud de destination: Hôte ou dispositif qui reçoit des datagrammes IPv4
  • Intervalle de réutilisation d'ID: Intervalle de temps minimal entre les datagrammes avec le même tuple adresse source/adresse de destination/protocole pour réutiliser la même valeur d'ID

Navigation:

2. Le champ ID IPv4​

Le champ d'identification IPv4 (ID) a été initialement conçu pour prendre en charge la fragmentation et le réassemblage des datagrammes. Selon RFC 791, le champ ID doit être unique dans la durée de vie maximale des segments (MSL) pour les datagrammes avec la même adresse source, adresse de destination et protocole. Cependant, avec l'augmentation des vitesses réseau et l'évolution des besoins des applications, les implémentations actuelles se sont écartées de la spécification d'origine.

2.1 IPv4 ID pour la fragmentation​

Le champ ID IPv4 est principalement utilisé pour prendre en charge la fragmentation et le réassemblage des datagrammes. Lorsqu'un datagramme doit traverser une liaison avec une unité de transmission maximale (MTU) plus petite, le routeur intermédiaire peut fragmenter le datagramme en plusieurs fragments plus petits. Chaque fragment contient la même valeur d'ID afin que le nœud de destination puisse réassembler ces fragments en datagramme d'origine.

Dans les environnements à haute vitesse, le champ ID de 16 bits peut s'épuiser rapidement. Par exemple, sur une liaison 10 Gbps avec une taille moyenne de datagramme de 1500 octets, environ 833 333 datagrammes peuvent être transmis par seconde, épuisant l'espace ID de 16 bits en environ 0,079 seconde.

Pour résoudre ce problème, ce document introduit les concepts de datagrammes atomiques et datagrammes non atomiques:

  • Datagrammes atomiques: Datagrammes avec le drapeau DF défini. Ils ne sont pas fragmentés par les routeurs intermédiaires.
  • Datagrammes non atomiques: Datagrammes sans le drapeau DF défini. Ils peuvent être fragmentés par les routeurs intermédiaires.

2.2 IPv4 ID pour la détection des doublons​

En plus de la fragmentation, le champ ID IPv4 peut être utilisé pour détecter les datagrammes en double. Cependant, dans les environnements à haute vitesse, le champ ID peut se répéter rapidement, le rendant peu fiable pour la détection des doublons.

RFC 1122 indique que les protocoles de transport devraient utiliser leurs propres mécanismes pour détecter les datagrammes en double. Ce document réaffirme que le champ ID IPv4 est principalement utilisé pour la fragmentation et le réassemblage, pas pour la détection des doublons.

2.3 Contexte des problèmes de réassemblage IPv4 ID​

Dans les environnements à haute vitesse, la limitation de 16 bits du champ ID peut entraîner:

  1. Épuisement du champ ID: L'espace ID peut s'épuiser rapidement
  2. Erreurs de réassemblage: Des fragments de différents datagrammes peuvent être incorrectement combinés
  3. Dégradation des performances: Limitation du débit pour éviter l'épuisement de l'ID

RFC 4963 discute en détail de ces problèmes et note que la spécification actuelle du champ ID IPv4 n'est plus applicable dans les environnements à haute vitesse.

Navigation:

3. Mises à jour de la spécification ID IPv4​

Ce chapitre décrit les mises à jour de la spécification du champ ID IPv4 pour résoudre le problème d'épuisement de l'ID dans les environnements à haute vitesse.

3.1 IPv4 ID pour les datagrammes atomiques​

Les datagrammes atomiques sont des datagrammes IPv4 avec le drapeau DF (Don't Fragment) défini. Comme ils ne sont pas fragmentés, le champ ID n'est pas nécessaire pour le réassemblage.

3.1.1 Comportement de l'émetteur​

Pour les datagrammes atomiques, l'émetteur PEUT (MAY) définir le champ ID sur n'importe quelle valeur:

  • Valeur fixe: Tous les datagrammes atomiques peuvent avoir la même valeur
  • Compteur simple: Utiliser un compteur simple sans exigence d'unicité
  • Valeur aléatoire: Générer des valeurs ID aléatoires pour une meilleure confidentialité

3.1.2 Comportement du récepteur​

Pour les datagrammes atomiques, le récepteur DOIT (MUST) ignorer le champ ID:

  • Ne pas utiliser pour la détection des doublons
  • Ne pas faire d'hypothèses sur la signification ou l'ordre
  • S'appuyer sur les protocoles de transport

3.1.3 Comportement du nœud intermédiaire​

Les nœuds intermédiaires lors du transfert de datagrammes atomiques:

  • NE DOIVENT PAS (MUST NOT) modifier le champ ID
  • NE DOIVENT PAS (MUST NOT) fragmenter les datagrammes atomiques

3.2 IPv4 ID pour les datagrammes non atomiques​

Les datagrammes non atomiques sont des datagrammes IPv4 sans le drapeau DF défini. Ils peuvent être fragmentés, donc le champ ID doit être utilisé pour le réassemblage.

3.2.1 Comportement de l'émetteur​

Pour les datagrammes non atomiques, l'émetteur DOIT (MUST) garantir que le champ ID est unique pendant le délai de réassemblage.

3.2.2 Comportement du récepteur​

Pour les fragments de datagrammes non atomiques, le récepteur DOIT (MUST) utiliser le champ ID pour le réassemblage.

3.2.3 Comportement du nœud intermédiaire​

Les nœuds intermédiaires lors du traitement de datagrammes non atomiques:

  • PEUVENT (MAY) fragmenter si la taille dépasse le MTU
  • DOIVENT (MUST) conserver la valeur du champ ID d'origine

3.3 Conservation du comportement IPv4 ID​

Dans certains cas, les appareils peuvent conserver le comportement IPv4 ID traditionnel:

  1. Exigences de compatibilité: Interopérabilité avec les anciens appareils
  2. Applications spéciales: Applications dépendant de l'unicité de l'ID
  3. Considérations de sécurité: Mécanismes nécessitant l'aléatoire de l'ID

Navigation:

4. Impact des changements proposés​

Ce chapitre analyse les impacts des mises à jour du champ ID IPv4 sur les appareils existants, la génération de datagrammes et les schémas de compression d'en-tête.

4.1 Impact sur les appareils Internet hérités​

4.1.1 Impact sur l'émetteur​

Émetteurs hérités: Les émetteurs traditionnels restent conformes sous les mises à jour.

Nouveaux émetteurs: Peuvent utiliser des algorithmes de génération d'ID simplifiés pour les datagrammes atomiques.

4.1.2 Impact sur le récepteur​

Récepteurs hérités: Peuvent nécessiter des mises à jour pour ignorer les champs ID des datagrammes atomiques.

Nouveaux récepteurs: Devraient explicitement ignorer les champs ID des datagrammes atomiques.

4.1.3 Impact sur les nœuds intermédiaires​

Les routeurs et passerelles n'ont pas besoin de modifier leur comportement.

4.1.4 Résumé de compatibilité​

  • Rétrocompatibilité: Les appareils hérités continuent de fonctionner sans modification
  • Compatibilité ascendante: Les nouveaux appareils peuvent bénéficier des mises à jour
  • Interopérabilité: Les nouveaux et anciens appareils peuvent fonctionner ensemble

4.2 Impact sur la génération de datagrammes​

4.2.1 Génération d'ID pour les datagrammes atomiques​

Pour les datagrammes atomiques, les stratégies simplifiées incluent:

  1. Valeur fixe: Tous utilisent la même valeur
  2. Compteur simple: Compteur global
  3. Valeur aléatoire: Valeurs aléatoires pour la confidentialité
  4. Compteur par flux: Compteurs séparés par tuple

4.2.2 Génération d'ID pour les datagrammes non atomiques​

Pour les datagrammes non atomiques, garantir l'unicité:

  1. Compteur global: Simple mais peut s'épuiser
  2. Compteur par flux: Réduit le risque d'épuisement
  3. Algorithmes temporels: Utilise des horodatages
  4. Algorithmes hybrides: Combine compteur et aléatoire

4.3 Impact sur les schémas de compression d'en-tête​

Les schémas de compression d'en-tête peuvent nécessiter des ajustements pour s'adapter aux nouvelles spécifications.

Navigation:

5. Mises à jour des normes existantes​

Ce chapitre décrit les mises à jour spécifiques de RFC 791, RFC 1122 et RFC 2003.

5.1 Mises à jour de RFC 791​

RFC 791 est la spécification IPv4 de base. Ce document met à jour la spécification du champ ID:

Pour les datagrammes atomiques (DF=1):

  • L'émetteur PEUT (MAY) définir le champ ID sur n'importe quelle valeur
  • Le récepteur DOIT (MUST) ignorer le champ ID

Pour les datagrammes non atomiques (DF=0):

  • L'émetteur DOIT (MUST) garantir l'unicité pendant le délai de réassemblage
  • Le récepteur DOIT (MUST) utiliser le champ ID pour le réassemblage

5.2 Mises à jour de RFC 1122​

RFC 1122 définit les exigences pour les hôtes Internet. Les mises à jour incluent:

Pour les datagrammes atomiques (DF=1):

  • Les hôtes PEUVENT (MAY) définir le champ ID sur n'importe quelle valeur
  • Les hôtes NE DEVRAIENT PAS (SHOULD NOT) s'appuyer sur l'ID pour la détection des doublons
  • Les hôtes DOIVENT (MUST) utiliser les mécanismes de la couche transport

Pour les datagrammes non atomiques (DF=0):

  • Les hôtes DOIVENT (MUST) garantir l'unicité de l'ID
  • Les hôtes DEVRAIENT (SHOULD) maintenir des compteurs ID séparés par tuple

5.3 Mises à jour de RFC 2003​

RFC 2003 définit l'encapsulation IP-in-IP. Les mises à jour incluent:

Pour l'en-tête IPv4 externe:

  • Si DF externe=1: L'encapsulateur PEUT (MAY) définir l'ID sur n'importe quelle valeur
  • Si DF externe=0: L'encapsulateur DOIT (MUST) garantir l'unicité

Pour l'en-tête IPv4 interne:

  • L'encapsulateur NE DOIT PAS (MUST NOT) modifier le champ ID interne
  • Le désencapsulateur DOIT (MUST) préserver le champ ID interne

5.4 Résumé des mises à jour​

RFCContenu de mise à jourPortée d'impact
RFC 791Distinction atomique/non atomiqueSpécification IPv4
RFC 1122Exigences hôtes mises à jourImplémentations hôtes
RFC 2003Encapsulation IP-in-IP mise à jourTunnels IP et Mobile IP

Navigation:

6. Considérations de sécurité​

Ce chapitre discute des implications de sécurité des mises à jour du champ ID IPv4.

6.1 Implications pour la vie privée​

La stratégie de génération du champ ID peut divulguer des informations:

  1. Taux d'envoi de datagrammes: Par observation de la croissance de l'ID
  2. Empreinte d'appareil: Identification par modèles d'ID
  3. Suivi d'activité: Suivi par changements d'ID

Contre-mesures:

  • Utiliser des valeurs aléatoires pour les datagrammes atomiques
  • Compteurs par flux au lieu de compteurs globaux
  • Réinitialisation périodique des compteurs
  • Valeurs initiales aléatoires

6.2 Attaques de fragmentation​

La fragmentation IPv4 peut être exploitée pour diverses attaques:

6.2.1 Attaques de réassemblage​

Les attaquants peuvent:

  1. Épuisement des ressources: Envoyer des fragments incomplets
  2. Erreurs de réassemblage: Fragments avec même ID mais contenu différent
  3. Contournement de pare-feu: Fragmenter pour éviter l'inspection

Contre-mesures:

  • Utiliser des datagrammes atomiques (DF=1)
  • Path MTU Discovery
  • Limiter les fragments incomplets
  • Validation des fragments

6.3 Attaques de collision d'ID​

Les attaquants peuvent exploiter la capacité limitée de l'ID:

  1. Attaque de prédiction d'ID: Prédire les algorithmes de génération
  2. Attaque d'épuisement d'ID: Épuiser rapidement l'espace ID
  3. Attaque d'interférence de réassemblage: Fragments forgés avec même ID

Contre-mesures:

  • Génération d'ID randomisée
  • Espace ID par flux
  • Validation de la couche transport
  • IPsec

6.4 Attaques par déni de service​

Le traitement du champ ID IPv4 peut être ciblé par des attaques DoS.

Contre-mesures:

  • Limitation de débit
  • Gestion des ressources
  • Traitement prioritaire des datagrammes atomiques
  • Pare-feu et filtrage

6.5 Comparaison avec IPv6​

La fragmentation IPv6 est plus sécurisée:

  1. Fragmentation de bout en bout: Seuls les nœuds sources fragmentent
  2. Champ d'identification 32 bits: Plus grand espace ID
  3. En-tête de fragmentation explicite: Traitement plus clair

6.6 Recommandations​

  1. Préférer les datagrammes atomiques (DF=1)
  2. Utiliser la génération d'ID randomisée
  3. S'appuyer sur la protection de la couche transport
  4. Déployer des mécanismes de surveillance
  5. Maintenir à jour

Navigation:

Annexe A. Détectabilité des doublons​

Cette annexe discute du rôle du champ ID IPv4 dans la détection des datagrammes en double et l'impact des mises à jour sur la capacité de détection des doublons.

A.1 Contexte de la détection des doublons​

Les datagrammes en double peuvent survenir pour diverses raisons:

  1. Retransmission de la couche liaison: Trames perdues retransmises
  2. Boucles de routage: Erreurs de configuration réseau
  3. Équilibrage de charge: Datagrammes copiés sur plusieurs chemins
  4. Attaques malveillantes: Envoi intentionnel de datagrammes en double

A.2 Limitations de l'IPv4 ID pour la détection des doublons​

Le champ ID IPv4 a les limitations suivantes comme mécanisme de détection:

A.2.1 Espace ID limité​

16 bits ne peuvent représenter que 65 536 valeurs différentes, s'épuisant rapidement dans les environnements à haute vitesse.

A.2.2 Diversité des algorithmes de génération d'ID​

Différents appareils utilisent différents algorithmes de génération d'ID.

A.2.3 Impact de la fragmentation​

Tous les fragments du même datagramme partagent la même valeur d'ID.

A.3 Impact des mises à jour RFC 6864​

Pour les datagrammes atomiques (DF=1), le champ ID IPv4 ne fournit plus de capacité de détection des doublons. Les récepteurs doivent s'appuyer sur les protocoles de la couche transport.

A.4 Mécanismes recommandés pour la détection des doublons​

A.4.1 Mécanismes de couche transport​

  • TCP: Utilise des numéros de séquence 32 bits
  • UDP: La couche application doit implémenter ses propres mécanismes
  • SCTP: Utilise des numéros de séquence de transmission (TSN)

A.4.2 Mécanismes de couche application​

  1. Numéros de séquence
  2. Horodatages
  3. IDs de message (par exemple UUID)
  4. Conception idempotente

A.4.3 Mécanismes de couche réseau​

IPsec: Les protocoles ESP et AH contiennent des numéros de séquence pour détecter les attaques de rejeu.

A.5 Conclusion​

Le champ ID IPv4 sert principalement à la fragmentation et au réassemblage, pas à la détection des doublons. Les concepteurs d'applications et de protocoles devraient s'appuyer sur les mécanismes de la couche transport ou application.

Navigation:

Annexe B. Remerciements​

L'auteur de ce document remercie les personnes et organisations suivantes pour leurs contributions et leur soutien.

B.1 Contributeurs​

Le développement de ce document a bénéficié des contributions de nombreux membres de la communauté IETF. Remerciements particuliers à:

  • Fred Baker - Analyse approfondie des mécanismes de fragmentation IPv4 et IPv6
  • Brian Carpenter - Suggestions sur l'interopérabilité et les stratégies de transition
  • Wesley Eddy - Analyse de l'impact sur les protocoles de transport
  • Fernando Gont - Discussion détaillée des considérations de sécurité
  • Alfred Hoenes - Examen minutieux de la structure du document
  • John Leslie - Discussion sur les algorithmes de génération d'ID
  • Carlos Pignataro - Analyse de l'impact de l'implémentation
  • Dan Wing - Discussion sur l'impact de la compression d'en-tête

B.2 Contributions du groupe de travail​

Ce document a fait l'objet de discussions et d'examens approfondis au sein du groupe de travail IETF INTAREA (Internet Area).

B.3 Examen et retours​

Ce document a subi plusieurs cycles d'examen pendant le processus de normalisation.

B.4 Expérience d'implémentation​

Le développement de ce document a pris en compte l'expérience de plusieurs implémentations:

  • Implémentations de systèmes d'exploitation: Linux, FreeBSD, Windows
  • Équipements réseau: Routeurs, pare-feu, équilibreurs de charge
  • Applications: Diverses applications réseau

B.5 Contexte historique​

Le développement a été inspiré par les documents historiques suivants:

  • RFC 791 (1981) - Internet Protocol
  • RFC 1122 (1989) - Requirements for Internet Hosts
  • RFC 4963 (2007) - IPv4 Reassembly Errors at High Data Rates

B.6 Soutien organisationnel​

L'auteur remercie:

  • USC/ISI - Environnement de recherche et ressources
  • IETF - Plateforme de normalisation
  • IRTF - Résultats de recherche et bases théoriques

B.7 Remerciements spéciaux​

Remerciements spéciaux à tous ceux qui ont fourni des retours sur les listes de diffusion, lors des réunions et dans les discussions privées.

B.8 Adresse de l'auteur​

Joe Touch
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292
U.S.A.

Navigation: