Stable and reliable routes provide a solid basis for network communication. OSPFv3 is widely applied to ASs and therefore requires high levels of protection. OSPFv3 itself does not define any authentication mechanism; therefore, if no additional authentication mechanism is configured for OSPFv3, packets will be prone to be intercepted, modified, or faked. This can potentially affect OSPFv3 neighbor relationships and interrupt network communication.
RFC introduces IPSec for authenticating OSPFv3 packets. An AH or ESP header inserted into an OSPFv3 packet provides a basis for data origin authentication and data integrity authentication, protecting OSPFv3 neighbor relationships and network communication.
As shown in Figure 1, SwitchA and SwitchB run OSPFv3 and are reachable. To prevent packets along the route between SwitchA and SwitchB from being intercepted or faked, IPSec is configured between SwitchA and SwitchB.
IPSec can be deployed in an OSPFv3 process or area or on an interface.
OSPFv3 allows multiple instances on each link, and each instance is identified by the instance-id field. The IPSec header, however, does not support the instance-id field. Therefore, all OSPFv3 instances on an interface use the same SA.
As shown in Figure 1, IPSec is configured on all interfaces so that OSPFv3 neighbor relationships are set up only when IPSec authentication succeeds. Packets that fail IPSec authentication or undergo different authentication modes on IPSec peers will be dropped.