Re: example of ipsecif and racoon?

Some more notes, since I've got something working but not on NetBSD.

On Fri, 27 Sept 2024 at 16:28, Andrew Cagney <[email protected]> wrote:
>
> On Fri, 27 Sept 2024 at 16:03, Hubert Feyrer <[email protected]> wrote:
> >
> > Hi,
> >
> > does https://www.netbsd.org/docs/network/ipsec/ help?
>
> No (but that does remind me, the example section needs an update).
>
> These are the references I'm using:
>
> https://man.netbsd.org/ipsecif.4
> - the msgid can't be manipulated
> - the auto-generated policy is implicitly bound to the physical
> interface; which is, cough, old school

Given the packet flow:

  clear -> ipsecL -> physL -> ESP -> physR-> ipsecR -> clear

To me, old school is where the policy matches physL->physR while new
school is matching ipsecL->ipsecR.  With the former the acquire
indicates the need for an SA between physL->physR rather than getting
a packet to flow ipsecL->ipsecR.  When negotiating a Child SA it's the
latter that is needed.  I suspect this is an artifcact of the original
KAME design.

> https://man.freebsd.org/cgi/man.cgi?query=if_ipsec&sektion=4
> - the msgid can be manipulated directly
> - the auto-generated policy is bound to the ipsecN interface, and not
> the physical interface

Here, when the ipsec interface and kernel state (SA) are created they
are given the same msg id (by IKE say).
The kernel generates the kernel policy (SPD).

> https://man.openbsd.org/sec
> - which doesn't even bother with the policy; presumably it is left to
> the IKE daemon which, hopefully, binds it to the ipsec interface

Here, when creating the kernel state (SA), the ipsec interface it
needs to bind to is specified directly using sadb_x_xfrm_iface.
By avoiding policy this seems more robust (although to be honest I
find the struct's fields weird - it passes N from secN and not
if_nametoindex(), and for direction it uses ISIP_DIRECTION_* and not
IPSEC_DIRECTION_*).

> ip link add dev ipsec1 type xfrm dev eth1 if_id 0x1
> - again policy is left to the IKE daemon and bound to the ipsec interface

With linux they introduced if_id.  They also introduced marks but I'm
not sure if that is to get around an artifact of the design or solve a
general problem.

Coming back to NetBSD, I think the ipsecif(4) code needs to be
extended along the lines of one of the above.

Andrew