IPSec design for OSPFv3?
I'm looking around, and not seeing anything online regarding how to protect BIRD OSPFv3 with IPSec (at least on FreeBSD). I am able to configure IPSec transport mode to protect unicast traffic between routers; but multicast traffic is still transmitted without AH. A number of sources seem to be setting up a GRE/IPSec tunnel between routers, and running OSPF on that interface, facilitating multicast traffic. That seems counter to performance though, wouldn't data traffic then [needlessly] use the tunnel? Another thought I had was to configure all OSPF interfaces as NBMA, making OSPF traffic easier to protect. Thoughts on this? Are BIRD users just skipping authentication for OSPFv3? Thanks, -- Thomas Johnson -- This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the individual responsible for delivering the e-mail to the intended recipient, please be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender or call ClaimLynx at (952) 593-5969.
On Fri, Sep 06, 2013 at 11:47:59AM -0500, Thomas Johnson wrote:
I'm looking around, and not seeing anything online regarding how to protect BIRD OSPFv3 with IPSec (at least on FreeBSD). I am able to configure IPSec transport mode to protect unicast traffic between routers; but multicast traffic is still transmitted without AH.
Retrospectively, assuming IPSec would provide all OSPFv3 security wasn't smartest move from IETF. Although it could worked if OSes offered socket-specific API for configuring IPSec, but AFAIK it is usually needed to configure system-wide IPSec policy database, which is problematic from routing software POV.
A number of sources seem to be setting up a GRE/IPSec tunnel between routers, and running OSPF on that interface, facilitating multicast traffic
As traffic would be routed the same way as OSPF packets, that would also encrypt all the network traffic, which would increase routers' load many times.
Thoughts on this? Are BIRD users just skipping authentication for OSPFv3?
Well, i would just separate transit (router-to-router) networks from endpoint (router-to-hosts) networks, use TTL security on transit networks and stub mode on endpoint networks. Not as secure as cryptographic alternatives, but simple, prevents most remote DoS attacks and better than nothing.
This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed.
Nnot a good idea to send such e-mail to a mailing list with public archives ;-) . -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On 06.09.2013 22:20, Ondrej Zajicek wrote:
Although it could worked if OSes offered socket-specific API for configuring IPSec, but AFAIK it is usually needed to configure system-wide IPSec policy database, which is problematic from routing software POV.
Their is such an API for FreeBSD. netcat and inetd include examples of how it can be used. I don't know if the API works for anything else than unicast UDP.
Hi. On 06.09.2013 22:47, Thomas Johnson wrote:
I'm looking around, and not seeing anything online regarding how to protect BIRD OSPFv3 with IPSec (at least on FreeBSD). I am able to configure IPSec transport mode to protect unicast traffic between routers; but multicast traffic is still transmitted without AH.
A number of sources seem to be setting up a GRE/IPSec tunnel between routers, and running OSPF on that interface, facilitating multicast traffic. That seems counter to performance though, wouldn't data traffic then [needlessly] use the tunnel? Another thought I had was to configure all OSPF interfaces as NBMA, making OSPF traffic easier to protect.
If you are running ospf inside your own network then there is probably no need to encrypt it with ipsec. If you are running ospf in a WAN environment, you probaby run it inside gre/gif tunnels (which you use for some sort of VPNs), then their traffic should be encrypted too. I definitely cannot imagine an environment with IPSEC encrypting ospf, but without any sort of VPN and any other VPNed traffic. Cisco/Juniper equipment also can run an ipsec tunnel in a form of an interface capable running dynamic routing protocols (for same purpose as the gre/gif in FreeBSD). Linux is capable of this too, as I heard. FreeBSD cannot do this; so far noone seems to be interested in implementing this. Eugene.
participants (4)
-
Eugene M. Zheganin -
Jan Bramkamp -
Ondrej Zajicek -
Thomas Johnson