Appendix F. Multiple Interfaces to Same Network

        (2) Le champ checksum dans l'en-tête standard OSPF n'est pas calculé, mais est plutôt fixé à 0.

        (3) Le Key ID (voir Figure 18) est fixé au Key ID de la clé choisie.

        (4) Le champ Auth Data Len est fixé à la longueur en octets du message digest qui sera ajouté au paquet OSPF. Lors de l'utilisation de MD5 comme algorithme d'authentification, Auth Data Len sera de 16.

        (5) Le numéro de séquence cryptographique de 32 bits (voir Figure 18) est fixé à une valeur non décroissante (c'est-à-dire une valeur au moins aussi grande que la dernière valeur envoyée sur l'interface). Les valeurs précises à utiliser dans le champ de numéro de séquence cryptographique sont spécifiques à l'implémentation. Par exemple, il peut être basé sur un simple compteur, ou sur l'horloge du système.

        (6) Le message digest est ensuite calculé et ajouté au paquet OSPF. L'algorithme d'authentification à utiliser pour calculer le digest est indiqué par la clé elle-même. L'entrée de l'algorithme d'authentification consiste en le paquet OSPF et la clé secrète. Lors de l'utilisation de MD5 comme algorithme d'authentification, le calcul du message digest procède comme suit :

            (a) La clé MD5 de 16 octets est ajoutée au paquet OSPF.

            (b) Les champs de remplissage (pad) final et de longueur sont ajoutés, comme spécifié dans [Ref17].

            (c) L'algorithme d'authentification MD5 est exécuté sur la concaténation du paquet OSPF, de la clé secrète, du pad et des champs de longueur, produisant un message digest de 16 octets (voir [Ref17]).

            (d) Le digest MD5 est écrit par-dessus la clé OSPF (c'est-à-dire ajouté au paquet OSPF original). Le digest n'est pas compté dans le champ de longueur du paquet OSPF, mais est inclus dans le champ de longueur IP du paquet. Tout pad ou champ de longueur au-delà du digest n'est ni compté ni transmis.

D.5 Vérification de message (Message verification)

    Lorsqu'un paquet OSPF a été reçu sur une interface, il doit être authentifié. La procédure d'authentification est indiquée par le réglage de Autype dans l'en-tête standard du paquet OSPF, qui correspond au réglage de Autype pour l'interface OSPF réceptrice.

    Si un paquet de protocole OSPF est accepté comme authentique, le traitement du paquet se poursuit comme spécifié dans la section 8.2. Les paquets qui échouent à l'authentification sont ignorés.

    D.5.1 Vérification de l'authentification nulle (Verifying Null authentication)

        Lors de l'utilisation de l'authentification nulle, le champ checksum dans l'en-tête OSPF doit être vérifié. Il doit être fixé au complément à un sur 16 bits de la somme des compléments à un de tous les mots de 16 bits du paquet, à l'exclusion du champ d'authentification. (Si la longueur du paquet n'est pas un nombre entier de mots de 16 bits, le paquet est complété par un octet de zéro avant le calcul de la somme de contrôle.)

    D.5.2 Vérification de l'authentification par mot de passe simple (Verifying Simple password authentication)

        Lors de l'utilisation de l'authentification par mot de passe simple, le paquet OSPF reçu est authentifié comme suit :

        (1) Le champ checksum dans l'en-tête OSPF doit être vérifié. Il doit être fixé au complément à un sur 16 bits de la somme des compléments à un de tous les mots de 16 bits du paquet, à l'exclusion du champ d'authentification. (Si la longueur du paquet n'est pas un nombre entier de mots de 16 bits, le paquet est complété par un octet de zéro avant le calcul de la somme de contrôle.)

        (2) Le champ d'authentification de 64 bits dans l'en-tête du paquet OSPF doit être égal au mot de passe de 64 bits (c'est-à-dire la clé d'authentification) qui a été configuré pour l'interface.


    D.5.3 Vérification de l'authentification cryptographique (Verifying Cryptographic authentication)

        Lors de l'utilisation de l'authentification cryptographique, le paquet OSPF reçu est authentifié comme suit :

        (1) Localiser la clé configurée de l'interface réceptrice ayant un Key ID égal à celui spécifié dans le paquet OSPF reçu (voir Figure 18). Si la clé n'est pas trouvée, ou si la clé n'est pas valide pour la réception (c'est-à-dire heure courante < KeyStartAccept ou heure courante >= KeyStopAccept), le paquet OSPF est ignoré.

        (2) Si le numéro de séquence cryptographique trouvé dans l'en-tête OSPF (voir Figure 18) est inférieur au numéro de séquence cryptographique enregistré dans la structure de données du voisin émetteur, le paquet OSPF est ignoré.

        (3) Vérifier le message digest ajouté selon les étapes suivantes :

            (a) Le digest reçu est mis de côté.

            (b) Un nouveau digest est calculé, comme spécifié à l'étape 6 de la section D.4.3.

            (c) Le digest calculé et le digest reçu sont comparés. S'ils ne correspondent pas, le paquet OSPF est ignoré. S'ils correspondent, le paquet de protocole OSPF est accepté comme authentique, et le « cryptographic sequence number » dans la structure de données du voisin est fixé au numéro de séquence trouvé dans l'en-tête OSPF du paquet.

