White List/Black List Interaction

White lists and black lists may or may not be assigned to the IKEv2 interfaces. The following rules are used to support implementation of both list types.

1. If neither a white list nor a black list are assigned to an IKEv2 interface, all EAP authentication requests are forwarded to a RADIUS authentication server for final determination.
2. If only a white list is assigned to an IKEv2 interface, the incoming EAP identity is be checked against that white list. If the EAP identity is contained in the white list, the authentication request is forwarded to a RADIUS authentication server for final determination. If the EAP identity is absent, authentication is denied.
3. If only a black list is assigned to an IKEv2 interface, the incoming EAP identity is checked against that black list. If the EAP identity is contained in the black list, authentication is denied. If the EAP identity is absent, the authentication request is forwarded to a RADIUS authentication server for final determination..
4. If both a white list and a black list are assigned to an IKEv2 interface, the OCSBC checks both the white and the black list for incoming EAP identity.

   If the EAP identity is contained in the white list, and absent from the black list, the authentication request is forwarded to a RADIUS authentication server for final determination.

   If the EAP identity is contained in the black list and absent from the white list, authentication is rejected.

   If the EAP identity is present in both the lists, the black list takes priority. Consequently, authentication is rejected. This situation will have been previously reported by the verify-config ACLI command.

   If the EAP identity is absent from both the lists, the whate list takes priority. Consequently, since the EAP identity is not contained in the white list the authentication is denied.