7. Security Considerations (Considerazioni sulla sicurezza)
Questa sezione esamina i problemi di sicurezza sollevati dall'introduzione dei servizi differenziati, principalmente la possibilità di attacchi denial-of-service e la relativa possibilità di furto di servizio da parte di traffico non autorizzato (Sezione 7.1). La Sezione 7.2 tratta il funzionamento dei servizi differenziati in presenza di IPsec, incluse le interazioni con la modalità tunnel IPsec e altri protocolli di tunneling. Un trattamento più ampio delle preoccupazioni di sicurezza sollevate dall'architettura complessiva dei servizi differenziati può essere trovato in [ARCH].
7.1 Theft and Denial of Service (Furto e denial of service)
L'obiettivo primario dei servizi differenziati è consentire la fornitura di diversi livelli di servizio ai flussi di traffico su un'infrastruttura di rete comune. Varie tecniche possono essere utilizzate per raggiungere questo obiettivo, ma il risultato finale è che alcuni pacchetti ricevono un servizio diverso (ad esempio, migliore) rispetto ad altri. Poiché la mappatura del traffico di rete a comportamenti specifici che risultano in un servizio diverso (ad esempio, migliore o peggiore) è indicata principalmente dal codepoint DS, un avversario potrebbe essere in grado di ottenere un servizio migliore modificando i codepoint per indicare un comportamento utilizzato per un servizio esteso, o iniettando pacchetti con tali valori di codepoint. Spinto all'estremo, tale furto di servizio (theft-of-service) diventa un attacco denial-of-service (denial-of-service attack) quando il traffico modificato o iniettato esaurisce le risorse disponibili per inoltrare quel traffico e altri flussi di traffico.
La difesa contro questa classe di attacchi di furto e denial-of-service consiste in una combinazione di condizionamento del traffico ai confini del dominio DS e sicurezza e integrità dell'infrastruttura di rete all'interno del dominio DS. I nodi di confine del dominio DS devono (MUST) garantire che tutto il traffico che entra nel dominio sia marcato con valori di codepoint appropriati per il traffico e il dominio, ri-marcando il traffico con nuovi valori di codepoint se necessario. Questi nodi di confine DS sono la linea di difesa primaria (primary line of defense) contro gli attacchi di furto e denial-of-service basati su codepoint modificati. Il successo di un tale attacco indica che i codepoint utilizzati dal traffico attaccante erano inappropriati. Un'istanza importante di nodi di confine è che i nodi di origine del traffico in un dominio DS sono i nodi di confine iniziali per quel traffico. I nodi interni in un dominio DS si affidano ai codepoint DS per associare il traffico ai PHB di inoltro e non sono tenuti (are NOT REQUIRED) a verificare i valori dei codepoint prima di utilizzarli. Di conseguenza, i nodi interni si affidano al corretto funzionamento dei nodi di confine del dominio DS per prevenire l'arrivo di traffico con codepoint inappropriati o traffico che supera i livelli provisionati (provisioned levels) e disturba il funzionamento del dominio.
7.2 IPsec and Tunneling Interactions (Interazioni IPsec e tunneling)
I protocolli IPsec definiti in [ESP, AH] non includono il campo DS dell'header IP nei loro calcoli crittografici (nel caso della modalità tunnel, è il campo DS dell'header IP esterno che non è incluso). Pertanto, la modifica del campo DS da parte dei nodi di rete non può causare il fallimento dei controlli di integrità IPsec e quindi non influisce sulla sicurezza end-to-end di IPsec. Di conseguenza, IPsec non fornisce difesa contro la modifica del campo DS da parte di un avversario (cioè un attacco man-in-the-middle, man-in-the-middle attack), precisamente perché la modifica da parte dell'avversario non influisce nemmeno sulla sicurezza end-to-end di IPsec.
La modalità tunnel IPsec fornisce sicurezza per il campo DS dell'header IP incapsulato. Un pacchetto in modalità tunnel IPsec contiene due header IP: un header esterno fornito dal nodo di ingresso del tunnel (tunnel ingress node) e un header interno incapsulato fornito dalla sorgente originale del pacchetto. Quando un tunnel IPsec è ospitato (in tutto o in parte) su una rete di servizi differenziati, i nodi di rete intermedi manipolano il campo DS dell'header esterno. Al nodo di uscita del tunnel (tunnel egress node), l'elaborazione IPsec include la rimozione dell'header esterno e (se necessario) l'inoltro del pacchetto utilizzando l'header interno. I protocolli IPsec richiedono (REQUIRES) che questa elaborazione di decapsulazione (decapsulation processing) non modifichi il campo DS dell'header interno per garantire che le modifiche al campo DS non possano essere utilizzate per lanciare attacchi di furto o denial-of-service oltre gli endpoint del tunnel IPsec. Questo documento non apporta modifiche a questo requisito. Se l'header IP interno non è stato elaborato da un nodo di confine DS del dominio DS del nodo di uscita del tunnel, allora il nodo di uscita del tunnel è il nodo di confine per il traffico che esce dal tunnel e deve (MUST) quindi garantire che il traffico risultante abbia codepoint DS appropriati.
Se l'elaborazione di decapsulazione di uscita del tunnel IPsec include un controllo di integrità crittografica sufficientemente forte (cryptographic integrity check) del pacchetto incapsulato (la sufficienza è determinata dalla politica di sicurezza locale), allora il nodo di uscita del tunnel può assumere in modo sicuro che il campo DS dell'header interno abbia lo stesso valore che aveva al nodo di ingresso del tunnel. Un risultato importante è che altri link non sicuri in un dominio DS possono essere protetti da un tunnel IPsec sufficientemente forte. Questa analisi e le sue implicazioni si applicano a qualsiasi protocollo di tunneling che esegue controlli di integrità, sebbene il livello di garanzia (level of assurance) del campo DS dell'header interno dipenda dalla forza del controllo di integrità eseguito dal protocollo di tunneling. In assenza di garanzia sufficiente per un tunnel che può passare attraverso nodi al di fuori del dominio DS corrente (o altrimenti vulnerabile, otherwise vulnerable), i pacchetti incapsulati devono (MUST) essere trattati come se arrivassero a un confine dall'esterno del dominio DS.