P. Quinn (Cisco)U. Elzur
(Intel)C. Pignataro (Cisco)January20182018-01-14
Ce Network Service Header est un mécanisme
concret pour faire passer sur le réseau les paquets destinés à une
SF (Service Function, voir pour l'architecture et les définitions). On colle un NSH, stockant plusieurs métadonnées,
au paquet à traiter, on encapsule ce paquet
à traiter et on l'envoie au dispositif de traitement via un réseau
overlay. Et on fait
l'opération inverse au retour. L'encapsulation peut se faire dans
IP (par exemple avec
GRE) ou dans un autre protocole.
Les métadonnées mises dans le NSH sont le résultat d'un processus de
classification où le réseau décide ce qu'on va faire au
paquet. Par exemple, en cas de dDoS, le
classificateur décide de faire passer tous les paquets ayant telle
adresse source par un équipement de filtrage plus fin, et met donc
cette décision dans le NSH (section 7.1). Le NSH contient les informations nécessaires pour le SFC
(Service Function Chain, ). Sa lecture est donc très utile pour l'opérateur
du réseau (elle contient la liste des traitements choisis, et cette liste
peut permettre de déduire des informations sur le trafic en cours)
et c'est donc une information plutôt sensible (voir aussi le ).
Le NSH ne s'utilise qu'à l'intérieur de votre propre réseau (il
n'offre, par défaut, aucune authentification et aucune
confidentialité, voir section 8 du RFC). C'est à l'opérateur de
prendre les mesures nécessaires, par exemple en chiffrant tout son
trafic interne. Cette limitation à un seul domaine
permet également de régler le problème de la
fragmentation, si ennuyeux dès qu'on
encapsule, ajoutant donc des octets. Au sein d'un même réseau, on
peut contrôler tous les équipements et donc s'assurer que la
MTU sera suffisante, ou, sinon, que la
fragmentation se passera bien (section 5 du RFC).
Tout le projet SFC (dont
c'est le troisième RFC) repose sur une vision de l'Internet comme étant
un ensemble de
middleboxes tripotant les
paquets au passage, plutôt qu'étant un ensemble de machines
terminales se parlant suivant le principe de bout en
bout. C'est un point important à noter pour comprendre
les débats au sein de l'IETF.