E. Un algorithme pour assigner les Link State IDs (An algorithm for assigning Link State IDs)

Le Link State ID dans les AS-external-LSAs et les summary-LSAs est généralement fixé à l'adresse IP du réseau décrit. Cependant, si nécessaire, un ou plusieurs des bits hôte du réseau peuvent être fixés dans le Link State ID. Cela permet au routeur d'émettre des LSA séparés pour des réseaux ayant la même adresse, mais des masques différents. De tels réseaux peuvent survenir en présence de supernetting et de sous-réseau 0 (voir [Ref10]).

Cet appendice donne un algorithme possible pour fixer les bits hôte dans les Link State IDs. Le choix d'un tel algorithme est une décision locale. Des routeurs distincts sont libres d'utiliser des algorithmes différents, puisque les seuls LSA affectés sont ceux que le routeur émet lui-même. La seule exigence sur les algorithmes utilisés est que l'adresse IP du réseau doit être utilisée comme Link State ID chaque fois que possible ; cela maximise l'interopérabilité avec les implémentations OSPF antérieures à la RFC 1583.

L'algorithme ci-dessous est énoncé pour les AS-external-LSAs. Cela n'est que pour plus de clarté ; le même algorithme exact peut être utilisé pour les summary-LSAs. Supposons que le routeur souhaite émettre un AS-external-LSA pour un réseau ayant l'adresse NA et le masque NM1. Les étapes suivantes sont alors utilisées pour déterminer le Link State ID du LSA :

(1) Déterminer si le routeur émet déjà un AS-external-LSA avec un Link State ID égal à NA (dans un tel LSA, le routeur lui-même sera listé comme Advertising Router du LSA). Si non, le Link State ID est fixé égal à NA et l'algorithme se termine. Sinon,

(2) Obtenir le masque de réseau à partir du corps du AS-external-LSA déjà existant. Appelez ce masque NM2. Il y a alors deux cas :

    o   NM1 est plus long (c'est-à-dire plus spécifique) que NM2. Dans ce cas, fixer le Link State ID dans le nouveau LSA au réseau [NA,NM1] avec tous les bits hôte fixés (c'est-à-dire égal à NA OU-é avec tous les bits qui ne sont pas fixés dans NM1, ce qui est l'adresse de diffusion (broadcast address) du réseau [NA,NM1]).

    o   NM2 est plus long que NM1. Dans ce cas, modifier le LSA existant (ayant le Link State ID de NA) pour référencer le nouveau réseau [NA,NM1] en incrémentant le numéro de séquence, en changeant le masque dans le corps à NM1 et en insérant le coût du nouveau réseau. Puis émettre un nouveau LSA pour l'ancien réseau [NA,NM2], avec un Link State ID égal à NA OU-é avec les bits qui ne sont pas fixés dans NM2 (c'est-à-dire l'adresse de diffusion du réseau [NA,NM2]).