Re: [RFC/RFT] projects/ipsec

2017-02-06 Thread Andrey V. Elsukov
On 11.12.2016 02:07, Andrey V. Elsukov wrote: I am pleased to announce that projects/ipsec, that I started several months ago is ready for testing and review. The main goals were: * rework locking to make IPsec code more friendly for concurrent processing; * make lookup in SADB/SPDB faste

Re: [RFC/RFT] projects/ipsec

2017-01-13 Thread Alexandr Krivulya
11.12.2016 01:07, Andrey V. Elsukov пишет: Hi All, I am pleased to announce that projects/ipsec, that I started several months ago is ready for testing and review. The main goals were: * rework locking to make IPsec code more friendly for concurrent processing; * make lookup in SADB/S

Re: [RFC/RFT] projects/ipsec

2017-01-10 Thread Andrey V. Elsukov
Hi All, I ported the changes from projects/ipsec to stable/11 branch. So, if it is more suitable for testing, please, welcome. You can checkout the sources from github: https://github.com/bu7cher/freebsd/tree/stable/11 Also I made the standalone patch: https://people.freebsd.org

Re: [RFC/RFT] projects/ipsec

2017-01-09 Thread Andrey V. Elsukov
On 09.01.2017 14:38, Bjoern A. Zeeb wrote: On 27 Dec 2016, at 10:18, Andrey V. Elsukov wrote: So, if there will no objection, I'll merge projects/ipsec into head/ within two weeks. I still keep seeing almost daily changes to the branch and am having a hard time to convince myself to do a prop

Re: [RFC/RFT] projects/ipsec

2017-01-09 Thread Bjoern A. Zeeb
On 27 Dec 2016, at 10:18, Andrey V. Elsukov wrote: So, if there will no objection, I'll merge projects/ipsec into head/ within two weeks. I still keep seeing almost daily changes to the branch and am having a hard time to convince myself to do a proper review that way. I would very much pre

Re: [RFC/RFT] projects/ipsec

2016-12-27 Thread Ermal Luçi
On Tue, Dec 27, 2016 at 6:10 AM, Andrey V. Elsukov wrote: > On 27.12.2016 16:15, Jim Thompson wrote: > >> In it's initial state if_ipsec allows to use only one set of >>> encryption parameters (because only one sainfo anonyumous is >>> possible), so at this time it doesn't allow to create multipl

Re: [RFC/RFT] projects/ipsec

2016-12-27 Thread Andrey V. Elsukov
On 27.12.2016 16:15, Jim Thompson wrote: In it's initial state if_ipsec allows to use only one set of encryption parameters (because only one sainfo anonyumous is possible), so at this time it doesn't allow to create multiple tunnels with VPN hubs that use different cipers and/or transform sets,

Re: [RFC/RFT] projects/ipsec

2016-12-27 Thread Jim Thompson
> In it's initial state if_ipsec allows to use only one set of encryption > parameters (because only one sainfo anonyumous is possible), so at this time > it doesn't allow to create multiple tunnels with VPN hubs that use different > cipers and/or transform sets, but as far as I understand this

Re: [RFC/RFT] projects/ipsec

2016-12-27 Thread Andrey V. Elsukov
On 11.12.2016 02:07, Andrey V. Elsukov wrote: Hi All, I am pleased to announce that projects/ipsec, that I started several months ago is ready for testing and review. The main goals were: * rework locking to make IPsec code more friendly for concurrent processing; * make lookup in SADB/S

Re: [RFC/RFT] projects/ipsec

2016-12-14 Thread Eugene M. Zheganin
Hi, On 11.12.2016 4:07, Andrey V. Elsukov wrote: Hi All, I am pleased to announce that projects/ipsec, that I started several months ago is ready for testing and review. The main goals were: * rework locking to make IPsec code more friendly for concurrent processing; * make lookup in

Re: [RFC/RFT] projects/ipsec

2016-12-13 Thread Olivier Cochard-Labbé
On Sun, Dec 11, 2016 at 12:07 AM, Andrey V. Elsukov wrote: > Hi All, > > I am pleased to announce that projects/ipsec, that I started several > months ago is ready for testing and review. > The main goals were: > * rework locking to make IPsec code more friendly for concurrent > processing;

