HPE FlexFabric 5940 SERIES, Руководство по настройке безопасности

Страница: 315 / 571

302
•
AES —Encrypts plaintext data with a 128-bit, 192-bit, or 256-bit key. AES provides the highest
security strength and is slower than 3DES.
IPsec implementation
To implement IPsec protection for packets between two peers, complete the following tasks on each
peer:
•
Configure an IPsec policy, which defines the range of packets to be protected by IPsec and the
security parameters used for the protection.
•
Apply the IPsec policy to an interface or an application.
When you apply an IPsec policy to an interface, you implement IPsec based on the interface.
Packets received and sent by the interface are protected according to the IPsec policy. When you
apply an IPsec policy to an application, you implement IPsec based on the application. Packets of
the application are protected according to the IPsec policy, regardless of the receiving and sending
interface of the packets.
IPsec protects packets as follows:
•
When an IPsec peer identifies the packets to be protected according to the IPsec policy, it sets
up an IPsec tunnel and sends the packet to the remote peer through the tunnel. The IPsec
tunnel can be manually configured beforehand, or it can be set up through IKE negotiation
triggered by the packet. The IPsec tunnels are actually the IPsec SAs. The inbound packets are
protected by the inbound SA, and the outbound packets are protected by the outbound SA.
•
When the remote IPsec peer receives the packet, it drops, de-encapsulates, or directly
forwards the packet according to the configured IPsec policy.
Interface-based IPsec supports setting up IPsec tunnels based on ACLs.
ACL-based IPsec
To implement ACL-based IPsec, configure an ACL to define the data flows to be protected, specify
the ACL in an IPsec policy, and then apply the IPsec policy to an interface. When packets sent by the
interface match a permit rule of the ACL, the packets are protected by the outbound IPsec SA and
encapsulated with IPsec. When the interface receives an IPsec packet destined for the local device,
it searches for the inbound IPsec SA according to the SPI in the IPsec packet header for
de-encapsulation. If the de-encapsulated packet matches a permit rule of the ACL, the device
processes the packet. If the de-encapsulated packet does not match any permit rule of the ACL, the
device drops the packet.
The device supports the following data flow protection modes:
•
Standard mode —One IPsec tunnel protects one data flow. The data flow permitted by an ACL
rule is protected by one IPsec tunnel that is established solely for it.
•
Aggregation mode —One IPsec tunnel protects all data flows permitted by all the rules of an
ACL. This mode is only used to communicate with old-version devices.
•
Per-host mode —One IPsec tunnel protects one host-to-host data flow. One host-to-host data
flow is identified by one ACL rule and protected by one IPsec tunnel established solely for it.
This mode consumes more system resources when multiple data flows exist between two
subnets to be protected.
Application-based IPsec
Application-based IPsec does not require an ACL.
You can implement application-based IPsec by binding an IPsec profile to an application protocol. All
packets of the application protocol are encapsulated with IPsec. This method can be used to protect
IPv6 routing protocols. The supported IPv6 routing protocols include OSPFv3, IPv6 BGP, and RIPng.
All packets of the applications that are not bound to IPsec and the IPsec packets that failed to be
de-encapsulated are dropped.