hello,
thanks lagapidis, just another question.
the ospfv3 don’t used a PKI or PSK for authentication.
how the authentication is ensured ?
thanks
Hello Houssem
OSPFv3 doesn’t inherently support authentication itself. OSPFv2 had authentication built in, with the related packet headers etc, but OSPFv3 relies on IPv6’s built-in authentication methods.
As stated in this Cisco documentation on the topic:
When OSPFv3 runs on IPv6, OSPFv3 requires the IPv6 authentication header (AH) or IPv6 ESP header to ensure integrity, authentication, and confidentiality of routing exchanges. IPv6 AH and ESP extension headers can be used to provide authentication and confidentiality to OSPFv3.
The security policy itself is a combination of the SPI and the key (which is the key used to create and validate the hash value). This in essence within the framework of IPsec, is PSK.
I hope this has been helpful!
Laz
Hi team,
Let’s say one of the routers got compromised. Is there a way to hide the ESP Auth and Cipher keys?
Regards,
Vanilson Pedro
Hello Vanilson
There is no direct way to hide the ESP Auth and cipher keys in the configuration. It would be great if there were a command like the service password-encryption command which encrypts all of the plain text passwords in the config file, but there isn’t something similar for IPSec keys.
The solution to this is to ensure that the router doesn’t get compromised, and there are sufficient methods to ensure this.
I hope this has been helpful!
Laz
Hello, everyone.
Is OSPFv3 encryption commonly deployed? I could understand authentication but encryption seems a little off. That would mean that we don’t want anyone to even read the hello and LSA content in Wireshark. Either way, if the network is properly secured, no one should even have access to this information apart from the company.
It also feels complicated to configure - IKE doesn’t automatically generate the key so you must configure a 128, 192 or even a 256 AES key manually, same goes with SHA..
Thank you!
David
Hello David
The truth is that OSPFv3 encryption is rarely deployed in most production enterprise networks, and authentication alone is the far more common practice. However, there are scenarios where encryption is necessary or at least highly desired, and it is for these cases that the feature exists. Let me explain…
In typical enterprise LAN/WAN environments, most organizations use either authentication, thus preventing route manipulation, or they use no security at all, relying on physically secured internal segments, and for many, that’s sufficient.
Now, encryption addresses passive reconnaissance and topology disclosure attack vectors. While authentication deals with active attacks (i.e., unauthorized routers from forming adjacencies and injecting malicious routes), encryption prevents anyone from reading the OSPF packets, thus hiding your complete network topology, addressing scheme, link costs, and router IDs. The information contained in OSPF messages is extremely sensitive, and can be leveraged by knowledgable attackers. It’s no trivial thing for someone to learn the complete topology of your network!
Even if your internal links are physically secured, there are scenarios where an attacker might gain Layer 2 access. In such a case, encryption would be desirable. Such scenarios include a compromised host on the same VLAN as OSPF routers, a rogue VM in a data center fabric, or within a multi-tenant environment.
Sometimes, encryption of OSPF messages may be mandatory to adhere to specific compliance directives, or in high-security scenarios, which include government, military, and finance sectors.
If you have heard about the Zero Trust approach to security, the assumption is that perimeters will be breached. Under this philosophy, encryption of OSPF adjacencies is mandatory.
So even though it is rare, there are cases where encryption is needed. Make sense?
I hope this has been helpful!
Laz