Re: [RFC/RFT] projects/ipsec

2016-12-11 Thread Andrey V. Elsukov
On 11.12.2016 18:28, Slawa Olhovchenkov wrote: >> I already described how it works and that you can configure what >> you want. >> >> https://lists.freebsd.org/pipermail/freebsd-net/2016-December/046616.html > > This is don't clean about "we can't handle the returned packets". > If we can handle

Re: [RFC/RFT] projects/ipsec

2016-12-11 Thread Slawa Olhovchenkov
On Sun, Dec 11, 2016 at 03:53:49PM +0300, Andrey V. Elsukov wrote: > On 11.12.2016 15:50, Slawa Olhovchenkov wrote: > >> You can specify what you want, but this just will not work as you > >> expect. A router usually must not handle all TCP sessions that it > > > > You mean forward to IPSec syste

Re: [RFC/RFT] projects/ipsec

2016-12-11 Thread Andrey V. Elsukov
On 11.12.2016 15:50, Slawa Olhovchenkov wrote: >> You can specify what you want, but this just will not work as you >> expect. A router usually must not handle all TCP sessions that it > > You mean forward to IPSec system only packets with DST_IP = my_ip? > I that case, why you talk only about not

Re: [RFC/RFT] projects/ipsec

2016-12-11 Thread Slawa Olhovchenkov
On Sun, Dec 11, 2016 at 03:19:24PM +0300, Andrey V. Elsukov wrote: > On 11.12.2016 15:15, Slawa Olhovchenkov wrote: > >> IPsec is a set of protocol handlers - ESP/AH/IPcomp. Inbound packets are > >> handled by security association with given destination address and SPI. > >> If returned packets ar

Re: [RFC/RFT] projects/ipsec

2016-12-11 Thread Andrey V. Elsukov
On 11.12.2016 15:15, Slawa Olhovchenkov wrote: >> IPsec is a set of protocol handlers - ESP/AH/IPcomp. Inbound packets are >> handled by security association with given destination address and SPI. >> If returned packets aren't destined to your address, protocol handlers >> will not handle them. >

Re: [RFC/RFT] projects/ipsec

2016-12-11 Thread Slawa Olhovchenkov
On Sun, Dec 11, 2016 at 03:09:28PM +0300, Andrey V. Elsukov wrote: > On 11.12.2016 14:58, Slawa Olhovchenkov wrote: > >> No. An encapsulated by gif(4) packet is considered as own packet. The > >> described change is related to transport mode policies, that are match > >> forwarded packets, i.e. wh

Re: [RFC/RFT] projects/ipsec

2016-12-11 Thread Andrey V. Elsukov
On 11.12.2016 14:58, Slawa Olhovchenkov wrote: >> No. An encapsulated by gif(4) packet is considered as own packet. The >> described change is related to transport mode policies, that are match >> forwarded packets, i.e. when source and destination addresses are not >> our own. In this case we can'

Re: [RFC/RFT] projects/ipsec

2016-12-11 Thread Slawa Olhovchenkov
On Sun, Dec 11, 2016 at 02:33:43PM +0300, Andrey V. Elsukov wrote: > On 11.12.2016 12:13, Eugene Grosbein wrote: > > 11.12.2016 6:07, Andrey V. Elsukov пишет: > > > >> * use transport mode IPsec for forwarded IPv4 packets now unsupported. > >> This matches the IPv6 behavior, and since we can hand

Re: [RFC/RFT] projects/ipsec

2016-12-11 Thread Andrey V. Elsukov
On 11.12.2016 12:13, Eugene Grosbein wrote: > 11.12.2016 6:07, Andrey V. Elsukov пишет: > >> * use transport mode IPsec for forwarded IPv4 packets now unsupported. >> This matches the IPv6 behavior, and since we can handle the replies, I >> think it is useless. > > Does it include a case of packe

Re: [RFC/RFT] projects/ipsec

2016-12-11 Thread Eugene Grosbein
11.12.2016 6:07, Andrey V. Elsukov пишет: * use transport mode IPsec for forwarded IPv4 packets now unsupported. This matches the IPv6 behavior, and since we can handle the replies, I think it is useless. Does it include a case of packets going from LAN and forwarded into gif(4) tunnel connec