Hi! What is the plan for IPsec with regards to OSPFv3? Is it part of roadmap? If not a roadmap item, what is the recommended way to get IPsec support for OSPFv3 with bird? libreswan? Thanks, Kenth
On Mon, Jun 17, 2019 at 10:59:00AM +0000, Kenth Eriksson wrote:
Hi!
Hi Sorry for late reply, i finally got to answer some mails i missed in the past due to my mail delivery issue: https://bird.network.cz/pipermail/bird-users/2019-July/013549.html
What is the plan for IPsec with regards to OSPFv3? Is it part of roadmap?
We do not have any plans for IPsec for OSPFv3. AFAIK, IPsec is not well suited for multicast and RFC 7166 is a better solution for OSPFv3. OTOH, it is something that seems to be easy to implement, as it is just a few syscalls to configure manual SA entries. So patches are welcome.
If not a roadmap item, what is the recommended way to get IPsec support for OSPFv3 with bird? libreswan?
Where was setkey command from ipsec-tools, which would likely allow configuring manual SA entries necessary for OSPFv3, but it seems to be abandoned. I do not think that libreswan or other dynamic keying daemons are applicable for OSPFv3 due to its multicast nature. -- 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."
Hi, Dynamic routig works works good with route based ipsec. Some time I wrote a blog article about ipsec and bgp with bird. See blog.sys4.de Michael Am 8. August 2019 15:04:14 MESZ schrieb Ondrej Zajicek <santiago@crfreenet.org>:
On Mon, Jun 17, 2019 at 10:59:00AM +0000, Kenth Eriksson wrote:
Hi!
Hi
Sorry for late reply, i finally got to answer some mails i missed in the past due to my mail delivery issue:
https://bird.network.cz/pipermail/bird-users/2019-July/013549.html
What is the plan for IPsec with regards to OSPFv3? Is it part of roadmap?
We do not have any plans for IPsec for OSPFv3. AFAIK, IPsec is not well suited for multicast and RFC 7166 is a better solution for OSPFv3.
OTOH, it is something that seems to be easy to implement, as it is just a few syscalls to configure manual SA entries. So patches are welcome.
If not a roadmap item, what is the recommended way to get IPsec support for OSPFv3 with bird? libreswan?
Where was setkey command from ipsec-tools, which would likely allow configuring manual SA entries necessary for OSPFv3, but it seems to be abandoned.
I do not think that libreswan or other dynamic keying daemons are applicable for OSPFv3 due to its multicast nature.
-- 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."
-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
On Thu, 2019-08-08 at 15:04 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Mon, Jun 17, 2019 at 10:59:00AM +0000, Kenth Eriksson wrote:
Hi!
Hi
Sorry for late reply, i finally got to answer some mails i missed in the past due to my mail delivery issue:
What is the plan for IPsec with regards to OSPFv3? Is it part of roadmap?
We do not have any plans for IPsec for OSPFv3. AFAIK, IPsec is not well suited for multicast and RFC 7166 is a better solution for OSPFv3.
It's great that bird supports RFC 7166, but unfortunately interop will be limited. AFAIK, Juniper does not support RFC 7166. Cisco seems to have partial support for RFC 7166.
OTOH, it is something that seems to be easy to implement, as it is just a few syscalls to configure manual SA entries. So patches are welcome.
A few syscalls, can you elaborate? I thought you need iproute2 to setup 'ip xfrm' policies? Or you mean it can be done thru netlink layer directly?
If not a roadmap item, what is the recommended way to get IPsec support for OSPFv3 with bird? libreswan?
Where was setkey command from ipsec-tools, which would likely allow configuring manual SA entries necessary for OSPFv3, but it seems to be abandoned.
I do not think that libreswan or other dynamic keying daemons are applicable for OSPFv3 due to its multicast nature.
-- 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 Mon, Aug 19, 2019 at 11:05:50AM +0000, Kenth Eriksson wrote:
On Thu, 2019-08-08 at 15:04 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Mon, Jun 17, 2019 at 10:59:00AM +0000, Kenth Eriksson wrote:
Hi!
Hi
Sorry for late reply, i finally got to answer some mails i missed in the past due to my mail delivery issue:
What is the plan for IPsec with regards to OSPFv3? Is it part of roadmap?
We do not have any plans for IPsec for OSPFv3. AFAIK, IPsec is not well suited for multicast and RFC 7166 is a better solution for OSPFv3.
It's great that bird supports RFC 7166, but unfortunately interop will be limited. AFAIK, Juniper does not support RFC 7166. Cisco seems to have partial support for RFC 7166.
OTOH, it is something that seems to be easy to implement, as it is just a few syscalls to configure manual SA entries. So patches are welcome.
A few syscalls, can you elaborate? I thought you need iproute2 to setup 'ip xfrm' policies? Or you mean it can be done thru netlink layer directly?
Yes, setting SA/SP entries directly through netlink. There is already code sysdep/bsd/setkey.h that adds SA entries for TCP MD5 signature mechanism on BSD. I guess adding SA entries for IPsec is not that much different. Of course, on Linux it would use Netlink instead of PF_KEY socket. -- 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."
participants (3)
-
Kenth Eriksson -
Michael Schwartzkopff -
Ondrej Zajicek