No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

NE40E V800R010C10SPC500 Feature Description - Security 01

This is NE40E V800R010C10SPC500 Feature Description - Security
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Whitelist-based Access Control

Whitelist-based Access Control

An IPsec gateway can use a certificate attribute access control policy, which functions similarly as a whitelist, to authenticate the certificate of the IKE peer. However, this method has the following defects:
  1. Requires great numbers of workloads and difficult management.
  2. Does not provide exact match of certificates' common names.

The IPsec whitelist function resolves the preceding defects. You can define an IPsec whitelist and import it into a device. The IPsec whitelist function provides exact match of certificates' common names.

When IKE negotiation is implemented before an IPsec tunnel is created, the system checks whether the IPsec whitelist function is enabled. If the IPsec whitelist function is enabled, the system checks whether the common name of the peer end's certificate is whitelisted.
  • If the common name of the peer end's certificate is whitelisted, the peer end passes the authentication, and IKE negotiation is allowed to set up an IPsec tunnel.
  • If the common name of the peer end's certificate is not whitelisted, the peer end fails the authentication, and IKE negotiation is not allowed. As a result, the IPsec tunnel fails to be set up.
In this manner, only whitelisted devices are allowed to access the network, hardening network security.
Whitelist files are typically .xml files in the following formats:
<SerialnumberList>
    <Serialnumber>CN-on-Certificate_of-RBS-1</Serialnumber>
    <Serialnumber>CN-on-Certificate_of-RBS-2</Serialnumber>
    ¡­
    <Serialnumber>CN-on-Certificate_of-RBS-n</Serialnumber>
</SerialnumberList>
The character string listed in <Serialnumber></Serialnumber> is the common name of a peer device's certificate.
To allow users to update the whitelist as required, the following functions are available:
  • Imports a whitelist. If importing a whitelist fails, the system rolls back to the status where the whitelist is not imported.
  • Deletes a whitelist.
  • Adds incremental content to a whitelist.
  • Queries a whitelist.

On the network shown in Figure 17-6, an IPsec tunnel needs to be set up between an eNodeB and an IPsec gateway to ensure secure communications. To prevent an unauthorized device from setting up an IPsec tunnel with the IPsec gateway, configure the IPsec whitelist function on the IPsec gateway so that only whitelisted devices can access the network.

Figure 17-6 IPsec whitelist applications
Translation
Download
Updated: 2019-01-03

Document ID: EDOC1100055047

Views: 14181

Downloads: 34

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next