if_ipsec(4) and IKEv1 [security/ipsec-tools, racoon.conf]

[Harry Schmalzbauer]

Bezüglich Andrey V. Elsukov's Nachricht vom 27.02.2018 11:50 (localtime):
> On 27.02.2018 12:56, Harry Schmalzbauer wrote:
>>  Hello,
>>
>> I'm out of ideas how to quick-start with if_ipsec(4) and IKEv1.
>>
>> I'm familar with security/ipsec-tools, but I couldn't find out how
>> racoon(8) would interact with cloned if_ipsec(4) interfaces yet.
> 
> You need to manually configure if_ipsec interface, i.e. assign tunnel
> addresses and bring it up. After that you need to configure racoon to
> reply for ACQUIRE messages when some traffic will go trough configured
> tunnel. So, you configure if_ipsec tunnel and it creates security
> policies, these policies will produce ACQUIRE requests to racoon and
> racoon should reply and this will produce needed security associations.
> 
>> Also, how to tell racoon(8) to generate such tunnel interfaces, hence
>> policies?
>> I guess the latter isn't implemented in racoon(8) (yet).
> 
> I think there are not any IKE daemons that can do this.
> 
>> But is racoon(8) supposed to work with static policies generated by
>> if_ipsec(4)?
> 
> Yes, at least for one tunnel it worked for me. Probably it is possible
> for several tunnels too.

Thank you very much for your explanation!

Unfortunately, I couldn't get the P2P idea behind if_ipsec(4) and I
tought I'd just need a few minutes to switch from policy based tunnels
to route based – local brain contraints seem to require me much more time...

My intention was to incorporate ALTQ for ESP payload.
So my idea was, that I have if_ipsec(4) and utilize pf's queue feature.
But I have to stop here since I need time to think about if_ipsec(4).


Maybe others have similar questions, so I just post them at this point,
and because I will have forgotten next week otherwise:

Is the P2P definition (ifconfig ipsecX ipnum/mask ipnum) meant as
transfer network?
If so, why would I want a local IP with a mask other than 0xffffffff?
And why should the destination belong to the same subnet in that case?
I'm completely missing something here...

Also, I don't understand why if_ipsec(4) generates ipsec policies
defined as 0.0.0.0/0[any] 0.0.0.0/0[any].
For sure, that's handled differently than the policies I'm aware about,
because there's scope=ifnet and ifname, but I need some time to
elaborate the reasons for the way if_ipsec(4) is how it is.

Are there any 3rd-vendor papers, describing a similar implementation
convention?

Thanks,

-Harry