5. Intra-SR-Domain Deployment Model (Modèle de déploiement intra-domaine SR)

L'utilisation des SIDs exclusivement au sein du domaine SR et uniquement pour les paquets du domaine SR constitue un modèle de déploiement important.

Cela permet au domaine SR d'agir comme un système de routage unique.

Cette section couvre :

la sécurisation du domaine SR contre les tentatives externes d'utiliser ses SIDs
l'utilisation du domaine SR comme un système unique avec délégation entre composants
le traitement des paquets du domaine SR

5.1. Securing the SR Domain (Sécurisation du domaine SR)

Les nœuds extérieurs au domaine SR ne sont pas de confiance : ils ne peuvent pas utiliser directement les SIDs du domaine. Ceci est appliqué par deux niveaux de listes de contrôle d'accès :

Tout paquet entrant dans le domaine SR et destiné à un SID au sein du domaine SR est abandonné. Cela peut être réalisé avec la logique suivante. D'autres méthodes avec un résultat équivalent sont considérées conformes :
- Allouer tous les SIDs d'un bloc S/s
- Configurer chaque interface externe de chaque nœud de bordure du domaine avec une liste de contrôle d'accès d'infrastructure entrante (IACL) qui abandonne tout paquet entrant avec une adresse de destination dans S/s
- Le défaut de mise en œuvre de cette méthode de filtrage d'entrée expose le domaine SR aux attaques de routage par la source, comme décrit et référencé dans [RFC5095]
La protection distribuée en #1 est complétée par une protection par nœud, abandonnant les paquets vers les SIDs provenant d'adresses sources extérieures au domaine SR. Cela peut être réalisé avec la logique suivante. D'autres méthodes avec un résultat équivalent sont considérées conformes :
- Assigner toutes les adresses d'interface à partir du préfixe A/a
- Au nœud k, tous les SIDs locaux à k sont assignés à partir du préfixe Sk/sk
- Configurer chaque interface interne de chaque nœud SR k dans le domaine SR avec une IACL entrante qui abandonne tout paquet entrant avec une adresse de destination dans Sk/sk si l'adresse source n'est pas dans A/a.

5.2. SR Domain as a Single System with Delegation among Components (Domaine SR comme système unique avec délégation entre composants)

Tous les paquets intra-domaine SR appartiennent au domaine SR. L'en-tête IPv6 est originé par un nœud du domaine SR et est destiné à un nœud du domaine SR.

Tous les paquets interdomaines sont encapsulés pour la partie du trajet du paquet qui se trouve au sein du domaine SR. L'en-tête IPv6 externe est originé par un nœud du domaine SR et est destiné à un nœud du domaine SR.

En conséquence, tout paquet au sein du domaine SR appartient au domaine SR.

Le domaine SR est un système dans lequel l'opérateur peut vouloir distribuer ou déléguer différentes opérations de l'en-tête le plus externe à différents nœuds au sein du système.

Un opérateur d'un domaine SR peut choisir de déléguer l'ajout de SRH à un nœud hôte au sein du domaine SR et de déléguer la validation du contenu de tout SRH à un routeur ou commutateur plus fiable attaché à l'hôte. Considérons un commutateur top-of-rack T connecté à l'hôte H via l'interface I. H reçoit un SRH (SRH1) avec un HMAC calculé via une méthode SDN en dehors du champ d'application de ce document. H classifie le trafic qu'il génère et ajoute SRH1 au trafic nécessitant un accord de niveau de service (SLA) spécifique. T est configuré avec une IACL sur I nécessitant la vérification du SRH pour tout paquet destiné au bloc SID du domaine SR (S/s). T vérifie et valide que SRH1 est valide et contient un TLV HMAC ; T vérifie ensuite le HMAC.

Un opérateur du domaine SR peut choisir de faire vérifier le HMAC par tous les segments du domaine SR. Ce mécanisme permettrait de vérifier que la liste de segments SRH n'est pas modifiée lors de la traversée du domaine SR.

5.3. MTU Considerations (Considérations MTU)

Un nœud de bordure d'entrée du domaine SR encapsule les paquets traversant le domaine SR et doit prendre en compte le MTU du domaine SR. Au sein du domaine SR, des techniques d'atténuation bien connues sont RECOMMANDÉES, telles que le déploiement d'une valeur MTU supérieure au sein du domaine SR qu'aux bordures d'entrée.

L'encapsulation avec un en-tête IPv6 externe et un SRH partage les mêmes considérations de MTU et de fragmentation que les tunnels IPv6 décrits dans [RFC2473]. Une investigation plus approfondie sur les limitations de diverses méthodes de tunnelisation (y compris les tunnels IPv6) est discutée dans [INTAREA-TUNNELS] et DEVRAIT être considérée par les opérateurs lors de la prise en compte du MTU au sein du domaine SR.

5.4. ICMP Error Processing (Traitement des erreurs ICMP)

Les paquets d'erreur ICMP générés au sein du domaine SR sont envoyés aux nœuds sources au sein du domaine SR. Le paquet invoquant dans le message d'erreur ICMP peut contenir un SRH. Étant donné que l'adresse de destination d'un paquet avec un SRH change à mesure que chaque segment est traité, elle peut ne pas être la destination utilisée par le socket ou l'application qui a généré le paquet invoquant.

Pour que la source d'un paquet invoquant puisse traiter le message d'erreur ICMP, l'adresse de destination ultime de l'en-tête IPv6 peut être requise. La logique suivante est utilisée pour déterminer l'adresse de destination à utiliser par les gestionnaires d'erreurs de protocole.

Parcourir tous les en-têtes d'extension du paquet IPv6 invoquant jusqu'à l'en-tête d'extension de routage précédant l'en-tête de couche supérieure.
- Si l'en-tête de routage est de type 4 Segment Routing Header (SRH)
  
  o Le SID à Segment List[0] peut être utilisé comme adresse de destination du paquet invoquant.

Les erreurs ICMP sont ensuite traitées par les transports de couche supérieure comme défini dans [RFC4443].

Pour les paquets IP encapsulés dans un en-tête IPv6 externe, le traitement des erreurs ICMP est tel que défini dans [RFC2473].

5.5. Load Balancing and ECMP (Équilibrage de charge et ECMP)

Pour tout paquet interdomaine, le nœud source SR DOIT imposer une étiquette de flux calculée en fonction du paquet interne. Le calcul de l'étiquette de flux est tel que recommandé dans [RFC6438] pour le point de terminaison de tunnel émetteur.

Pour tout paquet intradomaine, le nœud source SR DEVRAIT imposer une étiquette de flux calculée comme décrit dans [RFC6437] pour aider l'équilibrage de charge ECMP aux nœuds de transit incapables de calculer un 5-tuple au-delà du SRH.

À tout nœud de transit au sein d'un domaine SR, l'étiquette de flux DOIT être utilisée comme défini dans [RFC6438] pour calculer le hachage ECMP vers l'adresse de destination. Si une étiquette de flux n'est pas utilisée, le nœud de transit hacherait probablement tous les paquets entre une paire de nœuds de bordure SR vers le même lien.

À un nœud de point de terminaison de segment SR, l'étiquette de flux DOIT être utilisée comme défini dans [RFC6438] pour calculer tout hachage ECMP utilisé pour transférer le paquet traité vers le segment suivant.

5.6. Other Deployments (Autres déploiements)

D'autres modèles de déploiement et leurs implications sur la sécurité, le MTU, le HMAC, le traitement des erreurs ICMP et l'interaction avec d'autres en-têtes d'extension sont en dehors du champ d'application de ce document.