Comprendo che AH fornisce integrità e autenticazione mentre ESP fornisce crittografia e autenticazione, ma a me sembra che qualche IP Header Address Spoofing sia ancora possibile, no?
Perché l'intestazione IP non è inclusa nella parte di autenticazione di ESP? Era il motivo per renderlo compatibile NAT?
E possono essere usati insieme?
Sì, quando si utilizza ESP l'indirizzo IP di origine può essere modificato da un utente malintenzionato. Ma a meno che questo non si traduca in un attacco di amplificazione, non vedo davvero un punto nel farlo. Un utente malintenzionato che è in grado di modificare gli indirizzi IP può anche solo eliminare il traffico o leggerlo passivamente (se non è crittografato), tuttavia, non sarà in grado di creare nuovi pacchetti, indipendentemente dal protocollo utilizzato.
Sebbene i due protocolli possano essere combinati (ad es. usare ESP solo per riservatezza e AH per integrità), la funzionalità di integrità fornita da ESP offre la stessa sicurezza con meno overhead (specialmente quando si usano algoritmi AEAD), RFC 4302 (AH):
ESP may be used to provide the same anti-replay and similar integrity services, and it also provides a confidentiality (encryption) service. The primary difference between the integrity provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (e.g., via use of tunnel mode).
Quindi, se proteggere parti dell'intestazione IP esterna (e delle intestazioni di estensione) non è un requisito, ESP fornisce fondamentalmente la stessa funzionalità di AH. L'ESP può persino essere utilizzato senza riservatezza, RFC 4303 (ESP):
Integrity-only ESP is an attractive alternative to AH in many contexts, e.g., because it is faster to process and more amenable to pipelining in many implementations.