5. Intra-SR-Domain Deployment Model (Modello di distribuzione intra-dominio SR)

L'uso dei SID esclusivamente all'interno del dominio SR e unicamente per i pacchetti del dominio SR è un importante modello di distribuzione.

Questo consente al dominio SR di agire come un singolo sistema di routing.

Questa sezione copre:

protezione del dominio SR da tentativi esterni di utilizzare i suoi SID
utilizzo del dominio SR come un singolo sistema con delega tra componenti
gestione dei pacchetti del dominio SR

5.1. Securing the SR Domain (Protezione del dominio SR)

I nodi esterni al dominio SR non sono affidabili: non possono utilizzare direttamente i SID del dominio. Questo è applicato da due livelli di liste di controllo accessi:

Qualsiasi pacchetto che entra nel dominio SR e destinato a un SID all'interno del dominio SR viene scartato. Questo può essere realizzato con la seguente logica. Altri metodi con risultato equivalente sono considerati conformi:
- Allocare tutti i SID da un blocco S/s
- Configurare ogni interfaccia esterna di ogni nodo edge del dominio con una lista di controllo accessi infrastrutturale in ingresso (IACL, Infrastructure Access Control List) che scarta qualsiasi pacchetto in arrivo con un indirizzo di destinazione in S/s
- Il mancato implemento di questo metodo di filtraggio in ingresso espone il dominio SR ad attacchi di source-routing, come descritto e referenziato in [RFC5095]
La protezione distribuita in #1 è integrata con protezione per-nodo, scartando pacchetti destinati ai SID da indirizzi sorgente esterni al dominio SR. Questo può essere realizzato con la seguente logica. Altri metodi con risultato equivalente sono considerati conformi:
- Assegnare tutti gli indirizzi di interfaccia dal prefisso A/a
- Al nodo k, tutti i SID locali a k sono assegnati dal prefisso Sk/sk
- Configurare ogni interfaccia interna di ogni nodo SR k nel dominio SR con una IACL in ingresso che scarta qualsiasi pacchetto in arrivo con un indirizzo di destinazione in Sk/sk se l'indirizzo sorgente non è in A/a.

5.2. SR Domain as a Single System with Delegation among Components (Dominio SR come singolo sistema con delega tra componenti)

Tutti i pacchetti intra-dominio-SR sono del dominio SR. L'header IPv6 è originato da un nodo del dominio SR ed è destinato a un nodo del dominio SR.

Tutti i pacchetti interdominio sono incapsulati per la parte del percorso del pacchetto che è all'interno del dominio SR. L'header IPv6 esterno è originato da un nodo del dominio SR ed è destinato a un nodo del dominio SR.

Di conseguenza, qualsiasi pacchetto all'interno del dominio SR è del dominio SR.

Il dominio SR è un sistema nel quale l'operatore potrebbe voler distribuire o delegare diverse operazioni dell'header più esterno a diversi nodi all'interno del sistema.

Un operatore di un dominio SR può scegliere di delegare l'aggiunta dell'SRH a un nodo host all'interno del dominio SR e delegare la validazione dei contenuti di qualsiasi SRH a un router o switch più affidabile collegato all'host. Si consideri uno switch top-of-rack T connesso all'host H tramite l'interfaccia I. H riceve un SRH (SRH1) con un HMAC calcolato tramite qualche metodo SDN al di fuori dello scopo di questo documento. H classifica il traffico che origina e aggiunge SRH1 al traffico che richiede uno specifico Service Level Agreement (SLA). T è configurato con una IACL su I che richiede la verifica dell'SRH per qualsiasi pacchetto destinato al blocco SID del dominio SR (S/s). T controlla e verifica che SRH1 sia valido e contenga un TLV HMAC; T verifica quindi l'HMAC.

Un operatore del dominio SR può scegliere di far verificare l'HMAC da tutti i segmenti nel dominio SR. Questo meccanismo verificherebbe che la Segment List dell'SRH non sia modificata mentre attraversa il dominio SR.

5.3. MTU Considerations (Considerazioni sulla MTU)

Un nodo edge di ingresso del dominio SR incapsula i pacchetti che attraversano il dominio SR e deve considerare la MTU del dominio SR. All'interno del dominio SR, sono RACCOMANDATE tecniche di mitigazione ben note, come distribuire un valore MTU maggiore all'interno del dominio SR rispetto agli edge di ingresso.

L'incapsulamento con un header IPv6 esterno e SRH condivide le stesse considerazioni su MTU e frammentazione dei tunnel IPv6 descritti in [RFC2473]. Un'ulteriore investigazione sulla limitazione di vari metodi di tunneling (inclusi i tunnel IPv6) è discussa in [INTAREA-TUNNELS] e DOVREBBE essere considerata dagli operatori quando considerano la MTU all'interno del dominio SR.

5.4. ICMP Error Processing (Elaborazione errori ICMP)

I pacchetti di errore ICMPv6 generati all'interno del dominio SR sono inviati ai nodi sorgente all'interno del dominio SR. Il pacchetto invocante nel messaggio di errore ICMP può contenere un SRH. Poiché l'indirizzo di destinazione di un pacchetto con un SRH cambia man mano che ogni segmento viene elaborato, potrebbe non essere la destinazione utilizzata dal socket o dall'applicazione che ha generato il pacchetto invocante.

Affinché la sorgente di un pacchetto invocante elabori il messaggio di errore ICMP, potrebbe essere richiesto l'indirizzo di destinazione finale dell'header IPv6. La seguente logica è utilizzata per determinare l'indirizzo di destinazione da utilizzare dai gestori di errore del protocollo.

Scorrere tutti gli extension header del pacchetto IPv6 invocante fino all'header di estensione di routing che precede l'header dello strato superiore.
- Se l'header di routing è di tipo 4 Segment Routing Header (SRH)
  
  o Il SID alla Segment List[0] può essere utilizzato come indirizzo di destinazione del pacchetto invocante.

Gli errori ICMP sono quindi elaborati dai trasporti di livello superiore come definito in [RFC4443].

Per i pacchetti IP incapsulati in un header IPv6 esterno, la gestione degli errori ICMP è come definito in [RFC2473].

5.5. Load Balancing and ECMP (Bilanciamento del carico e ECMP)

Per qualsiasi pacchetto interdominio, il nodo sorgente SR DEVE imporre una flow label calcolata in base al pacchetto interno. Il calcolo della flow label è come raccomandato in [RFC6438] per il Tunnel End Point mittente.

Per qualsiasi pacchetto intradominio, il nodo sorgente SR DOVREBBE imporre una flow label calcolata come descritto in [RFC6437] per assistere il bilanciamento del carico ECMP nei nodi di transito incapaci di calcolare una 5-tupla oltre l'SRH.

In qualsiasi nodo di transito all'interno di un dominio SR, la flow label DEVE essere utilizzata come definito in [RFC6438] per calcolare l'hash ECMP verso l'indirizzo di destinazione. Se una flow label non viene utilizzata, il nodo di transito probabilmente hasherebbe tutti i pacchetti tra una coppia di nodi Edge SR sullo stesso link.

In un nodo endpoint di segmento SR, la flow label DEVE essere utilizzata come definito in [RFC6438] per calcolare qualsiasi hash ECMP utilizzato per inoltrare il pacchetto elaborato al segmento successivo.

5.6. Other Deployments (Altre distribuzioni)

Altri modelli di distribuzione e le loro implicazioni sulla sicurezza, MTU, HMAC, elaborazione degli errori ICMP e interazione con altri extension header sono al di fuori dello scopo di questo documento.