5. Conformance Requirements (Requisiti di conformità)

5. Conformance Requirements (Requisiti di conformità)

Le implementazioni che rivendicano conformità o compliance con questa specifica DEVONO implementare la sintassi e l'elaborazione ESP descritte qui per il traffico unicast, e DEVONO conformarsi a tutti i requisiti aggiuntivi di elaborazione dei pacchetti imposti dal documento sull'architettura di sicurezza [Ken-Arch]. Inoltre, se un'implementazione afferma di supportare il traffico multicast, essa DEVE conformarsi ai requisiti aggiuntivi specificati per il supporto di tale traffico. Se la chiave utilizzata per calcolare un ICV è distribuita manualmente, la corretta fornitura del servizio anti-replay richiede il corretto mantenimento dello stato del contatore presso il mittente (attraverso riavvii locali, ecc.), fino a quando la chiave non viene sostituita, e probabilmente non ci sarebbe alcuna disposizione di recupero automatizzato se l'overflow del contatore fosse imminente. Pertanto, un'implementazione conforme NON DOVREBBE fornire il servizio anti-replay in congiunzione con SA con chiavi manuali.

Gli algoritmi obbligatori da implementare per l'uso con ESP sono descritti in un documento separato [Eas04], per facilitare l'aggiornamento dei requisiti dell'algoritmo indipendentemente dal protocollo in sé. Algoritmi aggiuntivi, oltre a quelli obbligatori per ESP, POSSONO essere supportati.

Poiché l'uso della crittografia in ESP è opzionale, è richiesto anche il supporto dell'algoritmo di crittografia "NULL" per mantenere la coerenza con il modo in cui i servizi ESP vengono negoziati. Il supporto per la versione del servizio ESP solo confidenzialità è opzionale. Se un'implementazione offre questo servizio, essa DEVE anche supportare la negoziazione dell'algoritmo di integrità "NULL". NOTARE che sebbene l'integrità e la crittografia possano ciascuna essere "NULL" nelle circostanze sopra indicate, esse NON DEVONO essere entrambe "NULL".